[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKv+Gu87t-AnDKvtk699CpEfkEPgB=6DE-8EhBCMMnczemVQ4Q@mail.gmail.com>
Date: Mon, 15 Aug 2016 12:56:58 +0200
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Catalin Marinas <catalin.marinas@....com>
Cc: Will Deacon <will.deacon@....com>, Mark Rutland <mark.rutland@....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:52, Catalin Marinas <catalin.marinas@....com> wrote:
> On Mon, Aug 15, 2016 at 12:43:31PM +0200, Ard Biesheuvel wrote:
>> 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 did this before for AArch32 + LPAE (patches on the list sometime last
> year I think). But the idea was nak'ed by the ARM architects. The
> TCR_EL1.A1 can be cached somewhere in the TLB state machine, so you need
> TLBI (IOW, toggling A1 does not guarantee an ASID switch).
>
But how is TTBR0_EL1 any different? The ARM ARM equally mentions that
any of its field can be cached in a TLB, so by that reasoning, setting
a new ASID in TTBR0_EL1 would also require TLB maintenance.
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.
