flawedworld

matchboxbananasynergy
@flawedworld
Confirming my understanding and a few questions: am I correct in my understanding that MTE is only a probabilistic measure, i.e. a mitigation measure, against Spectre? Project Zero
It says that the random assignment of tag parts can be achieved using compression techniques (e.g. EA0) to achieve more assignments, but will GrapheneOS developers ever modify this on their own?
Also, is the idea of having the tag generation, compression, and allocation calculations implemented in a sandbox within a TEE (v8 TrustZone, v9 RME, etc.) realistic?Implement MTE tag compression for swapped pages

sev

Regards the white bar please see: https://discuss.grapheneos.org/d/608-how-to-remove-bottom-white-bar/7

In reference to root methods such as Magisk being used on GrapheneOS:

If you unlock your bootloader and root your device you are then NOT running GrapheneOS which will be confirmed by Auditor when you run it afterwards. As such the discussion would no longer be appropriate for the GrapheneOS Discussion Forum as you are no longer discussing GrapheneOS.

@flawedworld It would be a violation of the security model and we will never support root
Source: [Matrix]

@Hulk GrapheneOS with root is not GrapheneOS
Source: [Matrix]

@TommyTran732 No point in using GrapheneOS if you are rooting. You are cripling your security with that.
Source: [Matrix]

@june:grapheneos.org we also are not exposing root support in any way. they can compile the OS themselves with root support or leave the bootloader unlocked with a patched boot image knowing they have ruined the security and privacy of GrapheneOS.
Source: [Matrix]

@akc3n Root destroys the Android Security Model.
Source: [Matrix]

@matchboxbananasynergy In a way, even if it's possible, a rooted GrapheneOS installation isn't really GrapheneOS anymore :)
Source: [Matrix]

As this is the GrapheneOS Discussion Forum further discussion surrounding such things would not be appropriate.

Please check using
* # * # 4636 # * # *
that VoLTE is provisioned. This does NOT have to be available to toggle but even greyed out is in the ON position.

If it is it should work if not this should be taken up with your carrier unless @flawedworld can add anything further.

ice if you wish to avoid utilising the privileged eSIM activation with sandboxed pkay services you should indeed be able to follow the same procedure as before.

Maybe @flawedworld the resident carrier expert can clarify and confirm that in either case the only additional information Google receives in both cases is your IMEI number.

Just listening to @flawedworld interview with THO and the conversation around FIDO and the convenience discussion.

It was mentioned how leveraging the TItanM for FIDO added a convenience for not having to go grab a standalone key like a Yubikey and how they can easily be lost.

Would a reasonable counter be that you can also lose your phone and is it just as inconvenient in having to make changes to your accounts if you did and had to move to another device or upgrade old to new say 4a to 7? Does a separate key not make handset migration easier?

Or am I off base and the TitanM info can be migrated from one handset to the next?

Also please feel free to discuss anything FIDO related as we go etc.

This is an awesome interview, congratulations @flawedworld 🔥

Here is the rewritten single-header library that wraps most (?all?) MTE functionality, mentionned earlier by @flawedworld.
I'll address a few points regarding what has been said in this thread quickly:

1. Intrinsics
   When I started working on it, I don't think intrinsics were readily available, or at least I wasn't able to find them. For this reason I used raw ASM instead (which causes other issues down the line but I digress).
   I fully agree that intrinsics should be used if possible, and will take a look at them more closely.
   However, some optimizations I do in MTELib might not be possible without assembly (e.g. this); though I haven't done any profiling so maybe the gain is insignificant and this point is moot.
2. The do/while in pointer tagging functions
   This comes from a misunderstanding on my side on how the random tag generation worked (I thought that all bits in the exclude mask were excluded in the random gen'ed tag, when I should have understood that bit X in exclude mask prevent tag X from being generated). This issue is addressed in MTELib.
3. DC GVA/DC GZVA
   I wasn't aware those existed as they're not mentioned in the MTE whitepaper.
   From a quick glance in the AArch64 Instructions documentation, it looks like they might generate exceptions (though it looks related to hypervisor so maybe it's just hyp traps?). I will look into this more closely later.

I will try to integrate this library in hardened_malloc in a similar fashion to what I currently have on GitHub in the next few days.