Fixed value for reset vector #76
-
|
I want to use rustBoot to boot firmware that is not written in Rust itself. I then, of course, need to implement update_trigger and update_success, which seems easy enough. However, I have another problem. It seems rustBoot checks the reset vector of the firmware and panics if it is not the expected value. When I build a project in, for example, STM32CubeIDE, the reset vector is not the same as in the firmware examples provided in rustBoot. What is the rationale behind enforcing a specific value for the reset vector? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
The rationale: assuming we have a fully verified boot-chain i.e. where rustBoot is verified by (something like) a BootROM, rustBoot tries to prevent potential attackers from hijacking the boot-flow by replacing the contents of the reset vector to load unauthorised (or malicious) firmware from an address other than the expected (or trusted) one. We can extend this idea to cases where rustBoot serves as a second or third stage boot-loader. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't it enough that the reset vector is part of the signed image? If someone tampers with it I would assume the signature check would fail. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delay, I've been away on business travel. In theory - verifying cryptographic signatures should suffice. However, an attacker (depending on the level of access to hardware and available HW protections) might still be able to take advantage of what's usually referred to as TOC/TOU (time of check Vs. time of use.), where they can potentially replace contents of the reset vector post verification. Performing a hard-coded check is just an additional measure to make it harder. Nonetheless, we should probably put this behind a conditional compilation flag. |
Beta Was this translation helpful? Give feedback.
Sorry for the delay, I've been away on business travel. In theory - verifying cryptographic signatures should suffice. However, an attacker (depending on the level of access to hardware and available HW protections) might still be able to take advantage of what's usually referred to as TOC/TOU (time of check Vs. time of use.), where they can potentially replace contents of the reset vector post verification.
Performing a hard-coded check is just an additional measure to make it harder. Nonetheless, we should probably put this behind a conditional compilation flag.