"Kevin O'Connor" <kevin@koconnor.net> wrote on 08/26/2014 11:19:14 AM:

>
> On Tue, Aug 26, 2014 at 10:42:31AM -0400, Stefan Berger wrote:
> > >As we discussed in the past, the main concern I have is the addition
> > >of the TPM boot menu.  The problem with the menu, is that I suspect
> > >the number of people who will find utility in it is extremely small.
> > >(Most people wont even know what a TPM is.)  However, many more users
> > >are likely to see the prompt, click through it, and then get very
> > >confused with the available options and the implications of choosing
> > >them.  So, I think it is a poor trade off of complexity for gain.
> >
> > Here's the justification for the menu: A TPM can have an owner who
> > identifies himself via owner password. In the case that the owner forgets
> > the password, there is no way for the owner to give up ownership of the TPM
> > unless there is a BIOS menu that allows him to give up ownership under
> > physical presence (1). Physical presence is only assumed while the BIOS is
> > active and a user for example pressed a key when the machine initialized to
> > indicate physical presence. (I would think pressing F11 to enter the BIOS
> > menu would be enough for indicate physical presence). I don't know of
> > another way of doing this.
>
> If I understand the intent of the above, the goal is to prevent
> malicious software on the guest from reprogramming the TPM without the
> users' knowledge.  (The malicious software sees that the TPM is
> password locked, so it unlocks the TPM, clears the password, and
> continues.)
>


Yes. This should not be possible under normal circumstances where the BIOS gives up physical presence once it goes into the boot loader.


> If this is the intent, can't we just pass a flag (via fw_cfg) from
> QEMU command line to SeaBIOS to force a clear?  That is, the guest
> software can't manipulate the QEMU command line (or its fw_cfg
> entries) and so the ability to set a flag there is proof of physical
> presence.  (Access to the virtual machine disk images and virtual
> 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 becomes disabled and deactivated. The BIOS would then
presumably automatically have to enabled and activate the TPM again without user interaction.

The other aspect is that this extension propagates all the way into higher 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 another API and/or GUI support in your cloud stack for doing
just this...  I doesn't seem to become a lot easier this way.

>
> On coreboot, a similar solution could be accomplished by setting a
> flag in CBFS (the flash).  Granted, one doesn't need to be physically
> present to reprogram the flash, but if one can reprogram the flash,
> they could just as easily reprogram SeaBIOS anyway.


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
to write the above flag(s) into the flash at the right position.

    Stefan