Anthony Liguori firstname.lastname@example.org writes:
Gerd Hoffmann email@example.com 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.