linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] arm64: use non-global mappings for UEFI runtime regions
Date: Tue, 17 Nov 2015 17:21:48 +0000	[thread overview]
Message-ID: <20151117172107.GK30101@arm.com> (raw)
In-Reply-To: <CAKv+Gu-L+YKonkzE2fyH9AzXcBERjMREMrHRXFu=xy2f+4gwpw@mail.gmail.com>

On Tue, Nov 17, 2015 at 06:11:56PM +0100, Ard Biesheuvel wrote:
> On 17 November 2015 at 18:08, Will Deacon <will.deacon@arm.com> wrote:
> > On Tue, Nov 17, 2015 at 09:53:31AM +0100, Ard Biesheuvel wrote:
> >> As pointed out by Russell King in response to the proposed ARM version
> >> of this code, the sequence to switch between the UEFI runtime mapping
> >> and current's actual userland mapping (and vice versa) is potentially
> >> unsafe, since it leaves a time window between the switch to the new
> >> page tables and the TLB flush where speculative accesses may hit on
> >> stale global TLB entries.
> >>
> >> So instead, use non-global mappings, and perform the switch via the
> >> ordinary ASID-aware context switch routines.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >> ---
> >>  arch/arm64/include/asm/mmu_context.h |  2 +-
> >>  arch/arm64/kernel/efi.c              | 14 +++++---------
> >>  2 files changed, 6 insertions(+), 10 deletions(-)
> >
> > Acked-by: Will Deacon <will.deacon@arm.com>
> >
> > Please do *not* tag this for stable! ;)
> >
> 
> OK, thanks for clarifying.
> 
> So for stable, should we keep the global mappings and do something
> like this instead?
> 
> """
>        cpu_set_reserved_ttbr0();
> 
>        local_flush_tlb_all();
>        if (icache_is_aivivt())
>                __local_flush_icache_all();
> 
>        if (mm != &init_mm)
>                cpu_switch_mm(mm->pgd, mm);
> """

That looks good to me, but I think we'd want to give it a good testing
given that we're solving a problem that has been spotted by code inspection
as opposed to real failures on hardware. There's even an argument that
it's not worth doing anything for -stable.

Will

  reply	other threads:[~2015-11-17 17:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-17  8:53 [RFC PATCH] arm64: use non-global mappings for UEFI runtime regions Ard Biesheuvel
2015-11-17 15:25 ` Mark Rutland
2015-11-17 16:34   ` Will Deacon
2015-11-17 16:48     ` Mark Rutland
2015-11-17 17:00       ` Ard Biesheuvel
2015-11-17 17:05         ` Ard Biesheuvel
2015-11-17 17:05         ` Will Deacon
2015-11-17 17:17         ` Mark Rutland
2015-11-18  6:42           ` Ard Biesheuvel
2015-11-18 12:01             ` Mark Rutland
2015-11-17 17:01     ` Ard Biesheuvel
2015-11-17 17:07       ` Will Deacon
2015-11-17 17:08 ` Will Deacon
2015-11-17 17:11   ` Ard Biesheuvel
2015-11-17 17:21     ` Will Deacon [this message]
2015-11-18  9:43 ` Catalin Marinas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151117172107.GK30101@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).