Don’t use `random_buffer` in the simulator
What the developer wrote
Authored by Greg Pfeil
Don’t use `random_buffer` in the simulator
The implementation isn’t compiled for the simulator, so trying to call
it breaks compilation.
What changed, and why it matters
This is a minor build-fix change for the software simulator. It wraps a call to a hardware-specific random-number function so the simulator can compile. It does not change real-device behavior or introduce a security vulnerability.
No security action required. If the simulator needs deterministic or mock randomness for tests, consider explicitly providing a simulator-only implementation rather than leaving the buffer unfilled, but this is a testing/quality concern, not a product security issue.
Security signals we found
No strong security signals were identified.
Evidence from the diff
The commit adds #ifndef COMPILE_SIMULATOR around random_buffer(randomness, len) in GenerateTRNGRandomness(). The random_buffer implementation is not compiled for the simulator target, so the call caused a build failure. In simulator builds the function now returns SUCCESS_CODE without filling the buffer. On real firmware builds (COMPILE_SIMULATOR not defined) behavior is unchanged.
Changed components
src/managers/keystore.cInspect captured patch +2 / −0
diff --git a/src/managers/keystore.c b/src/managers/keystore.c
index 04bf506..1cdf58c 100644
--- a/src/managers/keystore.c
+++ b/src/managers/keystore.c
@@ -827,7 +827,9 @@ void random_buffer(uint8_t *buf, size_t len)
int32_t GenerateTRNGRandomness(uint8_t *randomness, uint8_t len)
{
+#ifndef COMPILE_SIMULATOR
random_buffer(randomness, len);
+#endif
return SUCCESS_CODE;
}
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.