[SeaBIOS] [PATCH v8 0/8] Add TPM support to SeaBIOS

[Stefan Berger]

"Kevin O'Connor" <kevin at koconnor.net> wrote on 08/27/2014 07:00:23 PM:


> 
> On Wed, Aug 27, 2014 at 05:04:51PM -0400, Stefan Berger wrote:
> > On 08/27/2014 12:26 PM, Kevin O'Connor wrote:
> > >On Wed, Aug 27, 2014 at 09:51:02AM +0200, Gerd Hoffmann wrote:
> > >>Same applies here.  IMO it should be possible to manage the TPM 
without
> > >>having to touch the virtual machine configuration.  Persistent 
storage
> > >>isn't an issue in that case, the tpm device provides that.
> > >Realistically, though, who is ever going to manage their TPM? Perhaps
> > >I'm missing an important use case.  If so, Stefan, maybe you can
> > >describe some real-world scenarios.
> > 
> > The above scenario with a user having forgotten the password or a 
machine
> > being handed off to another user where the previous user did not give 
up
> > ownership of the TPM. In these cases the user would manage the TPM via 
the
> > BIOS in so far as he would have to give up the TPM ownership (under 
physical
> > presence) which is typically done in a TPM BIOS menu item. 
There'stypically
> > also another option in the BIOS and that is one to activate / enable 
the
> > device, maybe as one menu item or as two. Some people may want to 
leave it
> > off, others may want to turn it on and the BIOS menu gives them this 
option.
> 
> You seem to be describing two use cases: 1 - the tpm password must be
> reset (eg, because it was forgotten or the machine was given
> away/sold), and 2 - some people have a TPM chip but don't want it
> being used.  I understand these two use cases and agree it would be
> worthwhile to provide a solution for them.
> 
> However, I don't think an additional SeaBIOS boot menu is a good
> solution for the above two use cases.  By my estimation, in real world
> use, the above actions would likely come up only once every few years
> (if ever) for a given machine.  Prompting the user on every boot for
> such a rare case is not a good complexity vs utility trade off.
> 
> Are there other use cases to consider, or am I misunderstanding the
> frequency of the above cases?

These are probably rare events.

> 
> To expand on my earlier proposal, lets take the second use case - a
> user that does not want the tpm chip being used.  This decision is a
> machine hardware decision and I think it is something that fits well
> in fw_cfg/cbfs.  I could see a setting "etc/tpm-state" with a value of
> 0 = TPM is forced to disabled, deactivated, and unowned, and a value
> of 1 = TPM is forced to enabled, activated, and ownable.  This allows
> the user to set a control policy (for the next and subsequent boots)
> via either their virt manager (qemu) or flash tools (coreboot).  This
> method also indirectly addresses the first use case (password reset)
> by the two part sequence of disabling the tpm, rebooting, then
> reenabling the tpm (if desired) and rebooting.  Sure, it's slightly
> more work for the user to reset the password, but for an action that
> happens so rarely I don't see it as a problem.

:-/ Once we push these operations to the outside of the VM, we'll need to 
propagate
it through all the management software (if we decided to support it there 
then).
It runs into QEMU monitor, libvirt API and virsh management tool, 
virt-manager,
and every cloud stack that is out there needs support in its cloud 
controller and
on the cloud mgmt. software on the host where the VM is located (and where 
libvirt is)
and in its API, GUI, and its own CLI tools where users will control the 
VM's TPM from
home. All this effort would be required for an operation that is rare but 
not
'contained' anymore, though should be there for correctness and 
completeness reasons.

> 
> > A TPM menu in the BIOS is probably implemented in all of today's 
machines
> > where users expect to adjust those parameters. I would say it's almost
> > expected to find the possibility to do this in the BIOS and those 
> who are used
> > to it would probably get more confused if it wasn't implemented 
> this way. This
> > of course doesn't preclude additional ways to support TPM management.
> 
> SeaBIOS doesn't have a system configuration menu though.  On QEMU the
> system config menu is in the virt manager and on coreboot it's in
> various OS tools.

There's another spec form TCG that requires the implementation of ACPI
support with the possibility to send messages to the ACPI interface 
indicating
what to do upon reboot. It seems like this ACPI offers an API and could 
write these messages (operations) into the TPM's NVRAM (ACPI programs
the memory mapped IO of the TPM TIS interface as it seems) that the BIOS 
could
then look at and act upon. Maybe that would be the spec to follow and
'contain' the problem to the inside of the VM. I did use some of those 
ideas already
when the user chosen menu item was translate in an 'operation code'.

The reserved NVRAM index of the TPM for this purpose is 0x50010000. It 
would
be easy to read the message (1 byte) from that position from the TPM's 
NVRAM via
the BIOS. Access is basically by sending a TPM request to the TIS 
interface
for reading data from this special NVRAM location. The more challenging 
part
is the ACPI program that now needs to write a similar packet
to the TIS interface to write the 1 byte operation code into that NVRAM 
location

http://www.trustedcomputinggroup.org/files/resource_files/353F514C-1A4B-B294-D02230C310A97F1D/Physical_Presence_Interface_1-20_0-100.pdf


   Stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.seabios.org/pipermail/seabios/attachments/20140827/b8c8d46d/attachment-0001.html>