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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 12 Apr 2009 17:39:17 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	"H. Peter Anvin" <hpa@...or.com>, Pavel Machek <pavel@....cz>,
	mingo@...hat.com, linux-kernel@...r.kernel.org, tglx@...utronix.de,
	hpa@...ux.intel.com, rjw@...k.pl,
	linux-tip-commits@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [tip:x86/setup] x86, setup: "glove box" BIOS calls --	infrastructure

Ingo Molnar wrote:
> * H. Peter Anvin <hpa@...or.com> wrote:
>
>   
>> Avi Kivity wrote:
>>     
>>> kvm might help detecting these issues, but not in fixing them.  
>>> If you isolate the BIOS, then you've prevented corruption, but 
>>> you've also prevented it from doing whatever it is it was 
>>> supposed to do.  If you give it access to memory and the rest of 
>>> the system, then whatever evil it has wrought affects the system.
>>>
>>> You could try to allow the BIOS access to selected pieces of 
>>> memory and hardware, virtualizing the rest, but it seems to me it 
>>> would be more like a recipe for a giant headache that a solution.
>>>
>>>       
>> The main thing you could do is drop or virtualize memory accesses 
>> to RAM it should never access in the first place, like some BIOSes 
>> which scribble over random locations in low memory.
>>     
>
> it would be enough to get the information out. That way we could see 
> (from the access patterns) what the heck it is trying to do (did 
> someone rootkit the bios?), and what we can do about it. Trying to 
> contain it will likely break the BIOS and causes silent hangs with 
> no usable bug report left.
>   

Hmm, it's doable with the 1:1 mode; Andrea did some work on this.

However if the bios tries to do anything clever (like using SMM) things 
will fail pretty badly.

-- 
error compiling committee.c: too many arguments to function

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ