qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28


From: Markus Armbruster
Subject: Re: [Qemu-devel] [SeaBIOS] KVM call agenda for 2013-05-28
Date: Wed, 29 May 2013 18:35:56 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

Anthony Liguori <address@hidden> writes:

> Gerd Hoffmann <address@hidden> writes:
>
>> On 05/29/13 01:53, Kevin O'Connor wrote:
>>> On Thu, May 23, 2013 at 03:41:32PM +0300, Michael S. Tsirkin wrote:
>>>> Juan is not available now, and Anthony asked for
>>>> agenda to be sent early.
>>>> So here comes:
>>>>
>>>> Agenda for the meeting Tue, May 28:
>>>>
>>>> - Generating acpi tables
>>> 
>>> I didn't see any meeting notes, but I thought it would be worthwhile
>>> to summarize the call.  This is from memory so correct me if I got
>>> anything wrong.
>>> 
>>> Anthony believes that the generation of ACPI tables is the task of the
>>> firmware.  Reasons cited include security implications of running more
>>> code in qemu vs the guest context,
>>
>> I fail to see the security issues here.  It's not like the apci table
>> generation code operates on untrusted input from the guest ...
>
> But possibly untrusted input from a malicious user.  You can imagine
> something like a IaaS provider that let's a user input arbitrary values
> for memory, number of nics, etc.
>
> It's a stretch of an example, I agree, but the general principle I think
> is sound:  we should push as much work as possible to the least
> privileged part of the stack.  In this case, firmware has much less
> privileges than QEMU.

Firmware runs in a primitive, unforgiving environment, and should do as
little as humanly possible.  For an instructive example of deviating
from that rule, check out UEFI.

[...]



reply via email to

[Prev in Thread] Current Thread [Next in Thread]