lkml.org 
[lkml]   [2008]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH RFC] x86: check for and defend against BIOS memory corruption
Hugh Dickins wrote:
>
> hpa introduced the 64k idea, and we've all been repeating it;
> but I've not heard the reasoning behind it. Is it a fundamental
> addressing limitation within the BIOS memory model? Or a case
> that Windows treats the bottom 64k as scratch, so BIOS testers
> won't notice if they corrupt it?
>
> The two instances of corruption we've been studying have indeed
> been below 64k (one in page 8 and one in page 11), but that's
> because they were both recognizable corruptions of direct map PMDs.
>
> If there is not a very strong justification for that 64k limit,
> then I don't think this approach will be very useful, and we should
> simply continue to rely on analyzing corruption when it appears, and
> recommend memmap= as a way of avoiding it once analyzed. If there
> is a strong justification for it, please dispel my ignorance!
>

The 64K number was empirical, of course. The bottom 64K is somewhat
special, however, in that it is what you can address in real mode (as
opposed to big real mode) with your segments parked at zero, so you end
up with something approaching a flat real mode. Especially the first
32K (below 0x7c00) are frequently used by various BIOS items, but I
believe the corruption observed was at 0x8000, so it's beyond even this
first barrier.

Obviously, it's extremely hard to predict where BIOS vendors will have
choosen to scribble, but the observations in this particular case seemed
to finger this particular area.

-hpa


\
 
 \ /
  Last update: 2008-08-29 19:09    [W:0.106 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site