Re: [PATCH -tip] kmemcheck: fix crash in PnP BIOS calls

["Vegard Nossum" <vegard.nossum@gmail.com>]

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