Bigmac attack: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 15: | Line 15: | ||
f00d processor stops updating CTR and bigmac no longer usable. | f00d processor stops updating CTR and bigmac no longer usable. | ||
=== Testing half a reset operation from ARM === | === Testing half a reset post-secure_kernel operation from ARM === | ||
The following was executed from post-secure_kernel lk ARM context: | The following was executed from post-secure_kernel lk ARM context: | ||
*REG32(0xE0010000) = 1 | *REG32(0xE0010000) = 1 | ||
==== Result ==== | ==== Result ==== | ||
No change in state. | 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". |
Revision as of 19:07, 24 June 2018
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".