feat(core): only allow kernel to access specific records in backup ram
What the developer wrote
Authored by tychovrahe
feat(core): only allow kernel to access specific records in backup ram
[no changelog]
What changed, and why it matters
This commit tightens access control on a special memory area called 'backup RAM' in Trezor's secure core. Previously, the kernel could potentially read or write any record in backup RAM through verified system calls. Now it is restricted to only two specific records: one related to power-management recovery and one related to Bluetooth settings. This reduces the damage if malicious or buggy kernel code tries to access sensitive records it should not touch.
Treat as a security hardening improvement. Review whether any legitimate kernel code currently relies on accessing other backup RAM keys through these verified calls, as the whitelist would now block such access. Consider whether the two allowed keys themselves require additional integrity or confidentiality protections.
Security signals we found
Addition of an explicit access-control check in verified syscall wrappers
Restriction of kernel-accessible backup RAM keys to a whitelist of two records
Use of existing `apptask_access_violation()` enforcement path
No changelog entry, consistent with internal hardening
Targets SECURE_MODE build only
Evidence from the diff
The change introduces backup_ram_kernel_accessible() in the STM32U5 backup RAM driver, which returns true only for BACKUP_RAM_KEY_PM_RECOVERY and BACKUP_RAM_KEY_BLE_SETTINGS. The existing backup_ram_read__verified() and backup_ram_write__verified() secure-monitor-call verifiers now call this function and trigger apptask_access_violation() if the key is not kernel-accessible. This is a defense-in-depth hardening change that limits the kernel’s backup RAM access surface.
Changed components
core/embed/sys/backup_ram/stm32u5/backup_ram.ccore/embed/sys/smcall/stm32/smcall_verifiers.ccore/embed/sys/backup_ram/inc/sys/backup_ram.hInspect captured patch +20 / −0
diff --git a/core/embed/sys/backup_ram/inc/sys/backup_ram.h b/core/embed/sys/backup_ram/inc/sys/backup_ram.h
index b56cb756d..af0eadbbf 100644
--- a/core/embed/sys/backup_ram/inc/sys/backup_ram.h
+++ b/core/embed/sys/backup_ram/inc/sys/backup_ram.h
@@ -127,3 +127,10 @@ bool backup_ram_write(uint16_t key, backup_ram_item_type_t type,
*/
bool backup_ram_read(uint16_t key, void* buffer, size_t buffer_size,
size_t* data_size);
+
+/**
+ * @brief Determines if a key is accessible by the kernel.
+ * @param key Key to check
+ * @return true if the key is accessible by the kernel, false otherwise
+ */
+bool backup_ram_kernel_accessible(uint16_t key);
diff --git a/core/embed/sys/backup_ram/stm32u5/backup_ram.c b/core/embed/sys/backup_ram/stm32u5/backup_ram.c
index 7ed2756c5..e982d7c64 100644
--- a/core/embed/sys/backup_ram/stm32u5/backup_ram.c
+++ b/core/embed/sys/backup_ram/stm32u5/backup_ram.c
@@ -511,4 +511,9 @@ cleanup:
return success;
}
+bool backup_ram_kernel_accessible(uint16_t key) {
+ return (key == BACKUP_RAM_KEY_PM_RECOVERY ||
+ key == BACKUP_RAM_KEY_BLE_SETTINGS);
+}
+
#endif // SECURE_MODE
diff --git a/core/embed/sys/smcall/stm32/smcall_verifiers.c b/core/embed/sys/smcall/stm32/smcall_verifiers.c
index 8037e8779..ab777c514 100644
--- a/core/embed/sys/smcall/stm32/smcall_verifiers.c
+++ b/core/embed/sys/smcall/stm32/smcall_verifiers.c
@@ -525,6 +525,10 @@ bool backup_ram_read__verified(uint16_t key, void *buffer, size_t buffer_size,
goto access_violation;
}
+ if (!backup_ram_kernel_accessible(key)) {
+ goto access_violation;
+ }
+
return backup_ram_read(key, buffer, buffer_size, data_size);
access_violation:
apptask_access_violation();
@@ -537,6 +541,10 @@ bool backup_ram_write__verified(uint16_t key, backup_ram_item_type_t type,
goto access_violation;
}
+ if (!backup_ram_kernel_accessible(key)) {
+ goto access_violation;
+ }
+
return backup_ram_write(key, type, data, data_size);
access_violation:
apptask_access_violation();
Why this scored 64/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.