matchboxbananasynergy thank you. Sounds very positive :)
MTE support status for GrapheneOS
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?
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!
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.
miles992 If you have the latest update, it's enabled by default everywhere since the previous upgrade except Vanadium (for now).
[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.
Yes I think so
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.