What is this article about

On Habré several times mentioned SMM - mode of the x86 / 64 processor which has more privileges than even the hypervisor mode. Something similar is in the ARMv7 and ARMv8 architecture processors. The computational cores of these architectures may have an optional extension called ARM Security Extensions, which will allow to divide the executable code, memory and peripherals into two domains - trusted and untrusted. The official marketing name for this technology is ARM TrustZone. But techies often prefer to talk about security extensions.

This will be a review article, so I will not go into the deaf technical jungle. However, technical details will be present. The first part of the article will be devoted to the question of why this is all needed, and the second - how it works in general terms. If society is interested, the next article will contain more technical details. Who cares - welcome under cat.

Why do we need ARM Security Extensions

Although the name contains the word "security", these extensions are needed not only to implement security-related functions in the usual sense of the word. When we say security, we usually think about encryption, access restriction, TPM , secure storage, and so on. Security extensions allow you to implement all these functions, but they are also used for such things as, for example, starting and stopping processor cores, rebooting the system, etc.

Not quite security features

We all know that there is such a thing as BIOS (and now EFI). Their task is to initialize the system, load the OS, provide the OS with information about the system, assist the OS in managing the computer.

Historically, on ARM-based platforms there is no (more precisely, there was not) an analogue of BIOS. Usually, a simple bootloader was present in the ROM code, which found and loaded the full bootloader. Often, such a full-fledged bootloader is u-boot. U-boot, in turn, initiated a minimum of peripherals (for example, started a DRAM controller), found and started the linux kernel. The linux kernel, in turn, could completely wipe the u-boot out of memory, because it is no longer needed. And everything, after loading the kernel was completely provided to itself. All the information about the system where it works was sewn directly into it (or on the side, in a special structure called the device tree). All operations for managing the system (for example, overclocking the processor) the kernel had to perform itself.

This was inconvenient for a number of different reasons. For example, manufacturers do not want to give core developers control over all sorts of "delicate" modules such as caches and buses. Or, for example, the procedure for resetting the chip requires some tricky manipulations that are inconvenient to produce from the kernel code.

In short, the need for something like a BIOS exists. Only in ARM systems it calls Secure Monitor and works thanks to Security Extensions. In my experience, it is most often used to start and stop additional cores in a multiprocessor system, control the bus, transfer running code between powerful and weak cores in the big.LITTLE achrititure, activate the hypervisor mode, and similar delicate things.

Security features

Security extensions allow you to run on the side of another OS with its own kernel and user applications. It is commonly called Trusted OS. This OS will have its own protected memory and access to the protected periphery, for example, crypto-accelerator. Two examples of such OSs are google trusty and open source OP-TEE . There is a consortium of Global Platform which has developed general requirements for such an OS called Trusted Execution Environment .

Google, for example, uses its OS to securely store keys ( keymaster's android service). Motorola once used a proprietary implementation of a secure OS for DRM . There was generally a fantastic system: the user could store and play DRM-videos, while even the android core could not at any time gain access to the memory where the decompressed (or at least decoded) video frames were stored. But at the same time, Android could, for example, draw controls on top of such a video.

Custom applications can be loaded into a secure OS (naturally signed). This allows for example to drive a banking application there for payments via NFC or a virtual SIM card. True, to be honest, in practice, I have not yet come across this.

Also secure extensions allow you to organize Secure Boot: the root of trust is the ROM code that verifies the signature of the next bootloader, the bootloader can verify the kernel signature by contacting Secure Monitor. The kernel, in turn, can also check the signatures of the executable code. Thus, the main components will be protected from change. The technology is controversial, but some developers of android-devices love it very much.

How it all works

Information on technical details is open. You can download the ARM Technical Reference Manual and read it yourself. In addition, the web lacks all sorts of beautiful presentations. I will not go into the deep jungle, just describe the main ideas. I will use the terminology from ARMv8, because it is more consistent in comparison with the terms used in ARMv7.

CPU Modes

This section will provide some technical details. If system programming is an absolutely dark topic for you, you can skip this section.

Actually, everyone probably heard about the protection rings in x86. In ARM, there is exactly the same thing, only here they are called Exception Levels (abbreviated as EL). They can be from two to four (or six, depending on how you count). These are the modes of operation of the processor. The higher the Exception Level, the more privileges the code executing in it has.

All ARMv7 or ARMv8 cores support at least two of them: EL0 and EL1.

Custom programs (for example, your browser) work on EL0. The code executing in EL0 has no privileges: it cannot (usually) work with peripherals, reconfigure the MMU , prohibit (and allow) interrupts, and handle exceptional situations. But the browser does not need this. And if you still need, then you need to ask the kernel OS.

On the EL1, the kernel and drivers work. They, respectively, have the opportunity to work with the periphery, to program the MMU and further on the list. Even 10 years ago, this would be quite enough. But technology does not stand still.

Two more ELs may appear if the processor core includes additional extensions: virtualization extensions and security extensions. Moreover, both of these extensions are optional (although they are present in all modern chips) and the processor can have either any of them, or both. A large part of the ARM Technical Reference Manual is devoted to the interaction of these extensions.

So, if there is virtualization extensions in the kernel, then EL2 appears. At this level, the hypervisor works. Also, the MMU becomes a two-stage and a virtual interrupt controller appears. But this is another story to tell separately.

If security extensions are present in the processor, then the EL3 mode and the S-EL0 and S-EL1 modes appear. In addition, the concept of secure mode appears (and accordingly non-secure mode) - these are processor modes orthogonal exception levels. EL3 has the same privileges as EL2, plus another feature. Only in EL3 mode can the code switch the processor between secure and non-secure mode. What is the difference between them? And the difference is only in the value of one bit - NS .

The fact is that security extensions are not only extensions for the compute core. These extensions also affect the MMU, interrupt controller, and bus controller. For example, the bus controller checks the value of this NS bit itself when accessing memory and peripherals. If the memory is marked as secure, then access to it can only be obtained from secure mode. This means that neither the kernel of the normal OS, nor the hypervisor can read / change the "safe" memory. The same with the periphery. If an interrupt arrives which is marked as secure, then the interrupt will not be processed by the normal OS, but by the trusted OS from the secure mode.

It turns out that two worlds live in the same processor: the normal world and the secure world (these are terms from the official documentation, if that). At what secure world can interfere in the affairs of the normal world, but not vice versa. In EL3 mode, a secure monitor works, which serves as a Charon - allows you to get from one world to another.

As you probably already guessed, the S-EL0 and S-EL1 modes are EL0 and EL1 analogues from the normal world. In S-EL1, the core of the "safe" OS runs, and in S-EL0 - applications (for example, the same virtual SIM card). The picture above uses the terminology from ARMv7, but it’s easy to understand what’s what (I hope).

Normal World and Secure World interaction

The processor always starts in secure-mode (because otherwise it will not get there). Trusted OS is loaded and initialized, after which the processor goes into non-secure mode and loads the normal OS.

It would seem that with all its capabilities the secure world should occupy a dominant position in the system. But actually the opposite is true. Most of the time it is inactive. Only when a normal OS needs some services, does it turn to the secure monitor and control passes to the secure world. Thus, it is the normal world that decides when the secure world will work. This is done in order not to interfere with the user to work with the device, watch videos and listen to music. After all, if a secure world takes control at an inopportune moment, then it can disrupt normal world.

In fact, the secure world has the ability to get control bypassing the normal world using interrupts. For example, you can start a timer that will periodically call a secure world. But this is not usually done for the reasons indicated above. User experience is paramount.

For the linux kernel, there is a patch set that allows normal applications to interact with applications running on Trusted OS, according to the GlobalPlatform TEE specifications, which I already mentioned above. So developers can write applications that (with minor changes) will be able to work on any compatible Trusted OS.

Paranoiac corner

Can a secure world keep track of you? Theoretically, yes. In practice, I had access to a proprietary trusted OS, which was then installed on user devices. In their code, I did not see such functions. Which, of course, does not mean anything.

If secure boot is activated on your device, then you have problems. In the sense that you can not do anything with code running in a secure world. True, you also can not do anything with code running in kernel mode.

Fortunately, SoCs with a secure boot enabled are quite rare and they try not to sell them to everyone. Therefore, you rather have the opportunity to replace the trusted OS with your own. True, there is still a ROM code with which you can do almost nothing. And if the secure monitor is sewn into a ROM code, then again you have problems. But, there are SoCs, on which you can install your secure monitor. For example - Renesas RCAR H3. So all is not lost.

For those who want to experiment - there is an opportunity to raise Trusted OS on the Raspberry PI. How to do this is written in the documentation for OP-TEE.