<tt><font size=2>"Kevin O'Connor" <kevin@koconnor.net>
wrote on 08/27/2014 07:00:23 PM:<br>
<br>
</font></tt>
<br><tt><font size=2>> <br>
> On Wed, Aug 27, 2014 at 05:04:51PM -0400, Stefan Berger wrote:<br>
> > On 08/27/2014 12:26 PM, Kevin O'Connor wrote:<br>
> > >On Wed, Aug 27, 2014 at 09:51:02AM +0200, Gerd Hoffmann wrote:<br>
> > >>Same applies here.  IMO it should be possible to
manage the TPM without<br>
> > >>having to touch the virtual machine configuration.  Persistent
storage<br>
> > >>isn't an issue in that case, the tpm device provides
that.<br>
> > >Realistically, though, who is ever going to manage their
TPM?  Perhaps<br>
> > >I'm missing an important use case.  If so, Stefan, maybe
you can<br>
> > >describe some real-world scenarios.<br>
> > <br>
> > The above scenario with a user having forgotten the password
or a machine<br>
> > being handed off to another user where the previous user did
not give up<br>
> > ownership of the TPM. In these cases the user would manage the
TPM  via the<br>
> > BIOS in so far as he would have to give up the TPM ownership
(under physical<br>
> > presence) which is typically done in a TPM BIOS menu item. There'stypically<br>
> > also another option in the BIOS and that is one to activate /
enable the<br>
> > device, maybe as one menu item or as two. Some people may want
to leave it<br>
> > off, others may want to turn it on and the BIOS menu gives them
this option.<br>
> <br>
> You seem to be describing two use cases: 1 - the tpm password must
be<br>
> reset (eg, because it was forgotten or the machine was given<br>
> away/sold), and 2 - some people have a TPM chip but don't want it<br>
> being used.  I understand these two use cases and agree it would
be<br>
> worthwhile to provide a solution for them.<br>
> <br>
> However, I don't think an additional SeaBIOS boot menu is a good<br>
> solution for the above two use cases.  By my estimation, in real
world<br>
> use, the above actions would likely come up only once every few years<br>
> (if ever) for a given machine.  Prompting the user on every boot
for<br>
> such a rare case is not a good complexity vs utility trade off.<br>
> <br>
> Are there other use cases to consider, or am I misunderstanding the<br>
> frequency of the above cases?</font></tt>
<br>
<br><tt><font size=2>These are probably rare events.</font></tt>
<br><tt><font size=2><br>
> <br>
> To expand on my earlier proposal, lets take the second use case -
a<br>
> user that does not want the tpm chip being used.  This decision
is a<br>
> machine hardware decision and I think it is something that fits well<br>
> in fw_cfg/cbfs.  I could see a setting "etc/tpm-state"
with a value of<br>
> 0 = TPM is forced to disabled, deactivated, and unowned, and a value<br>
> of 1 = TPM is forced to enabled, activated, and ownable.  This
allows<br>
> the user to set a control policy (for the next and subsequent boots)<br>
> via either their virt manager (qemu) or flash tools (coreboot).  This<br>
> method also indirectly addresses the first use case (password reset)<br>
> by the two part sequence of disabling the tpm, rebooting, then<br>
> reenabling the tpm (if desired) and rebooting.  Sure, it's slightly<br>
> more work for the user to reset the password, but for an action that<br>
> happens so rarely I don't see it as a problem.</font></tt>
<br>
<br><tt><font size=2>:-/ Once we push these operations to the outside of
the VM, we'll need to propagate</font></tt>
<br><tt><font size=2>it through all the management software (if we decided
to support it there then).</font></tt>
<br><tt><font size=2>It runs into QEMU monitor, libvirt API and virsh management
tool, virt-manager,</font></tt>
<br><tt><font size=2>and every cloud stack that is out there needs support
in its cloud controller and</font></tt>
<br><tt><font size=2>on the cloud mgmt. software on the host where the
VM is located (and where libvirt is)</font></tt>
<br><tt><font size=2>and in its API, GUI, and its own CLI tools where users
will control the VM's TPM from</font></tt>
<br><tt><font size=2>home. All this effort would be required for an operation
that is rare but not</font></tt>
<br><tt><font size=2>'contained' anymore, though should be there for correctness
and completeness reasons.</font></tt>
<br><tt><font size=2><br>
> <br>
> > A TPM menu in the BIOS is probably implemented in all of today's
machines<br>
> > where users expect to adjust those parameters. I would say it's
almost<br>
> > expected to find the possibility to do this in the BIOS and those
<br>
> who are used<br>
> > to it would probably get more confused if it wasn't implemented
<br>
> this way. This<br>
> > of course doesn't preclude additional ways to support TPM management.<br>
> <br>
> SeaBIOS doesn't have a system configuration menu though.  On
QEMU the<br>
> system config menu is in the virt manager and on coreboot it's in<br>
> various OS tools.</font></tt>
<br>
<br><tt><font size=2>There's another spec form TCG that requires the implementation
of ACPI</font></tt>
<br><tt><font size=2>support with the possibility to send messages to the
ACPI interface indicating</font></tt>
<br><tt><font size=2>what to do upon reboot. It seems like this ACPI offers
an API and could </font></tt>
<br><tt><font size=2>write these messages (operations) into the TPM's NVRAM
(ACPI programs</font></tt>
<br><tt><font size=2>the memory mapped IO of the TPM TIS interface as it
seems) that the BIOS could</font></tt>
<br><tt><font size=2>then look at and act upon. Maybe that would be the
spec to follow and</font></tt>
<br><tt><font size=2>'contain' the problem to the inside of the VM. I did
use some of those ideas already</font></tt>
<br><tt><font size=2>when the user chosen menu item was translate in an
'operation code'.</font></tt>
<br>
<br><tt><font size=2>The reserved NVRAM index of the TPM for this purpose
is 0x50010000. It would</font></tt>
<br><tt><font size=2>be easy to read the message (1 byte) from that position
from the TPM's NVRAM via</font></tt>
<br><tt><font size=2>the BIOS. Access is basically by sending a TPM request
to the TIS interface</font></tt>
<br><tt><font size=2>for reading data from this special NVRAM location.
The more challenging part</font></tt>
<br><tt><font size=2>is the ACPI program that now needs to write a similar
packet</font></tt>
<br><tt><font size=2>to the TIS interface to write the 1 byte operation
code into that NVRAM location</font></tt>
<br>
<br><a href="http://www.trustedcomputinggroup.org/files/resource_files/353F514C-1A4B-B294-D02230C310A97F1D/Physical_Presence_Interface_1-20_0-100.pdf"><tt><font size=2 color=blue>http://www.trustedcomputinggroup.org/files/resource_files/353F514C-1A4B-B294-D02230C310A97F1D/Physical_Presence_Interface_1-20_0-100.pdf</font></tt></a><tt><font size=2><br>
</font></tt>
<br><tt><font size=2>   Stefan</font></tt>
<br>