refactor(core/embed): factor out `lt_r_mem_data_erase_write()`
What changed, and why it matters
This commit is a simple code cleanup: it extracts a repeated two-step operation (erase then write) into a single helper function and updates the only existing caller to use it. There is no change to what the code actually does, only to how it is organized. No security issue is introduced or fixed.
No action required; this is a non-functional refactor.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The diff refactors core/embed/sec/tropic/tropic.c by adding lt_r_mem_data_erase_write() and lt_r_mem_data_erase_write_time(), then replaces the inline erase+write sequence in tropic_pin_set_kek_masks() and tropic_pin_set_kek_masks_time() with calls to these helpers. Behavior is identical: erase is still performed, then write, and the same error path (goto cleanup) is preserved. Timing accounting is unchanged (55 ms + 77 ms).
Changed components
core/embed/sec/tropic/tropic.cInspect captured patch +20 / −9
diff --git a/core/embed/sec/tropic/tropic.c b/core/embed/sec/tropic/tropic.c
index 1779fcb90..229f5841c 100644
--- a/core/embed/sec/tropic/tropic.c
+++ b/core/embed/sec/tropic/tropic.c
@@ -455,11 +455,27 @@ static void lt_r_mem_data_write_time(uint32_t *time_ms) {
*time_ms += 77;
}
+static void lt_r_mem_data_erase_time(uint32_t *time_ms) { *time_ms += 55; }
+
static void lt_mcounter_get_time(uint32_t *time_ms) { *time_ms += 51; }
static void lt_mcounter_update_time(uint32_t *time_ms) { *time_ms += 51; }
-static void lt_r_mem_data_erase_time(uint32_t *time_ms) { *time_ms += 55; }
+lt_ret_t lt_r_mem_data_erase_write(lt_handle_t *h, const uint16_t udata_slot,
+ uint8_t *data, const uint16_t size) {
+ lt_ret_t ret = lt_r_mem_data_erase(h, udata_slot);
+ if (ret != LT_OK) {
+ return ret;
+ }
+
+ return lt_r_mem_data_write(h, udata_slot, data, size);
+}
+
+lt_ret_t lt_r_mem_data_erase_write_time(uint32_t *time_ms) {
+ lt_r_mem_data_erase_time(time_ms);
+ lt_r_mem_data_write_time(time_ms);
+ return LT_OK;
+}
static uint32_t g_change_pin_counter_cached = 0;
static bool g_is_change_pin_counter_cached = false;
@@ -727,12 +743,8 @@ bool tropic_pin_set_kek_masks(
uint16_t masked_kek_slot = get_kek_masks_slot(drv);
- if (lt_r_mem_data_erase(&drv->handle, masked_kek_slot) != LT_OK) {
- goto cleanup;
- }
-
- if (lt_r_mem_data_write(&drv->handle, masked_kek_slot, masks,
- sizeof(masks)) != LT_OK) {
+ if (lt_r_mem_data_erase_write(&drv->handle, masked_kek_slot, masks,
+ sizeof(masks)) != LT_OK) {
goto cleanup;
}
@@ -746,8 +758,7 @@ cleanup:
}
void tropic_pin_set_kek_masks_time(uint32_t *time_ms) {
- lt_r_mem_data_erase_time(time_ms);
- lt_r_mem_data_write_time(time_ms);
+ lt_r_mem_data_erase_write_time(time_ms);
}
bool tropic_pin_unmask_kek(
Why this scored 15/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.