On Fri, Jul 10, 2026 at 4:05 AM Andre Przywara <[email protected]> wrote: > > Hi James, > > On 7/10/26 00:46, James Hilliard wrote: > > This series enables Allwinner Crypto Engine backed FIT decryption and > > FIT signature/hash validation for secure-boot flows on H6/H616-class > > boards, covering both SPL and U-Boot proper. > > > > The purpose is to use CE-backed AES for encrypted FIT payloads on H6/H616 > > and CE-backed ECDSA validation where the CE ECC engine is available, > > currently H616, instead of relying only on software crypto paths. > > May I ask: why? In general those proprietary vendor crypto offload > engines are somewhat frowned upon, and especially in the Allwinner case > I am not even sure if someone has tried to validate the hardware.
Validate the hardware in what sense? While developing this I've validated the various crypto operations against the expected outputs and everything seems fine. > So what is wrong with using a reviewable (and reviewed) and tested > software implementation? Do you have data that shows any advantage here? I did some more benchmarking and optimization of the aes decryption operations and managed to get it over 4 times faster than this v3 implementation. The CE aes decryption after my latest round of optimizations is well over 100x faster than the existing uboot software aes implementation. Here's a few benchmarks I did with a 64 MiB in-place AES-256-CBC Buffer Decryption: U-Boot's existing AES C software implementation: 3.72 MiB/s OpenSSL Generic in Linux userspace: 24.18 MiB/s OpenSSL NEON instructions in Linux userspace: 34.98 MiB/s OpenSSL ARMv8 AES instructions in Linux userspace: 533.60 MiB/s Optimized dual channel CE AES implementation in U-Boot: 568.0 MiB/s > Just from a high level point of view: the CE uses uncached DMA > operations, and runs at 24 MHz, if I see this correctly. The manual documents it as running at 300MHz for the h616, there's actually a bug in my v3 implementation that was only clocking it to 150MHz, fixing that bug doubled the speed roughly. > I am pretty > sure the AES instructions in the Cortex-A53 beat this easily, I guess > even a NEON-optimised pure software implementation would be faster. I managed to beat both, so I don't think that's the case. > So what I see here is just a lot of code added, but with little (read: > no) improvement. > In the BROM the rationale is a bit different, so I see why it uses the > CE there, but IIRC there is even a chicken bit in the fuses to not use > the CE, so they might even have a software fallback? Well performance wise at least a CE AES decryption operation does seem to beat even OpenSSL's AES instruction optimized implementation by a measurable margin. The chicken-bit fuse documented in the wiki doesn't appear to be present in the h616 SBROM at all from my analysis. If you look at the h616 cryptoengine block diagram in the manual you'll notice it actually has 4 CE channels that can operate in parallel. For the AES-256 CBC decryption case I noticed we can use two channels (Symm/Raes) simultaneously which yielded a ~2x performance increase compared to single channel AES decryption. My v4(not sent yet) which is what the above benchmarks were against will be over 4x faster than my v3 for AES decryption due to this dual channel decryption optimization and the CE clock frequency fix. Since the CE Hash channel can operate in parallel with the two AES decryption channels we should also in theory be able to hash and decrypt a FIT image item in a single pass, although this may require some refactoring. The Asymm CE channel can probably also be fed the signature for validation while the other 3 engines decrypt/hash the FIT image item buffer in theory. I still need to compare the ecdsa and hash performance but I'm thinking it's likely those can also beat even an optimized software implementation.
