Trezor firmware

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.

This patch fixes a kernel crash that could occur when an external (untrusted) application running on the Trezor device faults. The crash happened because the kernel tried to read a return address from a memory region it was not allowed to access. The fix temporarily relaxes memory protection just long enough to safely read that address, then restores it. It is a stability/reliability fix in a security-sensitive component, but the commit itself does not claim it is exploitable for theft of funds or secrets.

This commit introduces a new application loader and cache subsystem for the Trezor firmware. It adds code that loads external ELF-format applications into memory, manages their execution as isolated applets, and handles memory allocation for them. The change is a feature addition, not a documented security fix. The code includes a prominent warning that the STM32 ELF loader implementation should not be shipped in production devices. There is no evidence in the commit or supplied references that this resolves a known security incident or vulnerability.

This commit adds a new MicroPython module called `trezorapp` that lets Python code create, write, finalize, and run third-party application images inside the Trezor firmware. It is a feature implementation rather than a bug fix, and there is no direct evidence in the commit that it fixes a security vulnerability. However, because it exposes low-level app loading and task control to Python, any weaknesses in the underlying `app_cache`/`app_loader` C code or in how Python callers use this wrapper could become security-relevant. The commit itself does not describe security relevance, credit a researcher, or acknowledge a vulnerability report.

This commit adds a brand-new inter-process communication (IPC) subsystem to the Trezor firmware kernel. It lets separate software tasks send fixed-size messages to each other through kernel-managed queues, with memory copies that temporarily disable the memory-protection unit on STM32 hardware. There is no claim in the commit that this fixes a security bug; it appears to be a new feature. The code includes access checks (verifiers) for the user-space syscall path, but because this is a new and complex kernel mechanism, any mistakes in the queue logic or memory copying could become security issues in the future.

This commit adds a new internal API surface called 'coreapp API' that lets the core firmware expose a small set of system services (timers, events, debug console, IPC, and shutdown helpers) to a separate 'coreapp' component. It is only enabled for the T3W1 model and is guarded by an 'app_loading' build feature. The change is architectural: it wires a function-pointer getter into the vector table and stores it in the coreapp header so the coreapp can request versioned API tables. There is no direct evidence in the commit of a vulnerability, exploit, or security fix; it appears to be a feature introduction for future app-loading support.

This commit adds a new build-time switch called EXTAPP_SUPPORT. When turned off (the default), it prevents the 'app_loading' feature from being compiled into firmware for the T3W1 model. This is purely a build-system/configuration change and does not alter runtime behavior, fix a bug, or change any security-critical code path on its own.

This commit changes a single internal constant so the device can keep track of one extra background process when the optional app-loading feature is enabled. By itself it does not look like a security fix or vulnerability; it appears to be a straightforward capacity increase for a new feature.