mirror of
https://github.com/saymrwulf/xous-core.git
synced 2026-11-04 04:27:34 +00:00
b99b4cb665
Signature checking parameters are now consolidated into a single "SecurityConfiguration" record. This allows the sum total of security state transitions to be summarized in the bao1x-api/src/pubkeys/mod.rs file, easing maintenance and audit. Reaction to the signature check is split into a `hardened_erase_policy` API call which can take the results of the signature check and react to it if necessary. This allows the signature check routine to be used for both audit (where reaction is not necessary) and for live testing of the code (where reaction is required). It also simplifies the implementation of double-checking signatures in the case of paranoid mode. Another important improvement is that the signature checking API outputs the target address for the jump, but masked with an XOR of the function code of the signed block. The purpose of the XOR mask isn't to obfuscate the value; rather, it's to prevent there being a single, simple, fixed-constant jump instruction laying around that a glitcher can use as a target: instead, a pair of registers must be loaded with the target and its mask. This is an example of what the final jump looks like: ``` 60003a8e: ffffffff .word 0xffffffff 60003a92: 0440006f j 60003ad6 <bao1x_hal::hardening::die> 60003a96: ffffffff .word 0xffffffff 60003a9a: 167d addi a2,a2,-1 60003a9c: fe71 bnez a2,60003a78 <rust_entry+0x2f74> 60003a9e: a00d j 60003ac0 <rust_entry+0x2fbc> 60003aa0: 0360006f j 60003ad6 <bao1x_hal::hardening::die> 60003aa4: ffffffff .word 0xffffffff 60003aa8: 02e0006f j 60003ad6 <bao1x_hal::hardening::die> 60003aac: ffffffff .word 0xffffffff 60003ab0: 0260006f j 60003ad6 <bao1x_hal::hardening::die> 60003ab4: ffffffff .word 0xffffffff 60003ab8: 01e0006f j 60003ad6 <bao1x_hal::hardening::die> 60003abc: ffffffff .word 0xffffffff 60003ac0: 0149c533 xor a0,s3,s4 60003ac4: 600805b7 lui a1,0x60080 60003ac8: d0058593 addi a1,a1,-768 # 6007fd00 <_etext+0x6e9dc> 60003acc: 82aa mv t0,a0 60003ace: 852e mv a0,a1 60003ad0: 4581 li a1,0 60003ad2: 8282 jr t0 ``` So here you can see the alternating bollards in the region that will cause any glitches that don't land exactly right to either halt the machine or cause a reaction. Line 0x6003ac0 is where the xor happens to compute the target address. Should a glitcher land on that address, `s3` and `s4` will need to be loaded with the target address and a value when XOR'd with it that yields a meaningful result. While there is a non-zero chance that this can be arranged, it's definitely not as easy as targeting a jump-to-fixed address exit sequence. |
||
|---|---|---|
| .. | ||
| bao1x-api | ||
| bao1x-hal | ||
| blitstr2 | ||
| chat | ||
| cos_table | ||
| flatipc | ||
| flatipc-derive | ||
| keystore-api | ||
| mass-storage | ||
| perflib | ||
| precursor-hal | ||
| tls | ||
| userprefs | ||
| ux-api | ||
| xous-bio | ||
| xous-bio-bdma | ||
| xous-pio | ||
| xous-pl230 | ||