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