I believe the GrapheneOS team demands, in particular, a security feature called Memory Tagging Extensions (MTE). This feature has a phone's processor attach a "tag" to each memory location saying what's stored there and requires accesses to that memory to bear a matching tag. Buffer overflow type attacks are effectively prevented because a read into the adjoining region having a different tag gets rejected.

This feature is usually NOT present in desktop computers, and has only really been implemented by the Google Pixel hardware so far. It's unclear why it's viewed as being so critically necessary for Graphene: MTE is certainly useful but I personally wouldn't say its absence indicates an "insecure" device, and it imposes both a clear performance (and battery life!) penalty and a significant hardware burden on the SoC manufacturer. It's a pretty significant trade-off.

Anyway, that's the biggest single reason why GrapheneOS devs say "this hardware is not adequately secure": 99% of phone chips are excluded because they do not support MTE.

▲

rustcleaner 5 hours ago | parent | next [-]

While yes I am on GrapheneOS' side on these issues, I'm surprised nobody clones the GrapheneOS repo and simply disables the minimal handful of features which block it from working on devices. Maybe calling the clone CarbonOS? If MTE is required to boot GrapheneOS and Fairphones don't have MTE, then Fairphone clones GrapheneOS and disables MTE for its images. Graphene has so many features beyond just hardware security that other Androids lack, that it would be worthwhile to do this and it would still be higher security than the others (even if it's below GrapheneOS' own full security). Sensor & network permissions, storage & contact scopes, autoreboot, scrambled pin, radio auto-off, MAC address randomization, and more, I'm sure don't require MTE or Titan etc. Just follow GrapheneOS as upstream, making sure that the minimal set of changes needed to get it working on other/older devices transfers with the new updates.

▲

pferde 5 hours ago | parent | next [-]

Lack of MTE is not the only huge reason why the GrapheneOS team refuses most devices. Most vendors' lack of timely bugfixes for device-specific drivers and firmware, and no commitment to keep providing bugfixes for a number of years is another major factor.

	▲	rustcleaner 4 hours ago \| parent [-]
		Still, a 'degraded' GrapheneOS as my proposed CarbonOS, beats /e/, Lineage, Calyx, and stock. Not doing CarbonOS is throwing the baby (non-hardware hardening and features) out with the bathwater (the lack of hardware hardening). I for one do not wholly rely on Titan and use a long alphanumeric password on my primary profile to ensure BFU disk encryption isn't violated, while living in secondary daily-driver profiles which are PIN protected for ease of use. If I suspect phone seizure becomes a non-infinitesimal possibility, I can just reboot! Additionally, I would love to see an option in GOS that allows me to change the action bound to the panic sequence (5+ rapid presses of power): I would never call police using that sequence, I would 100x rather that sequence cause a shutdown instead. That way if I am asked to hand over my phone I can just panic sequence it as I am removing it from my pocket. As it stands now I would have to pause to interact with the screen to shut it off, significantly increasing the likelihood of the adversary snatching it before I could get it into BFU.

▲

gib444 2 hours ago | parent | prev [-]

> I'm surprised nobody clones the G®apheneOS repo and simply disables the minimal handful of features which block it from working on devices.

I wouldn't recommend that. They would be denounced by GOS (which is just idealism and purism and definitely not bullying – not at all.) Anything which isn't G®apheneOS is by definition technically inferior, wicked, insecure, privacy-invading and should erased from your device immediately.

▲

cherryteastain 4 hours ago | parent | prev [-]

MTE is not the only blocker here. Pixel 7 series do not have it and are currently supported by GrapheneOS. There are other concerns regarding things like a proper secure element implementation and timely firmware/binary blob updates.

	▲	rustcleaner 3 hours ago \| parent [-]
		Right, but still my CarbonOS idea ('degraded' GrapheneOS) is better than /e/, Lineage, Calyx, and stock. By 'degraded' I mean the minimal changes to current GrapheneOS needed to get it working on a given GrapheneOS-unsupported device.