"Kevin O'Connor" <email@example.com>
wrote on 08/26/2014 12:49:57 PM:
> From: "Kevin O'Connor" <firstname.lastname@example.org>
> To: Stefan Berger/Watson/IBM@IBMUS
> Cc: email@example.com, Stefan Berger <firstname.lastname@example.org>
> Date: 08/26/2014 12:50 PM
> Subject: Re: [SeaBIOS] [PATCH v8 0/8] Add TPM
support to SeaBIOS
> On Tue, Aug 26, 2014 at 12:07:54PM -0400, Stefan Berger wrote:
> > "Kevin O'Connor" <email@example.com> wrote on
08/26/2014 11:19:14 AM:
> > > If this is the intent, can't we just pass a flag (via fw_cfg)
> > > QEMU command line to SeaBIOS to force a clear? That
is, the guest
> > > software can't manipulate the QEMU command line (or its
> > > entries) and so the ability to set a flag there is proof
> > > presence. (Access to the virtual machine disk images
> > > machine command line is as close to "physical"
as one can get.)
> > One would need at least a flag to indicate that the BIOS automatically
> > give up ownership of the TPM.
> > Giving up ownership also means that the device automatically
> > disabled and deactivated. The BIOS would then
> > presumably automatically have to enabled and activate the TPM
> > without user interaction.
> Off the top of my head, I would think one could use a single
> multi-purpose state indicator (eg, "TPM is enabled, active, ownable",
> "TPM is enabled, active, non-ownable", "TPM is disabled,
> cleared, unownable", etc.). I'd guess there are several
> that wouldn't make sense and the total list could be simplified.
> > The other aspect is that this extension propagates all the way
> > layers: libvirt would need an API and command
> > line tool extension just to set this flag and presumably
use the QEMU
> > monitor with a new command to indicate it.
> > You want to be able to do this in a cloud environment, you need
> > API and/or GUI support in your cloud stack for doing
> > just this... I doesn't seem to become a lot easier this
> Not easier. But I don't think adding this menu to SeaBIOS is
> solution either. As before, for the bulk of users it's just
> and for those rare users that do need it, it is not in a place they
> want it.
Let me approach this all the way from the cloud user
One can add a TPM to a VM via an attribute to the
image one wants to deploy. So having a TPM attached to a VM
would be an option. Libvirt can then create a slightly
different XML that instructs QEMU to show the SeaBIOS menu
IF a TPM is attached. If no TPM is attached, no menu
is shown, so no changes here. I find this a useable solution
that helps those that want a TPM to be attached to
the VM and leaves things as they are for those that don't.
OpenStack for example allows you to interact with
the VGA console that QEMU presents and where you have access
to the SeaBIOS menu. If one needs to interact with
the menu for example to release ownership of the TPM, then this would
be an occasion a user presses the F11 button to get
to the TPM menu and control it, otherwise the user can wait those
2 seconds for the auto-boot to start.
Having to interact with cloud CLI tools or libvirt
tools for setting the flags for what the BIOS
is supposed to do with the TPM the next time the VM
is warm-rebooted (cold boot presumably would not work)
doesn't sound that attractive. Besides that root gets
too much control over VMs with attached TPMs running on a
system if libvirt was to be extended with this kind
of support. You could then set the above mentioned flags and
see what happens when the VM gives up ownership the
next time it boots...