[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <151586746590.5820.13343935159472776801.stgit@dwillia2-desk3.amr.corp.intel.com>
Date: Sat, 13 Jan 2018 10:17:46 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: linux-kernel@...r.kernel.org
Cc: Mark Rutland <mark.rutland@....com>, Tom Lendacky <thomas.lendacky@....com>,
linux-arch@...r.kernel.org, gregkh@...uxfoundation.org,
Peter Zijlstra <peterz@...radead.org>, Alan Cox <alan.cox@...el.com>,
x86@...nel.org, Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>, kernel-hardening@...ts.openwall.com,
tglx@...utronix.de, torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
Elena Reshetova <elena.reshetova@...el.com>, alan@...ux.intel.com
Subject: [PATCH v3 4/9] x86: implement ifence()
The new barrier, 'ifence', ensures that speculative execution never
crosses the fence.
Previously the kernel only needed this fence in 'rdtsc_ordered', but now
it is also proposed as a mitigation against Spectre variant1 attacks.
When used it needs to be placed in the success path after a bounds check
i.e.:
if (x < max) {
ifence();
val = array[x];
} else
return -EINVAL;
With this change the cpu will never issue speculative reads of
'array + x' with values of x >= max.
'ifence', via 'ifence_array_ptr', is an opt-in fallback to the default
mitigation provided by '__array_ptr'. It is also proposed for blocking
speculation in the 'get_user' path to bypass 'access_ok' checks. For
now, just provide the common definition for later patches to build upon.
Suggested-by: Peter Zijlstra <peterz@...radead.org>
Suggested-by: Alan Cox <alan.cox@...el.com>
Cc: Tom Lendacky <thomas.lendacky@....com>
Cc: Mark Rutland <mark.rutland@....com>
Cc: Greg KH <gregkh@...uxfoundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...hat.com>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: x86@...nel.org
Signed-off-by: Elena Reshetova <elena.reshetova@...el.com>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
---
arch/x86/include/asm/barrier.h | 4 ++++
arch/x86/include/asm/msr.h | 3 +--
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index 7fb336210e1b..b04f572d6d97 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -24,6 +24,10 @@
#define wmb() asm volatile("sfence" ::: "memory")
#endif
+/* prevent speculative execution past this barrier */
+#define ifence() alternative_2("", "mfence", X86_FEATURE_MFENCE_RDTSC, \
+ "lfence", X86_FEATURE_LFENCE_RDTSC)
+
#ifdef CONFIG_X86_PPRO_FENCE
#define dma_rmb() rmb()
#else
diff --git a/arch/x86/include/asm/msr.h b/arch/x86/include/asm/msr.h
index 07962f5f6fba..e426d2a33ff3 100644
--- a/arch/x86/include/asm/msr.h
+++ b/arch/x86/include/asm/msr.h
@@ -214,8 +214,7 @@ static __always_inline unsigned long long rdtsc_ordered(void)
* that some other imaginary CPU is updating continuously with a
* time stamp.
*/
- alternative_2("", "mfence", X86_FEATURE_MFENCE_RDTSC,
- "lfence", X86_FEATURE_LFENCE_RDTSC);
+ ifence();
return rdtsc();
}
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.
