Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replacement for Boot ROM aes_unwrap #7773

Merged
merged 7 commits into from
Jan 13, 2021

Conversation

mhightower83
Copy link
Contributor

@mhightower83 mhightower83 commented Dec 17, 2020

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 at 0x3FFFEA80, which may step on the SYS stack in special circumstances such as HWDT Stack Dump.

When not using WPS, the address space 0x3FFFE000 up to 0x40000000 is mostly available for the stacks. The one known exception is the ROM AES APIs. When aes_decrypt_init is called, it uses memory at 0x3FFFEA80 up to 0x3FFFEB30
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 stack
space. 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 function aes_decrypt_init. All other painted
memory in the area was untouched after starting WiFi.

static void aes_decrypt_deinit(void *ctx) {
if (ctx) {
ets_memset(ctx, 0, 16*11);
if ((uint32_t)ctx != 0x3FFFEA80ul) {
Copy link
Collaborator

@earlephilhower earlephilhower Dec 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you're now taking over responsibility for the buffer, can this if ever be true false?

Copy link
Contributor Author

@mhightower83 mhightower83 Dec 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Paranoid programming on my part.
It should be removed or may be changed to a DEV debug check.

Copy link
Contributor Author

@mhightower83 mhightower83 Dec 23, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I was a little confused. It is never needed. There should never be a problem with the buffer address being wrong in that way. Removed in the most recent push.

Copy link
Collaborator

@earlephilhower earlephilhower left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the potential random/unrepeatable failures this can avoid, I think it s well worth 170 bytes of IROM and a little heap during WiFi reconnect.

Copy link
Collaborator

@d-a-v d-a-v left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for hacking the FW !

@earlephilhower earlephilhower merged commit a4b6003 into esp8266:master Jan 13, 2021
@mhightower83 mhightower83 deleted the pr-aes_unwrap branch January 14, 2021 04:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants