On Mon, Dec 10, 2018 at 02:29:45PM +0000, Will Deacon wrote: > On Mon, Dec 10, 2018 at 08:22:06AM -0600, Richard Henderson wrote: > > On 12/10/18 6:03 AM, Catalin Marinas wrote: > > >> However, it won't be too long before someone implements support for > > >> ARMv8.2-LVA, at which point, without changes to mandatory pointer tagging, we > > >> will only have 3 authentication bits: [54:52]. This seems useless and easily > > >> brute-force-able. [...] > > Perhaps the opt-in should be at exec time, with ELF flags (or equivalent) on > > the application. Because, as you say, changing the shape of the PAC in the > > middle of execution is in general not possible. > > I think we'd still have a potential performance problem with that approach, > since we'd end up having to context-switch TCR.T0SZ, which is permitted to > be cached in a TLB and would therefore force us to introduce TLB > invalidation when context-switching between tasks using 52-bit VAs and tasks > using 48-bit VAs. > > There's a chance we could get the architecture tightened here, but it's > not something we've pushed for so far and it depends on what's already been > built. Just a quick summary of our internal discussion: ARMv8.3 also comes with a new bit, TCR_EL1.TBIDx, which practically disables TBI for code pointers. This bit allows us to use 11 bits for code PtrAuth with 52-bit VA. Now, the problem is that TBI for code pointers is user ABI, so we can't simply disable it. We may be able to do this with memory tagging since that's an opt-in feature (prctl) where the user is aware that the top byte of a pointer is no longer ignored. However, that's probably for a future discussion. -- Catalin _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
