Re: [Qemu-devel] [SeaBIOS] [PATCH V5 0/9] Add TPM support to SeaBIOS

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 07/07/2011 08:43 AM, Kevin O'Connor wrote:
> On Thu, Jul 07, 2011 at 07:48:29AM -0400, Stefan Berger wrote:
>> On 07/06/2011 06:58 PM, Kevin O'Connor wrote:
>>> BTW, I don't think patch 7 or 9 really make sense to integrate in the
>>> official version of SeaBIOS.  Also, in patch 8, I'd prefer to see all
>>> new fw_cfg entries use the "romfile" mechanism.
>> Patch 7 is the menu. This patch is needed in 'some form' since in
>> some cases, like after giving up ownership of the TPM, the TPM
>> becomes disabled and deactivated and one has to interact with the
>> BIOS to activate and enable it again. Other scenarios include
>> someone who has forgotten the owner password for the TPM and now has
>> to go through the BIOS to give up ownership of it -- that's the only
>> way one can do this then.
> Hrmm.  I don't recall seeing this menu on the factory BIOS of real
> machines.  How do normal users interact with it?
Everyone has to go through the BIOS menu to maybe even enable and 
activate the TPM before first use. It's typically under 'security'.
> Can the info be passed in from QEmu?
>
To a certain limit, yes. I have an experimental patch that allows one to 
pass in a parameter via command line to Qemu which then passes this 
parameter on to the BIOS via the firmware interface. It tells the BIOS 
what it should do with the TPM upon VM startup / reboot. I can for 
example tell it to always enable and activate the TPM so that the user 
doesn't have to go through the BIOS once he gave up ownership of the 
device. However, I cannot tell the BIOS to give up ownership every time 
there is a startup/reboot since otherwise all keys that the TPM owner 
generated will be lost. So the case where the user forgot his password 
is problematic and in that case he would have to get to the BIOS menu, 
give up ownership and then boot the machine again. The reason is that 
only during an early bootup the TPM is in a state that would allow 
certain commands to be sent that among other things allow giving up 
ownership.

>> I'll have a look at the 'romfile' mechanism for patch 8.
>>
>> I only post patch 9 for someone who is interested to be able to run
>> the tests. Since the 128kb are slowly filling up, it's not going to
>> be compilable with it for much longer and I don't expect it to go
>> into the repo.
So regarding the romfile mechanism for patch 8: In patch 8 I (expect 
Qemu to) hash for example files passed via -kernel, -initrd and data 
provided via -append or modules in case of multiboot, write them into 
concatenated data structures and pass the byte array to the firmware 
interface for SeaBIOS to pick up. Now with the romfile mechanism I have 
the impression that these are more or less static data, whereas what is 
happening in patch 8 depends on the parameters pass to qemu.

Here an example for such a command line when Qemu starts in this type of 
paravirtualized mode:

qemu -kernel /boot/vmlinuz-2.6.36 -initrd /boot/initrd-2.6.36 -append 
"ro [...]" [...]

In effect Qemu does a

sha1sum /boot/vmlinuz-2.6.36
sha1sum /boot/initrd-2.6.36
echo -n "ro [...] | sha1sum

and logs what it measured, i.e., kernel, initrd, or command line.

And here's the corresponding patch for Qemu:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg69677.html

> There is no limit at 128K - if it's exceeded the build will start
> using a 256K rom.
>
Good to know.

    Stefan
> More important than the total size is the "fixed" size reported at the
> end of the build - that's how much space is used under 1 Meg after the
> "post" phase completes.  Ideally it would stay under 64K though that's
> not a hard limit either.
>
> -Kevin