linux-kernel - [PATCH 05/18] x86: implement nospec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <151520102116.32271.8160376567325482844.stgit@dwillia2-desk3.amr.corp.intel.com>
Date:   Fri, 05 Jan 2018 17:10:21 -0800
From:   Dan Williams <dan.j.williams@...el.com>
To:     linux-kernel@...r.kernel.org
Cc:     Mark Rutland <mark.rutland@....com>, linux-arch@...r.kernel.org,
        peterz@...radead.org, gregkh@...uxfoundation.org,
        torvalds@...ux-foundation.org, netdev@...r.kernel.org,
        Alan Cox <alan.cox@...el.com>, tglx@...utronix.de,
        Arjan van de Ven <arjan@...ux.intel.com>,
        Elena Reshetova <elena.reshetova@...el.com>,
        alan@...ux.intel.com
Subject: [PATCH 05/18] x86: implement nospec_barrier()

The new speculative execution barrier, nospec_barrier(), ensures
that any userspace controllable speculation doesn't cross the boundary.

Any user observable speculative activity on this CPU thread before this
point either completes, reaches a state it can no longer cause an
observable activity, or is aborted before instructions after the barrier
execute.

In the x86 case nospec_barrier() resolves to an lfence if
X86_FEATURE_LFENCE_RDTSC is present. Other architectures can define
their variants.

Note the expectation is that this barrier is never used directly, at
least outside of architecture specific code. It is implied by the
nospec_{array_ptr,ptr} macros.

x86, for now, depends on the barrier for protection while other
architectures place their speculation prevention in
nospec_{ptr,array_ptr} when a barrier instruction is not available or
too heavy-weight. In the x86 case lfence is not a fully serializing
instruction so it is not as expensive as other barriers.

Suggested-by: Peter Zijlstra <peterz@...radead.org>
Suggested-by: Arjan van de Ven <arjan@...ux.intel.com>
Suggested-by: Alan Cox <alan.cox@...el.com>
Cc: Mark Rutland <mark.rutland@....com>
Cc: Greg KH <gregkh@...uxfoundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Alan Cox <alan@...ux.intel.com>
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 |    6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/barrier.h b/arch/x86/include/asm/barrier.h
index 7fb336210e1b..1148cd9f5ae7 100644
--- a/arch/x86/include/asm/barrier.h
+++ b/arch/x86/include/asm/barrier.h
@@ -24,6 +24,12 @@
 #define wmb()	asm volatile("sfence" ::: "memory")
 #endif

+/*
+ * CPUs without LFENCE don't really speculate much. Possibly fall back to IRET-to-self.
+ */
+#define __nospec_barrier() alternative("", "lfence", X86_FEATURE_LFENCE_RDTSC)
+#define nospec_barrier __nospec_barrier
+
 #ifdef CONFIG_X86_PPRO_FENCE
 #define dma_rmb()	rmb()
 #else