On Sat, Jul 4, 2026 at 4:38 AM Peter Robinson <[email protected]> wrote: > > Hey James, > > > 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. > > Out of interest do you have details of the speed up?
I don't have direct comparisons for everything being added since there doesn't appear to be a software ECDSA pathway in uboot for example. AES-256 CBC when I tested was generally going at least 25 MiB/s. Hash algos were generally fairly similar. I think ecdsa signatures were generally around 30ms per signature validated but that was just measured via UART timing mostly. Note that these are very rough numbers. > > > At a high level this adds: > > > > - SPL driver-model crypto plumbing for AES and hash providers. > > - FIT decrypt-to-buffer support and SPL FIT cipher support, so SPL can > > decrypt an encrypted U-Boot proper FIT without allocating another full > > payload buffer. > > - A shared sun8i-ce parent driver with AES and hash children for H6/H616. > > - An H616 ECDSA child for CE-backed FIT signature validation, plus common > > ECDSA curve-size and key-encoding fixes for secp224r1, prime256v1, > > secp384r1 and secp521r1. > > > > The AES child supports software-provided AES-128/192/256 keys in ECB and > > CBC modes. The hash child supports the CE one-shot MD5/SHA1/SHA256/SHA384/ > > SHA512 methods used by FIT verification. The ECDSA child exposes the H616 > > CE ECC verifier through UCLASS_ECDSA. > > This is me purely thinking out loud. I did some very basic testing on > a Allwinner A64 device of the HW crypto engine and the arm native > crypto extensions and while there was some difference I wonder whether > it makes more sense to looks at implementing the later, upstream Linux > seems to be going more in that route rather than device specific > engines as the performance is compatible and it's more widely deployed > and hence we'd have one code path that can benefit the majority of > devices rather that a bunch of specific drivers that need maintenance. > Had you considered that option? Well I think it's probably good to have both as options either way as a HW crypto engine may have various benefits beyond just performance. For example some HW crypto engines can use efuse based keys directly via special CE slots.
