Redefining the Trust Boundary in Android and Embedded Linux – Part 2

Part 2: One Big Bucket: When Sharing a Secure World Becomes a Liability

In Part 1, we walked through how TrustZone splits the processor into two hardware-enforced security states (Normal World and Secure World) and how the only path between them runs through EL3, triggered by an SMC instruction. That boundary is real and strong: even a fully compromised Linux kernel cannot directly read Secure World memory.

But at the end of Part 1, I noted that this model works well for a small number of well-defined, relatively simple workloads. The moment the number and complexity of secure services starts to grow, the architecture begins to show its limits. That’s exactly where Part 2 picks up.

7. The One Big Bucket Problem

So far we’ve established that TrustZone creates a strong hardware boundary between Android and the TEE. Even if an attacker gains full control of the Linux kernel, they cannot directly read Secure World memory.

But that’s only half the story.

As I mentioned before (and I hope you remember), TrustZone creates exactly two main domains:

• Normal World
• Secure World

The architecture does not, by itself, divide the Secure World into multiple independent compartments. As a result, almost every sensitive service on the device ends up sharing the same security environment. On a typical Android phone, all of the following may run inside a single TEE:

• KeyMint
• Gatekeeper
• Widevine
• Biometric Services
• OEM Trusted Applications
• Secure Payment Services
• And any other proprietary Trusted Applications

From the hardware’s point of view, every one of these services is a member of the same single world.

The fact that these services share an environment does not automatically mean they can read each other’s memory. The TEE kernel typically gives each Trusted Application its own virtual address space and enforces software-level isolation through the MMU. At first glance, that looks like enough. But that isolation only holds as long as the TEE kernel itself remains uncompromised.

Every Trusted Application depends on the same shared kernel for memory allocation, CPU scheduling, interrupt handling, IPC, and resource management. Which means:

if an attacker gains control of that kernel, all the software boundaries between Trusted Applications collapse.

To put it precisely, the problem with TrustZone isn’t that Trusted Applications run in a single process. The problem is that they all depend on a single point of trust. This is what I mean by the One Big Bucket.

8. How Far Does Software Isolation Actually Hold?

Inside the Secure World, the execution model looks a lot like a regular operating system. The TEE kernel runs at S-EL1. Trusted Applications run at S-EL0. Each one has its own virtual memory space. The kernel is responsible for creating address spaces, managing page tables, scheduling CPU time, handling interrupts, managing inter-TA communication, and controlling shared memory. As long as the kernel is healthy, Widevine cannot read KeyMint’s memory. Gatekeeper cannot see Biometric Service data.

So the natural question is: if an attacker can’t directly reach KeyMint, is there another way in?

Yes. And that brings us to one of the most important attack patterns in modern security architecture.

9. The Pivot Attack

In security, an attacker doesn’t always go after the most valuable target directly. Sometimes the highest-value target is simply too well defended. So the attacker takes a detour: compromise something less guarded first, and use it as a launching pad to reach the real objective. This technique is called a pivot.

The same thing happens inside a TEE. Imagine an attacker finds a buffer overflow in Widevine. Widevine is complex software. It has to handle DRM protocols, process various media formats, and interact with the Normal World continuously. The larger and more complex a service’s attack surface, the more likely it is to contain exploitable bugs. That makes Widevine a much more realistic target than KeyMint, which is small and purpose-built.

Step one: the attacker sends malformed media data to Widevine from the Normal World. The vulnerability fires. The attacker achieves arbitrary code execution inside the Widevine Trusted Application.

Nothing catastrophic has happened yet. The attacker controls Widevine. Widevine’s address space is still separate from KeyMint and Gatekeeper. The QSEE kernel is still enforcing memory boundaries between TAs. So the attacker can’t just reach over and read KeyMint’s keys. Not yet. But the attacker’s position has fundamentally changed. They’re no longer attacking the TEE from Android.

They’re now inside the Secure World.

And from there, the next target isn’t KeyMint. The next target is the TEE kernel.

If the attacker can find a vulnerability in one of the kernel’s internal interfaces, a system call handler, a memory management routine, anything that takes input from S-EL0 and processes it at S-EL1 , they may be able to escalate from S-EL0 to S-EL1.100%

At that point, every software boundary between Trusted Applications disappears.

This is exactly why the presence of a relatively large and complex service like Widevine can affect the security of something as tight and simple as KeyMint.

The attacker doesn’t target the most valuable service. They target the easiest one, and use it as a stepping stone to own the entire secure environment.

10. A Real Case: The Qualcomm QSEE Attack

The pivot attack isn’t a theoretical exercise. Real research has demonstrated exactly this kind of chain: compromise a Trusted Application, then use that foothold to attack the TEE kernel from inside the Secure World.

One of the best-documented examples is the work of Gal Beniamini from Google Project Zero on the Qualcomm Secure Execution Environment, QSEE.

QSEE was used across a large number of Android devices as Qualcomm’s Trusted Execution Environment. The architecture was exactly the model we just described:

• QSEE kernel at S-EL1
• Trusted Applications at S-EL0
• Services like Widevine, Keymaster, and Gatekeeper all dependent on the same shared TEE kernel

10.1 Phase One: Getting a Foothold in Widevine

A direct attack on Keymaster or Gatekeeper was likely to be difficult. These services expose a narrow interface and do very specific things.

Widevine was a better entry point. It had to process complex DRM requests and media content. The more complex the inputs a program handles, the higher the probability of finding memory corruption bugs, buffer overflows, use-after-free, and input validation errors.

The attacker could send a crafted DRM request to Widevine from the Normal World. Processing that input triggered a memory corruption vulnerability in the Widevine Trusted Application. The attacker gained arbitrary code execution inside Widevine.

That was a significant step: the attacker’s code was no longer running in Android or the Linux kernel. It was now executing inside the Secure World, at S-EL0.

But they still didn’t control the TEE. Widevine’s address space was separate from Keymaster and Gatekeeper. The QSEE kernel was still enforcing those boundaries.

Widevine was just the foothold.

10.2 Phase Two: Pivoting to the QSEE Kernel

From inside the compromised Trusted Application, the attacker had access to the QSEE kernel’s internal interfaces.

Just as user-space programs use system calls to request services from the Linux kernel, Trusted Applications make calls to the TEE kernel for memory allocation, resource management, and inter-service communication. Those interfaces accept input from S-EL0 code and process it at S-EL1, which makes them security-critical.

After taking over Widevine, the attacker could invoke those interfaces directly, with arbitrary arguments and in unexpected sequences.

One of the vulnerable paths involved how QSEE managed memory mappings. That flaw allowed the attacker to escalate execution from S-EL0 to S-EL1.

In phase one, the attacker controlled one Trusted Application.

In phase two, that same application became the platform for attacking the shared TEE kernel.

10.3 Full Collapse of Internal Boundaries

Once the attacker had code execution at S-EL1, the software isolation between Trusted Applications was effectively gone.

The QSEE kernel manages page tables, memory mappings, scheduling, and resource control across the entire Secure World. An attacker who controls the kernel can map other applications’ memory spaces, read their data, and alter their behavior.

At that point, the attacker could potentially:

• Read Keymaster’s memory and extract private keys
• Bypass Gatekeeper’s rate-limiting and forge authentication tokens
• Read biometric service memory
• Modify the behavior of other Trusted Applications

The critical point: the initial vulnerability wasn’t in the most sensitive service on the device. The entry point was Widevine, a service whose primary job is DRM and media processing. But because Widevine and all the other security services shared the same kernel, compromising it ultimately affected the entire Secure World.

11. What the QSEE Attack Tells Us

This research made a few important architectural points visible.

First: the security of a TEE is not determined solely by the robustness of its most sensitive component. If KeyMint is small, carefully written, and minimal, but runs alongside a large and complex Trusted Application on the same kernel , its security still depends on the weakest member of the environment.

Second: the software boundary between Trusted Applications is not the same as the hardware boundary between Normal World and Secure World. TrustZone enforces the latter in hardware. But the isolation between Widevine and KeyMint is enforced by the TEE kernel. If the kernel falls, that isolation falls with it.

Third: adding more Trusted Applications directly increases the attack surface of the Trusted Computing Base. Every new TA brings more code into the Secure World, adds more interfaces to the kernel, accepts more input from the Normal World, and raises the probability of an exploitable bug.

Putting a service inside the Secure World doesn’t automatically make the overall system more secure. It may protect that service from the Linux kernel , while simultaneously expanding the attack surface of everything else in the TEE.

12. The Second Problem: Closed Binaries and Chip Vendor Dependency

The shared kernel problem isn’t the only structural limitation of the traditional TEE model.

A large portion of the Secure World software is typically developed by the chip vendor and delivered to the device manufacturer as a prebuilt binary.

A phone manufacturer may receive QSEE (or equivalent firmware components) from Qualcomm as closed files. The source code may not be available to Google, to security researchers, or even to different teams inside the device manufacturer.

In that situation, the manufacturer knows it needs to include a specific binary in the firmware image. But it doesn’t necessarily know:

• Exactly what code runs inside it
• Which libraries it depends on
• What its real attack surface looks like
• Which component versions are bundled inside
• Or how to fix a flaw without going back to the chip vendor

These proprietary binaries typically have direct relationships with low-level hardware: power and clock management, hardware crypto engines, memory controllers, secure boot, and communication with other firmware components on the device.

That tight hardware coupling is exactly what makes them difficult to replace or update independently.

13. The Long Patch Chain

Suppose a vulnerability is found in one of these TEE components.

In ordinary software, the developer fixes the code, builds a new version, and ships an update.

In the firmware-dependent TEE model, that process may involve several organizations in sequence:

If the vulnerability is in QSEE, Qualcomm has to investigate and fix it first. Then a new firmware version has to be built and delivered to device manufacturers. Each manufacturer integrates it into their own software stack, runs compatibility and security tests, and eventually publishes an OTA update.

Depending on the device model, region, carrier, and support lifecycle, that process can take weeks or months. For devices that have reached end of support, the patch may never arrive at all. So even after a vulnerability is known and fixed upstream, a large number of devices may continue running the vulnerable version.

14. Version Fragmentation Across the Android Ecosystem

The chip vendor and OEM dependency doesn’t just cause patch delays. It produces a large ecosystem of divergent versions and implementations. Two devices running the same version of Android may have completely different TEEs. One may run Trusty. The other may run QSEE or a proprietary implementation from a different vendor. Even two devices with the same chip may run different versions of the TEE firmware. As a result, the security posture of the Secure World can’t be determined just by looking at the Android version or the monthly security patch level. The Android framework and Linux kernel may be fully up to date, while one of the underlying firmware components is still on an older version. This makes security assessment, testing, and management significantly harder and makes it difficult for Google to deliver a consistent, portable security architecture across all Android devices, since part of the security behavior is tied to vendor-specific implementations.

15. The Third Problem: The EL3 Risk

So far I’ve focused mainly on the TEE kernel at S-EL1.

But in the TrustZone architecture there is a component with even higher privilege: the Secure Monitor at EL3.

EL3 is the highest exception level in the ARM architecture. The Secure Monitor is responsible for switching control between Normal World and Secure World it saves and restores execution context for both worlds and changes the processor’s security state.

Because EL3 sits above EL2, EL1, and S-EL1, a vulnerability at this level can affect the entire device security model.

15.1 The Privilege Hierarchy

In a modern Arm-based Android device, the privilege structure looks like this:

The Secure Monitor at EL3 oversees every transition between these environments.

15.2 Why Compromising EL3 Is Catastrophic

The Secure Monitor sits in one of the most sensitive positions in the entire architecture. It can change the processor’s security state, save and restore Normal World context, manage Secure World context, and transfer control between environments. If an attacker achieves arbitrary code execution at EL3, there is no higher boundary inside the processor left to stop them. Depending on the hardware implementation, they may be able to read Secure World memory, alter TEE behavior, observe or manipulate the Android kernel, change memory security configurations, undermine hypervisor isolation, or target low-level boot and firmware components. If Android Virtualization Framework and pKVM are running on the same processor, code running at EL3 is above EL2 in privilege. Compromising EL3 can therefore threaten the security boundaries created by the hypervisor as well.

16. The Principle of Minimizing EL3 Code

Because of these consequences, there’s a clear design principle: the Secure Monitor should remain as small as possible.

EL3 is not the right place for complex logic.

Tasks like media decoding, format parsing, file management, network protocols, or running large security services should not live directly at EL3. Every additional capability adds more code, more inputs, and more attack surface at the highest privilege level on the chip. This is why implementations like Trusted Firmware-A work to keep EL3 responsibilities minimal. The Secure Monitor’s job should be primarily: managing transitions between security states, saving and restoring execution context, routing certain interrupts, and performing the minimum platform control operations necessary. More complex logic belongs at lower levels, so that if a vulnerability exists, an attacker doesn’t land directly at the top of the privilege stack.

17. Three Structural Limitations of the Classic Architecture

At this point, three important architectural limitations of the traditional TrustZone model have become clear.

17.1 One Shared Secure World

Services with very different sensitivity levels and attack surfaces run on a single shared kernel. A vulnerability in something like Widevine can become the entry point for compromising the entire Secure World.

17.2 Dependency on Proprietary Firmware

A large part of the TEE is delivered by the chip vendor. Google and the device manufacturer may have no direct control over the code, its development, or its update timeline. That dependency creates patch delays and ecosystem fragmentation.

17.3 A Highly Privileged Component at EL3

The Secure Monitor has to manage world switches, so it carries exceptional privilege. Any vulnerability there has a blast radius larger than a compromise of the Linux kernel or even the TEE kernel.

None of this means TrustZone is broken or useless. It still creates a strong hardware boundary between Normal World and Secure World. But the “one Secure World for all services” model doesn’t align well with what Android needs today: fine-grained isolation, independent updatability, portability, and reduced vendor dependency.

These limitations are exactly what motivated the second architecture path.

The idea: run sensitive services inside protected virtual machines, with isolation enforced by a hypervisor not shared with everything else in a single Secure World.

The Architecture That Came Next

None of this means TrustZone is broken or useless. It still creates a strong hardware boundary between Normal World and Secure World — and for many use cases, that boundary is exactly what you need. But the “one Secure World for all services” model doesn’t align well with what modern Android needs: fine-grained isolation between services, independent updatability, reduced vendor dependency, and the ability to protect workloads even from a compromised Linux kernel.

These three limitations ( the shared kernel, the closed binaries, and the EL3 blast radius) are exactly what motivated the second architecture path.

In this part, we’ll look at what Google built in response: a framework where sensitive services don’t share a kernel at all. They run in their own protected virtual machines, with isolation enforced by a hypervisor, and with a trust chain that doesn’t depend on what’s inside a vendor blob.

The architecture has a name: Android Virtualization Framework. And the way it draws the trust boundary is fundamentally different from everything we’ve covered so far.

Footnotes:

1. Arm, Learn the architecture: TrustZone for AArch64 — TrustZone hardware architecture (NS bit and memory-system isolation / TZASC). https://developer.arm.com/documentation/102418/latest (same source as Diagram 2)
2. (Optional — these are generic examples and need no citation.) For an official list of comparable TEE use cases, see Arm/Google, Trusty TEE, “Uses and examples”. https://source.android.com/docs/security/features/trusty
3. OP-TEE Project, About OP-TEE / architecture — OP-TEE runs alongside a non-secure Linux kernel on Arm. https://optee.readthedocs.io/en/latest/general/about.html
4. Google, Trusty TEE, “Apps and services” — Trusty apps run as isolated processes in unprivileged mode, each in its own virtual-memory sandbox. https://source.android.com/docs/security/features/trusty
5. https://mominux.com/redefining-the-trust-boundary-in-android-and-embedded-linux-part-1/

Version status and review date

The technical information in this article was reviewed as of 20 July 2026. The reference versions are:

• Android 17, released on 16 June 2026;
• Android Virtualization Framework, first introduced with Android 13;
• The major AVF and pKVM changes documented in Android 16;
• Linux mainline documentation for Linux 7.2-rc4;
• OP-TEE 4.10.0, released on 17 April 2026;
• Trusted Firmware-A 2.15, released on 2 June 2026;
• Xen 4.21, released in November 2025.

At the time of writing, Android 17 is the newest released version of Android. That said, the most recent large set of AVF changes described in the versioned AOSP documentation belongs to Android 16. The public AVF pages were also updated in June and July 2026. So the basis for this article is Android 17, with the AVF capabilities documented up to Android 16 and the current AOSP documentation.