Enable ARMv9 Memory Tagging Extension (MTE) on Pixel 8 | Hacker News Reader

Enable ARMv9 Memory Tagging Extension (MTE) on Pixel 8

outflux.net

111 pointstranspute57 comments

Consider using GrapheneOS instead of stock Android for an improved version of MTE (and extra security and privacy as a bonus): https://discuss.grapheneos.org/d/8439-mte-support-status-for...

> Stock Pixel OS has it as a developer option which isn't usable in practice since it breaks far too much. The implementation is also much less powerful than hardened_malloc.

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

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

Also, currently it's not clear if it makes sense to enable kernel MTE:

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

Writing this from a Pixel running GrapheneOS. I've been away from Graphene (using Lineage) since the CopperheadOS days. Coming back I can safely say I will be buying Pixels as long as GrapheneOS is around. The robustness a finish is just amazing.

To anyone using a Pixel: install and donate (if you can)!

The web installer[1] is basically a few clicks on a web page. So damned impressed.

[1] https://grapheneos.org/install/web

Do you lose the whole play store? Does it even make sense if I use gmail? I like the idea at least. And my 4a isn't getting updates now(on graphene either apparently) which is a shame because I still like it. I used to ise lineage on Samsung devices.

One of GrapheneOS's absolute best features is the sandboxed Google Play Services.

Basically, where other privacy AOSP forks typically offer up to three choices...

- no Google at all

- root and install an extremely fragile FOSS alternative GPS implementation (MicroG)

- root and install the full Google Play Services binary blobs

... GrapheneOS offers option #4: you can install Google Play Services in a sandbox so that they still run, but they don't get root-level access to your system, instead they are treated the same as any other app (so e.g. you get to manage their access to location/storage/contacts etc.).

Note that you don't have to, it's just an option in the built-in Apps menu. I personally run GrapheneOS with no GPS at all in my main profile, and occasionally access my old Gmail/Gdrive accounts via web browser.

One of the things that Graphene doesn't support is Android Auto -- They have stated they will never support it due to the sheer rootkit levels that Android Auto does to the OS. Its a shame they have not found a good work around for it yet.

Does Google Wallet / NFC payments work?

Play store is available, just not installed by default. It also lives in a sandbox so has to ask for permission more than it does under standard android.

I never realized how many permissions the play store had, until I ran it under graphene.

GrapheneOS is the number one reason to get a Pixel. They do a lot of good work. Strcat's posts are very informative:

https://news.ycombinator.com/threads?id=strcat

Coming from an absolute outsider (recent ambivalent iPhone switch, previously Android), how can I know that GrapheneOS is secure and the provenance of my build is legitimate, so that I can trust it with my banking, email, photos, identity, etc.?

Builds are reproducible [1], so you can compile them yourself and check they match the official ones. Additionally, official releases are signed and the update client verifies them and prevents downgrade attacks [2]. You can also install updates offline from a computer if you prefer [3].

[1] https://grapheneos.org/build#reproducible-builds

[2] https://grapheneos.org/releases#about-the-releases

[3] https://grapheneos.org/usage#updates-sideloading

Provenance -> They have a bunch of tooling including attestation that you can use to verify your OS. GrapheneOS also operates like the stock OS with a locked bootloader, just signed with their keys, and the integrity of the boot chain up to and including the OS is what the attenstation app can verify after an initial pairing.

Secure -> It's code. There are no absolute guarantees. They have security enhancements on top of AOSP. So that's a rough proxy for what you should expect.

What about the propietary blobs?

I saw @jchw stating some good point but seems most in this thread here got their head in the sand.

too much trust in a product/service that may be secure on the surface, never means it's actually secure;

I ended up installing lineageOS rooted and firewalling everything and uninstalling useless services...that's better than having a system that is being advertised as state of the art security.

How dl you think google feels if their main OS market is being taken by a "secure" alternative like Graphene OS, unless they both struck a deal or are working together behind closed doors?

I got a suspicion that there's something the lead Dev of Graphene Os is unrevealing to us...hence they put him on desk job like a rookie cop who came across some sh*t that the public shouldn't know...

Meanwhile noone can fully confirm what's inside the OEM signed blobs that are on Graphene OS and other components. What more the heavy suggestion for never rooting; when over 200k apps on the playstore are riddled with malware/spyware?

Why would a billion dollar coorp let such clumsy mistake happen? I am starting to trust the fdroid store over Googleplay (despite being unable to have access to other apps) due to the fact:

Fdroid it's community baded/ the ppl make the app out of purely enjoyment versus montary need.

I have pxl4xl and ended up uninstalling Graphene OS something feels off about it.

No company CEO/Lead Dev just have a public dispute digitally and never explain why and the very next moment they are claimed to have had a mental breakdown.

and the fact that people are asking sincere questions and are being ridiculed for it, even raises more red-flags...

Think about it;

it's 2023, people gotta start thinking for themselves, nothing seems as it awlays is based on surface exposure.

I started only using software/tools by individuals or teams where the morale or principles is non-political and is in alignment with what makes sense no matter where you apply it.

It's a bunch of conspiratorial nonsense.

Reading your comment and the dead comment from the other guy, I can't actually tell what the grievance is. One of the lead devs stepped away from social media? Okay?

From what others have explained, graphene OS is fully open, has a number of provable security improvements over AOSP, and has notable improvements in controlling how apps access your device.

Some healthy skepticism in security software is fine. But I don't think there's anything to what you or the other person are saying. Is there a specific portion of the project, some specific lack of reproducibility in builds or some binary blob injection you're worried about? And if a minor personnel issue is enough to make you question an entire project, maybe you should buy a dumb phone with a Faraday cage, and run slackware on a Thinkpad.

Arm memory tagging whitepaper (2019), https://developer.arm.com/-/media/Arm%20Developer%20Communit...

> MTE provides a mechanism to detect both [spatial, temporal] categories of memory safety violation. MTE assists the detection of potential vulnerabilities before deployment by increasing the effectiveness of testing and fuzzing. MTE also assists detection of vulnerabilities at scale after deployment ... Memory locations are tagged by adding four bits of metadata to each 16 bytes of physical memory. This is the Tag Granule. Tagging memory implements the lock. Pointers, and therefore virtual addresses, are modified to contain the key.

And Googles announcement from 2019...

https://security.googleblog.com/2019/08/adopting-arm-memory-...

Project Zero today, https://googleprojectzero.blogspot.com/2023/11/first-handset...

> The ability of MTE to detect memory corruption exploitation at the first dangerous access is a significant improvement in diagnostic and potential security effectiveness. The availability of MTE on a production handset for the first time is a big step forward, and I think there's real potential to use this technology to make 0-day harder.

Memory tagged extension, to prevent some memory access bugs Here more info: https://brandulox.medium.com/pixel-8-and-8-pro-the-first-sma...

Per [1], I've also enabled MTE for user applications via the `persist.arm64.memtag.app_default` property. So far, the only crashes I've seen have been in apps that use cgo (eg. syncthing and rclone).

With root access, things can be persistently whitelisted on a per-app basis [2]:

    su -c 'setprop persist.arm64.memtag.app.<package name> off'

or based on basename(argv[0]) [3]:

    su -c 'setprop persist.device_config.memory_safety_native.mode_override.process.<basename> off'

[1] https://googleprojectzero.blogspot.com/2023/11/first-handset...

[2] https://cs.android.com/android/platform/superproject/main/+/...

[3] https://cs.android.com/android/platform/superproject/main/+/...

MTE is something like hardware-blessed address sanitizer. For more on MTE, I would recommend this nice short article: https://lwn.net/Articles/834289/

Why isn't it enabled by default?

There's probably a very good reason for it.

I would definitely advice anyone against enabling "Developer options" on your phone without having a good understanding what those options do. They are hidden and hard to access for a reason.

Sadly they contain some options which ought to be part of the normal system settings, but they aren't.

Such as animation speed. I hate _so much_ all the wobblyness of the GUI! Everything bouncing, sliding, and hovering around. Thankfully one can enable Developer options and set all that stuff to 0x, which effectively disables everything and now the system becomes crisp and instant, as it should be.

Another essential setting for saving much precious battery, is to not have the cellular data active at all times even when WiFi is active. If I come home and enable wifi, I do not want the cellular data to stay active too in the background. It's much better waiting the couple seconds it might take to switch networks, in exchange for some extra juice.

Also, configure "Smallest width" to a high dp value to fit more content on the screen.

For sure! that one is a very good candidate for basic option to tune on any phone. I always up it a bit to gain more screen estate.

Because it keeps catching poorly written code that hasn’t yet been fixed.

Or clever code that should not be fixed

I just added my own tagging to my pointers. I have 48-bit pointers and 16-bit of tagging data.

I replaced all my struct { word type; char* data }; with something like (type << 48) | data. This saves a memory allocation and pointer indirection. It is much faster

There is almost certainly a performance and battery life hit. Each pointer dereference will trigger a lookup in the MTE tag table, and a comparison between the pointer's tag and the table's tag.

So you have a decently sized chunk of RAM set aside for the tag table, more memory bandwidth used up by table lookups, and the cost of the actual tag checks.

Sounds very useful. Even just for testing.

Does x86 have something comparable?

Yes. Kind of.

AMD processors have Upper Address Ignore (UAI) with 7 bits of ancillary data, for Intel there is Linear Address Masking (LAM) with 6 or 15 bits [1]. The latter has made it into Linux after some initial resistance [2].

[1]: https://lwn.net/Articles/888914

[2]: https://www.phoronix.com/news/Intel-LAM-Merged-Linux-6.4

Those sound analogous to the TBI feature in Arm, rather than MTE itself (which uses TBI).

They did, MPX, however the design was buggy and eventually removed.

Currently x86 is the only mainstrem architecture without a plan for hardware memory tagging.

Even RISC-V has an ongoing discussion for hardware memory tagging extensions.

If AMD and Intel drag their feet long enough, CHERI will be production ready before then.

True, however unless Windows developer community finally embraces ARM, that is something that will only worry them on the server with UNIX based workloads.

IIRC, Intel announced about a year later plans to develop something similar. That being said, at the time they didn't have a specific timeline.

https://archive.is/09uCE

Wait, is this the first ARMv9 chip?

(Apple M3 is ARMv8.x, with X being 4 or 6 depending on who you ask)

Tensor G3 uses Cortex-X3/Cortex-A715/Cortex-510 from ARM, which are all ARMv9 cores. That said, there are other, earlier cores that also implement the ISA: Cortex-X2/Cortex-A710, for example.

I just wish there were a great virtual machine manager for Pixels. Apparently it is now possible without root, but only nestbox is available, AFAIK. It might be ok, but the monthly fee isn't a great deal, IMO.

I would love to hear a first-hand report of running in this mode from a week or two. Any bugs? Performance isses?

GrapheneOS runs with MTE on by default and it works great. I can't speak to issues with stock AOSP or Pixel roms but if there are issues, the GrapheneOS team has patched over them well enough that I haven't noticed one yet

Multicultural Toronto English? Something else?

(site seems dead)

Memory Tagging Extension (MTE)

This allows to assign tag to each memory allocation. And subsequent accesses to the same memory area must be made with a pointer having a correct tag.

Memory Tagging Extension, an arm v9 hardware feature for mitigating some memory safety bugs.

Is this the outcome of the Morello project? Honestly sounds nice.

CHERI vs MTE is a bit of a nuanced topic. At least one part of the limiting factor for MTE is that you get a finite number of tag “color codes” which opens the opportunity for some form of probabilistic attacks. Of course this helps with defense in depth as it’s yet another layer of security, but it isn’t as strong of a prevention as a CHERI capability for example.

This page explains it pretty well: https://msrc.microsoft.com/blog/2022/01/an_armful_of_cheris/

This survey by the same author also provides a good comparison https://saaramar.github.io/memory_safety_blogpost_2022/

No, AFAIK Morello project is about designing an Arm CPU with CHERI, a hardware architecture with extra security capabilities that is still WIP: https://tratt.net/laurie/blog/2023/two_stories_for_what_is_c...

I've been trying to get a Morello board for months, but they only offer them to large research institutions, not individuals who just want a hobby project. I'm aware of CHERI being different from this, but it still seems similar.

MTE is somewhat like an in-band, weak version of Morello, but the project is independent of MTE.

Reply on news.ycombinator.com