[SeaBIOS] [PATCH v2 3/3] Add a menu for TPM control

[Stefan Berger]

On 06/02/2015 01:44 PM, Kevin O'Connor wrote:
> On Tue, Jun 02, 2015 at 01:05:47PM -0400, Stefan Berger wrote:
>> On 06/01/2015 12:54 PM, Kevin O'Connor wrote:
>>> On Tue, May 26, 2015 at 03:48:35PM -0400, Stefan Berger wrote:
>>>> This patch provides an addtional menu entry that enables the user to control
>>>> certain aspects of the TPM's state.
>>>>
>>>> If a working TPM has been detected, the boot menu will look like this:
>>>>
>>>> Select boot device:
>>>>
>>>> 1. ata0-1: QEMU HARDDISK ATA-7 Hard-Disk (6144 MiBytes)
>>>> 2. Legacy option rom
>>>> 3. iPXE (PCI 00:03.0)
>>>>
>>>> t. TPM Menu
>>>>
>>>> Upon pressing t the TPM menu will be shown:
>>>>
>>>> 1. Enable TPM
>>>> 2. Disable TPM
>>>> 3. Activate TPM
>>>> 4. Deactivate TPM
>>>> 5. Clear ownership
>>>> 6. Allow installation of owner
>>>> 7. Prevent installation of owner
>>>> Escape for previous menu.
>>>> TPM is enabled, active, does not have an owner but one can be installed.
>>> I'm okay with adding a "t" to the boot menu.  However, I think this
>>> sub-menu is too complex and cryptic.  (For example, I suspect most
>>> users wont even know what "TPM" means.)
>>>
>>> I think I'd prefer something like:
>>>
>>> t. TPM Configuration
>>>
>>> Upon pressing t the TPM menu will be shown:
>>>
>>>
>>> The Trusted Platform Module (TPM) is a hardware device in this
>>> machine.  It can help verify the integrity of system software.
>>>
>>> The current state of the TPM is:
>>>    Enabled
>> Well, there are two independent state bits indicating enabled/disable and
>> activated/deactivated.
> Could you describe the difference?  Why would anyone want an enabled
> and deactivated tpm?  I would like to see less use of "TPM lingo" in
> the menu.  I think a casual user would not know the distinction
> between "enabled" and "activated" and would therefore find it
> confusing.

So then we could combine the active/enabled state into let's say an 
'enabled' state and any other combination of the states would be 
regarded as 'disabled'.

These states basically indicate the amount of functionality that is 
available. An enabled + active + owned TPM provides all of its 
functionality and a disabled + deactivated + un-owned TPM is basically a 
device that is turned off. There are other combinations in between that 
enable more functionality.

More info in Part 1 Design Principles section 9.4.x  here (search for 
'S8' for example):

http://www.trustedcomputinggroup.org/resources/tpm_main_specification




>
>>>    No ownership key has been installed
>> No ownership password has been set.
> Okay - if it's a password (in the sense of "p5ssw0rd") then it of
> course should say password.  For some reason I thought it was a
> public/private key pair that enabled remote management.


Such a key gets generated as part of taking ownership of the TPM, which 
is done by using a password.



>
>>>    System software can install an ownership key
>> The system owner can take ownership of the TPM.
> If you take a step back and look at that sentence from a pure English
> / non-technical perspective, I think you'll see my concern with it.
> (The person who purchased the machine already owns both the system and
> the tpm hardware in the system, and no software can alter that.)
>
>>> Available options are:
>>>    d) Disable TPM and clear any ownership key settings
>> I think the disablement and clearing of ownership should be separated. The
>> thing with the TPM 1.2 is that all keys that one has created (after taking
>> ownership of it) depend on the ownership of the TPM. Once one gives up
>> ownership, one looses all keys. Also, the device becomes disabled and
>> deactivated, so one has to enable and activate it again, which even requires
>> a reboot.
> So, are you saying that one might want to "disable the tpm", but not
> clear out any keys?  I'm not against adding that option, but I don't
> see why anyone would want to do that.

The only point I can bring here is to leave the flexibility to the user 
of being able to control those TPM states independently.


>
>>> If no change is desired or if this menu was reached by mistake, press
>>> ESC and this machine will be rebooted without change.
>> There's no need to reboot if we only leave the menu. If the user activates
>> the device from it being deactivated, a reboot will automatically happen.
> I think it's a better fit (and simpler) to just always reboot.  Thus,
> one is not entering the "tpm menu", but is booting into the "tpm
> configuration".
>
> If I understand this correctly (and please correct me if I'm not), a
> real world user might realistically want to enter this menu once a
> decade at most.  Thus, the extra time to reboot (or even two reboots -
> one to disable and then one to re-enable) is not a problem.

rotfl %eax   :-)

It's just no necessary to reboot upon certain state changes, that's all 
there is to it. The way I implemented the menu, it would program the TPM 
immediately and reboot immediately when going from deactivated to 
activated. Otherwise no reboot is necessary.

    Stefan



>
>>> Specifically, I think the menu should be a little more verbose (for
>>> users that just explore the menu), it should only be reached if the
>>> given hardware is present, and menu options should only be shown if
>>> they are actually available and make sense to invoke.
>> Ok. I'll rework this and will probably put this in front of the physical
>> presence patch.
> Thanks,
> -Kevin
>