what does TZEN really do ?

[mete]

I know TZEN is used to enable TrustZone. At first, this made sense, but now I think about the MCU implementing the Security/TrustZone, and it sounds strange that TrustZone can be disabled. So my question is, what does it really do ? Does it really somehow disable (power down?, clock gated?) the TrustZone related things (SAU, GTZC etc.) ? so there is really a signal somewhere inside the die that enables/disables this. Or, is the TrustZone in the core always enabled and TZEN just reconfigures things so everything runs like a secure binary or maybe nothing generates a security fault ?

[tjaekel]

TrustZone is not related to power or clocks (not directly directly).
It just means: only code running on TrustZone domain (e.g. inside a TrustZone enabled memory) can write to TrustZone enabled registers or features.

It separates your code in a "TrustZone" code and a "user" code. It does not allow your "user code" to access "TrustZone enabled" features, e.g. memory regions, registers.

TrustZone is a "concept" to spit your entire FW system (all the code) into two pieces: TrustZone code or not TrustZone  ("user").
The MCU has registers which can be enabled as "only access-able in TrustZone mode". So, your "user" code cannot modify or do anything (on HW, system, even in memories) when this sits now in "TrustZone".
The MCU would "know" which code is executed as "TrustZone" code and which is not (it realizes the code executed, in which mode or from where it is executed, it "knows" if it is "TrustZone" code doing something on "TrustZone" registers and memories and does not grant access to "user" code to "TrustZone" stuff).

[mete]

I know more or less what TrustZone is and how it functions. My question is specifically about what TZEN does. There are non-ST Cortex-M33 MCUs that gives no such option (thus TrustZone is always enabled) and I find it difficult to understand how TrustZone can be disabled in an implementation with TrustZone. So I wonder if it really does disable/remove TrustZone (related hardware) in the core or is it somehow a workaround to make programmer believe there is no TrustZone running when TZEN=0.

[mete]

More specifically, Cortex-M33 TRM says this (page 22):

"When the Arm®v8‑M Security Extension is included in the processor, the programmers
model includes two orthogonal security states, Secure state and Non-secure state. When the
Security Extension is implemented, the processor always resets into Secure state. When the
security state is not implemented, the processor resets into Non-secure state. Each security
state includes a set of independent operating modes and supports both privileged and
unprivileged user access. Registers in the System Control Space are banked across Secure
and Non-secure state, with the Non-secure register view available at an aliased address to
Secure state. When the Arm®v8‑M Security Extension is not included in the processor, the
programmers model includes only the Non-secure state."

I do not see a concept of disabling TrustZone here, so if security extensions are implemented, it sounds like it should always be enabled.

[BarryWhit]

---

@mete wrote:

I do not see a concept of disabling TrustZone here, so if security extensions are implemented, it sounds like it should always be enabled.

---

a security guard may always be present at the front gate, but you can instruct them to either check everyone's papers, or let everyone in.

Furthermore, the quote you provided doesn't state that a chip with TrustZone support is always in the secured state. It only states (at most) that upon reset it defaults to the secure state. To the contrary, the quote explicitly says that when hardware implements TrustZone "the programmers model includes two orthogonal security states".

[mete]

Not sure what is the easiest way to implement this, that is why I wonder, there are probably many details that I cannot think of.

Naturally it is not always in the secure state, but there is no concept of "disabling TrustZone", that was my point. The condition in the documents (TRM or ARMv8-M Arch Ref Man) is if TrustZone is implemented or not. So TZEN=0 sounds like it magically removes the TrustZone or Security extension from the implementation.

[BarryWhit]

Again, I'm reading the same thing you are, and that's not what it says.

If you are so much more comfortable thinking about it as "Switch to insecure state" instead of "Disable TrustZone", you're free to do that. It amounts to the same thing.

[mete]

Not sure if my question is not clear enough. The quote from TRM does not matter but as far as I can see neither TRM nor arch ref manual says security extension can be disabled in an implementation with the security extension.

"Switch to insecure state" instead of "Disable TrustZone" does not answer my question much, or maybe I dont get it. Looking at STM32H562 ref manual, it looks like TZEN controls things like secure registers (so they are RAZ/WI when TZEN=0) and also GTZC (TZEN is shown in the block diagram) etc. So now it looks to me like it is used like an enable/configuration signal that changes quite a lot of things, but the actual units of security extension is still in place. I wonder if this is provided by the Arm IP out of the box or this is ST's own addition or modification.

[BarryWhit]

I think you're right and I must be misunderstanding what you're asking. Do you want to know if setting TZEN=0 physically removes all gates involved in the implementation of TrustZone from the silicon die and sends them to another dimension??