> 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.
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.
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.
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].
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.
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.
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.
> What I'd hope to hear is that Daniel Micay is in better mental health, but they made the almost-certainly wise choice to stop engaging with social media, and I can't find much information about what actually went down, so I guess it's a question mark.
I mean, it sounds like you have pretty much all the relevant information already?
strcat's technical chops were AFAIK never in question, but he had a tendency to pick up loud internet fights - to be fair, sometimes the other party were also being hostile jerks, but sometimes they weren't and he'd just swing at shadows.
After he pissed off Rossmann, he either realized or someone close to him made him realize (doesn't really matter which) that he should step away from the public square, and he did. Now he's just an ordinary, and I presume highly valued, contributor to GrapheneOS and to upstream AOSP.
Whether he still lurks the GrapheneOS discussion threads or not, or whether he is currently undergoing therapy or just chilling with a good book isn't really anyone else's business.
I was curious if that actually happened or not. However, I didn't actually see anything about GrapheneOS's leadership structure, or any kind of blog or anything where news like this would be announced.
So if it happened, who replaced them? Are they trustworthy? At least in my cursory searching, I didn't figure out an answer to that.
I assume the answer is actually out there, but I don't have it.
> Whether he still lurks the GrapheneOS discussion threads or not, or whether he is currently undergoing therapy or just chilling with a good book isn't really anyone else's business.
Sure, whatever. But failing any information about whether or not anything happened, I assume they still have root access to critical infrastructure. If so... I mean, naturally, the problem of trust hasn't changed much. If that's the case, then you still need to trust them to trust GrapheneOS. Can you? Don't know.
They just stepped down as the official head and stopped making public comments. They still are a major developer for the project and still seem to own/run parts of the project.
That's an orphaned commit on their personal website (and that text doesn't appear anywhere on it), and still nobody seems to have any idea who has taken their place. I don't believe that someone should be eternally punished because of making poor decisions, and with time even a pattern of poor decisions can be forgiven, but as it stands from the outside there's zero clarity on what, if anything, actually happened, no apologies, and ultimately no way to know who you're trusting when you install GrapheneOS.
On one hand, the track record for the actual OS is still completely fine as far as anyone knows. On the other hand, the stuff said and done on record is pretty tough to swallow for someone you are investing a lot of trust into, for an OS that is meant to be privacy and security focused.
Like. It's one thing if you are a casual user running random ROMs off XDA, the risk is high and the only real assurance you get is online reputation and the normal assurances of social pressure. But this is software endorsed by Edward Snowden and many others whose opinions regarding security and privacy are well-regarded. The stakes could be quite high for some users. In the light of that, I really don't like the situation here at all.
Dismiss it if you want to, but there's really absolutely no good reason for this to simply remain effectively unaddressed indefinitely.
Wow, strcat - now that's not a name I've heard in a long, long time. I remember he contributed a fair deal to Rust in the early days and then blew up in a very similar fashion.
It sickens me that this tabloid blathering is the 2nd thing after the story link and about 1/2 the page after load. The disclaimer that it's important because it's an OS, OS' are important, thus people who work on OS' are important, and you are discussing their mental health because you need to know if they'd "abuse their position" is ham-fisted.
> 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.
> 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.
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'
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.
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.
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].
True, however unless Windows developer community finally embraces ARM, that is something that will only worry them on the server with UNIX based workloads.
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.
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
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.
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.
> 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.