Leveraging MTE and FF-A Features to Create Advanced TEE with Armv9-A

What is MTE?

MTE was introduced in the Armv8.5-A architecture update, which is a new hardware mechanism that allows users to tag regions of virtual memory.

When a memory region is tagged, it can only be accessed through virtual addresses that contain the same tag. If an attempt is made to access that region using a different tag, the Central Processing Unit [CPU] will block the access and abort.

The hardware cost of MTE is quite significant, so there are reasonable limitations: each application of an operating system can use 16 different MTE tags, and the minimum size of a memory region is 16 bytes.

This rule is already applicable to Linux applications, which can allocate tagged memory regions using mmap() and PROT_MTE. The clang toolchain also supports MTE and can use the new “-fsanitize=memtag” option to protect the stack.

How does Trustonic use MTE in Kinibi 600?

Through Kinibi, we aim to provide new MTE capabilities for the Trusted Applications [TA] of the TEE itself. The idea is to allow TAs to adopt MTE as painlessly as possible.

When hardware supports MTE, it is automatically enabled for dynamic memory management of TAs. This means that buffers allocated with TEE_Malloc() will be automatically tagged, and each call to TEE_Malloc() will return a buffer with a different tag.

Therefore, if an application attempts to access a buffer beyond its allocated size, the CPU will detect it and immediately terminate the TA. MTE will also detect when a buffer is accessed after being released or when it is released twice.

By detecting all these common errors, MTE demonstrates its power, allowing TAs to benefit without changing a line of code. The structure of the heap—or metadata—is always protected by a special tag.

Thus, applications cannot mistakenly access the metadata.

The process is illustrated in the following diagram:

When we enable MTE for dynamic allocation in Kinibi 600, we fixed several issues in the TEE.

In this project, we had to rewrite most of the dynamic allocator [libheap] to be compatible with MTE. We took the opportunity of this development to increase the code coverage of unit tests, achieving a coverage of 99.6% of the lines of code in the library.

When we started this project, we had no MTE hardware available, so we decided to use Quick Emulator [QEMU]. MTE can be enabled in QEMU using the “MTE=on” option.

MTE can be independently enabled and used in both the Normal World (Linux and user-space applications) and the Secure World (TEE and TA). It is particularly convenient to be able to use QEMU with new hardware features when the actual hardware is not yet available.

The following code snippet demonstrates the effect of using MTE for dynamic allocation in QEMU:

We can see that the trusted application was killed by the TEE because it attempted to access a buffer beyond its allocated size with the same tag.

Here we can see the TA was killed by the TEE because it attempted to access a previously released buffer.

MTE provides good protection against attacks while also offering an effective way to make the code more robust. In addition, TAs can also use MTE to protect their stack. To do this, TAs must be recompiled with the appropriate options. In summary, we strongly recommend developers to use MTE.

This feature is not only highly scalable, but we encountered no performance issues throughout the project.

What is FF-A?

In 2017, ARM released Armv8.4, which featured the Secure Monitor in SEL2. Since then, we have been in regular contact with ARM to discuss the implications for TEE. In 2020, we proposed how to leverage the Hypervisor in TEE.

Along with the hardware changes, ARM also announced an open-source Hypervisor called Hafnium, aimed at using the standardized communication protocol discussed publicly by ARM.

Ultimately, Hafnium became known as FF-A, and support for it was subsequently added to the Linux kernel, Trusted Firmware A [TF-A] – EL3 – and Kinibi. We believe FF-A can work at any level of architecture, and can even function when some components are absent, such as in legacy systems.

To achieve this, ARM contacted key players in the ecosystem, including Trustonic, and discussed these requirements over several months. Our meetings with ARM began in 2018 and have continued every two months since.

How does FF-A work in Kinibi 600?

As part of our future development projects, we launched an FF-A prototype in 2020 based on preliminary work from the ARM architecture team’s Fixed Virtual Platform [FVP].

In 2021, we ported the prototype to the HiKey960 board and redesigned the memory management to support the Hafnium Hypervisor on ARM’s Total Compute v0 [TOC] platform.

By the end of that year, we shared the first version of FF-A with two chip customers.

Then, in 2022, to enable our customers to validate the most common TEE use cases, such as Keymaster, Trusted User Interfaces [TUI] (phone payments), and Widevine’s Digital Rights Management [DDRM] system, we integrated a modified version of FF-A v.1.1 and added the necessary Application Programming Interfaces [APIs] for DRM and TUI, such as drApiMapFfaBuffer().

Today, in 2023, we have established an FF-A prototype on QEMU and contributed to the TF-A open-source project.

Customers considering FF-A need to keep several important aspects in mind:

• Support for FF-A in the Linux kernel or any chosen Operating System [OS]. Trustonic can provide support to assist with integrating FF-A into the operating system.

• Does the Hypervisor support FF-A?

• FF-A support should be obtained in EL3 using the latest TF-A firmware.

• Customers can implement the Secure World using Hafnium or their own Hypervisor. Kinibi can be used in various configurations with or without FF-A.

Today, FF-A is primarily launched by Google on Android-based devices. However, we also have other partners who are positively supportive of the implementation of FF-A.

Notably, FF-A is universal and can be used on Armv9 platforms—whether with or without a Hypervisor in the Secure World, and it can also be used on Armv4. This smooth upgrade path allows existing Board Support Packages [BSP] to transition to FF-A without requiring the Hypervisor as an initial step, instead adding it in a second step.

Regarding FF-A, virtual machines in the Secure World are referred to as Secure Partitions. The Hypervisor in the Secure World is referred to as the Secure Partition Manager.

In the Armv9-A architecture, the Hypervisor is divided into two parts: the SPM core [SPMC] running in SEL2 and the SPM scheduler [SPMD] running in EL3.

In the Armv8 architecture, both SPMC and SPMD run in EL3. Kinibi now also supports the device tree format with FF-A, which is required for TF-A implementation.

Some of the largest tech companies are researching FF-A and consider support for it a requirement for their upcoming products.

Trustonic is well-positioned to help Original Equipment Manufacturers and silicon vendors achieve this goal through the use of Kinibi 600, which comes with FF-A support as standard. Kinibi 600 is available for silicon vendors to evaluate and can be integrated for Original Equipment Manufacturers (OEM) assessment through partnerships with some of our existing silicon partners.

Conclusion

Armv9-A is the next step in the evolution of Arm processors. As a security company, we are particularly excited about MTE. While its primary role is to detect errors in programs early, in practice, it adds an extra layer of security, as attackers can no longer exploit these errors.

MTE makes life harder for attackers, thereby enhancing the security of our customers’ systems.