[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49E1FD15.50805@redhat.com>
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