On 08/26/2014 10:01 AM, Kevin O'Connor wrote:
On Mon, Aug 25, 2014 at 05:18:49PM -0400, Stefan
On 07/02/2014 11:51 AM, Kevin O'Connor
On Wed, Jul 02, 2014 at 11:38:44AM -0400, Stefan
> This is a repost of a series of patches providing TPM support to SeaBIOS.
> As an addition, this patch series now works on the Acer C720 Chromebook
> with limitations (S3 not getting invoked; no logging into TCPA table).
> The patch series cleanly applies to a checkout of tags/rel-1.7.5.
> The following set of patches add TPM and Trusted Computing support to SeaBIOS.
do you have comments about the patches? I have to say that in the meantime
I did some more minor work on them (fixed a bug or two), but the general
structure of the code is still the same.
Sorry for not responding earlier.
As we discussed in the past, the main concern I have is the addition
of the TPM boot menu. The problem with the menu, is that I suspect
the number of people who will find utility in it is extremely small.
(Most people wont even know what a TPM is.) However, many more users
are likely to see the prompt, click through it, and then get very
confused with the available options and the implications of choosing
them. So, I think it is a poor trade off of complexity for gain.
Here's the justification for the menu: A TPM can have an owner who
identifies himself via owner password. In the case that the owner
forgets the password, there is no way for the owner to give up ownership
of the TPM unless there is a BIOS menu that allows him to give up
ownership under physical presence (1). Physical presence is only assumed
while the BIOS is active and a user for example pressed a key when the
machine initialized to indicate physical presence. (I would think
pressing F11 to enter the BIOS menu would be enough for indicate
physical presence). I don't know of another way of doing this.
(1): TPM_ForceClear is to be sent by the BIOS.
Page 41 in the pdf from
Menus exist today in BIOSes and UEFI. Those users that care about them,
will look at them, others I would think will disregard them.
Which leads to my second major concern with bios menus
- those users
that would find gain are also likely to be the users that need to make
a change to hundreds of machines. Those users don't want to go around
connecting keyboards (or the VM equivalent) to all those machines.
I have a couple of other minor comments on the patch series - I'll
send some notes out. However, my other comments are minor and I think
finding a solution to the menu is the most important next step.
We now have ACPI support in QEMU as well. In
SeaBIOS the TPM patches add
the TPM ACPI tables (SSDT, TCPA) if SeaBIOS is building ACPI tables. I
suppose this is still the correct thing to do.
I'd prefer to keep the ACPI
code unchanged. New users that want TPM
functionality on QEMU can use a newer machine type, and users that
want to use an older machine type for compatibility reasons should not
see changes to the ACPI definitions.
So there is no existing use case where SeaBIOS is the only firmware on a
platform (other than on QEMU)? I know coreboot can run SeaBIOS as a
payload and therefore I would agree that in this case coreboot should
handle the ACPI tables.