[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 15 Aug 2016 12:31:29 +0200
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Will Deacon <will.deacon@....com>
Cc: Mark Rutland <mark.rutland@....com>, Catalin Marinas <catalin.marinas@....com>,
Kees Cook <keescook@...omium.org>, kernel-hardening@...ts.openwall.com,
Julien Grall <julien.grall@....com>, James Morse <james.morse@....com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 0/7] arm64: Privileged Access Never
using TTBR0_EL1 switching
On 15 August 2016 at 12:30, Will Deacon <will.deacon@....com> wrote:
> On Mon, Aug 15, 2016 at 12:21:00PM +0200, Ard Biesheuvel wrote:
>> On 15 August 2016 at 12:06, Mark Rutland <mark.rutland@....com> wrote:
>> > On Mon, Aug 15, 2016 at 12:02:33PM +0200, Ard Biesheuvel wrote:
>> >> On 15 August 2016 at 11:58, Mark Rutland <mark.rutland@....com> wrote:
>> >> > On Mon, Aug 15, 2016 at 10:48:42AM +0100, Catalin Marinas wrote:
>> >> >> On Sat, Aug 13, 2016 at 11:13:58AM +0200, Ard Biesheuvel wrote:
>> >> >> > On 12 August 2016 at 17:27, Catalin Marinas <catalin.marinas@....com> wrote:
>> >> >> > > This is the first (public) attempt at emulating PAN by disabling
>> >> >> > > TTBR0_EL1 accesses on arm64.
>> >> >> >
>> >> >> > I take it using TCR_EL1.EPD0 is too expensive?
>> >> >>
>> >> >> It would require full TLB invalidation on entering/exiting the kernel
>> >> >> and again for any user access. That's because the architecture allows
>> >> >> this bit to be cached in the TLB so without TLBI we wouldn't have any
>> >> >> guarantee that the actual PAN was toggled. I'm not sure it's even clear
>> >> >> whether a TLBI by ASID or a local one would suffice (likely OK for the
>> >> >> latter).
>> >> >
>> >> > It's worth noting that even ignoring the TLB-caching of TCR_EL1.EPD0, the
>> >> > control only affects the behaviour on a TLB miss. Thus to use EPD0 we'd at
>> >> > least need TLB invalidation by ASID to remove previously-allocated entries from
>> >> > TLBs.
>> >>
>> >> ... or update the ASID to the reserved ASID in TTBR0_EL1, but leave
>> >> the actual TTBR address alone.
>> >>
>> >> This would remove the need for a zero page, and for recording the
>> >> original TTBR address in a per-cpu variable.
>> >
>> > That's a good point, and a better approach.
>> >
>> > Unfortunately, we're still left with the issue that TCR_EL1.* can be cached in
>> > a TLB, as Catalin pointed out. Which at minimum would require a TLBI ASIDE1,
>> > and may require something stronger, given the precise rules for TLB-cached
>> > fields isn't clear.
>> >
>>
>> So how exactly would EPDn = 1 be cached in a TLB, given that the bit
>> specifically means that TTBRn_ELn is ignored on a TLB *miss*. Doesn't
>> that mean 'not covered by a TLB entry'? Or does it mean 'not covered
>> by a TLB entry describing a valid translation'?
>>
>> I guess it indeed makes sense to get this clarified ...
>
> We'll put Rutland on the case.
>
>> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
