* Pavel Machek <pavel@xxxxxx> wrote: > On Fri 2009-04-10 12:39:34, Ingo Molnar wrote: > > > > * Pavel Machek <pavel@xxxxxx> 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@xxxxxxxxx> > > > > Signed-off-by: H. Peter Anvin <hpa@xxxxxxxxxxxxxxx> > > > > Cc: Pavel Machek <pavel@xxxxxx> > > > > > > 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-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|