Pixel 11 drops hardware MTE

Pixel 11 does not support hardware memory tagging. GrapheneOS has stated the MTE capability is gone on the device. A hardware-enforced memory-safety control that was present on the previous generation is not present here. The wording “no longer” carries one necessary implication and no more: the primitive existed before, and it does not exist on Pixel 11.

This is not a configuration change. It is a change in what the silicon can do. A device that cannot tag memory in hardware cannot check pointer tags in hardware, regardless of the operating system loaded on top of it. GrapheneOS running on Pixel 11 inherits that constraint. The absence sits below the OS, so no software setting restores it.

State the boundary now, because the rest depends on it. What is confirmed: hardware MTE is absent on Pixel 11. What is not confirmed: the reason for the removal, whether any mitigation is intended to stand in its place, and how GrapheneOS previously configured MTE across the system. Those are separate claims, and none of them are established by the fact in front of us. Treat each as not confirmed until stated.

MTE is a memory-safety mechanism built into the processor. It assigns a tag to a memory allocation and a matching tag to the pointer that references it, then checks that the two agree each time the pointer is used. When they do not agree, the access is a memory-safety violation: a use-after-free, or a read or write outside the allocation. In synchronous operation the mismatched access faults at the point of access and the process is terminated. The detection happens in hardware, at the moment of the bad access, not after.

On Pixel 11 that check does not run, because the hardware that performs it is not present. This is the observable failure. It is not that a check produced a wrong result. It is that the check no longer exists to be performed. Any code path that depended on the processor to catch a tag mismatch now executes without that step. A control that is not present enforces nothing.

The scope of what GrapheneOS did with MTE on prior hardware is not confirmed here. Whether it ran synchronous or asynchronous tagging, which processes it covered, and whether it was enabled by default are not established by the stated fact. None of that changes the confirmed condition. The hardware primitive is gone, so every use of it, whatever its former coverage, is gone with it.

The reason Pixel 11 dropped hardware MTE is not confirmed. The fact states the outcome, not the cause. Do not read a vendor decision, a cost trade, or a design intent into it. The cause is a gap in the record, and a gap is a condition, not a story.

What is confirmed is the effect, and the effect is what matters for exposure. Hardware tag checking operated at access time and terminated on mismatch. Remove the hardware and that timing and that action both disappear. Software can attempt to approximate memory-safety detection, but it does not reproduce a per-access hardware tag comparison at the same cost or the same coverage, and no such replacement is confirmed on this device in any case. The layer that turned a memory-corruption bug into an immediate fault is not in place.

Stated precisely: on Pixel 11 a use-after-free or an out-of-bounds access that MTE would have faulted on is not faulted on by MTE, because MTE is not there. Whether any other control on the device detects or stops the same access is a separate question that the stated facts do not answer, and it is therefore not confirmed. The confirmed change is narrow and specific. One hardware-enforced detection mechanism that was present is now absent, and everything that mechanism used to catch at the point of access now passes that point unchecked by it.

The failure is not an event. It is a removed step in a sequence that previously ended in termination. Trace what happens now at the moment a pointer is used against an allocation it does not match. On hardware that supports MTE the processor compared the allocation tag to the pointer tag and faulted on mismatch, ending the process at the point of access. On Pixel 11 that comparison is not performed, because the unit that performs it is absent. The bad access does not fault on a tag mismatch. It continues. Whether any other mechanism on the device stops it is not confirmed. What is confirmed is that the tag check is not the thing that stops it, because the tag check does not run.

The characteristic of this failure is silence. A control that faults on a bad access produces a visible result: a terminated process at a known point. Remove the control and you remove that result with it. Absence of the check is absence of the fault, and absence of the fault is absence of the signal the fault generated. This is a logically necessary consequence of the stated fact, not an inference about attacker behaviour. The access that MTE would have converted into an immediate crash instead completes without producing the crash MTE produced. Nothing about the memory bug changed. The mechanism that reported it in hardware is gone.

The detection MTE performed had two properties that the absence removes together: timing and cost. The check ran at access time, in the processor, per access. That is why it caught use-after-free and out-of-bounds access at the moment of the access rather than after. A software approach does not reproduce a per-access hardware tag comparison at the same cost or the same coverage, and no such replacement is confirmed on this device. So the failure is not that detection moved to a slower layer. The failure is that the hardware layer that did per-access detection is not present, and the stated facts do not establish anything standing in its place. Treat the detection as removed, not relocated.

This exposes a property of every control anchored in silicon: it exists only where the silicon exists. The security property MTE provided did not belong to the operating system. It belonged to the processor, and the operating system used it. GrapheneOS on Pixel 11 is the same software making the same requests, and the property is still gone, because the property was never the software’s to carry. When the primitive is absent, no layer above it restores it. Phase 1 stated this as a constraint that sits below the OS. The pattern is the general form of that constraint.

The enforcement point is the deciding fact. MTE enforced memory-safety detection at the processor. A control’s enforcement point determines where it can be relied on and where it cannot. Put the same operating system on hardware without that enforcement point and the control is not weakened, it is not there. This is the distinction between a control that is configured and a control that is present. Configuration lives in software and travels with it. Presence lives in the hardware and does not. The record here describes a presence change, not a configuration change, and those are not interchangeable.

For anyone reasoning about device security, the pattern sets the unit of verification. A hardware-enforced control is a fact about a specific device and a specific generation, not about a brand, a platform, or an operating system’s reputation. The correct question is not whether a platform is known for memory safety. It is whether the primitive is present on the hardware in front of you. On the prior generation the answer for MTE was yes. On Pixel 11 the answer is no. The same OS, the same device line, the opposite answer. The property must be checked per device, because the primitive is a per-device fact.

State the condition plainly. On Pixel 11, hardware memory tagging is not a control you have. Any threat model that counted MTE as a detection or mitigation must remove it for this device. Whether something replaces it is not confirmed, and not confirmed is not a substitute for present. Until a replacement is stated and verified, model the memory-safety posture as one without hardware tag checking, because that is the only condition the facts support.

A control that is not present enforces nothing. This is not a judgement about GrapheneOS, which inherits the constraint and cannot code around missing silicon. It is a judgement about the boundary. The boundary for MTE was the processor, and on this device the boundary does not hold the check, because the check is not there. Do not carry the prior generation’s memory-safety assumptions onto Pixel 11. The words in the record are “no longer,” and they mean exactly one thing must change in your model: the primitive you could assume before, you cannot assume here.

What must now be true is narrow and firm. Verification of hardware-enforced controls happens per device, not by platform reputation. The Pixel 11 threat model treats hardware MTE as absent. Any claim of a compensating control is held as not confirmed until it is stated and checked, not assumed from the platform’s history. The confirmed fact is one removed hardware primitive. The required response is to stop treating a hardware property as something the operating system carries onto hardware that does not provide it. If the hardware cannot check it, nothing above checks it the same way, and the model must say so.