[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7e33326ecf792c1a2297d162735b3e63ac185ad0.camel@surriel.com>
Date: Mon, 27 Aug 2018 21:31:37 -0400
From: Rik van Riel <riel@...riel.com>
To: Andy Lutomirski <luto@...nel.org>, x86@...nel.org
Cc: Borislav Petkov <bp@...en8.de>, Jann Horn <jannh@...gle.com>,
LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Nadav Amit <nadav.amit@...il.com>
Subject: Re: [PATCH] x86/nmi: Fix some races in NMI uaccess
On Mon, 2018-08-27 at 16:04 -0700, Andy Lutomirski wrote:
> +++ b/arch/x86/mm/tlb.c
> @@ -345,6 +345,9 @@ void switch_mm_irqs_off(struct mm_struct *prev,
> struct mm_struct *next,
> */
> trace_tlb_flush_rcuidle(TLB_FLUSH_ON_TASK_SWITCH,
> TLB_FLUSH_ALL);
> } else {
> + /* Let NMI code know that CR3 may not match
> expectations. */
I don't get it. This is in the "ASID is up to date, do not
need a TLB flush" path.
In what case do we have a TLB that is fully up to date, but
a CR3 that does not match expectations?
Doesn't the CR3 check in nmi_uaccess_ok already catch the
window of time where the CR3 has already been switched over
to that of the next task?
What is special about this path wrt nmi_uaccess_ok that is
not also true for the need_flush branch right above it?
What am I missing?
> + this_cpu_write(cpu_tlbstate.loaded_mm, NULL);
> +
> /* The new ASID is already up to date. */
> load_new_mm_cr3(next->pgd, new_asid, false);
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists