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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 5 Oct 2008 21:04:04 +0200
From:	"Vegard Nossum" <vegard.nossum@...il.com>
To:	"Alan Cox" <alan@...rguk.ukuu.org.uk>
Cc:	"Ingo Molnar" <mingo@...e.hu>,
	"Pekka Enberg" <penberg@...helsinki.fi>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH -tip] kmemcheck: fix crash in PnP BIOS calls

Hi,

On Sun, Oct 5, 2008 at 8:15 PM, Alan Cox <alan@...rguk.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/