For L8437 and others who may not fully understand that concepts explained in the above tweets (which is completely understandable), I think this very short tweet by @GrapheneOS sums it up nicely:

https://twitter.com/GrapheneOS/status/1717590326016098401

GrapheneOS will be getting massive improvements to our defenses against remote exploitation. It's going to significantly widen the security advantage over an iPhone or Pixel until they get default enabled memory tagging support. It's going to be a serious game changer.

[deleted] Nothing is bulletproof. Not GrapheneOS, or anything else. Anyone trying to sell you on a 100% guarantee is being dishonest. As mentioned in the GrapheneOS documentation:

[...] The next line of defense is preventing an attacker from exploiting a vulnerability, either by making it impossible, unreliable or at least meaningfully harder to develop.

What MTE brings is substantial security improvements. The project claims that it is the biggest security feature being shipped since the project started in 2014. It really is quite significant.

GrapheneOS already heavily focused on defending against exploitation of unknown vulnerabilities, which is explained here:

https://grapheneos.org/features#exploit-protection

MTE will significantly strengthen GrapheneOS' defenses and will raise the bar for exploitation even further.

    Initial hardware memory tagging support now available for Pixel 8 and Pixel 8 Pro in the latest release:

    https://grapheneos.org/releases#2023103000

    • add infrastructure for hardware memory tagging support
    • hardened_malloc: add support for hardware memory tagging launched with the ARMv9 cores on the Pixel 8 and Pixel 8 Pro
    • Settings: enable memory tagging toggle at Settings ➔ Security ➔ More security settings ➔ Advanced memory protection beta on supported devices (Pixel 8 and Pixel 8 Pro)
    • Pixel 8, Pixel 8 Pro: enable memory tagging support for everything built by GrapheneOS (other than Vanadium, since Chromium currently disables it) and also user installed apps without native libraries (will be expanded to Vanadium later along with the option to use it for all user installed apps)
    • Pixel 8, Pixel 8 Pro: use asymmetric memory tagging mode on all cores to provide much higher security than asynchronous mode without much more overhead unlike the very expensive synchronous mode without any clear security benefits over asymmetric

    From what I've read it sounds like MTE is being used to protect userspace, not the kernel itself. I read this blog post from Google Project Zero that talks about issues with protecting the kernel itself with MTE: https://googleprojectzero.blogspot.com/2023/08/mte-as-implemented-part-3-kernel.html

    Out of curiosity, is this something the GrapheneOS team is looking at? It sounds like a lot of upstream work would be needed before this becomes a robust mitigation, but unless kernel MTE failures occur in practice, it seems like it would be worth having in the kernel as a defense in depth, even with the issues described in that blog post.

      PolarOctopus We've started with userspace heap MTE which is now available but not yet enabled by default, which we want to do. We'll investigate userspace stack MTE next. Kernel doesn't really have proper MTE support but rather includes it as part of kasan and it's designed more as a debugging feature than a hardening feature so it would need a major overhaul.

      This is great. I see that it's labelled as beta. Are there any reasons for problems to arise at the moment? I'm not sure if I should hold back activating it for now.

      https://twitter.com/GrapheneOS/status/1719894154652586169

      GrapheneOS now has hardware memory tagging support in our Stable channel. Memory tagging greatly improves protection against targeted attacks. Thanks to hardware support on the Pixel 8 and Pixel 8 Pro, it's extremely low overhead despite the massive benefits it's able to provide.

      GrapheneOS users on the Pixel 8 and Pixel 8 Pro can enable memory tagging via Settings ➔ Security ➔ More security settings ➔ Advanced memory protection beta on supported devices. We'll be enabling it by default soon since we have a solid approach to preserve app compatibility.

      We integrated it into hardened_malloc where it's able to provide stronger security properties than the experimental stock OS implementation.

      Our current toggle enables it for everything other than Vanadium, vendor executables and user installed apps bundling native libraries.

      We'll be enabling memory tagging support for Vanadium by default via the standard Chromium implementation.

      For the near future, we'll be leaving memory tagging disabled by default for user installed apps bundling native libraries to avoid introducing a new compatibility issues.

      It will be possible to enable memory tagging for all user installed apps with the ability to opt-out for specific apps where it causes issues. We want to eventually have it globally enabled by default, but we expect it to uncover a lot of issues hardened_malloc hasn't before.

      It's also possible to use MTE for protecting from stack buffer overflows and use-after-scope by aligning and tagging variables with an escaping pointer. LLVM has an implementation of this and we've confirmed it works but it may not be optimized enough to enable it quite yet.

      When fully integrated into the compiler and each heap allocator, MTE enforces a form of memory safety. It detects memory corruption as it happens. 4 bit tags limit it to probabilistic detection for the general case, but deterministic guarantees are possible via reserving tags.

      In hardened_malloc, we deterministically prevent sequential overflows by excluding adjacent tags. We exclude a tag reserved for free tag and the previous tag used for the previous allocation in the slot to help with use-after-free detection alongside FIFO and random quarantines.

      MTE support for protecting the Linux kernel isn't enabled yet, but we can likely enable that by default too. However, it's currently part of kasan and is more oriented towards debugging than hardening. It's not entirely clear that enabling it in the current state is a good idea.

      What mode is recommended for highest security?

        8 days later

        PMUSR synchronous, it seems, but that has high overhead. From everything I've read above, asymmetric mode seems to have as high of security as synchronous mode, while only requiring the overhead about of asynchronous mode (lower security but lower overhead).

        That us, if I've understood the above correctly, someone please correct me if I'm wrong in any way! I'm really looking forward to my Pixel 8 Pro mostly so I can enjoy the benefits of defenses against 70% of common security vulnerabilities!

        10 days later

        I just got my pixel 8 and installed GrapheneOS on it, unfortunately I cannot find the mentioned MTE option under security -> more security settings. Do I need to enable anything on a fresh install to get it?

          Is there an easy way to see if it was triggered, like a crash log monitor? For Linux and kasan you can look into journalctl for the backtrace, would be nice to have a way to monitor crash logs in an easy way on the device.

            • [deleted]

            Xtreix He's not even talking about that.

            I tried the test app which P0 also described on their blog, the app crashes but there is no log. Is Graphene blocking the creation of tombstones for crashes? I also can only see one of the getprops mentioned there as set.

            Reference: https://googleprojectzero.blogspot.com/

              One more thing, don't try to enable mte-kernel, you will end up in a unrecoverable bootloop.

              matchboxbananasynergy that's so crazy it gets me wanting to buy an 8 barely 6 months after getting a 7!

              On an unrelated but sort of related subject, Linux has recently added Rust support. I don't know how mature is it, but, anyway, you guys ever considered trying a Rust implementation of hardened_malloc? Or of something else, in case it makes more sense...