linux-kernel - Re: [tip:x86/setup] x86, setup: "glove box" BIOS calls -- infrastructure

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 21:57:14 +0300
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"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
Subject: Re: [tip:x86/setup] x86, setup: "glove box" BIOS calls --	infrastructure

Ingo Molnar wrote:
>> Sure, go ahead and wrap them in some kind of "save and restore all 
>> registers" wrapping, but nothing fancier than that. It would just 
>> be overkill, and likely to break more than it fixes.
>>     
>
> Yeah. I only brought up the virtualization thing as a hypothetical: 
> "if" corrupting the main OS ever became a widespread problem. Then i 
> made the argument that this is unlikely to happen, because Windows 
> will be affected by it just as much. (while register state 
> corruptions might go unnoticed much more easily, just via the random 
> call-environment clobbering of registers by Windows itself.)
>
> The only case where i could see virtualization to be useful is the 
> low memory RAM corruption pattern that some people have observed. 
>   

You could easily check that by checksumming pages (or actually copying 
them to high memory) before the call, and verifying after the call.

> The problem with it, it happens on s2ram transitions, and that is 
> driven by SMM mainly - which is a hypervisor sitting on top of all 
> the other would-be-hypervisors and thus not virtualizable.
>   

AMD in fact has a chapter called "Containerizing Platform SMM" or words 
to the effect, which describes how to take a running system and drop its 
SMM mode into a virtualization container.  I made a point of skipping 
over those pages with my eyes closed so I can't tell you how incredibly 
complex it is.

It's probably even doable on Intel, though much more difficult, due to 
Intel not supporting big real mode in a guest, and most SMM code using 
it to access memory.  You'd end up running most of the code in the 
emulator, and performing the transitions by hand.

Of course, the VMM has to be careful not to trigger SMM itself, or much 
merriment ensues.

> Which leaves us without a single practical case. So it's not going 
> to happen.
>   

I don't think the effort is worth the benefit in this case, but there 
actually is an interesting use case for this.  SMM is known to be 
harmful to deterministic replay games and to real time response.  If we 
can virtualize SMM, we can increase the range of hardware on which the 
real time kernel is able to deliver real time guarantees.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

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