[U-Boot] Limitations/Considerations when programming U-Boot

[Romain Izard <romain.izard.pro@gmail.com>]

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.

-- 
Romain Izard