Messages in this thread | | | Date | Sun, 5 Oct 2008 21:04:04 +0200 | From | "Vegard Nossum" <> | Subject | Re: [PATCH -tip] kmemcheck: fix crash in PnP BIOS calls |
| |
Hi,
On Sun, Oct 5, 2008 at 8:15 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote: >> It turns out that BIOS calls are made with a different code segment. So >> when kmemcheck tries to dereference the EIP/RIP (using the kernel data >> segment register), we get the unhandled page fault. >> >> I think we can solve this by verifying (in the page fault handler) that >> the faulting code is using the kernel CS. > > That isn't an entirely safe assumption and some services such as BIOS32 > are 32bit. Would it be better wrap BIOS calls with a kmemcheck wrapper > which changes the way kmemcheck works/dumps stuff and also gives you a > hook after BIOS calls to do stuff like corruption scans or change > detection on kernel pages ?
Thanks for the heads-up.
I think BIOS32 in particular is safe. I was looking at for instance check_pcibios() in arch/x86/pci/pcbios.c. It doesn't change any segment registers, so it means that whatever the actual code address is, we should be able to dereference it (i.e. inspect the BIOS code) without taking additional page faults.
And this is really all we need; BIOS code running with the kernel segments can even access kernel memory and kmemcheck will be able to catch those reads/writes just fine. I'm not sure if the BIOS code can change segments (it would need to switch LDT/GDTs, I think), and even if it did, I find it unlikely that it would directly access kernel memory using these new segment registers. Do you happen to know of any such cases?
Vegard
-- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036
| |