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