[10/11] x86 - add speculation_barrier pattern

Message ID 1532684275-13041-11-git-send-email-Richard.Earnshaw@arm.com
State New
Headers show
Series
  • (v2) Mitigation against unsafe data speculation (CVE-2017-5753)
Related show

Commit Message

Richard Earnshaw (lists) July 27, 2018, 9:37 a.m.
This patch adds a speculation barrier for x86, based on my
understanding of the required mitigation for that CPU, which is to use
an lfence instruction.

This patch needs some review by an x86 expert and if adjustments are
needed, I'd appreciate it if they could be picked up by the port
maintainer.  This is supposed to serve as an example of how to deploy
the new __builtin_speculation_safe_value() intrinsic on this
architecture.

	* config/i386/i386.md (unspecv): Add UNSPECV_SPECULATION_BARRIER.
	(speculation_barrier): New insn.
---
 gcc/config/i386/i386.md | 10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Uros Bizjak July 28, 2018, 8:25 a.m. | #1
On Fri, Jul 27, 2018 at 11:37 AM, Richard Earnshaw
<Richard.Earnshaw@arm.com> wrote:
>

> This patch adds a speculation barrier for x86, based on my

> understanding of the required mitigation for that CPU, which is to use

> an lfence instruction.

>

> This patch needs some review by an x86 expert and if adjustments are

> needed, I'd appreciate it if they could be picked up by the port

> maintainer.  This is supposed to serve as an example of how to deploy

> the new __builtin_speculation_safe_value() intrinsic on this

> architecture.

>

>         * config/i386/i386.md (unspecv): Add UNSPECV_SPECULATION_BARRIER.

>         (speculation_barrier): New insn.


The implementation is OK, but someone from Intel (CC'd) should clarify
if lfence is the correct insn.

Uros.
H.J. Lu July 31, 2018, 11:15 p.m. | #2
On Sat, Jul 28, 2018 at 1:25 AM, Uros Bizjak <ubizjak@gmail.com> wrote:
> On Fri, Jul 27, 2018 at 11:37 AM, Richard Earnshaw

> <Richard.Earnshaw@arm.com> wrote:

>>

>> This patch adds a speculation barrier for x86, based on my

>> understanding of the required mitigation for that CPU, which is to use

>> an lfence instruction.

>>

>> This patch needs some review by an x86 expert and if adjustments are

>> needed, I'd appreciate it if they could be picked up by the port

>> maintainer.  This is supposed to serve as an example of how to deploy

>> the new __builtin_speculation_safe_value() intrinsic on this

>> architecture.

>>

>>         * config/i386/i386.md (unspecv): Add UNSPECV_SPECULATION_BARRIER.

>>         (speculation_barrier): New insn.

>

> The implementation is OK, but someone from Intel (CC'd) should clarify

> if lfence is the correct insn.

>


I checked with our people.  lfence is OK.

Thanks.

-- 
H.J.

Patch

diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 559ad93..73948c1 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -301,6 +301,9 @@  (define_c_enum "unspecv" [
 
   ;; For CLDEMOTE support
   UNSPECV_CLDEMOTE
+
+  ;; For Speculation Barrier support
+  UNSPECV_SPECULATION_BARRIER
 ])
 
 ;; Constants to represent rounding modes in the ROUND instruction
@@ -20979,6 +20982,13 @@  (define_insn "cldemote"
   [(set_attr "type" "other")
    (set_attr "memory" "unknown")])
 
+(define_insn "speculation_barrier"
+  [(unspec_volatile [(const_int 0)] UNSPECV_SPECULATION_BARRIER)]
+  ""
+  "lfence"
+  [(set_attr "type" "other")
+   (set_attr "length" "3")])
+
 (include "mmx.md")
 (include "sse.md")
 (include "sync.md")