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