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]

            • Post #42

            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...

                    Velocity9490 These zero-days are pretty much single-use though

                    That's absolutely not the case. One smaller competitor of NSO that got on the news recently was selling packages of one hundred infections for $8 million.

                    Velocity9490 After an exploit gets deployed, it's likely for the device to be sent to an organization like Citizen Lab where it is closely examined, the malware is inspected and the vulnerability is reported to the vendor of the device/software and fixed

                    It doesn't really happen like this. Governments will have rules for having sensitive devices go through forensics regularly but of course that's not every day. Folks like journalists, politicians, dissidents, etc, will only send their phones to services like Citzen Lab in case of suspicion. Most of them don't even know about it.

                    And even then, it takes time to analyze the devices, discovering the bug that allowed the infection is probably far from guaranteed, than fixing the vulnerability is also not immediate, and, to top it all off, some people never update their phones, some people use old phones that won't get updates no more, so even patched vulnerabilities can still be used with some success.

                        • [deleted]

                        • Post #49

                        Hb1hf you guys ever considered trying a Rust implementation of hardened_malloc?

                        I don't expect them to rewrite the whole memory allocator in Rust.

                          miles992 Native crash reports do not get captured when native debugging is disabled. This will change in the next release

                            Is there any more detail on how and what settings of MTE are enabled by default? What code is now exactly protected? I am pretty confused after the first announcement with the switch and the changes afterwards.

                            Does it protect App+native libs, Apps, complete userland .... ? It's pretty important to understand what level of protection MTE currently provides to know the exact coverage of enablement.

                            Also there is the default bootctl flag, memtag and mem-tag kernel. I assume that the current implementation does not require memtag. The later one is for kernel/kasan and seems to break the system as I learned the hard way. Is there any difference in coverage between the bootctl flag and the current GrapheneOS implementation? I try to align these things and see what exact level of protection I got now.

                              miles992 Memory tagging is currently used in:

                              • all preinstalled apps (including Vanadium)
                              • all isolated WebView processes, including the ones that belong to apps that don't have memory tagging enabled
                              • all source-built system binaries (i.e. memory tagging is not used in proprietary vendor binaries)
                              • all third-party apps that don't have native code (they still use a lot of C/C++ code from system libraries)
                              • third-party apps that opted-in to memory tagging (almost none have done so)

                              Memory tagging support is enabled unconditionally via a bootloader flag:
                              https://github.com/GrapheneOS/device_google_zuma/commit/9f5ebd0cd557f661bed212ac01a71a74e0794361

                              Memory tagging is currently not used for:

                              • kernel memory allocators
                              • stack allocations
                              • hardened_malloc heap allocations that are larger than 128K. These large allocations use a separate allocator under the hood that provides a high level of protection even without memory tagging. Tagging such large allocations would have high overhead at allocation time
                              • Vanadium allocations that are larger than 1024 bytes and are made via PartitionAlloc (it's used for the majority of Vanadium allocations)