[crypto] Cleanup on failures#30181
Conversation
|
This attribute generates some code in the background, if we have many of these, will it have an measurable impact on the code size? |
Super good question, for the AES it's size went from 3928 bytes to 4028 bytes which means we are looking at a 2.5% increase |
827f843 to
e8f93ca
Compare
|
Argh, you are definitely correct. I see that GCM costs a lot more giving 600 bytes which is around an 8% increase in size to wipe everything |
3cb4593 to
a4f7dbe
Compare
Use the cleanup attribute in order to attach a guard to cleanup the hardware. These functions are called when the variables go out of scope. Hence, we clear the hardware on both the succesful execution (as it was before) and on bad status output (which is new). Apply this new setting to the AES, CMAC, and GCM where we split the driver to no longer clean the HW when calling aes_end. Instead, we always call it from impl (and users using the drivers still can manually call the clean in drivers). Signed-off-by: Siemen Dhooghe <sdhooghe@google.com>
a4f7dbe to
69c4d28
Compare
Clean the HMAC and KMAC also on errors by using a cleanup attribute. Signed-off-by: Siemen Dhooghe <sdhooghe@google.com>
|
I instead refactored it to clean up the HW also on bad status returns. This was already the case for our PKE, but not yet for HMAC/KMAC/AES. This PR adds a total of 266 bytes of code, but gives meaningful protection |
nasahlpa
left a comment
There was a problem hiding this comment.
Nice - this is a great approach of making sure that we are properly cleaning the CL and its HW before releasing it.
Use the cleanup attribute in order to attach cleanup functions to a guard to cleanup the hardware. These functions are called when the variables go out of scope. Hence, we clear the hardware on both the succesful execution (as it was before) and on bad status output (which is new).