[PATCH v6 00/28] Integrate MbedTLS v3.6 LTS with U-Boot

[Peter Robinson]

On Fri, 6 Sept 2024 at 01:44, Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On Wed, 4 Sept 2024 at 06:48, Peter Robinson <pbrobinson at gmail.com> wrote:
> >
> > Hi Simon,
> >
> > > I wonder if we could leave out the SHA stuff? The algorithms are
> >
> > One of the big advantages of the mbedtls when it comes to all things
> > security is that it's seen a wide audit of it's code which for a lot
> > of usecases is very useful from a security PoV, I'm not sure the
> > amount of audit the U-Boot in project code has had, I'm sure there has
> > been but I've not seen anything published.
>
> Definitely the hash routines and signing have been audited, in fact
> there was at least one bug that came out of it, although not in the
> hash routines themselves, which are solid.
>
> >
> > > stable and this would seem to avoid much of the size growth, and all
> > > the pain of trying to integrate another yet another hashing layer (we
> > > already have normal, progressive and h/w acceleration, plus
> >
> > What's the difference between the first two?
>
> Normal hashes the whole lot at once. Progressive does things a chunk
> at a time, to be watchdog-friendly. If CPUs are fast enough (and
> watchdogs lax enough), perhaps we don't need that code?
>
> >
> > > UCLASS_HASH which h/w acceleration should use but that migration never
> >
> > How hard would it be for UCLASS_HASH to use the mbed hashing underneath?
>
> I really don't see the point as there is nothing wrong with U-Boot's
> hashing, so far as I know. Half the patches in this series would
> likely not be necessary?
>
> But there is a hash_sw driver for UCLASS_HASH, which results in using
> software hashing, if hardware acceleration is not available.
>
> >
> > > happened). I struggle to see any benefit in replacing U-Boot's very
> > > solid hashing infra with something else, particularly as this series
> >
> > I would need to look at the HW support in both U-Boot and mbedtls but
> > given wider use of mbedtls I bet adding HW support there that U-Boot
> > could utilise may be more apertising to most HW vendors as it means
> > they only have to write one set of code and have it used much more
> > widely.
>
> I'm really not sure that mbedtls has wider use than U-Boot :-)

It's used extensively in RTOSes such as zephyr, micropython, FreeRTOS
just to name a few places I'm aware of.

> Yes, anything is possible in software, but I worry we might create
> Frankenstein's monster. U-Boot's acceleration stuff works fine and has
> a proper drive model. For example, with ast2500 it automatically does
> the right thing with the "aspeed,ast2600-hace" (compatible) node.
>
> >
> > > adds yet another. Better to invest the time to refactor it. I asked
> > > about this before and was told that it would happen 'later'. Let's
> > > just not change it at all, then it is more likely someone will sort it
> >
> > What, like the HW support in UCLASS_HASH? Things clearly don't work like that.
>
> Well, the big challenge here was the difficulty of avoiding *any* size
> growth, when I wrote common/hash.c - perhaps with the large features
> going in, this might be less important.
>
> >
> > > Also, if MbedTLS is wanting to be a general library for TLS (I assume
> > > transport-local security, not thread-local storage) perhaps it might
> > > consider changing to non-Windows newlines, or perhaps even kernel code
> > > style?
> >
> > I think the newlines might be a possible ask, they are generally
> > receptive to change (they relicensed it to be a dual license
> > compatible with U-Boot when asked), I don't think forcing a separate
> > to the kernel project to a kernel code style is a fair request.
>
> OK. So long as I don't have to change the code... but with this series
> there is an increase in the code debt in common/hash.c which I'm
> really not keen on, sorry.
>
> Regards,
> Simon