lkml.org 
[lkml]   [2008]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-10-05 21:07    [W:0.056 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site