Re: [PATCH RFC] x86: check for and defend against BIOS memory corruption

Ingo Molnar
2008-08-29T06:46:16Z

* Rafał Miłecki <zajec5@gmail.com> wrote:

> 2008/8/28 Jeremy Fitzhardinge <jeremy@goop.org>:
> > Some BIOSes have been observed to corrupt memory in the low 64k. This
> > patch does two things:
> > - Reserves all memory which does not have to be in that area, to
> > prevent it from being used as general memory by the kernel. Things
> > like the SMP trampoline are still in the memory, however.
> > - Clears the reserved memory so we can observe changes to it.
> > - Adds a function check_for_bios_corruption() which checks and reports on
> > memory becoming unexpectedly non-zero. Currently it's called in the
> > x86 fault handler, and the powermanagement debug output.
> >
> > RFC: What other places should we check for corruption in?
> >
> > [ Alan, Rafał: could you check you see:
> > 1: corruption messages
> > 2: no crashes
> > Thanks -J
> > ]
>
> I was trying my best to crash system with this patch applied and failed :)
>
> Works great.
>
> Just wonder if I should expect any printk from
> check_for_bios_corruption? I do not see any:
>
> zajec@sony:~> dmesg | grep -i corr
> scanning 2 areas for BIOS corruption

that's _very_ weird.

maybe the BIOS expects _zeroes_ somewhere? Do you suddenly see crashes
if you change this line in Jeremy's patch:

+ memset(__va(addr), 0, size);

to something like:

+ memset(__va(addr), 0x55, size);

If this does not tickle any messages either, then maybe the problem is
in the identity of the entities we allocate in the first 64K. Is there a
list of allocations that go there when Jeremy's patch is not applied?

but ... i think with an earlier patch you saw corruption, right?
Far-fetched idea: maybe it's some CPU erratum during suspend/resume that
corrupts pagetables if the pagetables are allocated in the first 64K of
RAM? In that case we should use a bootmem allocation for pagetables that
give a minimum address of 64K.

Ingo