MEMORY TAGGING (MTE) OUTLINE FOR GRAPHENEOS
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.
MetropleX [GrapheneOS] ⚡🟣
npub1gd…7cn8c
2023-11-03 00:25:37
Author Public Key
npub1gd3h5vg6zhcuy5a46crh32m4gjkx8xugu95wwgj2jqx55sfgxxpst7cn8cPublished at
2023-11-03 00:25:37Event JSON
{
"id": "c74c8ccfedcccf45adcbf831c30f3fd5e8126f4f93180ee5e3bf7b0990aa7b93",
"pubkey": "43637a311a15f1c253b5d60778ab7544ac639b88e168e7224a900d4a41283183",
"created_at": 1698971137,
"kind": 1,
"tags": [],
"content": "MEMORY TAGGING (MTE) OUTLINE FOR GRAPHENEOS\n\nGrapheneOS 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.\n\nGrapheneOS 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.\n\nWe integrated it into hardened_malloc where it's able to provide stronger security properties than the experimental stock OS implementation.\n\nOur current toggle enables it for everything other than Vanadium, vendor executables and user installed apps bundling native libraries.\n\nWe'll be enabling memory tagging support for Vanadium by default via the standard Chromium implementation.\n\nFor 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.\n\nIt 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.\n\nIt'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.\n\nWhen 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.\n\nIn 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.\n\nMTE 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.",
"sig": "6d0251facc00bd3fedb3d341bada5927e330550f13accc7fe4e4a7372d3810cf4cd04678533dbdc5c4312940c7bf5ec79955034f07539c9e0cb7bff54a5e0409"
}