STM32H563 TrustZone DMA: A Completed Transfer Can Still Contain Blocked Accesses

On STM32H563, DMA completion alone is not proof that the requested bytes crossed a TrustZone boundary. RM0481 explicitly documents blocked accesses that complete while writes are ignored and reads return zeros. A completion handler that reports success without considering security attribution can therefore conceal the actual failure.

This article uses the H563 system-security behavior in RM0481 Rev 5, especially Table 13. It concerns an authorized application's DMA integration, not bypassing security controls. No target transfer or security test was executed.

Separate channel ownership from transaction security

A channel has a secure/nonsecure assignment through SECx. When it is secure, secure software can independently select the source and destination transaction attributes with SSEC and DSEC. These are distinct decisions: a secure-owned channel is not a command to treat every source and destination as secure.

The target memory or peripheral has its own security attribution. A valid transfer requires the channel and transaction choices to fit those target attributes. Review the actual source and destination intervals, including their memory aliases and protection granularity, rather than inferring permission from the caller's current CPU security state.

The RM0481 GPDMA security description makes the nonsecure-memory cases explicit. For a secure channel reading nonsecure memory, SSEC must be zero. For one writing nonsecure memory, DSEC must be zero. A secure channel moving between two nonsecure memory regions requires both settings to be zero.

These are the documented memory cases, not a blanket instruction to clear both bits for every transfer. A peripheral's attribution and the actual secure/nonsecure route still have to be checked. A nonsecure channel cannot use this configuration to access a secure source or destination.

Understand what blocked completion means

Table 13's first footnote states that blocked transfers complete, with the corresponding writes ignored and reads returning zeros. It also says the source or destination target automatically triggers an illegal-access event to TZIC.

This explains two plausible observations. A destination may retain its old contents despite a completed operation because the relevant writes were blocked. Alternatively, a destination may contain zeros obtained from blocked reads. Neither observation is enough by itself to identify the cause: a legitimately zero-valued source and an unrelated buffer error are also possible.

The diagnostic distinction comes from combining the data result with the configured security route and the illegal-access evidence. Do not respond by repeatedly clearing DMA status and retrying the same incorrectly attributed transfer. That can produce repeated completion without changing the condition that rejected the access.

Include TZIC in the observation path

The H562/H563 datasheet's GTZC description identifies TZIC as the block collecting security illegal-access events and generating a secure interrupt. The relevant event handling and observation must be integrated deliberately; an application log that records only the DMA interrupt can omit the decisive evidence.

For diagnosis, record the channel's secure assignment, source/destination transaction attributes, the target-region security configuration and the relevant illegal-access status. Use addresses and public configuration identifiers appropriate for the product's diagnostic policy. There is no need to expose secret payloads to determine whether an access was rejected.

Use controlled, nonsecret test buffers with different source and destination patterns. An all-zero source makes a blocked-read result harder to distinguish. An unchanged destination sentinel makes ignored writes visible. Those patterns are diagnostic aids, while the security-event evidence and register configuration establish the mechanism being tested.

Review descriptors and reassignment as well

The same manual section says a secure channel fetches linked-list structures with secure transfers. Descriptors are therefore another memory object in the security design. An accessible payload does not prove that descriptor fetches use a correctly attributed region.

Also avoid changing a channel from secure to nonsecure while its prior transfer remains active. The manual requires secure software to abort the channel or wait for completion before switching it to a nonsecure state. Reassignment must include the relevant driver completion or abort contract, rather than merely rewriting an ownership bit and immediately exposing the channel to another client.

Nonsecure software also cannot inspect secure-channel registers as ordinary readable state: the documented channel registers read as zero and ignore nonsecure writes, with the stated exceptions for shared configuration registers. A debugger or diagnostic routine in the wrong security context can thus produce misleading zeros before any payload transfer is attempted.

Make the acceptance result specific

For a permitted nonsecure-memory transfer owned by a secure channel, verify the matching SSEC/DSEC settings, expected bytes and absence of the relevant illegal-access indication under the configured observation scheme. For an approved negative fixture, use disposable nonsecret regions and verify that the deliberately disallowed route is rejected as documented.

A passing negative case demonstrates the selected route's denial behavior; it does not establish isolation for every master or target in the device. Keep that scope in the report.

The release criterion is more precise than “DMA complete”: the intended route was authorized, the expected bytes arrived, and security diagnostics agree with that outcome. This closes a concrete H563 integration gap without weakening the protection that exposed it.