From: Ingo Molnar <mingo@elte.hu>
To: Pavel Machek <pavel@ucw.cz>, Avi Kivity <avi@redhat.com>
Cc: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, hpa@linux.intel.com, rjw@sisk.pl,
linux-tip-commits@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [tip:x86/setup] x86, setup: "glove box" BIOS calls -- infrastructure
Date: Fri, 10 Apr 2009 13:25:46 +0200 [thread overview]
Message-ID: <20090410112546.GD21506@elte.hu> (raw)
In-Reply-To: <20090410104648.GA31516@elf.ucw.cz>
* Pavel Machek <pavel@ucw.cz> wrote:
> On Fri 2009-04-10 12:39:34, Ingo Molnar wrote:
> >
> > * Pavel Machek <pavel@ucw.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@zytor.com>
> > > > Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> > > > Cc: Pavel Machek <pavel@ucw.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
next prev parent reply other threads:[~2009-04-10 11:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 23:06 [PATCH 0/6] x86, setup: "glove box" BIOS interrupts H. Peter Anvin
2009-04-09 23:12 ` [tip:x86/setup] x86, setup: "glove box" BIOS calls -- infrastructure H. Peter Anvin
2009-04-10 8:04 ` Pavel Machek
2009-04-10 10:39 ` Ingo Molnar
2009-04-10 10:46 ` Pavel Machek
2009-04-10 11:25 ` Ingo Molnar [this message]
2009-04-10 11:38 ` Pavel Machek
2009-04-10 11:49 ` Ingo Molnar
2009-04-11 16:13 ` Avi Kivity
2009-04-12 5:21 ` H. Peter Anvin
2009-04-12 14:01 ` Ingo Molnar
2009-04-12 14:39 ` Avi Kivity
2009-04-12 14:59 ` Linus Torvalds
2009-04-12 16:33 ` Ingo Molnar
2009-04-12 18:57 ` Avi Kivity
2009-04-13 4:16 ` Ingo Molnar
2009-04-13 4:24 ` Ingo Molnar
2009-04-13 16:27 ` H. Peter Anvin
2009-04-13 16:57 ` Pavel Machek
2009-04-13 17:00 ` H. Peter Anvin
2009-04-13 18:34 ` Alan Jenkins
2009-04-13 19:08 ` H. Peter Anvin
2009-04-14 0:06 ` Ingo Molnar
2009-04-14 4:42 ` H. Peter Anvin
2009-04-14 9:03 ` Jeremy Fitzhardinge
2009-04-14 15:59 ` H. Peter Anvin
2009-04-13 6:44 ` Avi Kivity
2009-04-12 17:51 ` H. Peter Anvin
2009-04-10 17:17 ` H. Peter Anvin
2009-04-10 17:19 ` H. Peter Anvin
2009-04-09 23:13 ` [tip:x86/setup] x86, setup: "glove box" BIOS interrupts in the core boot code H. Peter Anvin
2009-04-09 23:13 ` [tip:x86/setup] x86, setup: "glove box" BIOS interrupts in the APM code H. Peter Anvin
2009-04-09 23:13 ` [tip:x86/setup] x86, setup: "glove box" BIOS interrupts in the EDD code H. Peter Anvin
2009-04-09 23:13 ` [tip:x86/setup] x86, setup: "glove box" BIOS interrupts in the MCA code H. Peter Anvin
2009-04-09 23:13 ` [tip:x86/setup] x86, setup: "glove box" BIOS interrupts in the video code H. Peter Anvin
2009-04-10 8:05 ` Pavel Machek
2009-04-10 18:05 ` [PATCH 0/6] x86, setup: "glove box" BIOS interrupts Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090410112546.GD21506@elte.hu \
--to=mingo@elte.hu \
--cc=avi@redhat.com \
--cc=hpa@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).