On 2013-05-15, Oliver Stäbler oliver.staebler@bytesatwork.ch wrote:
I'm currently investigating the possibility of using a cryptographic library in U-Boot to verify signatures during a fatload (or similar).
You should take a look at Simon Glass's Verified Boot patchset, as it has the same objectives. http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/156422
While the patchset is not currently integrated in the mainline, from my understanding it is still in progress, and the goal is to get it done for the next release, expected to be 2013.07.
You can help in testing and giving feedback to the existing patchset, and do so when newer versions will be posted.
So my question is, what has to be considered when choosing a crypto library?
As far as I understood so far, U-Boot only implements a part of the C Standard Library. So this has to be considered, right?
As crypto is usually very self-contained, it should not be a problem.
The README mentions that the stack space is very limited. Is this still the case when the "shell" is loaded or is this just the case during initialization? If so, this means for a crypto library that it should not do a lot in the stack, but prefer heap space? Then again, are there any boundaries in using heap? Maybe increase CONFIG_SYS_MALLOC_LEN?
Is there anything else I have to consider?
License compatibility is a point you must consider. U-Boot as a whole is GPLv2 (only), and you cannot include code with an incompatible license.