[tools] FIT tools rework

[Tom Rini]

On Wed, Jun 03, 2020 at 12:35:19AM +0200, Alexandre BESNARD wrote:

> Hello 
> 
> I would like to introduce a change in the FIT host tools, and thus I'm looking for advice and opinion. 
> The change would only take place on the host FIT reading tools, namely fit_info, fit_check, and their libraries. 
> 
> The main idea here is, I think this tool is quite handy and complete for development and debug, but my need is a production ready tool set, usable on the target booted by u-boot. The use case being a target fully booted wanting to check and retrieve information from its own FIT images. 
> In my opinion (and I may very well have misunderstood it and be wrong), this tool (or any other one) may not answer this need, not even with small fixes. 
> That's why I'd like to refactor it as a whole, changing its architecture (that's a big word for a single toolset and a couple of functions in libraries, with respect to actual implementation). 
> I tend to prefer removing current front-end implementation, as a new toolset would actually make it redundant. I would however understand the idea of breaking compatibility with external tests could rule this out (fishing for advice here). 
> 
> Here are the main points I would like to find in a renewed toolset, usable in the linux environment booted from u-boot. Take this as the way of a program doing one thing only, but doing it well and clearly. 
> - a separate program for each feature 
> - perform separate checks on FIT images: I should be able to only check signature, or only integrity 
> - check signatures out of crt, pem, ... files: DTB stored public keys are pretty uncommon on userspace, and that goes against usual pubkey formats 
> - use various device types as FIT image input (MTD, UBI volume, ...): I'm not sure about this one. I think that could (and should) be handled out of the tool, and the caller should provide a readable file. Fishing for opinion nontheless 
> - retrieve FIT properties: indeed fit_info provides properties, but I think a more friendly way would improve readability and ease of use. Among other things, that includes the ability to return only the property value (for scripting indeed), for a few data types. In my opinion, reading FIT metadata is a must have for a userspace application, and while dtc (and others) provides a way to do it, such an utility could be included in the fit tools. It should be able to return several properties at once, that would be nice and better for processing time. 
> - check authenticity when retrieving properties: while chances of external corruption between a signature check and properties value check are low, the ability to check FIT metadata while retrieving some of them could come in handy. 
> 
> Those are only my ideas of what such a tool should have and you are indeed more than welcome to add ideas, challenge them, or simply tell me there already are usable ways of doing all this and no such change is required. 

So I guess the main answer is that this sounds interesting but needs to
be done in iterative patches that can be reviewed and used against the
existing testsuite today, and with new tests added as new functionality
is added.  And broken down in to small chunks.  So start with whatever
re-organization needs to be done and move on from that.  Thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200605/1e2975d1/attachment.sig>