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
