[U-Boot] Signing Images - was: TPM: remove dead code

[Wolfgang Denk]

[Note: Subject changed, Threading restarted].

Dear Simon,

In message <CAPnjgZ11wScsnvPG29CFDRYz7Xbtp=WB+tL0UmGvNvHmHmJ-RA at mail.gmail.com> you wrote:
> 
> > 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

I don;t think this is a good idea...

> 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). ...

Are you sure that would really be a problem?

First, what makes you sure that checking the signature over N parts is
so much slower than checking it over one summary image with a much
larger size (totalling the sum of the images, plus overhead)?  Is
setting up such a check really such an expensive operation?

Second, who says you must check the signature of all parts?  Even if
you have a large number of DT blobs, you will select only one for
booting, so it should be sufficient to verify only this one - why
should you care about all the other, unused ones?  Actually that could
be _faster_ than checking everything.

Third, there may be many alternative approaches.  For example, you
could put all the DT blobs into a small file system (to be used in
U-Boot as a RAM disk) - then you can verify just a single file system
image, and then just read the needed DT from that.  Think a bit
longer, and more approaches will spring up.

>      ... 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.

True.

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

This does not make much sense to me, too complicated, and I don't see
the real need yet.

> 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?

Each "object" carries it's own meta-data, but what an object actually
is, is pretty much flexible - of course, the command infrastructre
needs to support it.  If you want to use "bootm" with the FIT image to
boot it directly, then you need to stick with the current format.  But
of course the bootm command can already now be used as individual
sub-commands, and similarly we could (and probably should) add a set
of commands (resp. one "fit" command with a set of sub-commands) to
perform specific operations on the parts of a FIT image.

> > 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.

We could try to come up with a lawyer-proof specification of the
requirements for such a command (i. e. that it has to perform a
"real", or "useful" operation etc.), thus trying to prevent the
creation of dummy commands that are ment only to fulfil the "no dead
code" requirement.  I don't want to go that far.  Let's apply common
sense.  If you write a driver, you probably want to test it some way,
so you will have to implement some command interface to exercise the
driver in any case.  I think there are only few cases where such a
command would not be included in the normal U-Boot configuration.

But yes, there are grey areas; but maybe it's enough if we plant big
signs "Here Abide Monsters" on such ways...

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
"You know, after a woman's raised a family and so on,  she  wants  to
start living her own life."   "Whose life she's _been_ living, then?"
                                  - Terry Pratchett, _Witches Abroad_