Bigmac attack
Testing parameters for resetting the f00d processor. On normal boot ARM resets the f00d processor to load secure_kernel writing:
*REG32(0xE0010000) = 1; *REG32(0xE0010000) = 0;
Testing this from lk after secure_kernel results in no change in state. The testing material is a f00d payload that is constantly updating a counter in DRAM. f00d state is verified by checking if this counter is updated.
Testing reset from f00d
The following is executed from f00d context:
*REG32(0xE0010000) = 1; *REG32(0xE0010000) = 0;
Result
f00d processor stops updating CTR and bigmac no longer usable.
Testing half a reset post-secure_kernel operation from ARM
The following was executed from post-secure_kernel lk ARM context:
*REG32(0xE0010000) = 1
Result
No change in state.
Testing half a reset pre-secure_kernel operation from ARM
The following was executed from post-secure_kernel lk ARM context:
*REG32(0xE0010000) = 1
Result
secure-kernel failed to load, stuck at "wait 2".
Investigation of f00d reset registers
xSleep signal response
The theory here is that the f00d reset would only work after responding to xSleep signal from the f00d processor. This idea was inspired from second_loader and secure_kernel always ending with a sleep loop.
Result
reset is still unavailable from ARM after f00d is sleeping.
f00d reset from ARM window
ARM can reset f00d to start secure_kernel. Once secure_kernel is started this functionality to reset f00d from ARM is disabled through some unknown mechanism.
f00d reset using bigmac
bigmac cannot be used to set *0xE0010000 = 0 or *0xE0010000 = 1.