GrapheneOS says Pixel 11 has MTE support after all

Post by wat10000 » Thu, Sep 03, 2026, 12:29 PM UTC

Eufrat wrote: post #148

wat10000 wrote: post #60

Earlier quoted context omitted.

To expand a bit: 16-byte chunks of memory can be associated with a four bit tag. Then you steal four unused high bits from your pointers to store a tag value. When memory has a tag, a pointer used to access it must have the matching tag in its high bits. Your malloc implementation can then assign a different tag to adjacent allocations and any overflow into an adjacent allocation will have a mismatched tag and will t…

Implementing MTE is mostly another step in Apple’s efforts towards memory safety. There are bunch of things they’ve done to try to make this work a little better, but for obvious reasons, this is never going to be turned on by default for user apps and is only enabled for specific pathways. > Because EMTE tag checking imposes a performance cost, we designed Memory Integrity Enforcement to take advantage of our secure…

Post by timschmidt » Thu, Sep 03, 2026, 2:05 PM UTC

yaro330 wrote: post #156

timschmidt wrote: post #144

Earlier quoted context omitted.

> It is a niche, it always was. Again, only because the platforms are locked down and there is no single standardized target for universally bootable ROMs in the way a Linux ISO can boot on any PC. Kinda sounds like you might be younger and didn't live through the 8bit micro -> PC transition. Standardization of the platform led to a cambrian explosion. https://en.wikipedia.org/wiki/Influence_of_the_IBM_PC_on_the...

> Again, only because the platforms are locked down and there is no single standardized target for universally bootable ROMs in the way a Linux ISO can boot on any PC. Couple of things here. Android was never that open to begin with. There were always (and still going) issues with the kernel sources being withheld indefinitely, AOSP side changes are almost never released at all, iirc only Google released anything. Bo…

Post by mmooss » Thu, Sep 03, 2026, 2:19 PM UTC

preisschild wrote: post #154

mmooss wrote: post #30

My strong instinct is that GrapheneOS's plan could be problematic: Generally, do not to invest in features that the upstream vendor isn't fully committed to. It might work today, but tomorrow or next year, etc., it might not. They might even deploy other things that are incompatible or do other things that assume the feature is disabled. In fact, plans to do those things might be the reason they disabled MTE. Also, n…

GrapheneOS is a non-profit, publicly naming the actual issues is the only thing they can do to make Google fix those issues. And it is clear that security/privacy is their first priority, not "brand image"

Post by disconnect3d » Thu, Sep 03, 2026, 2:34 PM UTC

delta_p_delta_x wrote: post #39

chekibreki wrote: post #3

For anyone else not knowing what MTE stands for: > Memory safety bugs, which are errors in handling memory in native programming languages, are common code issues. They lead to security vulnerabilities as well as stability problems. >Armv9 introduced the Arm Memory Tagging Extension (MTE), a hardware extension that allows you to catch use-after-free and buffer-overflow bugs in your native code. https://developer.andr…

MTE is essentially hardware-accelerated AddressSanitiser[1]. [1]: https://clang.llvm.org/docs/AddressSanitizer.html

Post by eigenform » Thu, Sep 03, 2026, 6:01 PM UTC

yxuehr wrote: post #155

eigenform wrote: post #132

> It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE. What I'd like to know is, is it not sufficient to just check the feature bits in ID_AA64PFR1_EL1? (Isn't this the first thing you'd try when trying to determine if the hardware supports some feature?) If they were making the determination solely based on the fact that `arm64.…

ID_AA64PFR1_EL1 was discussed five days ago https://discuss.grapheneos.org/d/41564-pixel-11-doesnt-meet-...