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.