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

[Tom Rini]

On Wed, Sep 04, 2024 at 01:48:43PM +0100, Peter Robinson 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.

Yes, it's a positive in my mind to bring in the assorted hashing
algorithms from mbedTLS here.

> > 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?
> 
> > 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?

This, long term, is what I would like to see figured out how to do.

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

We had some discussion in earlier iterations about HW acceleration for
the algorithms for mbedTLS and I thought this version of the series
exposed what was available when it's available (like the ARM crc32
instructions can be used, but not the full HW accelerators of some other
HW platforms) ?

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

Yes, I too am OK with figuring out what needs to be done here, if all
that much / anything really, honestly, afterwards. Maybe common/hash.c
needs to be split up, but "do something very clever to the hash_algo
table" sounds like something that could be a lot of effort for
questionable gains (and possibly some losses wrt code size).

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

While it would be nice for newlines to change, I'm not sure it's
strictly needed? One of the first steps in the process is fixing those,
and I believe git handles subsequent re-merges fine. And yes, just like
other external code we aren't really in a position to demand (nor should
we, nor expect someone else to) rework their codebase.

-- 
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/20240904/f3bc7c5c/attachment.sig>