What the developer wrote
Authored by ww3512687
driver optimzie
What changed, and why it matters
This commit updates the hardware random number generator (TRNG) driver in a cryptocurrency hardware wallet firmware. It adds detection for a physical tamper/attack signal from the TRNG chip and, if an attack is detected, wipes the random data and aborts. The change appears to be a security hardening fix: the previous driver could keep using random numbers even when the TRNG hardware reported a fault/attack condition.
Treat this as a security hardening patch. Review whether the assert/abort path is safe for all callers (e.g., seed generation, nonce generation), verify that `TRNG_GetITStatus` is cleared appropriately elsewhere, and confirm `memset_s` is implemented correctly on this platform. Consider whether a CVE is warranted if the prior behavior could produce predictable/non-random output during a fault.
Security signals we found
New check of TRNG_IT_RNG0_ATTACK tamper/attack interrupt status
Failure path now zeroes output and local buffer before aborting
Addition of ASSERT guards and secure memset_s usage
Driver previously continued copying TRNG data without checking attack/fault status
Evidence from the diff
The patch refactors drv_trng.c for the Keystone 3 firmware. It introduces TrngReadBlock(), which starts the TRNG and waits for data, but now also checks TRNG_IT_RNG0_ATTACK. If the attack interrupt status is set, it returns failure. TrngGet() now calls this helper in a loop; on failure it securely zeroes both the local buffer and the entire caller buffer, asserts (likely triggering a fault/reboot), and returns. The patch also adds null-pointer/length assertions and secure memset_s clearing of the local stack buffer. The previous code ignored the attack status and would copy TRNG output regardless of hardware fault state.
Changed components
src/driver/drv_trng.cTRNG0 driverfirmware random number generation pathInspect captured patch +29 / −5
### src/driver/drv_trng.c
@@ -1,7 +1,22 @@
#include "drv_trng.h"
#include "mhscpu.h"
-//#include "string.h"
-//#include "log_print.h"
+#include "mhscpu_trng.h"
+#include "assert.h"
+#include "user_memory.h"
+
+static bool TrngReadBlock(uint32_t output[4])
+{
+ TRNG_Start(TRNG0);
+
+ while (TRNG_Get(output, TRNG0) != 0) {
+ if (TRNG_GetITStatus(TRNG_IT_RNG0_ATTACK) == SET) {
+ return false;
+ }
+ }
+
+ // Data-ready and attack can be asserted at the same time.
+ return TRNG_GetITStatus(TRNG_IT_RNG0_ATTACK) == RESET;
+}
void TrngInit(void)
{
@@ -11,15 +26,24 @@ void TrngInit(void)
void TrngGet(void *buf, uint32_t len)
{
- uint32_t buf4[4];
+ uint32_t buf4[4] = {0};
+
+ ASSERT(buf != NULL || len == 0);
for (uint32_t i = 0; i < len; i += 16) {
- TRNG_Start(TRNG0);
- while (0 != TRNG_Get(buf4, TRNG0));
+ if (!TrngReadBlock(buf4)) {
+ memset_s(buf4, sizeof(buf4), 0, sizeof(buf4));
+ memset_s(buf, len, 0, len);
+ ASSERT(false);
+ return;
+ }
+
if (len - i >= 16) {
memcpy((uint8_t *)buf + i, buf4, 16);
} else {
memcpy((uint8_t *)buf + i, buf4, len - i);
}
}
+
+ memset_s(buf4, sizeof(buf4), 0, sizeof(buf4));
}Why this scored 59/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.