Messages in this thread | | | Date | Fri, 29 Aug 2008 08:45:40 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH RFC] x86: check for and defend against BIOS memory corruption |
| |
* 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |