I really want to see someone from the Pixel team justifying the decision here. I really wonder what the thought process is for someone to disable such a significant security feature for negligible performance gain.
I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
AOSP also only directly supports the phones/tablets we support. We were only talking about 2 of the devices supported by AOSP. Pixels enabling MTE is not connected to other devices. App compatibility is also not an issue because it can be enabled for the base OS with user installed apps excluded until they opt into it. It can be made opt-out in a future target API level (Android 15) and then the opt-out can be removed in the next target API level. This is entirely doable.
> I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
We're not ignoring it. We're talking about the Pixel 8, Pixel 8 Pro and future Pixels. It's a request for Pixels to enable it, not AOSP to enable it for all devices.
> I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
Performance and memory usage are definitely the only blocker to enabling it for the base OS. It would already be enabled if the security team was in charge of these decisions. It's not enabled because they likely have to prove it's fast enough. Our specific recommendation was enabling it in asynchronous mode for all cores for the base OS and user installed apps explicitly opting into it. We do not think it's a good idea to start automatically opting apps into using it until more Android devices support it. Google could require that ARMv9 devices support MTE as a developer option for Android 15 onwards in the CDD in order to make sure developers have it available for testing. App developers can't be expected to have a Pixel so it's unrealistic to have it forced on app developers via target API level until more devs have devices available to test it. We understand all that and what we are pushing for takes that into account.
We're only proposing enabling it for the base OS and user installed apps opting into it. Google has already fixed nearly all the crashes due to testing with HWAsan and MTE. They don't test enough with real world usage yet because they haven't deployed it for all the dogfooding devices. To do that, they need to set up enabling it for the base OS without enabling it for all user installed apps because that's not currently very practical. Google has already done most of the work for enabling it for the base OS, not us. We have to fix some bugs, but they're almost all regressions which don't live past the next quarterly releases since they do find and fix them. Google is 100% capable of enabling MTE for the Pixel stock OS within the base OS without a significant increase to crashes for users. In fact, it will significantly decrease user-facing crashes once it matures. It will result in so many memory corruption bugs being fixed. Testing internally with MTE doesn't do the same thing as deploying it to production in terms of bug fixing and also doesn't provide hardening against the bugs not occurring during regular usage.
They could enable it for the whole base OS and apps opting into it. They have already fixed nearly all the bugs uncovered in regular usage. They did nearly all the work but didn't take it over the finish line due to performance and memory/cache usage concerns. Their security engineers did their job already. They have very talented people working for them. Our ability to ship this feature before them is because the performance and memory concerns are not significant enough to matter to us. We're more than willing to lose 3.125% memory/cache and we accept the performance overhead of asymmetric MTE which is in the ballpark of a few percent overhead in most cases rather than near 0% like asynchronous MTE. There are cases where asymmetric MTE has a larger overhead than a few percent, but it's not common. Async mode is nearly free. MTE may not be as low overhead on future Pixels. It depends on them deciding to prioritize MTE performance in their future custom CPU design. If they do not ship it in production, it's unlikely that they'll prioritize the performance. The overhead may increase from 0% for async and a few percent for asymm to a far more significant cost.
The performance argument against MTE being deployed in production and against supporting MTE at all is the argument that's relevant. There is no other significant reason not to ship it for the base OS and enable it for all their own apps in their manifests. Getting it enabled for the whole app ecosystem is a much bigger problem requiring multiple steps: 1) broad availability of MTE capable devices for app developers, 2) making it opt-out instead of opt-in for a future target API level so developers get around a year and a half to either opt-out or deal with it, 3) removing the opt-out for a future target API level so that developers cannot simply opt-out. We know that part is hard. We know that part involves documentation, developer relations, concerns about giving app developers too much to deal with too quickly, etc. It isn't what we expect them to do short term. What we want them to do is enabling the near 0 overhead sync MTE for Pixels by default, with it used in the base OS and Google apps opting into it. They already did most of the work, even years earlier via HWAsan testing.
We don't expect them to enable asymmetric MTE or keep track of tags to provide more deterministic guarantees as we're doing. We understand they don't want to sacrifice 5% overall performance, and don't expect them to, but they could provide an opt-in for asymmetric mode + better deterministic guarantees. Google can could do it for Android 15 if they make the decision to do it now. A reasonable prediction is that in a couple years Apple ships MTE support in hardware with async mode by default and asymm in lockdown mode, and then Google does the same. They have a chance to be a leader on a hardware security feature far more valuable than the PAC feature where iOS is years ahead.
Longer answer:
Google folks were responsible for pushing on Hardware MTE in the first place - It originally came from the folks who also did work on ASAN, syzkaller, etc. They are not in Android, but it was done with the help and support of folks in Android. That's the Google side, it was obviously a partnership with ARM/etc as well.
I was the director for the teams that created/pushed on it, way back when - this was years ago at this point because of the lead times on a hardware/architecture feature like this.
So i'm very familiar with the tradeoffs.
It is more than just the memory usage or cache. The post is correct that it was designed to be able to be enabled/disabled dynamically, and needed to have expected perf cost ~0, but the main use case at the time was sampling based bug finding.
That is, if you turn MTE on (whether servers, phones, whatever) for 1% of the time for your entire fleet, and you have a large enough fleet, you will find basically all bugs very quickly. You can do this during dogfooding, etc.
Put another way - the goal was to make it possible to use have the equivalent of ASAN be flipped on and off when you want it.
Keeping it on all the time as a security mitigation was a secondary possibility, and has issues besides memory overhead.
For example, you will suddenly cause tons of user-visible crashes. But not even consistently. You will crash on phones with MTE, but not without it (which is most of them).
This is probably not the experience you want for a user.
For a developer, you would now have to force everyone to test on MTE enabled phones when there are ~1 of them. This is not likely to make developers happy.
Are there security exploits it will mitigate? Yes, they will crash instead of be exploitable. Are there harmless bugs it will catch? Yes.
But keep in mind what i said at the beginning - i would not assume they don't use it.
I would instead assume they don't necessarily use it in production on all the time.
Anyone who has experience on hardware feature bringup of this kind will tell you the fact that they can boot and run the system and only when they do this one thing does it crash under MTE is actually a very good sign they do use it.
Otherwise it would have probably crashed a million times :)
As an aside - It's also not obvious it's the best choice for run-time mitigation.
We know they're actively testing HWASan and MTE builds, but not with enough real world usage. If they tested it a lot on actual devices used by Google employees, they'd have fixed this Bluetooth LE audio issue before the release.
>As an aside - It's also not obvious it's the best choice for run-time mitigation.
What are some of the current contenders/arguments?
GrapheneOS uses our own implementation of hardware memory tagging for hardened_malloc with stronger security properties. In order to enable it by default for the base OS, we had to fix or work around various issues including this one. We use MTE in asymmetric mode across all cores rather than using asynchronous MTE for the main cores. Asymmetric mode is asynchronous for writes but synchronous for reads, which blocks exploitation properly rather than having a window of opportunity to succeed with exploitation. It gets checked on system calls and io_uring (another potential source of bypasses) is only available to 2 core system processes on Android via SELinux restrictions (fastbootd which is only used during installation and snapuserd used by the core OS after applying updates).
GrapheneOS always uses heap MTE for the base OS and apps known to be compatible with it. For user installed apps which are not in our compatibility database and which do not mark themselves as compatible, we provide a per-app toggle for enable MTE. Users can also toggle on using MTE by default for user installed apps which may not be compatible and can instead opt-out for incompatible apps. In order for this to be usable, we had to implement a user-facing crash reporting system. We did this in a way that users can easily copy a useful crash report to provide developers.
https://youtu.be/KmFVPyHyfqQ / https://ghostarchive.org/varchive/KmFVPyHyfqQ
https://youtu.be/9wRT2hNwbkA / https://ghostarchive.org/varchive/9wRT2hNwbkA
Edit: Nevermind, I seen it's only for Pixel 8 phones: https://news.ycombinator.com/item?id=38125379
We provided a user facing crash report system for memory corruption detected by MTE. MTE has no false positives. We strongly recommend users use the feature we provided for copying the crash report to report these bugs to app developers. App developers can replicate many of the bugs reported this way using either MTE on a Pixel 8 or a smaller subset by building their app with HWASan support.
Since many apps have latent memory corruption, we only enable it for the base OS, base OS apps and known compatible user installed apps by default. Users can opt-in to heap MTE for all user installed apps via Settings > Security and can then opt-out for apps with memory corruption occurring during regular use. Over time, we plan to add more apps like Signal/Molly known to be compatible to it into our app compatibility database so that it's force enabled for them by default without users enabling it in Settings > Security. The option to opt-out is only available for apps not known to be compatible with it, which is part of dealing with the issue of users potentially allowing it after an exploit attempt.
We're trying to convince Google to at least enable asynchronous MTE by default for the stock Pixel OS with user installed apps excluded from it unless they opt-in to it. The memory overhead is 3.125% and asynchronous heap MTE is near 0 performance overhead. Asymmetric heap MTE provides much better security but is more comparable to the overhead of a feature like legacy stack smashing protection. Stack MTE adds more overhead but SSP could be disabled to partly make up for it and deterministic protection of stack spills, return value, etc. can be provided through MTE instead since by not being tagged they have the 0 tag and everything tagged will be a random non-0 tag.
Android has monthly, quarterly and yearly releases. Other Android OEMs only ship the monthly security backports with only all of the Critical/High severity fixes, not most of the Moderate/Low severity fixes including most privacy fixes. This is PARTLY addressed by using an alternate OS shipping these patches, but every alternate OS available for those devices rolls back security in a lot of ways. Firmware and a lot of the device support code comes from the OEM in practice. Running Android 14 QPR2 on top of Android 12 kernel / drivers is possible but will be missing the security improvements for a huge portion of the OS.
The batteries in Pixels aren't trivial to replace without damaging the device, but it's officially supported and there are official parts available:
https://www.ifixit.com/Device/Google_Pixel
We simply can't support insecure devices without the basics. Our hardware requirement list includes very basic things not provided by most Android OEMs along with more advanced features such as MTE which we now consider basic requirements for decent security. We want to support other devices, but those devices must meet these requirements. Memory tagging is a baseline feature supported by standard Cortex ARMv9 cores. It's unfortunate that Qualcomm is not implementing support for it and that OEMs using an SoC supporting it are not bothering to set it up. It's sad having a feature available in the CPU architecture that's not usable due to the SoC or OEM.
https://grapheneos.org/features
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches. CalyxOS does not have features like this. It does the opposite of this.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
https://grapheneos.org/usage#sandboxed-google-play
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
Our hardware security requirements are listed at https://grapheneos.org/faq#future-devices. Pixels are the only devices providing the requirements we set for updates and the list of security features. They also provide proper alternate OS support where all those security features work correctly. Samsung has most of the expected features and provides a similar length of support and number of major yearly updates but is missing the proper alternate OS support, MTE and the monthly/quarterly updates.
Each month, there's a new Android release which are distinct from the partial backporting of privacy/security patches to older versions. It's not monthly security releases but rather monthly performance/security/feature releases with separate backports of all Critical/High severity patches to older versions. Android 14 and Android 14 QPR1 are older versions of Android, and there are security backports to Android 14 separate from the monthly releases. This is currently fairly exclusive to Pixels. Samsung is getting much better at doing the security backports and are reducing delays for major updates but they're still acting as if the monthly/quarterly releases don't exist.
Def can't trust Apple, can't trust Samsung. Google has managed to be the best. (Go ahead and @ me some cases that basically never hit the wild)
VoLTE in general is quite the trash fire.
Nope, unless you can fore your phone to only charge to below 80% they strain the battery just as much if not more by keeping them at 100% all the time.
(They support devices for slightly longer than the devices are supported upstream)
ARM did the work of designing it and integrating it into their standard ARM Cortex core/cache designs. Google/Samsung did the work of preserving standard ARM functionality, unlike Qualcomm which currently loses it. Google/Samsung also had to integrate it into the boot chain. They'd already previously done most of the bug fixing work via testing with HWASan. It is certainly true that Google paved the way to use MTE with HWASan and did a lot of the bug fixing work in the OS but external security researchers did a lot of this work too.
As an alternative to replaceable batteries you could consider installing something like acc[1] to mitigate stress on your battery. My phone is 7 years old and the original battery still holds a charge like the day I bought it.
[0]: https://github.com/uBlockOrigin/uBlock-issues/discussions/22...
Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking.
> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).
Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
Never heard of Google making installation of non genuine components hard the way Apple does.
*If your hands are too clumsy to reconnect battery wires when swapping batteries, get a swiss knife.
Look at this: https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacem...
That's not "swiss knife" replacement.
https://www.ifixit.com/repairability/smartphone-scores
> The battery is stubbornly glued down, and the soldered charge port can’t be easily replaced.
You have to take a heat gun to your phone to soften the glue to get the old battery out. Too little heat, the battery won't budge. Too much heat, you damage your screen or worse, ignite your battery. Good luck.
2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?
However, recently my wife and I travelled to Orlando Florida to visit Disney World and Universal Studios. While their apps mostly worked with sandboxed Google Play Services, I did have some annoying issues. The My Disney Experience app gave me a lot of glitches related to Location (it was intermittent but I would occasionally be told I need to be in US or Canada to do something important and we had to use my wife's phone as a workaround) and I found myself unable to log in to my account on the Universal App (again, worked fine on my wife's stock Samsung Galaxy so pretty sure it was GrapheneOS).
Another limitation is that if you use Google Wallet to make credit card payments, this is unsupported since Google will not certify GrapheneOS. Wallet does work otherwise.
Uber works just fine for me. Other than that, I don't use any proprietary apps.
If you intend to stick mostly to FOSS apps you shouldn't have any issues. Most proprietary apps will work with sandboxed Google Play Services, but if any of those are mission critical for you then be warned that you might run into some annoying issues like I did with Universal Studio & My Disney Experience.
Yes that means google will get your location, but it's still better than going back to stock which is also better than any other third party skin in terms of privacy/security.
2. No, it is very convenient. It has a sandbox for Google Play Services, which IMO is the best of both worlds as it means you can install all the proprietary crapware apps that make modern life tolerable, but Google Play doesn't have unfettered access to everything on your phone. If you want even more isolation you can set up a separate user and run all the Google Play stuff in a separate user account, which I did briefly try but personally I can't be bothered switching user all the time.
The phone has never crashed. My bank apps work.
I have a Pixel 6a.
As for it not working, were you running a Flatpak/Snap version of the browser? Apparently those are problematic with Web USB. I personally haven't tried on Linux yet (just Mac O's) but now that I've switched to Fedora I might encounter the same issue you did.
There's a bug on many Linux distributions which was fixed in fwupd but is still present because they haven't updated it to a recent version. It interferes with reconnecting to the device when it reboots into fastbootd mode as part of the install. We cover it in our install guides now. fwupd usually loses the race to connect to the device to the CLI install tool but wins the race against Chromium's implementation, which is why it impacts web install more. This is likely what you experienced before we documented this fwupd bug and got them to fix it upstream. The problem is that even though fwupd fixed it a while ago, Debian and even the latest Ubuntu still have the bug.
The two major things I need from my phone is good camera quality and being able to use Google Pay which is useful where I'm at.
It's very easy to install with the web installer.
https://grapheneos.org/install/web
You can buy a device with it, but nearly anyone can use the web installer. It's particularly easy to use from Android, ChromeOS and macOS. Windows is a bit trickier since you need to install a driver. Desktop Linux requires installing udev rules, and some distributions with frozen software versions have a buggy service which interferes.
> Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions?
Non-technical people can do it. You only need a browser with WebUSB. You don't need any special software.
> Is it very inconvenient to use as a daily driver?
Nearly the same as the stock Pixel OS with nearly as broad app compatibility if you use sandboxed Google Play.
> How often phone just crashes and requires a few days of debugging?
You likely won't experience significantly more crashes. It has user-facing crash reporting not existing in the stock OS so you'll notice crashes you wouldn't have known about it. Buggy apps with memory corruption may crash until you enable the per-app compatibility mode, ESPECIALLY if you opt-in to forcing MTE for all user installed apps.
> Will my bank app work on it?
If your bank allows a non-Google-certified OS, which most still do. Banks are gradually disallowing using a non-Google-certified OS and this essentially needs to be addressing as an anti-competition regulation issue. We're working on convincing banks to use https://grapheneos.org/articles/attestation-compatibility-gu... in the meantime.
No but it is not the most convenient thing either. The Security Additions, Sandboxing Setup and a bit of slowness due to the hardened memory allocator are more annoying than just using plain android and clicking ok for whatever data it wants from you. Initial Setup and understanding what makes grapheneos different and how to use it's security features takes a bit though.
> How often phone just crashes and requires a few days of debugging?
Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
> Will my bank app work on it?
Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
You can opt-out of secure app spawning if you deeply care about the small latency added to initial cold start app spawning time. You can opt-out of hardened_malloc with a per-app toggle if you find an app that's incompatible (memory corruption bugs caught by it) or which has bad performance with it.
There's no noticeable performance impact in regular usage. The only thing that was noticeable is the secure spawning (exec-based spawning) taking longer for initial app spawning time but that's entirely covered up by the animation time on current generation devices. There's a toggle for this for people who absolutely cannot cope with it, but we strongly recommend using secure spawning because many other security features depend on each app getting their own initial memory instead of being clones from the same template process (zygote) with a shared memory layout. It's not only about ASLR. It impacts PAC, MTE and any other partially or fully probabilistic mitigations.
> Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
GrapheneOS has user-facing crash reporting not present in the stock OS so users will definitely notice system process crashes they wouldn't have otherwise noticed. This helps us find issues like the Bluetooth crash the thread we posted was about fixing. We make all MTE detected crashes user facing since they tend to be serious issues and the crash reports tend to be useful for app developers or to us. We don't report all crashes by default but rather have a toggle for enabling that for the base OS in Settings > Security because it's too noisy. For example, sometimes hardware fails to fully wake up in the initial second of boot which automatically restarts the OS. It ends up reported as a kernel crash despite the fact that people wouldn't normally notice it. We got flooded with reports about this and had to reduce the scope of the user-facing reporting by default with opt-in to the rest.
Our features do find memory corruption bugs which were often not causing breakage in the stock OS but we believe this Bluetooth bug DOES often cause breakage in stock OS. It shows the other side of it which is that by finding the bugs, you can fix them, and you have fewer bugs remaining. GrapheneOS has dozens of fixes for upstream bugs. We try to report the security bugs upstream but their handling of non-security bug reports is awful so we don't bother for those.
> Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
At this point, it's nearly just the apps that are deliberately trying to prevent using an alternate OS which don't work. Apps using Play Integrity API to forbid using an alternate OS is nearly anything that doesn't work. Some apps also have older implementations of manually detecting an alternate OS. For example, a tiny number of apps look at the call stack leading to starting their app and purposely crash it doesn't match the stock OS which happens with exec-based spawning enabled, which we could add a per-app toggle to work around but an alternative without more complexity would be making it show the same call stack. It's quite silly that this is a problem. Play Integrity API is replacing most of these custom hacks to detect tampering with apps, hooking apps, etc. Play Integrity API COULD allow using GrapheneOS by verifying it using hardware attestation but of course doesn't. Apps can use hardware attestation themselves to do this, but they don't currently do it. We're working on convincing at a few major apps to do that. It's covered at https://grapheneos.org/articles/attestation-compatibility-gu....
As for how it works, it's been my daily driver OS on my Google pixel 6 nearly since the pixel 6 came out, and I've never once had it crash on me. Ever. It's never bugged out or needed me to debug or fix or maintain it in any way either. Every app I've ever tried just works on it too, as if I was using stock android, I literally don't even notice the difference honestly. Like sometimes I even forget this isn't what my phone came with. Personally my banking app, discover, works, but I don't know if others would, although I think they probably should since it has Google Play services and the bootloader is locked once you're done installing.
- There's no Google cloud backup, it uses Seedvault instead. It was a bit of a pain setting up some apps from scratch again (those that didn't have other backup mechanisms), but if I ever reinstall or switch to another phone running GrapheneOS I can copy over the backups and presumably restore them. It also supports some remote storage providers, but I haven't bothered with those yet.
- There's no Google Digital Wellbeing, which I used to track screen time and set limits for some apps. There are some limited alternatives on F-Droid, but I just ended up using Tasker to give me reminders when I'm staring at the screen for too long.
Other than that I didn't have any problems, and really enjoy the privacy features. Especially the ability to block network access per app, and set up custom storage scopes.
> and set up custom storage scopes
There's also Contact Scopes now. We've started work on adding App Communication Scopes for controlling that within profiles and we'd like to do similar features for Camera, Microphone and Location (the standard mock location feature is not great).
It's nearly indistinguishable from stock Android. It seriously Just Works. You may have to enable sandboxed Google Play Services to get some apps but other than that it's basically perfect.
As a daily driver, it's very mature and stable. The only downside for me is just a discovery of how much of the Google apps I use and how much they improve the stock experience. The biggest example for me was the keyboard (including speech to text). Thankfully (and something I give credit to Google for as they could make this hard or impossible), you can install most or all of those apps, including the Pixel Camera app, so you don't really have to give up much.
One important thing to note with Graphene is that they prioritize security, which is a little different than many ROMs in the past. For example, they highly discourage rooting due to its security implications, whereas in the past many ROMs came with root out of the box.
2. Not for me, but this highly depends on the use case. Graphene has good, honest documentation regarding this[0]. Banking is a pain point, because to the phone, GrapheneOS is an unverified third party system. Other than this, I have never seen a single crash, and I even use the YouTube apps with the Play store that it lets you install.
You can use a Pixel Watch or Galaxy Watch paired with GrapheneOS and make payments from the Pixel Watch.
The only issue is that GrapheneOS doesn't provide a built-in way to have root privileges and if you want root on your phone securely you will have to implement that yourself or use some third-party solution (e.g. building a userdebug build, using https://github.com/chriswoope/resign-android-image, using Magisk, etc.).
If not and you use something called the Aurora Store, prepare for nightmares. Or at least that has been my experience as far as inconveniences are concerned with the Aurora Store.
The only inconveniences if you may call them that have been in alerting me of things naughty apps were doing.
Actually, no. One problem I've had is that external audio input via USB has not worked for me. Anyone else figure that out?
On top of that, clean and unified UX and usable features must be provided or the engineering is all for naught.
Pixel 8 and Pixel 8 Pro are the main option with it. MediaTek and Exynos have theoretically added support for it but that doesn't mean any device with their latest flagship SoC theoretically supporting it actually has it available and working.
It's unfortunate that MTE is only 4 bits rather than at least being 8 bits. 1/15 is much worse than 1/255. It could be larger. MTE paves the way for tagging with a larger number of bits, including via a future iteration of MTE with 8 bits or more supported.
It's not specifically a bug finding feature. You can build very useful deterministic exploit protections out of reserved tags, even by simply using the standard 0 reserved tag. 1/15 chance of catching memory corruption in the general case is also nothing to sneeze at especially when combined with other features. If an exploit uses both an arbitrary read vulnerability and then an arbitrary write vulnerability that's 2 opportunities to catch it. It also gets combined with other features which make those exploits less reliable and harder to write. It doesn't exist in isolation. In hardened_malloc, it's just one part of what it does, but it's a huge advancement for it. Tagging the subset of stack allocations with possible overflows or use-after-scope will be another huge step forward.
It would of course be much nicer having massive tags ruling out inter-object memory corruption nearly completely. That doesn't mean MTE is not a good exploit protection and only good for finding bugs. MTE is a lot stronger than most existing exploit mitigations like SSP. SSP provides probabilistic protection against stack buffer overflows by moving the safe variables to the other side and checking a canary on return. If the attacker can leak the canary which is global to the process in userspace, they can write that out as part of it. It also only works against linear or very small (simply by adding padding) overflows. It only has deterministic protection against certain types of C string overflows via a 0 byte if the libc puts one at the start of the canary.
MTE an CHERI use a similar approach but MTE doesn't have large enough tags to provide strong security in the general case. MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
It's best to not perpetuate the belief that it's dumb people because very few people think they're dumb and I've seen some absolutely amazing coders write some hilarious memory bugs. It just comes with the territory of those languages. It's not "if" it's "when".
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
After 50 years of the Morris worm, only C Machines can fix the non existence of the mythical high skilled developer, and as Hoare predicted it is finally becoming a liability not to care about security.
I like how they snuck that in there :-D
As someone who spent years writing C and C++, but no experience with Rust, with this porting from C to Rust, how much refactoring is required? That might should be two different questions:
1. How closely does C translate directly over to Rust? Does Rust require some reorganization/refactoring?
2. How is Google approaching this? Are they trying to closely "translate" it as much as possible, or is this an opportunity for major rewrite/refactor?
Also very curious if anyone knows, will the Android Bluetooth stack ever be usable on a standard Linux distro desktop system?
My conclusion is that if you're writing a simple CLI or request-response thing, Rust is probably an easy port. More generally, if your code structure could work well with arena allocations, moving to lifetime-tagging of references isn't a big deal.
But if you're writing (admitted ugly) code with cyclic references the way a C programmer would :), Rust will feel like an uphill battle and is not the place to start. I need to start by restructuring the C++ code, moving ownership to a common parent. I think that'll make things better. Iteratively learning more about Rust, but continuing to work in C++ until the code has a better correspondance to Rust.
Edit: forgot the word simulator, and changed RefCell to Box.
Just so you know, RefCell does not inherently point to the heap. If you put a Box or something inside, sure, but on its own, it doesn't allocate.
Looking at what GravityBox was able to do, nothing in that can be done in a stock ROM without getting root.
