Hi Wolfgang,
On Thu, Nov 8, 2012 at 2:31 AM, Wolfgang Denk wd@denx.de wrote:
[Note: Subject changed, Threading restarted].
Dear Simon,
In message CAPnjgZ11wScsnvPG29CFDRYz7Xbtp=WB+tL0UmGvNvHmHmJ-RA@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 FITimage, 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@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_