Replacement for Boot ROM aes_unwrap #7773
Merged
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge. Suggestion cannot be applied right now. Please check back later.
This replacement is in and is required by the HWDT Stack Dump PR #7010 (comment).
This PR separates the fix out of the HWDT Stack Dump PR and makes the replacement
aes_unwrap
available all the time.While I have not seen issues outside of HWDT PR, there is a concern that the AES buffer in the stack address space issue may cause a crash or data corruption in some other sketch. This may be viewed as an overabundance of caution. I cannot prove it is needed beyond my special case. However, everybody's sketch is different. It does
adduse 304 bytes of IROM.This description is taken from the
aes_unwrap.cpp
module:Replacement for the ROM
aes_unwrap
() function. It uses the heap instead of the static DRAM address at0x3FFFEA80
, which may step on the SYS stack in special circumstances such as HWDT Stack Dump.When not using WPS, the address space
0x3FFFE000
up to0x40000000
is mostly available for the stacks. The one known exception is the ROM AES APIs. Whenaes_decrypt_init
is called, it uses memory at0x3FFFEA80
up to0x3FFFEB30
for a buffer. At the finish,
aes_decrypt_deinit
zeros out the buffer.The NONOS SDK appears to have replacements for most of the ROM's AES APIs. However, the SDK still calls on the ROM's
aes_unwrap
function, which uses the ROM's AES APIs to operate. These calls can overwrite some of the stackspace. To resolve the problem, this module replaces
aes_unwrap
.Final note, so far, I have not seen a problem when using the extra 4K heap option without the "debug HWDT". It is when combined with the HWDT Stack Dump that a problem shows. This combination adds a Boot ROM stack, which pushes up the SYS and CONT stacks into the AES Buffer space. Then the problem shows.
While debugging with painted stack space, during WiFi Connect, Reconnect, and about every hour, a block of memory
0x3FFFEA80
-0x3FFFEB30
(176 bytes) was zeroed by the Boot ROM functionaes_decrypt_init
. All other paintedmemory in the area was untouched after starting WiFi.