Xen devel - Dec 2006 - [PATCH] [Firmware] TCG BIOS extensions for the Bochs BIOS

This patch adds an implementation of the TCG BIOS extensions to the
Bochs BIOS and enables logging of boot measurements using the previously
implemented support for TCPA ACPI tables. A low-level driver for a TPM
TIS device and an Atmel device is provided.

The implemented specification is described here:

https://www.trustedcomputinggroup.org/specs/PCClient/TCG_PCClientImplementationforBIOS_1-20_1-00.pdf

I added a #define ''BX_TCGBIOS'' to rombios.c that enables or
disables
these extensions. It''s currently disabled so none of the code is
compiled into the BIOS.

The implementation passes the tests implemented in a newer version of
trusted grub (available through the trousers project on sourceforge).

Signed-off-by: Stefan Berger <stefanb@us.ibm.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 7/12/06 22:04, "Stefan Berger" <stefanb@us.ibm.com> wrote:
> Bochs BIOS and enables logging of boot measurements using the previously
> implemented support for TCPA ACPI tables. A low-level driver for a TPM
> TIS device and an Atmel device is provided.
> 
> The implemented specification is described here:
> 
>
https://www.trustedcomputinggroup.org/specs/PCClient/TCG_PCClientImplementatio
> nforBIOS_1-20_1-00.pdf
> 
> I added a #define ''BX_TCGBIOS'' to rombios.c that enables
or disables
> these extensions. It''s currently disabled so none of the code is
> compiled into the BIOS.
Is there a good reason for it being implemented almost entirely in assembly
language?

 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

xen-devel-bounces@lists.xensource.com wrote on 12/08/2006 04:24:31 AM:
> On 7/12/06 22:04, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> 
> > Bochs BIOS and enables logging of boot measurements using the 
previously
> > implemented support for TCPA ACPI tables. A low-level driver for a TPM
> > TIS device and an Atmel device is provided.
> > 
> > The implemented specification is described here:
> > 
> > https://www.trustedcomputinggroup.
> org/specs/PCClient/TCG_PCClientImplementatio
> > nforBIOS_1-20_1-00.pdf
> > 
> > I added a #define ''BX_TCGBIOS'' to rombios.c that
enables or disables
> > these extensions. It''s currently disabled so none of the code
is
> > compiled into the BIOS.
> 
> Is there a good reason for it being implemented almost entirely in 
assembly
> language?
The compiled TCG extension code adds approximately 0x2500 bytes to the 
BIOS and would add more to it if it was written in ''C''.

   Stefan

> 
>  -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 8/12/06 13:30, "Stefan Berger" <stefanb@us.ibm.com> wrote:
>> > Is there a good reason for it being implemented almost entirely in
assembly
>> > language? 
> 
> The compiled TCG extension code adds approximately 0x2500 bytes to the BIOS
> and would add more to it if it was written in ''C''.
Presumably only those who want TPM functionality will run with the
TPM-enabled BIOS, and they are unlikely to care whether the implementation
is e.g., 10kB or 15kB. Even people not using the TPM capabilities are not
really going to care about a few kilobytes. It¹s not like you¹re constrained
to 64kB (0xF0000-0xFFFFF) ‹ you can stick the 32-bit code below 4GB.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <keir@xensource.com> wrote on 12/08/2006 08:36:05 AM:
> On 8/12/06 13:30, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> > Is there a good reason for it being implemented almost entirely in 
assembly
> > language? 
> 
> The compiled TCG extension code adds approximately 0x2500 bytes to 
> the BIOS and would add more to it if it was written in
''C''.
> 
> Presumably only those who want TPM functionality will run with the 
> TPM-enabled BIOS, and they are unlikely to care whether the 
> implementation is e.g., 10kB or 15kB. Even people not using the TPM 
> capabilities are not really going to care about a few kilobytes. It?
> s not like you?re constrained to 64kB (0xF0000-0xFFFFF) ? you can 
> stick the 32-bit code below 4GB.
Someone who wants to add new functionality to the Bochs BIOS might care 
about the amount of free space in that 64kb segment. Currently there''s 
enough room left even with the TPM extensions.
Even if we move these extensions to some 32bit area, the hook into the 1Ah 
interrupt and all those other function calls surrounded by #if BX_TCGBIOS 
in rombios.c are needed as well as later on some code that switches into 
protected mode and jumps up into the 32 bit area. The BIOS code should at 
some point be compiled with those TPM extensions independent of whether a 
TPM is available in the VM or not. The extensions don''t influence the
BIOS
if a TPM is not available.

How would you connect the two code areas and the functions? Would 
hvmloader write the 32 bit address somewhere into the Bochs BIOS and the 
to reach the 32 bit area one uses a jump table to call all those functions 
up there? I''d really rather leave the TPM extensions in the BIOS
segment
for now. The bulk of the code is located in its own file anyway. I will 
convert parts of the code to ''C'', though.

  Stefan
> 
>  -- Keir
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

I would imagine this working by having generic real-mode/32-bit gateway
routines in rombios, and then getting the hell out to 32-bit protected mode
asap for new code. The advantages are that you get to code in C, compiled
with a modern optimising compiler (gcc), and that you avoid the silly 64kB
limitation. As you say, hvmloader would be responsible for poking the
routines into high memory, marking them as E820_RESERVED, and then doing
some jump-table poking in rombios (which might more generically, and
grandiosely, be termed Œlinking¹ of the BIOS and its extensions :-).

TBH I¹m not happy to check in big gobs of assembly code, or even really bcc
C/asm code. We should do the leg work to be able to use gcc. An hvmloader
type of environment is what we should aim for --  another way of looking at
this is removing hvmloader¹s restriction of only running at bootstrap so
that it can also provide ongoing run-time services.

 -- Keir

On 11/12/06 15:26, "Stefan Berger" <stefanb@us.ibm.com> wrote:
> Someone who wants to add new functionality to the Bochs BIOS might care
about
> the amount of free space in that 64kb segment. Currently there''s
enough room
> left even with the TPM extensions.
> Even if we move these extensions to some 32bit area, the hook into the 1Ah
> interrupt and all those other function calls surrounded by #if BX_TCGBIOS
in
> rombios.c are needed as well as later on some code that switches into
> protected mode and jumps up into the 32 bit area. The BIOS code should at
some
> point be compiled with those TPM extensions independent of whether a TPM is
> available in the VM or not. The extensions don''t influence the
BIOS if a TPM
> is not available.
> 
> How would you connect the two code areas and the functions? Would hvmloader
> write the 32 bit address somewhere into the Bochs BIOS and the to reach the
32
> bit area one uses a jump table to call all those functions up there?
I''d
> really rather leave the TPM extensions in the BIOS segment for now. The
bulk
> of the code is located in its own file anyway. I will convert parts of the
> code to ''C'', though.



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Keir Fraser <keir@xensource.com> wrote on 12/11/2006 10:43:27 AM:
> 
> I would imagine this working by having generic real-mode/32-bit 
> gateway routines in rombios, and then getting the hell out to 32-bit
> protected mode asap for new code. The advantages are that you get to
> code in C, compiled with a modern optimising compiler (gcc), and 
> that you avoid the silly 64kB limitation. As you say, hvmloader 
Since I am running out of space in the BIOS segment now while converting 
the functions to ''C''...
Do you know of some good ''constructs'' that can be left in the
rombios as
markers for linking the two pieces? I''d like to start with lifting up a
single function into 32 bit space and then continuously put more up there, 
but get the linking right. Probably funneling everything through a single 
function and demultiplexing in 32 bit space is not what we would want.

I suppose HVMloader will have to carry a relocateable file (-fPIC) and be 
able to re-locate it to whatever memory could be reserved.

   Stefan
> would be responsible for poking the routines into high memory, 
> marking them as E820_RESERVED, and then doing some jump-table poking
> in rombios (which might more generically, and grandiosely, be termed
> ?linking? of the BIOS and its extensions :-).
> 
> TBH I?m not happy to check in big gobs of assembly code, or even 
> really bcc C/asm code. We should do the leg work to be able to use 
> gcc. An hvmloader type of environment is what we should aim for -- 
> another way of looking at this is removing hvmloader?s restriction 
> of only running at bootstrap so that it can also provide ongoing 
> run-time services.
> 
>  -- Keir
> 
> On 11/12/06 15:26, "Stefan Berger" <stefanb@us.ibm.com>
wrote:
> Someone who wants to add new functionality to the Bochs BIOS might 
> care about the amount of free space in that 64kb segment. Currently 
> there''s enough room left even with the TPM extensions. 
> Even if we move these extensions to some 32bit area, the hook into 
> the 1Ah interrupt and all those other function calls surrounded by 
> #if BX_TCGBIOS in rombios.c are needed as well as later on some code
> that switches into protected mode and jumps up into the 32 bit area.
> The BIOS code should at some point be compiled with those TPM 
> extensions independent of whether a TPM is available in the VM or 
> not. The extensions don''t influence the BIOS if a TPM is not
available.
> 
> How would you connect the two code areas and the functions? Would 
> hvmloader write the 32 bit address somewhere into the Bochs BIOS and
> the to reach the 32 bit area one uses a jump table to call all those
> functions up there? I''d really rather leave the TPM extensions in 
> the BIOS segment for now. The bulk of the code is located in its own
> file anyway. I will convert parts of the code to ''C'',
though.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 12/12/06 3:25 pm, "Stefan Berger" <stefanb@us.ibm.com> wrote:
> Since I am running out of space in the BIOS segment now while converting
the
> functions to ''C''...
> Do you know of some good ''constructs'' that can be left in
the rombios as
> markers for linking the two pieces? I''d like to start with lifting
up a single
> function into 32 bit space and then continuously put more up there, but get
> the linking right. Probably funneling everything through a single function
and
> demultiplexing in 32 bit space is not what we would want.
> 
> I suppose HVMloader will have to carry a relocateable file (-fPIC) and be
able
> to re-locate it to whatever memory could be reserved.
How about just have a table below 1MB, indexed by function id (where
function ids also are statically allocated too). This table will be produced
as part of the building and linking of the 32-bit extensions (it¹ll probably
be a C array of pointers, in its own data section which the linker will know
to place at the very start of the extension ROM): it can then be patched
into the rombios at compile time, or copied to a pre-decided address below
1MB by hvmloader at boot time.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel