[Safe 7] HASH peripheral is fully locked inside secmon, firmware has no way to use it

[DinhMaiMTD]

Hi team,

This issue focuses specifically on Trezor Safe 7 (T3W1, STM32U5G9).

I'd like to report what looks to me like an overly tight resource partitioning: the HASH peripheral (SHA256 hardware accelerator) is fully locked into the secure world, and the main firmware (non-secure, running after secmon hands over) has no way to reach it.

HASH is a shared accelerator — it holds no secret, is not bound to any key, anyone can hash their own data with it. But on a T3W1 build (USE_SECMON_LAYOUT=1, USE_HASH_PROCESSOR=1) the situation is:

• secmon calls hash_processor_init() in drivers_init() (core/embed/projects/secmon/main.c).
• secmon-side tz_init() sets GTZC_PERIPH_HASH and GPDMA1 channel 12 as secure & privileged core/embed/sec/trustzone/stm32u5/tz_init.c).
• At the end of tz_init, GTZC TZSC1/TZSC2 have the LCK bit set, so the attributes cannot be flipped until system reset.
• The whole of core/embed/sec/hash_processor/stm32u5/hash_processor.c is wrapped in #ifdef SECURE_MODE, so the symbols don't even exist on the non-secure side to link against.
• smcall_numbers.h / smcall_dispatch.c contain no SMCALL wrapping hash_processor_sha256_. (The existing SMCALL_FIRMWARE_HASH_ is for the BLAKE2s firmware-image hash, unrelated to the HASH peripheral.)

So from the non-secure side, there is no path at all — direct MMIO is blocked by GTZC IAC, and there is no SG stub to call through secmon. The Safe 7 main firmware is forced to fall back to software SHA256 even though the STM32U5G9 has a hardware accelerator sitting idle after init.

I'm not sure whether this is an intentional decision or just the default when secmon was written, so my questions are:

1. Is there a specific security reason for keeping the HASH eripheral secure-only on Safe 7?
2. If not, would the team consider opening it up for the main firmware to use?

Thanks!