Does GrapheneOS control the TEE environment?

ryrona

Sorry for starting a lot of threads, but I was told not to write all my questions in the same one.

Does GrapheneOS control the TEE (trusted execution environment) on Pixel phones, or is it controlled by proprietary firmware and in that case by whom? Is the code running in TEE open source?

Just trying to understand if there is a non-GrapheneOS part that runs with higher privileges than GrapheneOS or not.

de0u

ryrona Does GrapheneOS control the TEE (trusted execution environment) on Pixel phones, or is it controlled by proprietary firmware and in that case by whom? Is the code running in TEE open source?

I believe the OS running on the trusted element is open-source (TrustyOS) but the package run in TrustZone on Pixel devices may not be, i.e., the apps bundled with the OS image may not be open.

ryrona Just trying to understand if there is a non-GrapheneOS part that runs with higher privileges than GrapheneOS or not.

I'm not sure "higher privileges" is the most accurate conception. My understanding is that code in the TEE has no access to devices or to memory except for a limited IPC channel to GrapheneOS. So GrapheneOS can't inspect or change the state inside the TEE, but that code can't inspect or change the state of GrapheneOS.

ryrona

de0u I believe the OS running on the trusted element is open-source (TrustyOS)

Oh, nice.

de0u but the package run in TrustZone on Pixel devices may not be, i.e., the apps bundled with the OS image may not be open.

What do you mean? You mean some apps running on Trusty in the TEE is not open source, even if Trusty itself is?

de0u I'm not sure "higher privileges" is the most accurate conception. My understanding is that code in the TEE has no access to devices or to memory except for a limited IPC channel to GrapheneOS. So GrapheneOS can't inspect or change the state inside the TEE, but that code can't inspect or change the state of GrapheneOS.

This contradicts my understanding, I thought the protection was one-sided here, main OS cannot reach TEE OS, but TEE can access everything. Like TEE is host and main OS runs in a virtual machine. But now I got uncertain, I am not that familiar with for TEE works, and not TrustZone specifically. I may need to ask someone I know that knows these things.

But if it is all open source anyway, it doesn't really matter.

de0u

ryrona You mean some apps running on Trusty in the TEE is not open source, even if Trusty itself is?

I do believe I mean that.

ryrona I thought the protection was one-sided here, main OS cannot reach TEE OS, but TEE can access everything.

According to this article:

By default, [Trusted Applications] cannot operate in the context of other TAs, directly communicate with device peripherals or interact with other processes in the Normal World (NWd) or Secure World (SWd), except as explicitly allowed by the TEE OS.

So I think an open-source TEE OS can verifiably constrain closed-source TEE applications from accessing kernel and user and device state.

ryrona

de0u Thank you. This significantly increased my trust in GrapheneOS.

I just need to see if I can get the VPN leaks I found fixed, and figure out the actual truth about what privacy level the disk encryption offers, and then I am ready to switch to GrapheneOS for real!

GrapheneOS

The TEE has multiple security levels with isolated processes similarly to the OS. There's good documentation here:

https://developer.arm.com/documentation/102412/0103/Execution-and-Security-states/Security-states

Trusted Services in the TEE are applets like keymint, widevine (until it moves to a protected VM as they announced), etc. Those are similar to sandboxed apps in the OS.

Pixels use Trusty OS for the TEE and also the secure core. The secure core is a separate isolated processor on the SoC mainly existing to communicate with the secure element chip. pKVM is used as the hypervisor which is part of the overall meta-OS so we could change it as we see fit and are already hardening it in a generic sense.

ryrona

GrapheneOS Thank you, this clarifies the design and security of it a lot. Now when I understand it better I guess my question is whether the Secure Monitor is open source, since it is the root of trust here. But maybe that doesn't matter much anyway since I hardly believe there is much code running at that privilege level.

GrapheneOS

ryrona It's Trusty's secure monitor so it's open source in the sense that Trusty is open source. They haven't yet pushed tags used for specific releases on Pixels, seemingly just because no one is assigned to dealing with it. There are only minor changes to Trusty itself so the applets are the part that's largely not published as open source code yet. None of it is obfuscated so it's straightforward to look at what it does particularly when most of the sources are published already. We've had to do this in the past to figure out how to do things that were not well documented yet.

Similarly, littlekernel is open source but they've pushed their modifications to it for the bootloader yet. Qualcomm publishes their EDK2 source code for their bootloader but Google didn't publish their very minor modifications to it for Snapdragon Pixels.

Similarly, OpenTitan is open source and they've said they're going to publish the Titan M2 firmware/hardware sources that are based on OpenTitan but they haven't gotten around to it yet. They've significantly modified and extended that code though compared to Trusty OS which already suits the use case. OpenTitan is more server-oriented upstream and doesn't implement the required APIs.

The general pattern is that the firmware is increasingly based on open source projects. Trusty and OpenTitan are started as their own projects (OpenTitan is more like an LLVM style project now) while littlekernel was made externally but they hired the person who made it and it's now developed with their use cases in mind. They didn't assign someone to dealing with pushing the Pixel forks so despite deciding to open source them it hasn't happened yet. It will happen, but they're going to need to assign someone to do what they dedided to do. They announced the Titan M would be open source years ago and then published Open Titan, but they still need to start pushing what Pixels uses to fulfill that commitment.

ryrona

GrapheneOS Okay, thanks. Then I understand the situation well. Let's hope they open source the custom modifications soon too, and that the builds will be reproducible for the parts that cannot be replaced by GrapheneOS. Thank you for taking your time to answer all my questions! I think I am starting to get a pretty good view now of how the security on Google Pixel, AOSP and GrapheneOS works.