[Tharre]

No secure element, no memory tagging support, no proper cellular baseband isolation, no verified boot, taking months to ship security updates .. the list is long.

From a security/privacy perspective the fairphone is on the worse side of options unfortunately.

[neobrain]

> From a security/privacy perspective the fairphone is on the worse side of options unfortunately.

Compared to Pixel phones this is without a doubt true, but how does it compare against your average mid-range Android device? Do those typically have any of the features you mentioned?

[Tharre]

Very roughly, and assuming mid-range is around 400-500 bucks like the fairphone:

- Memory tagging is still pixel exclusive for now, but it's part of ARMv9 so it should be available on more devices in the future unless they disable it

- Most devices now have a secure element, though the exact capabilities vary

- Baseband isolation - no idea really, most chipsets should support IOMMU (or SMMU as ARM calls it) but is not very obvious if that's setup sanely or even used at all on your average device. So I'm guessing most devices are about the same.

- Security patches certain vendors are much better (like Samsung, for their non-budget devices anyway) but a lot do much the same. It shouldn't generally be worse because of Google's requirements.

- Verified boot is pretty standard

[strcat]

Memory tagging isn't Pixel exclusive anymore. Fairphone doesn't lack baseband isolation since it's a standard Snapdragon feature. Fairphone is worse than many OEMs at providing the standard security features and patches. Repeatedly using publicly available signing keys meant for testing for signing their OS is one example which has hopefully been fully addressed for the latest device.

[IshKebab]

> no memory tagging support

That's not a security feature though... We established that. Fair enough on the other points.

[strcat]

Memory tagging is an important security feature. The way GrapheneOS uses it is explained at https://news.ycombinator.com/item?id=44678704.

Only having 16 possible tags doesn't impact the deterministic protections we provide. One of the tag values is reserved for free data, internal metadata, etc. and can also be used as a form of 16 byte guard page. For heap allocation, we also dynamically omit the most recent adjacent non-free tags and the previous non-free tag for the current slot. There are 15 possible random values but 3 are dynamically omitted.

An attack often needs to use multiple invalid memory accesses where each one would have a 1/15 chance of success from probabilistic MTE alone. MTE gets combined with other probabilistic memory allocator protections. Our main memory allocator also has slot randomization and quarantine randomization.

A future revision of MTE could be easily be increased to 8 bits and it paves the path to having much larger memory tagging in the future too.

[Tharre]

For people out of the loop, parent is referring to TikTag[0], a side-channel speculative execution attack breaking MTE in a probabilistic defense scenario, and the weird cope coming from some people that "MTE was only supposed to be a debugging feature anyway".

However, you need some form of code execution beforehand already for this attack, and more importantly it doesn't affect any of the deterministic guarantees of MTE. And those are the main appeal to GrapheneOS in the first place, preventing things like use-after-free by tagging the memory such that it simply can't be accessed anymore. So it's very much a security feature.

[0] https://news.ycombinator.com/item?id=40715018

[IshKebab]

> MTE was only supposed to be a debugging feature anyway

It literally was. MTE is a padlock with 16 combinations.

[Tharre]

The number of combinations is irrelevant if you're not relying on randomness. Graphene sets the tag to a static value on deallocation[0] to prevent use-after-free, you don't even need to guess! The same is true for a lot of buffer overflows, as their allocator ensures two adjacent allocations have different tags, so unless the vuln allows you to skip ahead you'll always trigger a fault.

[0] https://github.com/GrapheneOS/hardened_malloc/blob/7481c8857...

[strcat]

We use the standard reserved tag (zero) for freed data but we also dynamically exclude the previous non-free tag for the current slot and the most recent adjacent non-free tags (i.e. the current tag for the adjacent slots or the previously used on if they're currently free). This provides a lot of deterministic protection against use-after-free especially when combined with our quarantine. It provides full deterministic protection against small or linear overflows. The fallback to probabilistic protection with 15 random values is still very valuable and does not mean only lowering exploit chance to 1/15. An exploit can require multiple invalid memory accesses. Side channels for leaking tag values aren't inherently usable in every case and an attacker can't simply choose the memory layout.

[IshKebab]

Interesting, fair point! I guess it helps for vulnerabilities that don't allow pointer control (which is probably a lot of them).

[strcat]

MTE mainly exists to catch the initial memory corruption in the first place rather than to protect specific targets from memory corruption. The current limitation of only having 16 possible tag values makes the fallback to probabilistic protection fall weaker than it could be but it's still very useful and multiple invalid memory accesses are often required. An invalid read is protected against as much as an invalid write. ARM acknowledged the issue of side channels able to leak side channels in certain circumstances and that's being addressed for newer hardware. Bear in mind side channels can be used to directly leak sensitive data too and it's a huge class of issues not specific to memory tagging.

[strcat]

https://news.ycombinator.com/item?id=44776816