From mboxrd@z Thu Jan 1 00:00:00 1970 From: Markus Armbruster Subject: Re: [SeaBIOS] KVM call agenda for 2013-05-28 Date: Wed, 29 May 2013 18:35:56 +0200 Message-ID: <87vc61spzn.fsf@blackfin.pond.sub.org> References: <20130523124132.GA18596@redhat.com> <20130528235309.GA31648@morn.localdomain> <51A5C117.6000609@redhat.com> <871u8p92v8.fsf@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain Cc: Gerd Hoffmann , "Kevin O'Connor" , KVM devel mailing list , Juan Quintela , seabios@seabios.org, qemu-devel qemu-devel , "Michael S. Tsirkin" , dwmw2@infradead.org To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:37084 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757259Ab3E2Qgd (ORCPT ); Wed, 29 May 2013 12:36:33 -0400 In-Reply-To: <871u8p92v8.fsf@codemonkey.ws> (Anthony Liguori's message of "Wed, 29 May 2013 11:18:03 -0500") Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori writes: > Gerd Hoffmann 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. [...]