Repository navigation
fix(secure_boot): write the rollback counter to its own OTP field #160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,10 +16,14 @@ | |
| #include "eos_hal.h" | ||
| #include <string.h> | ||
|
|
||
| /* OTP offsets for root-of-trust */ | ||
| /* OTP offsets for root-of-trust. The map is docs/key_lifecycle.md 3.2 | ||
| * with OTP base 0x100: key slots at 0x100/0x120 and the revoke mask at | ||
| * 0x140 (core/keystore.c), the security_version counter at 0x144. 0x180 | ||
| * holds the recovery shared secret (core/recovery.c), so the counter must | ||
| * never be written there. */ | ||
| #define OTP_KEY_HASH_OFFSET 0x100 | ||
| #define OTP_KEY_HASH_SIZE 32 | ||
| #define OTP_ROLLBACK_OFFSET 0x180 | ||
| #define OTP_ROLLBACK_OFFSET 0x144 | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
| #define OTP_DEBUG_LOCK_OFFSET 0x1F0 | ||
|
|
||
| /* Global attestation log — persisted in RAM for kernel to read */ | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟠 High · Rollback floor does not advance
When an external caller raises the floor on a board whose monotonic hooks are separate from raw OTP writes, or a later value requires clearing a programmed OTP bit,
eos_secure_boot_update_rollback()writes ordinary big-endian bytes directly to OTP, whileeos_rollback_verify()reads the floor througheos_hal_monotonic_read()and advances it througheos_hal_monotonic_increment(). The write therefore fails or leaves the checked floor unchanged, despite returning success.Advance the requested rollback floor through the monotonic HAL interface so updates use the same counter that boot verification checks.
Prompt for AI agents