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

[Stefan Berger]

On 08/27/2014 12:26 PM, Kevin O'Connor wrote:
> On Wed, Aug 27, 2014 at 09:51:02AM +0200, Gerd Hoffmann wrote:
>>    Hi,
>>
>>> 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.
>> I'm not so sure moving this to fw_cfg is the right answer here.
> I appreciate the additional perspective.
>
>> We use fw_cfg for alot of configuration bits, because it is easier that
>> way.  We don't need a setup menu in seabios.  We don't need persistent
>> storage for config options.
>>
>> There are exceptions though.  We have a boot menu, which strictly
>> speaking would not be needed as you can set the boot order via fw_cfg.
>> But it is very useful that you can change the boot order interactively
>> if needed (for a guest reinstall for example), without having to touch
>> the virtual machine configuration.
>>
>> 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'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.

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.

    Stefan


>
> For QEMU, I would have thought there were only two interesting states
> - TPM chip not present (and thus not enabled, not activated, and not
> ownable) - or TPM chip present and enabled, activated, and ownable.
> What's the value in the other states, and in what common situations
> would one want to change between states during the lifetime of a VM?
>
> For coreboot, where a TPM chip is present, I imagine there would also
> be two common states - the user wishes to use the chip and thus it is
> enabled, activated, and ownable - or the user doesn't wish to use the
> chip and thus it is disabled and deactivated.
>
>> We could add a fw_cfg file to enable/disable the tpm menu, simliar to
>> the etc/show-boot-menu file for the boot menu.  That way the menu would
>> be off by default, avoiding user confusion.
>>
>> For the qemu case it would not be needed IMHO as the tpm menu shows only
>> up in case tpm hardware is present, and why should you add a tpm to your
>> VM if you don't want to use it?
>>
>> When running (via coreboot) on physical hardware it is more useful as
>> you can't simply rip off the tpm chip to disable the menu ;)
> If adding "tpm-bios-running-state" to fw_cfg isn't viable, then
> another possible way forward would be to add a setup program to
> SeaBIOS.  The way I would envision this is there would be a program
> stored in flash (or fw_cfg) and upon user request (eg, "Press F1 to
> enter setup") SeaBIOS would launch this program instead of using its
> normal boot process.  This setup program could enable all sorts of
> useful functionality (eg, configuring time, default bootorder,
> passwords, tpm, reflash firmware, etc).
>
> This would be a great feature to have.  Unfortunately, it is not an
> easy solution.
>
> -Kevin
>