Who the hell told me what this M23 and M33 is?
It jumped from single digits to double digits!
What happened to the previous ten brothers?
Don’t say it has anything to do with M3, will the next generation be called 2333333?
What comes will eventually come, so how can we simply and straightforwardly understand these two brand new processors? Here is an exclusive, irresponsible, and simplified formula provided by a fool:
Cortex-M23 =
Cortex-M0/M0 + Hardware Divider + Performance Improvement +
Dedicated Stack Overflow Hardware Detection +
Subtle actions in the instruction set +
Security Extension (TrustZone for Armv8-M) +
Friendly Improvements in the MPU Developer Model
Cortex-M33 =
Cortex-M3/M4 + Performance Improvement +
Dedicated Stack Overflow Hardware Detection +
Subtle actions in the instruction set +
Security Extension (TrustZone for Armv8-M) +
Friendly Improvements in the MPU Developer Model
-
Enhanced Cortex-M0/M0+
According to official statements, Cortex-M23 implements the Baseline sub-architecture of the Armv8-M architecture, which we can understand as the “entry-level” product in mobile phones.
Note: Image from ARM official website
Cortex-M23 is also very straightforward in its positioning, which is to add a security extension to Cortex-M0/M0+. Therefore, basically all binary codes compiled for Cortex-M0/M0+ can be executed on Cortex-M23/M33 without modification—unless your original code used the MPU. In addition, Cortex-M23 surprisingly comes with a hardware divider, which undoubtedly elevates the “basic configuration” a notch in the original Cortex-M0 and Cortex-M0+ 8-bit/16-bit market.
In terms of the instruction set, Cortex-M23 inherits from Armv6-M, and in addition to supporting the necessary instructions for the “Security Extension,” this entry-level product also makes a “subtle action”—that is, in addition to Cortex-M33, Cortex-M23 can also support “Execute Only Memory (XOM)” with very little cost.
What is dark code? Similar to “dark matter,” which can only be theorized but is difficult to detect—“Dark code” is a type of program that can only be executed by the processor (fetch instructions) but cannot be read in any form (OPCODE) at all—that is, the so-called XO (eXecute-Only) code. “Dark code” is not achieved by the kernel but requires the joint efforts of the compiler and the kernel to support it. This is because XOM essentially refers to a special area in the address space defined by the chip manufacturer—only the processor can fetch instructions for code execution (Instruction Fetch), while normal data access (Data Access) is not allowed.This means that “dark code” cannot directly store any constants—they must be encoded into the instructions—existing as part of the instruction in the form of immediate values.
The instruction set of Armv6-M mostly consists of 16-bit Thumb instructions, so the binary length of the immediate values that the 16-bit instructions can encode is understandably very limited.Armv7-M introduced the 32-bit Thumb2 instruction set, greatly enhancing the ability to carry immediate values.To bring this capability into the Baseline instruction set of Armv8-M, the MOVT and MOVW instructions, which can carry 32-bit immediate values “high and low 16 bits,” were specially added to the instruction set used by Cortex-M23. Consideringthe emphasis on information security in Armv8-M, the significance of “dark instructions” for firmware protection is evident.
2. Enhanced Cortex-M3/M4
Compared to Cortex-M3/M4, the performance improvement of Cortex-M33 is not surprising, let’s not mention it.It is worth noting that the Cortex-M7 from the city can still outperform other Cortex-M processors by a wide margin in performance—the difference between a 6-stage pipeline and a 3-stage pipeline is not comparable to the difference between a three-cylinder car and a six-cylinder BMW! (Serious face).
Note: Image from ARM official website
3. ARMv8-M is a good kid who corrects mistakes
I don’t know how many people have actually used Armv7-M, which is the MPU of Cortex-M3/M4—a system-level peripheral that modifies memory attributes by region. Originally, the design thought was very simple, one region, give it a size (Size), give it a base address (Base Address), then give it an attribute (Memory Attribute), enable it, and it works, very simple, very happy. However, due to the optimization of the internal kernel area, a limitation was artificially added to the setting of the region address range:
The base address must be aligned with its size, and the size must be a power of two (and must be greater than four).
So what did Armv8-M do? It corrected this painful setting, namely: The setting of the region evolved from “base address + size” to “start address + end address”, and aside from the requirement that both addresses must be multiples of 32 bytes, there are no more perverse limitations such as “the base address must be a multiple of the region size.” Don’t you suddenly feel enlightened, as if you’ve discovered a treasure? The MPU suddenly became fun.
4. How to simply understand the Security Extension (TrustZone for ARMv8-M)?
-
What is the relationship between TrustZone for Armv8-M and TrustZone?
Firstly, “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
-
They share some abstract models in theory for understanding and designing embedded information security
-
The security effects are basically the same
However, they differ in at least the following aspects:
-
The architectural definitions are completely different
-
The technical implementations are completely different
-
The execution efficiencies are completely different
-
The various costs are completely different
-
The usage methods are completely different
-
……
(Actually, Ipersonally feel that TrustZone for ARMv8-M is more advanced than TrustZone. This is certainly not just because “I am from the Cortex-M camp,” but because I think “it’s obvious that TrustZone for ARMv8-M, as a latecomer, has sufficient reason to be more advanced than TrustZone.”
-
Functional Safety (Safety) and Information Security (Security)
For instance, if you buy a smart light bulb, then for this product:
-
The protective circuit that prevents the bulb from being damaged due to overvoltage, undervoltage, or excessive current implements functional safety, represented by the English word Safety;
-
The design that protects your light bulb from being controlled by the neighbor or protects the camera (if any) and microphone (if any) on your light bulb from being eavesdropped by the neighbor implements information security, represented by the English word Security.
Further summarizing, you can simply and straightforwardly think:
Safety ensures that the system has normal working logic under various (usually extreme) environments; or that the functions and services provided are normal; if the environment is too extreme, it enters a protective state to avoid providing incorrect or dangerous services to users.——Safety counters challenges from the environment.
Security ensures that under human destruction, the system can effectively detect attacks, ensure that effective information is not leaked, and that the system is not controlled by unauthorized users—— Security counters the neighbor and various hidden cloud entities on the network.
NOTE: For more detailed information about the relationship between Safety and Security, please refer to the article“Plain Talk About Embedded Security (1)”
In fact, Security must be achieved through hardware and software; only when its functions and logic are adequately protected can it effectively counter attackers. Therefore, “neighbors” often exploit the Safety of the system, i.e., functional safety, to attempt to undermine its information security— Security is built on Safety; when discussing Security, it is inevitable to consider Safety—which is also why people often confuse the two concepts. At the same time, we cannot mix them indiscriminately just because they have a one-way dependency relationship (Security depends on Safety, but not necessarily the reverse).
-
Why do people suddenly pay so much attention to Security?
In the past, most microcontroller projects could be completed by local teams, often without cooperation with third parties, and did not require large-scale connections to the network. The purpose of modularity was purely for rapid development, so security issues in information were not very prominent, basically staying at the level of cloning and plagiarism.
However, aside from the eternal reason of cloning and plagiarism, 1) the arrival of IoT has made more embedded devices unable to exist in isolation, thus communication security has become prominent; 2) the concept of ecosystems and platforms has taken root, and single local teams are increasingly unable to independently complete an entire project, leading to cooperation 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 cooperation, and modularity will only help IP be used more efficiently but does not inherently protect intellectual property. Furthermore, purely modular technology cannot ensure that manufacturers obtain sustainable and stable returns from the final product.
Based on the above reasons, simply put: because I need to collaborate with the neighbor to sell pancakes, I provide the equipment, and the neighbor provides the service, I am worried that the neighbor “you know” will spy on your property, while also hoping the neighbor will not steal my equipment’s blueprint and kick me out to profit himself, so Security is necessary in the IoT era.
-
In a nutshell, grasp the essence of security technology
The core of Security technology implementation is Isolation.
Isolation in time is achieved by allocating processor time according to different security levels—establishing what is called secure and non-secure operations, or different security level operating modes.
Isolation in space is achieved through various permissions control for access to memory and peripherals (Access Attribution Management).
It is worth noting that access control is a general tool, and you can use it for various resource allocation, such as resource management in operating systems, or for achieving information security. This does not mean that resource management is part of information security, nor can it be said that information security is achieved through resource management—this kind of statement is most problematic because it is “seemingly true but misleading,” thus confusing many people. If someone debates this with you, my suggestion is: it’s useless to argue or bet with him, just understand it yourself—”Yes, yes, Zhuge Kongming is two people.”
-
TrustZone for ARMv8-M: Technologies Programmers Must Know
Since we are going for a simple and straightforward approach, 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 operational 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
-
Code stored in Secure Memory is Secure Code, which must run in Secure State; code stored in Non-Secure Memory is Non-Secure Code, which must run in Non-Secure State—simply put, “you are you, I am me”.
-
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’s up… 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’s messing around in my territory?
Non-Secure Code: Bro, this… is a misunderstanding…
-
Secure Memory and Non-Secure Memory are jointly determined by the Secure Attribution Unit and Implementation Defined Attribution Unit.
You can think of them as a couple: the man IDAU is responsible for the external (defined by the chip manufacturer), while the woman SAU is internal (configured by the Secure Code at runtime via registers). For every bus access to Cortex-M23/33, SAU and IDAU will compare the target address with the information they possess and vote, with the priority order being: Non-Secure, Non-Secure-Callable, and Secure. The closer to Secure, the more authoritative.
SAU: Hey~ Fault Brother, caught someone!
Secure Fault: Of course, 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 didn’t know…
SAU/IDAU: Kid, what’s the address?
Non-Secure Code: I… come from a non-secure domain…
SAU: Oh, a Non-Secure person, do you know that the address you were peeking at belongs to Secure? You can’t look at it!
Non-Secure Code: I didn’t know it was Secure Memory…
SAU/IDAU: I say it is, so it is!
Non-Secure Code: Oh… oh… (looks down not daring to look)
SAU/IDAU: Fault Brother, check the rules set by the ancestors, report what should be reported, reset what should be reset, act according to the procedure.
Secure Fault: Understood, let’s go!
-
Secure Code will provide services to Non-Secure Code through some special APIs, which are called 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 the bank’s lobby, and the small holes on the bulletproof glass are Secure Entry.
-
TrustZone for ARMv8-M aims for Non-Secure Code and Secure Code to believe they each exclusively own the entire system. For Cortex-M23, Non-Secure Code believes it runs on a Cortex-M0/M0+; while for Cortex-M33, Non-Secure Code believes it exclusively owns a Cortex-M3/M4.
We know that the exclusivity of Non-Secure Code is an “illusion” because it does not know the existence of Secure Code, and any out-of-bounds access (from its perspective, any access to unknown space) will be intercepted and treated as a Secure Fault. The exclusivity of Secure Code is genuine because it knows the existence of Non-Secure and can access them at any time.
To construct this illusion, the cost is huge. For some core resources, such as NVIC, SysTick, MPU, Cortex-M23/33 genuinely provides an extra copy for Non-Secure Code; for other expensive core resources, such as pipelines, general-purpose register pages, Debug logic, floating-point units, Secure Code can only humbly share them with Non-Secure Code.
-
Non-Secure Code and Secure Code exchange information through Secure Entry. When Non-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 (which is Secure Memory, so the code inside is Secure Code); generally, Secure Entry will immediately jump to other pure Secure Memory for execution.
Secure Code can call Non-Secure Memory code through special function pointers in a callback manner (temporarily switching back to Non-Secure state). For more details, please refer to various public documents.
-
Secure Code and Non-Secure Code can each have their own exception handlers, and the switching between Secure and Non-Secure is automatically handled by hardware, so programmers don’t 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. Moreover, we have a dedicated register bit that allows the priority of all Non-Secure Exceptions to be lower than that of any Secure Exception.
In summary, TrustZone for ARMv8-M creates two worlds, Secure domain and Non-Secure domain. SAU/IDAU jointly divide the 4G address space into multiple Secure, Non-Secure, and Non-Secure-Callable regions. Both Secure and Non-Secure domains can view themselves as a regular Cortex-M0/M0+ or Cortex-M3/M4 processor for development—everyone has their own NVIC, SysTick, and even independent MPU.
Secure can hit Non-Secure, while Non-Secure cannot fight back because all resources theoretically belong to Secure domain first.
-
Conclusion
The security extension introduced by Cortex-M23/33 provides the foundation for information security in the entire ARM embedded system. However, relying solely on this “foundation” is not enough to build a solid defense system—chip manufacturers, OEM manufacturers, software IP vendors, toolchains, system software, and application design, each link needs to introduce 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 castle in the air; and solely relying on TrustZone for Armv8-M to protect information security is akin to burying one’s head in the sand. Users must not only know what they want to protect and how to protect it, but also understand that constructing a solid security design foundation requires far more than just slapping a “TrustZone Inside” sticker on their products.
If you like my thoughts, feel free to subscribe to Bare-Metal Thinking
