Message-ID: <20090410112546.GD21506@elte.hu>
Date:	Fri, 10 Apr 2009 13:25:46 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Pavel Machek <pavel@....cz>, Avi Kivity <avi@...hat.com>
Cc:	mingo@...hat.com, hpa@...or.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


* Pavel Machek <pavel@....cz> wrote:

> On Fri 2009-04-10 12:39:34, Ingo Molnar wrote:
> > 
> > * Pavel Machek <pavel@....cz> wrote:
> > 
> > > Hi!
> > > 
> > > > x86, setup: "glove box" BIOS calls -- infrastructure
> > > > 
> > > > Impact: new interfaces (not yet used)
> > > > 
> > > > For all the platforms out there, there is an infinite number of buggy
> > > > BIOSes.  This adds infrastructure to treat BIOS interrupts more like
> > > > toxic waste and "glove box" them -- we switch out the register set,
> > > > perform the BIOS interrupt, and then restore the previous state.
> > > > 
> > > > LKML-Reference: <49DE7F79.4030106@...or.com>
> > > > Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
> > > > Cc: Pavel Machek <pavel@....cz>
> > > 
> > > Sounds quite sane. Disadvantage is that we will no longer detect 
> > > those buggy BIOSen.
> > 
> > I'd call that an advantage: sandboxing BIOS calls as much as we can 
> > and trusting all data from it as if it were a random packet from the 
> > Internet is the only sane way forward IMHO.
> 
> Well, difference is that you can defend against arbitrary network 
> packet, but you can't defend against arbitrarily broken BIOS. If 
> it loops forever, or overwrites random memory place, we lost...

We could protect against random memory corruption too, if it ever 
became a widespread problem: by executing the BIOS call in a virtual 
machine. (We can probably use the KVM code to properly emulate big 
real mode, etc.)

That way we can monitor and warn about any undue access patterns.

The solution Peter did here sandboxes the CPU context: which was 
observed to be randomly corrupted by BIOSen and depending on 
register layout details of other OSs (Windows mostly) it might not 
have caused trouble there.

Memory corruption would be noticed under Windows too, so while it 
does show up every now and then, it rarely remains unfixed. Register 
corruptions will stay unfixed forever if they dont affect Windows 
(which they often dont) - so these are far more of a priority to 
sandbox.

> > If we really care we could put in checks for unexpected register 
> > state changes ... but is it worth the trouble?
> 
> So maybe we do need to cooperate with BIOS people, making them fix 
> their code. Checking for unexpected changes would certainly be 
> good idea for firmware testing kit... and it would probably make 
> sense to complain during regular boot, too.

"BIOS people" are operating in a completely different culture. Time 
to market, hardware workarounds, short-term differentiators, secret 
bootstrap sequences and code compactness are king in that space. 
Code quality is dead last in the list. I strongly doubt that given 
the radically conflicting priorities a reasonable dialogue can be 
established.

Reasonable dialogue could be established with efforts that turn 
Linux into a replacement of the firmware: CoreBoot a'ka LinuxBIOS. 
Having an end-to-end Linux solution for all things bootstrap is a 
very strong concept IMHO. For various reasons that relationship is 
not unstrained either, unfortunately.

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