<br><tt><font size=2>"Kevin O'Connor" <kevin@koconnor.net>
wrote on 08/26/2014 11:19:14 AM:<br>
</font></tt>
<br><tt><font size=2>> <br>
> On Tue, Aug 26, 2014 at 10:42:31AM -0400, Stefan Berger wrote:<br>
> > >As we discussed in the past, the main concern I have is the
addition<br>
> > >of the TPM boot menu.  The problem with the menu, is
that I suspect<br>
> > >the number of people who will find utility in it is extremely
small.<br>
> > >(Most people wont even know what a TPM is.)  However,
many more users<br>
> > >are likely to see the prompt, click through it, and then
get very<br>
> > >confused with the available options and the implications
of choosing<br>
> > >them.  So, I think it is a poor trade off of complexity
for gain.<br>
> > <br>
> > Here's the justification for the menu: A TPM can have an owner
who<br>
> > identifies himself via owner password. In the case that the owner
forgets<br>
> > the password, there is no way for the owner to give up ownership
of the TPM<br>
> > unless there is a BIOS menu that allows him to give up ownership
under<br>
> > physical presence (1). Physical presence is only assumed while
the BIOS is<br>
> > active and a user for example pressed a key when the machine
initialized to<br>
> > indicate physical presence. (I would think pressing F11 to enter
the BIOS<br>
> > menu would be enough for indicate physical presence). I don't
know of<br>
> > another way of doing this.<br>
> <br>
> If I understand the intent of the above, the goal is to prevent<br>
> malicious software on the guest from reprogramming the TPM without
the<br>
> users' knowledge.  (The malicious software sees that the TPM
is<br>
> password locked, so it unlocks the TPM, clears the password, and<br>
> continues.)<br>
> </font></tt>
<br>
<br><tt><font size=2>Yes. This should not be possible under normal circumstances
where the BIOS gives up physical presence once it goes into the boot loader.</font></tt>
<br>
<br><tt><font size=2><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.)</font></tt>
<br>
<br><tt><font size=2>One would need at least a flag to indicate that the
BIOS automatically give up ownership of the TPM.</font></tt>
<br><tt><font size=2>Giving up ownership also means that the device automatically
becomes disabled and deactivated. The BIOS would then</font></tt>
<br><tt><font size=2>presumably automatically have to enabled and activate
the TPM again without user interaction.</font></tt>
<br>
<br><tt><font size=2>The other aspect is that this extension propagates
all the way into higher layers: libvirt would need an API and command</font></tt>
<br><tt><font size=2>line tool extension just to set this flag  and
presumably use the QEMU monitor with a new command to indicate it.</font></tt>
<br><tt><font size=2>You want to be able to do this in a cloud environment,
you need another API and/or GUI support in your cloud stack for doing</font></tt>
<br><tt><font size=2>just this...  I doesn't seem to become a lot
easier this way.</font></tt>
<br><tt><font size=2><br>
> <br>
> On coreboot, a similar solution could be accomplished by setting a<br>
> flag in CBFS (the flash).  Granted, one doesn't need to be physically<br>
> present to reprogram the flash, but if one can reprogram the flash,<br>
> they could just as easily reprogram SeaBIOS anyway.</font></tt>
<br>
<br><tt><font size=2>I am not so familiar with how CBFS is handled. Is
it at least access-restricted to root? I guess one would need a tool </font></tt>
<br><tt><font size=2>to write the above flag(s) into the flash at the right
position.</font></tt>
<br>
<br><tt><font size=2>    Stefan</font></tt>
<br>