[TR3-FIR-155] Finalize AES HW accelerator drivers for embassy

[grochowski-withintent]

Overview

This change brings drivers for AES hardware accelerator. At this point, only AES CCM is supported.

Methodology and resources

At first, I have taken cryp.rs module from embassy-stm32, and then reworked it to the point of containing ~90% authored code. There was a lot of modifications due to cryp hardware being singnificantly different, as well as removals for the sake of simplifying the interface for us.

All algorithms are build upon RM0434 AES chapter as closely as possible. Currently DMA is the used way of moving payloads around. It is possible to move to polling/interrupts but not possible to choose at this point (though there are tools in place to easily allow that in the future).

Testing

The AES drivers have been proven to work right against several test vectors from RFC3610, and represents same results as currently used software AES. I plan to do automated tests directly at the repository where these will be applied.

Open points

• This code contains multiple panic invocations in case thing are unbearable for the AES engine.
  I have tried to make them compile-time checks, but unfortunately Rust tools for that are too prototype-y at the moment.
  My understanding is not complying to them would make talking to the application impossible, hence panics are reasonable. @mattcaron-token please let me know if this conforms to your methodology.

• Due to how DMA works, the input slices for the algorithms must be u32, aligned, even though they are [u8]. There's also no compile time check assuring that, I can only make these panic when this condition is met. Does this work for us?

[ghost]

Looks good to me, let's see what @mattcaron-token has to say about all the copy_from_slice.

[mattcaron-token]

One serious question about the stm32-metapac version.

The rest are piddly things.

Overall, it seems fine, with the caveat that I did not review any of the documents for the AES hardware, so I did not verify that the code is doing what it should per the docs.

Splitting it into a new module was the correct choice here - that way it won't conflict with upstream changes. Good call.

I'll respond to other questions individually.

[mattcaron-token]

Looks good to me, let's see what @mattcaron-token has to say about all the copy_from_slice.

(matt@spider) ~/workspace/code/embassy (main)$ grep -Ir copy_from_slice * | wc -l
208

I would say that it is consistent with the existing code.

If we want to clean up embassy so it doesn't implicitly panic, we can do that later.

[mattcaron-token]

Open points

* This code contains multiple `panic` invocations in case thing are unbearable for the AES engine.

Which is consistent with the original code - it does the same thing.

(matt@spider) ~/workspace/code/embassy (main)$ grep -Ir panic * | wc -l
1090

There are many panics on the codebase.

  My understanding is not complying to them would make talking to the application impossible, hence panics are reasonable. @mattcaron-token please let me know if this conforms to your methodology.

I don't like them, but it is consistent with the existing code. Going through and reworking embassy to not panic is a different project altogether.

* Due to how DMA works, the input slices for the algorithms **must** be u32, aligned, even though they are `[u8]`. There's also no compile time check assuring that, I can only make these panic when this condition is met. Does this work for us?

Yes. At least, for now.

[mattcaron-token]

I'm still good with this.