[U-Boot] [PATCH] TPM: remove dead code

[Simon Glass]

Hi Wolfgang,

On Wed, Nov 7, 2012 at 11:35 AM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Simon,
>
> In message <CAPnjgZ0V=MwiVYQ3H-dsVEpNVHMdOPx3Yh3qtPdje0=_Cz=smg at mail.gmail.com> you wrote:
>>
>> > This is not exactly a proposal that triggers enthusiasm to me.
>>
>> Enthusiasm is a strong word...
>
> I tried to find a strictly non-negative phrasing here, because I felt
> that would be somewhat better ;-)

Much appreciated :-)

>
>> Let's take an example. We have AHCI/SATA support in U-Boot. There may
>> be no board code in U-Boot that actually reads from a disk (I am not
>> sure, but it is plausible, since hard-coded disk/fs access from a
>> board's C code would be odd). Let's say this code exists only in
>> commands that may or may not be executed by board scripts, which are
>> out of tree. I'm sure this isn't considered dead code, but I want to
>
> As soon as I can type on the console something like
>
>         ext2load sata 0:1 200000 boot/uImage
>
> and this is actually capable of reading data from a S-ATA attached
> storage device, then this is perfectly fine:  the driver provides a
> functionality, which can be used in U-Boot to perform certain actions
> on the real system.
>
>> understand the difference. If there is a TPM command which may or may
>> not be executed by board scripts (also out of tree), what is the
>> difference?
>
> If there is a TPM command which actually communicates with the TPM
> hardware and can be used for example to verify an image checksum or
> such, then it provides a function.
>
>> Following this dead code argument, whole U-Boot subsystems are dead
>> code since they are only used indirectly from the command line and not
>> directly by any board code?
>
> This is not what I mean.
>
>> So my thinking now is that I should:
>>
>> 1. Create a way of extracting verification information from a signed
>> block (e.g. kernel hash, rollback info)
>> 2. Add some commands to access this
>> 3. Create a basic script which uses these commands
>>
>> Does this sound right?
>
> 3. would actually not be needed, as long as 1. and 2. really work on
> some system.

OK I think I understand this now. I will take a look at this and see
what I can come up with.

>
> Comment for 1. (but not relateds to this thread, just a note while we
> are at it): I imagine such functionality should be integrated with the
> FIT image handling, i. e. like we are today able to verify - say - a
> sha256 checksum of an image, your code would be able to verify a TPM
> backed signature.  Does this match your plans?

That would be nice. That format seems almost infinitely flexible so we
should be able to make it work.

Still, I believe the FIT image itself needs to be signed. If we try to
sign the components of the FIT image, then I think we will get into
trouble because it will need multiple crypto operations to verify each
piece (and there might be a lot of pieces if we have a lot of FDTs
inside). If we try to put the whole-FIT-image signature inside the FIT
image, then we have a chicken and egg problem - we cannot sign it
until we know what is in it, but we can't know what is in it until we
know the signature.

One option would be to embed a FIT image inside a FIT image, like this:

+---- Top Level FIT Image-----------------------------------+
|                                                           |
|    * Hash of embedded FIT image, signed with secret key   |
|                                                           |
|    +---Embedded FIT Image-------------+                   |
|    |                                  |                   |
|    |  kernels                         |                   |
|    |  fdts                            |                   |
|    |  configs                         |                   |
|    |                                  |                   |
|    +----------------------------------+                   |
|                                                           |
+-----------------------------------------------------------+

But this is not ideal because we have to verify the whole image
(including the large kernel) just to check its version / compatibility
(we may have several kernel options and be trying to pick the best).

Ideally we would be able to split the FIT image into a meta-data piece
and a data piece, so we can verify the meta-data all at once with a
single key, and the data only as needed when we decide we want to load
a particular kernel.

The FDT format sort-of does this, but I believe the kernel is embedded
as a blob, so in practice we can't separate the two. Right?

I will think about it some more.

>
>
>> So long as I can understand the definition then we should be fine.
>
> Can we agree on something like: code is considered to be "used" (in the
> sense of it is no dead code) when there is at least one board
> configuration in mainline where, either as part of the normal
> initialization sequence or as reaction to some interactive user
> command, said code will be executed and perform the specific function
> it was designed for ?
>
> As a side effect this means that there is at least one board
> configuration that will actually compile and link this piece of code.

Yes that seems reasonable, and it makes sense. But 'reaction to some
interactive user command' allows me to create such a command (as I did
with TPM) which exercises the driver and thus makes it undead code.
This is a bit of a grey area.

Regards,
Simon

>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> "Free markets select for winning solutions."        - Eric S. Raymond