Leaked documents show Google planned and then cut a key Pixel 11 security feature for GrapheneOS

GrapheneOS, the privacy-hardened Android fork that's shipped exclusively on Google's Pixel phones for years, says it can't properly support the new Pixel 11 series. After a week of trying to force a port through, the team found that the Pixel 11's Tensor G6 chip is missing hardware support for something called Memory Tagging Extension, or MTE, a security feature every Pixel chip has had since the Pixel 8 in 2023.

Here's basically what MTE does: your phone's memory is a huge grid of little storage boxes. A lot of exploits work by tricking an app into reading from or writing to the wrong box, one it wasn't supposed to touch. MTE stops this by slapping an invisible sticky note on every 16-byte chunk of memory and on every pointer allowed to access it. If the sticky notes don't match when a program tries to read or write, the chip slams on the brakes, terminating the process instead of quietly letting the exploit through. GrapheneOS uses MTE throughout its OS and argues that it kills off entire categories of remote hacking attempts before they can even start. The team says it looks like Google ripped MTE out of the Pixel 11 to save money; Google hasn't commented. GrapheneOS is now telling people to skip the Pixel 11 and buy a Pixel 8, 9, or 10 instead if they want to run GrapheneOS.

A research paper by researchers from UT Austin, UC Berkeley, Google, and Ampere Computing (arXiv:2601.11786) gives us an idea of what MTE costs to implement in real hardware, which also tells us what a company saves by skipping it.

The sticky notes themselves are quite small: 4 bits for every 16 bytes of memory, or about 3.125% overhead. ARM's rulebook doesn't say where chipmakers have to store these sticky notes, only that they need to exist somewhere. That's why companies do it differently. ARM's own reference design sets aside a dedicated chunk of RAM and performs two separate memory fetches on a cache miss, one for the data and one for its sticky note. Ampere, which makes server chips, instead piggybacks the notes onto bits normally used for error correction and grabs the data and note together in a single trip. Neither approach is more correct; ARM built in that flexibility on purpose.

The bigger cost isn't the extra 3.125% of memory needed on the chip, but the extra work the chip has to do on every memory access. Every time your phone touches memory, it has to check that little tag, which requires dedicated comparison circuitry. Assigning tags randomly so attackers can't predict them requires a random number generator built into the chip, and a fast one with enough entropy is hard to build without cutting corners. A few special instructions for writing tags need their own lane through the chip rather than reusing the normal path.

Think of an out-of-order CPU core like a kitchen with several cooks working ahead on different parts of an order at once, not necessarily in the sequence the order came in, as long as nothing depends on something that isn't ready yet. That's normally how a modern out-of-order core stays fast: it doesn't wait around; it works on whatever it can while slower steps catch up.

MTE's strict SYNC mode throws a wrench into one part of that kitchen: writing to memory. Normally, a core can write data to memory and keep working on the next few instructions while that write finishes in the background. But under MTE SYNC mode, every write first needs its little tag checked and confirmed as valid, and until that check clears, the core isn't allowed to move on to the next write. It's not that the whole kitchen grinds to a halt: cooking (reads, math, branching, etc.) carries on out of order just fine. It's specifically the "put the finished plate down" step that now has to happen one at a time, in order, while waiting for a tag check every single time. Code that writes to memory repeatedly in a tight loop feels this constantly, which is exactly why some benchmarks slowed by up to 6.64x. Code that mostly reads, calculates, or branches barely notices because the part of the pipeline that got slower isn't the part it's leaning on.

Even in MTE's lightweight mode, the regular "Big" core still saw slowdowns of up to 1.82x, and this is the exact mode Google's own Advanced Protection feature uses today. Meanwhile, Ampere's server chip and Apple's new M5 both barely noticed MTE was on, averaging only 2–3% overhead, with a worst-case slowdown of 10%. That gap proves these slowdowns aren't some unavoidable law of physics; they reflect how well (or badly) a given chip's engineers implemented the feature. And knowing Tensor, we don't expect much from it.

Search for the same stuff in the Pixel 11's bootloader and you get nothing. Not a single trace. That's quite a meaningful difference: if Google had just flipped a switch to turn MTE off, you'd still expect to find those function names and messages sitting in the code, just unused. Their total absence suggests the code was ripped out entirely, not just switched off. That backs up exactly what GrapheneOS said after giving up on its port.

Separately, GrapheneOS is finalizing a deal with Motorola to bring the OS to a non-Pixel phone for the first time, while Qualcomm has begun adding MTE support to its latest chips, including the Snapdragon 8 Elite Gen 5.

NotebookCheck has learned that Motorola is working on a flagship phone internally codenamed "Wukong," built around Qualcomm's next flagship chip, the Snapdragon 8 Elite Extreme Gen 6 (SM8975), which is due to be fully unveiled at the Snapdragon Summit on September 22. As of now, it's the only Motorola device planned around that chip. If Wukong ends up being GrapheneOS's launch phone with Motorola, it'll be the first phone to combine proper MTE support, a flagship Qualcomm chip, and GrapheneOS suppor, something you can't currently get on a Pixel 11 no matter how much you spend.

The standard caveat is warranted: this early in development, the specifications and even the "Wukong" codename come from internal material and could still change before anything is official. Motorola hasn't confirmed that the phone exists.

For the average person buying a Pixel 11, I don't think losing MTE is the disaster this story might make it sound like.

MTE is probabilistic, not a hard guarantee. There's a 1-in-16 chance that a given out-of-bounds access slips past the tag check entirely, and research cited in the same paper (TikTag) broke tag secrecy on real Pixel hardware using speculative execution, meaning even the protection it offers isn't as reliable in practice as "15/16" suggests. And, critically, almost none of the exploits an average phone owner actually needs to worry about are memory-safety bugs in the first place. Phishing, malicious app permissions, SIM swapping, stalkerware, and account takeovers, none of that touches what MTE protects against. Even GrapheneOS itself admits that coverage for third-party apps is opt-in and rarely used; Signal doesn't turn it on.

Where MTE actually earns its keep is in the threat model GrapheneOS itself is built for: expensive, reliability-dependent zero-click exploit chains, the kind sold for millions of dollars and used almost exclusively against journalists, dissidents, and government targets, not the median consumer. That's a real and important use case. It's just a narrow one. A phone that crashes instead of getting silently owned is a genuinely big deal if you're a high-risk target being surveilled by a state actor. It's a lot less relevant if your actual risk is losing your phone at a bar or clicking a bad link in a text. Practicing good OPSEC, using unique passwords, avoiding random QR codes, and not scattering your personal information across every website that asks for it do more real-world protective work for most people than any silicon-level memory-safety feature ever will.

None of that makes the Pixel 11's silicon regression a non-story. GrapheneOS's user base is exactly the crowd this matters most to, and losing a whole generation of Pixel support is a legitimate blow to that project. But it's worth being honest that MTE reads much more like a high-value mitigation for enterprises or high-risk users that happened to land in consumer silicon than like a feature the average person buying a Pixel 11 will ever notice the absence of. And there's some irony in how Google got here: it was the company that pushed MTE into the mainstream in the first place, shipping it in Tensor before almost anyone else in Android, funding research into it, and building an entire security mode around it. Now its own internal documents suggest it built MTE into its next chip, wrote it up in detail, and then quietly cut it before launch. Nobody out-engineered Google on this one. It out-engineered itself right out of the feature.