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

[Simon Glass]

Hi Wolfgang,

On Thu, Nov 8, 2012 at 2:31 AM, Wolfgang Denk <wd at denx.de> wrote:
> [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.

Yes I hope so. For now I think we could do something like sign the
kernel and FDTs individually (actually probably sign their hashes
since that is likely to be faster) and write the signature in along
with the hash.

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

That sounds good.

I feel that we may still need to sign the whole FIT image, or at least
enough to cover the strings and the structure. Otherwise we have a
fair bit of code which is looking at user-supplied unverified data.
The smaller this 'attach surface' is, the better. But for a starting
point I think it is reasonable, and we can perhaps come up with a
whole-image signing mechanism later.

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

OK.

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
> "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_