Repository navigation
Fault injection protection - #50
JamesHuard merged 8 commits into
Conversation
12ec658 to
6330714
Compare
(cherry picked from commit 12ec658)
6330714 to
32d027f
Compare
35abfa6
into
OpenDevicePartnership:mcxa-secure-boot
|
@felipebalbi @diondokter @JamesHuard This branch does not work. Pretty sure the registers are getting clobbered and are causing all sorts of unexpected behaviors. We need to revert the merge. I do have additional questions/concerns about the fault paths as well. |
|
One of the bigger concerns apart from the assembly itself: Seems like there is no protection around actual dev_mode detection (hinged on a single bit at its weakest without any guards). So, one fault in the actual dev_mode selection (SB turned on detection from Something else of concern (related, but minor): I know we explicitly set the CMPA security settings to all zeros in our provisioner, but no one is required to use it. And all erased CMPA with a valid header actually decodes as |
|
There was some logic in my original PR for protecting (or attempting to protect) the integrity of the data that drives the dev_mode decision. Their usefulness can be up for debate, but I'd image something to that effect would be needed (if not something completely different). |
|
Got the fix here: #55 |
…ten in fault rejection (#55) This should fix what @alamfarjadf saw here: #50 (comment) What happened was that one of the allocated registers was the LR register. I don't know why that's being picked as it sounds like a terrible choice. The value would get overwritten by the first `bl` instruction which caused the `body` closure to not get called (properly). By allocating the registers manually, we know they're ok to use. In the disassembly I can also see these registers are pushed and popped to/from the stack as they should.
Please review (and merge) #49 first.
This PR builds on top of it
This PR adds a protectec-if routine that protects against single instruction fault injection.