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
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.
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's typically
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?
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.
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.