Hi Slawomir,

Thanks for reporting this issue and for sharing the patch.

I was able to reproduce the SecureFault on memory-mapped reads from external flash in the NS domain. I also tested your proposed fix successfully, along with a few related improvements on our side.

The correction is currently under internal review. If no blocking issue is found, we expect to upstream it soon.

Regarding your remark on code organization, this is something we are aware of, and we agree it should be improved. This work is identified, but it is not yet formally scheduled as we currently have other priorities in progress.

Thanks again for the clear report and practical proposal.

Best regards, Marc JACOB

From: Sławomir Piotrowski via TF-M tf-m@lists.trustedfirmware.org Sent: Thursday, June 11, 2026 3:34 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Stm32: Memory mapped external Flash not available for non secure domain

Hello,

I'm working with the STM32U585 on the b_u585i_iot02a board using Zephyr and TF-M.

Currently, the OSPI2 controller itself is correctly assigned to the Non-Secure (NS) domain, allowing standard indirect flash operations. However, when I enable the Memory-Mapped mode for the external flash, any read attempt (e.g., using memcpy via flash_read) immediately triggers a SecureFault.

This happens because the memory-mapped region (0x70000000) is not configured as Non-Secure in the SAU and GTZC (MPCWM) during the TF-M boot process.

Since the configuration file (platform/ext/target/stm/common/stm32u5xx/secure/target_cfg.c) is located in the common directory rather than the board-specific folder, it's difficult to override this behavior cleanly in an out-of-tree custom board definition. Proposed Solution:

I suggest adding a conditional configuration in target_cfg.c that checks for board-specific definitions (e.g., EXTERNAL_FLASH) to explicitly allow NS/Unprivileged read access to the OSPI mapped region. I have attached a patch demonstrating this simple fix.

Note: Since the OSPI peripheral is already exposed to the NS domain, granting access to its memory-mapped region does not introduce a new security risk (an attacker could already read the flash via indirect commands). It simply restores the intended functionality.

Alternatively, an architectural redesign - such as moving board-specific security configs out of common or providing __weak hooks for board files - would be ideal, but this simple patch resolves the immediate blocker.

thank you, Sławomir Piotrowski