Trezor firmware

This commit adds a new hardware safety feature to Trezor firmware that detects when a device's battery appears to be physically disconnected (by checking if the battery voltage drops below 0.5 V). When disconnection is detected, the firmware now reports a 'Battery Disconnected' error and disables charging. It also fixes an unrelated bug where a temperature-control event flag was not being exposed to the user interface. There is no indication in the commit that this is a security fix for an exploitable vulnerability; it reads as a normal product-safety and diagnostics improvement.

This commit adds a new factory-testing command called pm-battery-test to Trezor's production-test firmware. It simply reads the battery voltage and temperature several times and reports whether the values are within expected hardware limits. There is no user-facing wallet feature, no handling of secrets, and no security-relevant change.

This commit adds a new internal counter that tracks how much charge has flowed through the device's battery over time, similar to an odometer for battery wear. The counter is calculated and stored in memory, but the code that would actually report or save the value is commented out and not active. There is no security-relevant change here.

This is a small internal code cleanup in the power-management code for Trezor hardware wallets. It removes a redundant flag (`fuel_gauge_initialized`) and instead asks the battery fuel-gauge subsystem directly whether it is locked/initialized. There is no user-facing change, no obvious security bug being fixed, and no changelog entry.

This commit is a code refactor that moves the battery fuel-gauge and battery-model code into a single, cleaner API. It does not add new user-facing features or fix a security bug. The change reorganizes existing battery estimation logic so other parts of the firmware call a new 'battery' module instead of calling the fuel-gauge and battery-model pieces directly. There is no indication in the commit that this is a security patch.

This commit tightens how a Trezor production-test tool parses X.509 certificate data. It replaces loose 'read the next item' calls with stricter 'read the item only if it has the expected tag' calls. That reduces the chance that a malformed or crafted certificate could trick the parser into misinterpreting fields, but the change is in an internal manufacturing/testing tool, not the main wallet firmware that protects user funds.

This is a routine feature addition to Trezor's cryptographic library. It adds helper functions for comparing DER-encoded data items and reading an item with an expected tag, plus a constant for OID tags and minor const-correctness cleanups. There is no indication of a security bug being fixed.

This commit only updates documentation. It renames a developer tutorial, fixes links, adds a new hardware model (Trezor Safe 7) to reproducible-build instructions, and refreshes code examples. No firmware, bootloader, or cryptographic code is changed, so it cannot directly affect device security.

This commit changes the Trezor production-test command-line interface so that CRC checksums can be applied either globally or per-command using a new 'checked-' prefix. It is a feature addition, not a fix for an exploitable vulnerability. The change does touch CRC parsing code, but the diff shows no obvious security bug such as buffer overflow or bypass. The main risk is that any mistake in the new CRC logic could weaken integrity checks for a low-privilege manufacturing/debug interface.

This commit only rewrites code comments in a single header file to follow Doxygen documentation style. It does not change any executable code, logic, or security behavior. The only functional-looking addition is a new error-code constant named CLI_ERROR_INVALID_CRC, but it is just a string literal definition with no code using it, so it cannot by itself create a vulnerability.

This commit adds two new commands to Trezor's production-test firmware: one that writes hex data into a small RAM buffer and one that reads it back. It is a test/debugging feature, not the normal wallet firmware users carry. The commands only touch a fixed 4 KB RAM buffer and do not directly read or write arbitrary memory addresses, so they appear limited in scope. However, adding interactive memory-style commands to a low-level test tool can be a stepping stone for deeper hardware attacks if combined with other vulnerabilities.

This commit adds an optional CRC-32 checksum feature to the Trezor production-test command-line interface (prodtest CLI). It is a data-integrity feature, not a fix for an existing security vulnerability. The change lets factory-test tools request that every command and response include a CRC checksum, helping detect accidental communication corruption. There is no indication in the commit that this addresses a known attack or security flaw.

This commit only rewrites code comments in three header files to use a Doxygen documentation style. It does not change any program logic, function signatures, data structures, or security behavior. There is no indication of a security fix or vulnerability.

This commit is a code cleanup that lets the Trezor firmware's emulator (used for testing on regular computers) run the core application as a separate 'applet' task, similar to how it runs on real hardware. It merges two setup functions into one and adds a Unix-specific implementation. There is no indication this fixes a security bug or introduces a vulnerability.

This commit cleans up how the Trezor firmware emulator (Unix build) shuts down its fake SD card and flash memory. Previously, these emulated memory buffers were automatically unmapped when the program exited via atexit handlers. The commit removes those automatic exit handlers and instead exposes explicit cleanup functions (sdcard_deinit, flash_deinit) that callers can invoke directly. The display emulator also loses its atexit-based deinit. This is a code-quality and resource-management change; it does not appear to fix an exploitable security vulnerability.

This commit is a code cleanup and architectural refactor for the Trezor firmware's Unix emulator. It moves the emulator startup logic into a new 'coreapp' task structure and splits hardware/driver initialization into a separate file. There is no indication in the commit that this fixes a security vulnerability or changes security-sensitive behavior; it appears to be internal restructuring only.

This commit rewrites how the Trezor firmware's kernel cleans up after the main user-interface app (the 'coreapp') finishes or crashes. It replaces a simple 'stop' function with a new 'unload' path that always clears the app's memory and, on real hardware, disables the special memory/peripheral access rights that were granted while the app ran. The change also adds a check so the kernel only tries to clean up tasks that were actually initialized. Overall it looks like a hardening/cleanup improvement rather than a new vulnerability, though the commit is a refactor and the diff alone cannot prove no bugs were introduced.

This small firmware change prevents the Trezor device from going to sleep or adding artificial delays when event pollers are still active. Previously, the code always paused after each polling loop, even if it had just woken up a task. Now it only pauses when no task was actually woken. The main practical effect is better responsiveness and lower latency, not a security fix.

This commit fixes a bug in how the Trezor hardware wallet's memory protection unit (MPU) is reconfigured when switching to or from a small helper program ('applet'). Previously, the code could read from a NULL pointer and store an invalid value, which might weaken memory isolation between the main firmware and the applet. The fix ensures the applet layout pointer is checked before use and the TLS (thread-local storage) area is safely zeroed when no applet is active.

This commit changes the memory protection unit (MPU) configuration in Trezor's STM32U5 firmware so that small helper programs ('applets') can run from RAM (SRAM) in addition to running from flash memory. Previously, applets were assumed to live in flash. The change adds a new memory region type for executable SRAM and checks whether an applet's code starts in flash; if not, it marks the SRAM region as executable. This is a feature addition, not a bug fix, and there is no direct evidence in the commit that it fixes a security vulnerability. However, allowing code execution from SRAM can increase attack surface if an attacker can write to that RAM, because executable writable memory is generally less safe than execute-only flash.

This commit is a tiny code cleanup in the memory-protection unit (MPU) code for the Trezor hardware wallet. It only adds the word 'const' to a function parameter in four files, meaning the function promises not to modify the input structure. No behavior of the device changes, and there is no security fix or vulnerability here.

This commit fixes a scheduling bug in the Trezor firmware's task-switching system. When the device switched from a small temporary 'applet' back to the main 'coreapp', the old code simply jumped tasks without telling the event scheduler to put the current task back on the runnable list. That could leave the current task unscheduled or cause a null-pointer write when the scheduler later tried to record which events woke it up. The patch adds a proper 'yield and reschedule' helper and guards the null-pointer write.

This commit adds a new internal feature to the Trezor firmware: a MicroPython wrapper that lets Python code send and receive inter-process communication (IPC) messages to another system task. It is a feature implementation, not a bug fix, and nothing in the commit or supplied references indicates it addresses a security vulnerability.

This commit adds a software-based emulation of Trezor's multitasking 'systask' system for the desktop emulator. Previously the emulator faked task functions as empty stubs; now it uses real POSIX threads and condition variables to mimic how tasks switch on the real hardware. It also moves some system shutdown helpers into a shared file used by both real devices and the emulator. There is no direct evidence this fixes a security bug; it is primarily an engineering change to make the emulator behave more like the real device.

This commit adds a new ELF (Executable and Linkable Format) loader to the Trezor firmware. It is marked as a feature implementation and explicitly carries a 'DO NOT SHIP THIS FILE' warning for production builds. The code parses ELF files, loads code and data segments, applies relocation fixups, and sets up memory protection for applets. Because this is new, complex parsing code that handles attacker-influenced binary data and modifies memory, it is security-relevant, but the commit itself does not describe a vulnerability and the production guard suggests it is not intended for release as-is.