Subject: [kernel-hardening] [PATCH 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching

From: [email-masked] (Will Deacon)
Date: Mon, 15 Aug 2016 12:00:49 +0100

On Mon, Aug 15, 2016 at 12:43:31PM +0200, Ard Biesheuvel wrote:
> On 15 August 2016 at 12:37, Will Deacon <[email-masked]> wrote:
> > On Mon, Aug 15, 2016 at 12:31:29PM +0200, Ard Biesheuvel wrote:
> >> On 15 August 2016 at 12:30, Will Deacon <[email-masked]> wrote:
> >> > On Mon, Aug 15, 2016 at 12:21:00PM +0200, Ard Biesheuvel wrote:
> >> >> As to Will's point, I suppose there is a window where a speculative
> >> >> TLB fill could occur, so I suppose that means updating TTBR0_EL1.ASID
> >> >> first, then TCR_EL1.EPD0, and finally perform the TLBI ASIDE1 on the
> >> >> reserved ASID.
> >> >
> >> > But then what do you gain from the reserved ASID?
> >> >
> >>
> >> To prevent TLB hits against the ASID of the current (disabled)
> >> userland translation
> >
> > Right, but if the sequence you described ensures that, then why not just
> > set TCR_EL1.EPD0 and do TLBI ASIDE1 on the current ASID?
> >
> 
> ... because then you wipe all the cached translations for current
> userland, which I suppose is best avoided. Wiping the reserved ASID
> only discards TLB entries that should not exist in the first place.

True, I guess we'd need to measure that vs. the extra cost of switching
to/from the reserved ASID.

> > I don't see the difference between a TLB entry formed from a speculative
> > fill using the reserved ASID and one formed using a non-reserved ASID --
> > the page table is the same.
> >
> 
> No, but EPD0 does not disable translations, it disable translation
> table walks on TLB misses, so we need to switch ASIDs to prevent user
> space accesses via TLB hits.

Right, only if you don't do the invalidation for the current ASID.

> But, how about we store the reserved ASID in TTBR1_EL1 instead, and
> switch TCR_EL1.A1 and TCR_EL1.EPD0 in a single write? That way, we can
> switch ASIDs and disable table walks atomically (I hope), and we
> wouldn't need to change TTBR0_EL1 at all.

I doubt that would work, unfortunately. Whilst the writes are atomic
from the point-of-view of the TCR, if the fields can be cached in the
TLB logic, then we can't guarantee the atomicity of changes to the
cached state. Nice idea, though!

Will