exchanging crypto drivers

[Olstyle]

Since I am on platforms (STM32L56x and STM32U58x) which can do all the crypto of mcuboot in hardware, I want to use hardware-drivers of those also in the bootloader to save some time and space compared to tinycrypt.
But how to best interface with MCUboot for that?
As far as I understand there i nothing comparable to flash_map_backend.c . So should I just wrap either the MbedTLS or the Tinycrypt interface or is there a better way?

[utzig]

But how to best interface with MCUboot for that?
As far as I understand there i nothing comparable to flash_map_backend.c . So should I just wrap either the MbedTLS or the Tinycrypt interface or is there a better way?

Tinycrypt does not originally support hardware acceleration and we didn't change it from upstream. Mbed TLS does have a way of using hardware acceleration, but we just use the library which is provided by the OS, so you need to check for the particular OS you are using if there is support for using HW acceleration, and if the drivers for L5x and U5x are implemented.

[Olstyle]

I am not using an OS in the Bootloader (and I still don't get what advantage that should have apart from wasting memory). I am using a bare mcuboot with my own drivers for flash, MCU etc. and now want to also use my own crypto drivers.

[d3zd3z]

We also have as upcoming work to update MCUboot to be able to use the PSA crypto API, which theoretically would make the easier to do.

[Olstyle]

Looking a bit deeper in the code mcuboot is pretty much prepared for having the option of adding your own functions. https://github.com/mcu-tools/mcuboot/tree/main/boot/bootutil/include/bootutil/crypto defines the (unfortunately undocumented) interface expected by mcuboot, which is neither completely MbedTLS nor Tinycrypt. So by adding a compile switch MCUBOOT_USE_CUSTOM_CRYPTO which results in just including "aes_ctr_custom.h" etc. the only thing left todo is to define ones own functions into the expected static inline calls in such headers.
Since the pre supported APIs will now go to 3 and might further expand, it could also make sense to always make such an include switch on the caller side and have one prepared header per API instead of a very long header including all supported APIs.

[d3zd3z]

I think it is important to note that this isn't an interface that is published. Adding new variants should not just try to hack them into this interface whether it works or not, but improve the interface within MCUboot so that it supports the new one well. For ciphers and hash functions, there aren't really drastic differences in how they operate, but signature algorithms will tend to have very different ways of using them, especially given how we kind of operate at a fairly low level, using more raw encodings than what are typically done.

[Olstyle]

Adding new variants should just try to hack them into this interface whether it works or not, but improve the interface within MCUboot so that it supports the new one well.

Are you missing a 'not' in the first part of that sentence?

[d3zd3z]

Are you missing a 'not' in the first part of that sentence?

Indeed. Hopefully it now says what I actually want it to.

[Olstyle]

AES and Hash are no issue as you already mentioned. ECDSA looks also usable to me. If you go really low level you can directly split the uncompressed public key format into x and y, omitting the 0x04 header byte for it. But since that wastes just one byte and can also be replaced by simple array indexing in the wrapping header I see no issue with it. (and the currently supported implementations expect uncompressed without header but as one successive stream anyway)
-> I think when I and/or a colleague get to it we will try the MCUBOOT_USE_CUSTOM_CRYPTO approach without touching the already present interface definitions. I'll try to add it as a MR as soon as it's done. If you don't like it you can still close it.