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

      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]

      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)

          That is super helpful thanks! Is it possible to force MTE for all apps? I saw the google gut setting a bunch of props including:

          shiba:/ $ setprop arm64.memtag.bootctl memtag
          shiba:/ $ setprop persist.arm64.memtag.default sync
          shiba:/ $ setprop persist.arm64.memtag.app_default sync

          I assume the first one is the same as the flag you set. I am quite interested in the second and third parameter which deal with sync mode can be set the same way with the same effect as on ASOP?

            • [deleted]

            • Edited

            miles992

            These commands are doing a couple of things - first, we're configuring the bootloader to enable MTE at boot. The second command sets the default MTE mode for native executables running on the device, and the third command sets the default MTE mode for apps. An app developer can enable MTE by using the manifest, but this system property sets the default MTE mode for apps, effectively making it opt-out instead of opt-in.

            Also do note that you do not have to use the setprop arm64.memtag.bootctl memtag command on GrapheneOS, as the bootloader.pixel.MTE_FORCE_ON bootloader flag is already enabled unconditionally, as muhomorr said.

              • [deleted]

              • Edited

              [deleted] Adding more to this, GrapheneOS treats async mode as asymm mode, which means that when asynchronous mode is requested/configured, actually asymmentric mode is used. You can learn more about this here: Configuring the CPU-specific preferred MTE level (developer.android.com). Also, GrapheneOS does have memory tagging in asymmentric mode enabled by default for both the OS (except the kernel) and apps containing native code.

                [deleted] From the post above it reads like it's only enabled for system apps and apps which request it (-> "third-party apps that opted-in to memory tagging (almost none have done so"), the Kotlin apps are not MTE candidates to me as they are bytecode, but again the VM code below and System components are protected.
                That would lead me to the conclusion that I have to force MTE on for all apps by default to have the full effect of MTE protection ("setprop persist.arm64.memtag.app_default sync" or async, whatever is preferred), because it's not the current setting. Otherwise third party app native code is not covered by the default settings yet.

                  • [deleted]

                  • Edited

                  miles992 Yes. Also, you should always use async (asynchronous) which is treated as as (assymentric), so actually assymentric mode is and will be used (on GrapheneOS), unless you need to properly debug memory safety violations

                  miles992
                  On GrapheneOS MTE is also enabled for all user installed apps which dont have native code.

                  The latest release which is currently moving through alpha and beta channels has an option to enable it for all user installed apps and a toggle to turn it off for any app that breaks.

                  Theres no need to enable any MTE features using adb. Use of adb is a security risk best avoided.

                  MTE is also enabled in vanadium now. Including vanadium webview. Any apps using webview benefit.

                    • [deleted]

                    • Edited

                    Carlos-Anso Any apps using webview benefit.

                    To be more clear, only the webview process(es) will benifit, not the whole app(s)

                    Very cool development, I hope the beta becomes final soon. In the meantime I worked around by setting the flag manually. I know the risk involved with adb.

                    GrapheneOS unstickied the discussion .