In the previous article, we unveiled the new members of the Cortex-M family, the two pioneers of the ARMv8-M architecture—Cortex-M23 inherited from Cortex-M0/M0+ and Cortex-M33 inherited from Cortex-M3/M4. We understood the changes in the instruction set, pipeline, and peripherals, but what about the Security Extension (安全扩展) or TrustZone for ARMv8-M, which is the highlight of ARMv8-M?
-
What is the relationship between TrustZone for ARMv8-M and TrustZone ?
First of all, “TrustZone for ARMv8-M” is a proprietary term, and it shares the following common characteristics with the “TrustZone” introduced in the Cortex-A series:
-
Both are marketing terms.
-
Both uphold the banner of TrustZone.
-
Both share some abstract models purely at a theoretical level, used for understanding and designing embedded information security.
-
The security effects are essentially the same.
However, they differ in the following aspects:
-
The architectural definitions are completely different.
-
The technical implementations are completely different.
-
The execution efficiencies are completely different.
-
The costs are completely different.
-
The usage methods are completely different.
-
……
(Actually, Ipersonally think TrustZone for ARMv8-M is more advanced than TrustZone. This is certainly not just because “I am from the Cortex-M camp,” but more because “it’s obvious that TrustZone for ARMv8-M is a latecomer and has ample reasons to be more advanced than TrustZone.”)
-
Functional Safety (Safety) and Information Security (Security)
For example, if you buy a smart bulb, then for this product:
-
The protection circuit that prevents the bulb from being damaged due to overvoltage, undervoltage, or excessive current is referred to as functional safety, represented by the English word Safety;
-
The design that protects your bulb from being controlled by the neighbor or protects the camera (if any) and microphone (if any) on your bulb from being eavesdropped by the neighbor’s design is referred to as information security, represented by the English word Security.
To summarize, you can simply think of:
Safety ensures that the system has normal working logic under various (usually extreme) environments; in other words, the functions and services provided are all normal; if the environment is too extreme, it enters a protective state to avoid providing erroneous or dangerous services to the user. — Safety counters challenges from the environment.
Security ensures that under malicious attacks, the system can effectively detect attack behaviors, ensure that valid information is not leaked, and the system is not controlled by unauthorized users — Security counters threats from malicious actors and various hidden threats on the network.
In fact, Security must be implemented through hardware and software. Only when its functions and logic are sufficiently protected can it effectively counter attackers. Therefore, malicious actors often exploit the Safety of the system, that is, functional safety, to attempt to undermine the information security built upon it — Security is built on Safety, and discussions about Security cannot be separated from Safety. This is also the reason why people often confuse the two concepts. At the same time, we cannot assume that because they have a unidirectional dependency relationship (Security depends on Safety, but not vice versa), we can interchange them indiscriminately.
-
Why are people suddenly paying so much attention to Security?
In the past, most microcontroller projects could be completed by local teams, did not often require collaboration with third parties, did not need to be extensively connected to the network, and the purpose of modularization was solely for rapid development. Therefore, the issues of information security in past systems were not very prominent, mostly remaining at the level of cloning and plagiarism.
However, apart from the eternal reason of cloning and plagiarism, 1) The advent of IoT has made more embedded devices unable to exist in isolation, thus making communication security prominent; 2) The concepts of ecosystems and platforms have become deeply ingrained, and single local teams are increasingly unable to complete entire projects independently, leading to collaboration with third parties becoming the norm, which inevitably introduces third-party black box modules, making runtime system information security prominent; 3) The establishment of business models encourages multi-party collaboration, and modularization will only help IP be used more efficiently, but does not inherently protect intellectual property. Furthermore, pure modular technology cannot guarantee that manufacturers will gain sustainable and stable profits from the final product.
Based on the above purposes, simply put: because I want to cooperate with others to sell pancakes, I provide equipment, and they provide services. I am worried about the neighbor peeking into my property for “you know what” reasons, while also hoping that they do not steal my device’s schematics and kick me out to profit themselves, therefore Security is essential in the IoT era.
-
Capturing the Essence of Security Technology in One Sentence
The core of Security technology implementation is Isolation.
Isolation in time is achieved by allocating processor time according to different security levels — establishing so-called secure (Secure) and non-secure (Non-secure) execution, or different security level operating modes.
Isolation in space is achieved through various access control of memory and peripheral access (Access Attribution Management).
It is particularly important to note that access control is a universal tool that can be used to implement various resource allocations, such as resource management in operating systems; it can also be used to achieve information security. This does not mean that resource management is part of information security, nor does it mean that information security is achieved through resource management — this misleading statement has confused many people. If someone argues with you about this, my advice is: arguing or betting with them is useless; just keep it clear in your mind — “Yes, yes, Zhuge Liang is two people.”
-
TrustZone for ARMv8-M is a must-know technology for programmers.
Since we want to keep it simple and straightforward, there’s no need to beat around the bush. The essence of the ARMv8-M Security Extension is still to achieve Isolation. So what effect should it achieve?
-
The CPU is divided into two operating states in time: Secure state and Non-Secure state.
-
In space, the 4GB address space is divided into two camps: Secure Memory and Non-Secure Memory.
-
The code stored in Secure Memory is Secure Code, which must run in Secure State; the code stored in Non-Secure Memory is Non-Secure Code, which must run in Non-Secure State — simply put, “you are you, and I am I.”
-
Secure Code can access all data.
Non-Secure Memory: What are you looking at?
Secure Code: What are you looking at?
Non-Secure Memory: No… what are you doing… I… I don’t know…
-
Non-Secure Code can only access data in Non-Secure Memory;
Secure Memory: What are you looking at?
Non-secure Code: What are you looking at?
Secure Memory: Do you know my boss?
Secure Fault: Who is messing around on my turf?
Non-secure Code: Bro, this… this is a misunderstanding…
Secure Fault: Misunderstanding? Is Secure Memory your territory? You! This! Is! Trouble! Get him out of here!
Non-secure Code: Bro… bro, calm down, you see, this territory isn’t defined by you; we still need to find the boss to reason with, right?
-
Secure Memory and Non-Secure Memory are jointly decided by Secure Attribution Unit and Implementation Defined Attribution Unit.
You can think of them as a couple: the man IDAU is the breadwinner (defined by the chip manufacturer), and the woman SAU manages the household (configured by Secure Code at runtime via registers). For every bus access to Cortex-M23/33, SAU and IDAU vote based on the target address comparison with the information they possess, with the arbitration priority being: Non-Secure, Non-Secure-Callable, and Secure. The one closest to Secure has the final say.
SAU: Oh~ Fault brother, caught someone again?
Secure Fault: Indeed, Secure Memory says this guy is Non-Secure.
Secure Memory: Sister, you must help me, this guy actually looked at me!
Non-secure Code: I had no idea…
SAU/IDAU: Kid, it doesn’t matter what else you say, what’s the address?
Non-secure Code: x iron.
SAU: Oh, a Non-Secure person, do you know it’s Secure? You just stare at it? Don’t you look in the mirror, is Secure Memory something you can gaze at?
Non-secure Code: How would I know it’s Secure Memory?
SAU/IDAU: What I say is what it is!
Non-secure Code: Oh… oh… (looking down, too scared to look).
SAU/IDAU: Fault brother, go check the rules set by the ancestors, report what needs to be reported, RESET as needed, and follow the procedure.
Secure Fault: Understood, let’s go!
-
Secure Code will provide services to Non-Secure Code through special APIs known as Secure Entry. Secure Entry must be placed in Non-Secure-Callable Memory. Non-Secure-Callable is actually Secure Memory, but its special feature is that it can store Secure Entry. — You can think of NSC as a bank hall, separated by bulletproof glass, with only a small window for Secure Entry.
-
TrustZone for ARMv8-M aims for both Non-Secure Code and Secure Code to believe they exclusively own the entire system.
For Cortex-M23, Non-Secure Code thinks it runs on a Cortex-M0/M0+; for Cortex-M33, Non-Secure Code believes it exclusively owns Cortex-M3/M4.
We know that the exclusivity of Non-Secure Code is an “illusion” because it does not know about the existence of Secure Code. Any unauthorized access (to what it perceives as unknown space) will be intercepted and treated as Secure Fault. The exclusivity of Secure Code is genuine because it not only knows about the existence of Non-Secure but can also access them at any time.
To create this illusion, the cost is immense. For some core resources, such as NVIC, SysTick, MPU, Cortex-M23/33 genuinely provides an extra for Non-Secure Code ; for other expensive core resources, such as pipelines, general register pages, debug logic, and floating-point units, Secure Code can only respectably share (strongly shared) with Non-Secure Code.
-
Non-Secure Code and Secure Code exchange information through Secure Entry. When Secure Code calls Secure Entry, if Secure Entry is valid and stored in NSC Memory, the CPU will switch from Non-Secure state to Secure State and run the code inside NSC (since NSC is Secure Memory, the code inside is Secure Code). Generally, Secure Entry will immediately jump to other pure Secure Memory for execution.
Secure Code calls Non-Secure Memory code through special function pointers in a callback manner (temporarily switching back to Non-Secure state). As for the numerous details involved, please refer to various public documents.
-
Secure Code and Non-Secure Code can have their own exception handlers, and the switching between Secure and Non-Secure is automatically handled by the hardware, so programmers do not need to worry. It is worth noting that after a reset, the entire system is in Secure state, and all exceptions belong to Secure Code. At this time, only Secure Code can generously allocate some interrupts for Non-Secure Code to use. Additionally, we have a dedicated register bit that makes the priority of all Non-Secure Exceptions lower than any Secure Exception.
In summary, TrustZone for ARMv8-M creates two worlds: Secure domain and Non-Secure domain. SAU/IDAU jointly split the 4G address space into Secure, Non-Secure, and Non-Secure-Callable. Both Secure Domain and Non-Secure Domain can consider themselves as a regular Cortex-M0 or Cortex-M3 processor for development. Everyone has their own independent NVIC, SysTick, and even independent MPU — Secure can strike Non-Secure, while Non-Secure cannot retaliate because all resources theoretically belong first to the Secure domain.
-
Conclusion
The security extensions introduced by Cortex-M23/33 provide a foundation for information security in the entire ARM embedded system. However, relying solely on this “foundation” is insufficient to build a robust defense system — chip manufacturers, OEM manufacturers, software IP manufacturers, toolchains, system software, and application design, each link must incorporate necessary information security technologies and measures. We can say:
Without TrustZone for ARMv8-M, the security built on the Cortex-M system would be a house of cards; relying solely on TrustZone for ARMv8-M to protect information security is even more like burying one’s head in the sand. Users must not only understand what they need to protect and how to protect it but also know that building a solid security design foundation requires much more than just sticking a “TrustZone Inside” label on their product.
More content related to microcontroller embedded information security design will be gradually unfolded in subsequent articles (if any). If you have anything to say about embedded information security, feel free to leave a message on the public account.
————— End of the main text —————
If you like my thinking, please subscribe to Bare Metal Thinking.
Copyright belongs to Bare Metal Thinking (a public account under Silly Kid Publishing Studio).
All content is original, strictly prohibited from any form of reproduction, sharing/forwarding is welcome.
(The difference between reproduction and sharing is: reproduction extracts the article content and publishes it on other media; sharing still centers on the Bare Metal Thinking public account to spread the article.)
