From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:52768) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeqPn-0001HN-OW for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:22:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QeqPl-0006lm-LW for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:22:55 -0400 Received: from e39.co.us.ibm.com ([32.97.110.160]:46724) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QeqPl-0006le-54 for qemu-devel@nongnu.org; Thu, 07 Jul 2011 11:22:53 -0400 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by e39.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p67F88Rm011772 for ; Thu, 7 Jul 2011 09:08:08 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p67FMV7Y185626 for ; Thu, 7 Jul 2011 09:22:32 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p67FMRLY026560 for ; Thu, 7 Jul 2011 09:22:27 -0600 Message-ID: <4E15CF32.20002@linux.vnet.ibm.com> Date: Thu, 07 Jul 2011 11:22:26 -0400 From: Stefan Berger MIME-Version: 1.0 References: <20110706163158.459850865@linux.vnet.ibm.com> <20110706225805.GA24189@morn.localdomain> <4E159D0D.3040701@linux.vnet.ibm.com> <20110707124319.GA23494@morn.localdomain> In-Reply-To: <20110707124319.GA23494@morn.localdomain> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [SeaBIOS] [PATCH V5 0/9] Add TPM support to SeaBIOS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin O'Connor Cc: seabios@seabios.org, qemu-devel@nongnu.org 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