x86-64: Remove syscall instructions at fixed addresses

Move vvars out of the vsyscall page into their own page and mark it NX.

Without this patch, an attacker who can force a daemon to call some fixed address could wait until the time contains, say, 0xCD80, and then execute the current time.

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/include/asm/fixmap.h        |    1 +
 arch/x86/include/asm/pgtable_types.h |    2 ++
 arch/x86/include/asm/vvar.h          |   22 ++++++++++------------
 arch/x86/kernel/vmlinux.lds.S        |   27 ++++++++++++++++-----------
 arch/x86/kernel/vsyscall_64.c        |    5 +++++
 tools/power/x86/turbostat/turbostat  |  Bin 0 -> 29200 bytes

Quoted 7 lines · Andy Lutomirski

Move vvars out of the vsyscall page into their own page and mark it NX.

Without this patch, an attacker who can force a daemon to call some fixed address could wait until the time contains, say, 0xCD80, and then execute the current time.

Quoted 8 lines

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/include/asm/fixmap.h        |    1 + arch/x86/include/asm/pgtable_types.h |    2 ++ arch/x86/include/asm/vvar.h          |   22 ++++++++++------------ arch/x86/kernel/vmlinux.lds.S        |   27 ++++++++++++++++----------- arch/x86/kernel/vsyscall_64.c        |    5 +++++ tools/power/x86/turbostat/turbostat  |  Bin 0 -> 29200 bytes

You've added the turbostat binary to the diffstat too. I believe this wasn't your intention, no? :)

arch/x86/kernel/traps.c +4 -0

+			print_vma_addr(" in ", regs->ip);
+			printk("\n");
+		}
+

Quoted 9 lines · Andy Lutomirski

arch/x86/kernel/entry_64.S +0 -0

@@ -1121,6 +1121,8 @@ zeroentry spurious_interrupt_bug do_spurious_interrupt_bug

 zeroentry coprocessor_error do_coprocessor_error errorentry alignment_check do_alignment_check zeroentry simd_coprocessor_error do_simd_coprocessor_error

arch/x86/kernel/entry_64.S +2 -0

+zeroentry intcc do_intcc
+

arch/x86/kernel/traps.c

Quoted 3 lines

      /* Reload gs selector with exception handling */ /* edi:  new selector */

arch/x86/kernel/traps.c +0 -0

I forgot to reply to your prior question about zeroentry vs. paranoidzeroentry.

That distinction is an undocumented x86-64-ism.

Btw, as a sidenote, and since you are already touching this code, would you be interested in putting this explanation into the source code? It's certainly not obvious and whoever wrote those macros did not think of documenting them for later generations ;-)

arch/x86/kernel/traps.c void __init trap_init(void) · line 877

Quoted 9 lines

+++ b/arch/x86/kernel/traps.c

arch/x86/kernel/traps.c +3 -0

@@ -872,6 +872,10 @@ void __init trap_init(void)
       set_bit(SYSCALL_VECTOR, used_vectors);
  #endif
 
+     set_system_intr_gate(0xCC, &intcc);
+     set_bit(0xCC, used_vectors);
+     printk(KERN_ERR "intcc gate isntalled\n");

I think you mentioned it but i cannot remember your reasoning why you marked it 0xcc (and not closer to the existing syscall vector) - please add a comment about it into the source code as well.

Ok, i suspect you marked it 0xCC because that's the INT3 instruction
- not very useful for exploits?

arch/x86/kernel/traps.c void __init trap_init(void)

Quoted 6 lines

arch/x86/kernel/traps.c +5 -0

+void dotraplinkage do_intcc(struct pt_regs *regs, long error_code)
+{
+     /* Kernel code must never get here. */
+     if (!user_mode(regs))
+             BUG();

Nit: you can use BUG_ON() for that.

Quoted 6 lines

+     local_irq_enable();
+
+     if (!in_vsyscall_page(regs->ip)) {
+             struct task_struct *tsk = current;
+             if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&

Nit: please put an empty new line between local variable definitions and the first statement that follows - we do this for visual clarity.

A not-so-nit: i'd not limit this message to unhandled signals alone. An attacker could install a SIGSEGV handler, send a SIGSEGV and attempt the exploit right then - he'll get a free attempt with no logging performed, right?.

Quoted 6 lines

+                 printk_ratelimit()) {
+                     printk(KERN_INFO
+                            "%s[%d] illegal int $0xCC ip:%lx sp:%lx",
+                            tsk->comm, task_pid_nr(tsk),
+                            regs->ip, regs->sp);

I'd suggest putting the text 'exploit attempt?' into the printk somewhere - a sysadmin might not necessarily know what an illegal int $0xCC is..

Quoted 5 lines

+                     print_vma_addr(" in ", regs->ip);
+                     printk("\n");
+             }

arch/x86/kernel/traps.c +1 -0

+

arch/x86/kernel/traps.c

Quoted 10 lines

arch/x86/kernel/traps.c +10 -0

+             force_sig(SIGSEGV, current);
+             return;
+     }
+
+     if (current->seccomp.mode) {
+             do_exit(SIGKILL);
+             return;
+     }
+
+     regs->ax = sys_gettimeofday((struct timeval __user *)regs->di, NULL);

Does the vsyscall gettimeofday ignore the zone parameter too?

arch/x86/kernel/traps.c

Quoted 5 lines

arch/x86/kernel/traps.c +4 -0

+
+     local_irq_disable();
+     return;
+}

Nit: no need for a 'return;' at the end of a void function.

Quoted 19 lines · Ingo Molnar

arch/x86/kernel/traps.c

Quoted 12 lines · Andy Lutomirski

arch/x86/kernel/entry_64.S +0 -0

@@ -1121,6 +1121,8 @@ zeroentry spurious_interrupt_bug do_spurious_interrupt_bug

 zeroentry coprocessor_error do_coprocessor_error errorentry alignment_check do_alignment_check zeroentry simd_coprocessor_error do_simd_coprocessor_error

arch/x86/kernel/entry_64.S +2 -0

+zeroentry intcc do_intcc
+

      /* Reload gs selector with exception handling */ /* edi:  new selector */

arch/x86/kernel/traps.c +0 -0

I forgot to reply to your prior question about zeroentry vs. paranoidzeroentry.

Quoted 1 line

That distinction is an undocumented x86-64-ism.

Is this an erratum or just the undocumented fact that swapgs twice puts usergs back and confuses the kernel?

Quoted 2 lines

Ok, i suspect you marked it 0xCC because that's the INT3 instruction
- not very useful for exploits?

Exactly.

The comments in irq_vectors.h make it sound like vectors 0x81..0xed are used for device interrupts but AFAICT it's only 0x20..0x39 that are used, so the precise choice of vector doesn't matter that much.

Quoted 4 lines

A not-so-nit: i'd not limit this message to unhandled signals alone. An attacker could install a SIGSEGV handler, send a SIGSEGV and attempt the exploit right then - he'll get a free attempt with no logging performed, right?.

I think if an exploit can call sigaction, then we've already lost.

But I can still make the change.

Quoted 5 lines

Quoted 3 lines

+     local_irq_disable();
+     return;
+}

Nit: no need for a 'return;' at the end of a void function.

:)

That pointless "return" statement was to hide the fact that the local_irq_enable wasn't correctly matched.

I'm changing this code a fair bit in preparation for the extra bonus patch to defang vsyscalls even more by trapping all of them.

Quoted 3 lines · Andrew Lutomirski

Quoted 2 lines

Ok, i suspect you marked it 0xCC because that's the INT3 instruction
- not very useful for exploits?

Quoted 5 lines

Exactly.

The comments in irq_vectors.h make it sound like vectors 0x81..0xed are used for device interrupts but AFAICT it's only 0x20..0x39 that are used, so the precise choice of vector doesn't matter that much.

No, we use almost all of the vector space for device interrupts. Why do you think only 0x20..0x39 is used?

Quoted 12 lines · Ingo Molnar

Quoted 8 lines · Andrew Lutomirski

Quoted 2 lines

Ok, i suspect you marked it 0xCC because that's the INT3 instruction
- not very useful for exploits?

Exactly.

The comments in irq_vectors.h make it sound like vectors 0x81..0xed are used for device interrupts but AFAICT it's only 0x20..0x39 that are used, so the precise choice of vector doesn't matter that much.

Quoted 2 lines

No, we use almost all of the vector space for device interrupts. Why do you think only 0x20..0x39 is used?

Possibility my inability to understand all the IRQ mapping code in just half an hour of trying.

In arch/x86/kernel/irq.c, arch_probe_nr_irqs returns NR_IRQS_LEGACY, which I think means that the genirq code allocates will only expect IRQs on that many vectors.

If I'm wrong then my patch could be bad: if something tries to use vector 0xcc for a device interrupt, then the vsyscall emulation code will eat that interrupt.

(0xcc is barely below the maximum. INVALIDATE_TLB_VECTOR_START could be as low as 0xcf.)

Quoted 13 lines · Andrew Lutomirski

Quoted 12 lines · Ingo Molnar

Quoted 8 lines · Andrew Lutomirski

Quoted 2 lines

Ok, i suspect you marked it 0xCC because that's the INT3 instruction
- not very useful for exploits?

Exactly.

The comments in irq_vectors.h make it sound like vectors 0x81..0xed are used for device interrupts but AFAICT it's only 0x20..0x39 that are used, so the precise choice of vector doesn't matter that much.

Quoted 5 lines

Quoted 2 lines

No, we use almost all of the vector space for device interrupts. Why do you think only 0x20..0x39 is used?

Possibility my inability to understand all the IRQ mapping code in just half an hour of trying.

Hey, you managed to find all the scattered pieces in just half an hour, i'm impressed ;-)

arch/x86/kernel/traps.c

Quoted 12 lines · Andy Lutomirski

arch/x86/kernel/entry_64.S +2 -0

@@ -1121,6 +1121,8 @@ zeroentry spurious_interrupt_bug do_spurious_interrupt_bug
 zeroentry coprocessor_error do_coprocessor_error
 errorentry alignment_check do_alignment_check
 zeroentry simd_coprocessor_error do_simd_coprocessor_error
+zeroentry intcc do_intcc
+
 
 	/* Reload gs selector with exception handling */
 	/* edi:  new selector */

arch/x86/kernel/traps.c +0 -0

I forgot to reply to your prior question about zeroentry vs. paranoidzeroentry.

That distinction is an undocumented x86-64-ism.

Background:

The SWAPGS instruction is rather fragile: it must nest perfectly and only in single depth, it should only be used if entering from user mode to kernel mode and then when returning to user-space, and precisely so. If we mess that up even slightly, we crash.

So when we have a secondary entry, already in kernel mode, we *must not* use SWAPGS blindly - nor must we forget doing a SWAPGS when it's not switched/swapped yet.

Now, there's a secondary complication: there's a cheap way to test which mode the CPU is in and an expensive way.

The cheap way is to pick this info off the entry frame on the kernel stack, from the CS of the ptregs area of the kernel stack:

        xorl %ebx,%ebx
        testl $3,CS+8(%rsp)
        je error_kernelspace
        SWAPGS

The expensive (paranoid) way is to read back the MSR_GS_BASE value (which is what SWAPGS modifies):

        movl $1,%ebx
        movl $MSR_GS_BASE,%ecx
        rdmsr
        testl %edx,%edx
        js 1f   /* negative -> in kernel */
        SWAPGS
        xorl %ebx,%ebx

1: ret

and the whole paranoid non-paranoid macro complexity is about whether to suffer that RDMSR cost.

If we are at an interrupt or user-trap/gate-alike boundary then we can use the faster check: the stack will be a reliable indicator of whether SWAPGS was already done: if we see that we are a secondary entry interrupting kernel mode execution, then we know that the GS base has already been switched. If it says that we interrupted user-space execution then we must do the SWAPGS.

But if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context, which might have triggered right after a normal entry wrote CS to the stack but before we executed SWAPGS, then the only safe way to check for GS is the slower method: the RDMSR.

So we try only to mark those entry methods 'paranoid' that absolutely need the more expensive check for the GS base - and we generate all 'normal' entry points with the regular (faster) entry macros.

I hope this explains!

All in one, your zeroentry choice should be fine: INT 0xCC will not issue in NMI context.

Btw, as a sidenote, and since you are already touching this code, would you be interested in putting this explanation into the source code? It's certainly not obvious and whoever wrote those macros did not think of documenting them for later generations ;-)

arch/x86/kernel/traps.c void __init trap_init(void) · line 877

Quoted 8 lines

+++ b/arch/x86/kernel/traps.c

arch/x86/kernel/traps.c +3 -0

@@ -872,6 +872,10 @@ void __init trap_init(void)
 	set_bit(SYSCALL_VECTOR, used_vectors);
 #endif
 
+	set_system_intr_gate(0xCC, &intcc);
+	set_bit(0xCC, used_vectors);
+	printk(KERN_ERR "intcc gate isntalled\n");

I think you mentioned it but i cannot remember your reasoning why you marked it 0xcc (and not closer to the existing syscall vector) - please add a comment about it into the source code as well.

Ok, i suspect you marked it 0xCC because that's the INT3 instruction
- not very useful for exploits?

arch/x86/kernel/traps.c void __init trap_init(void)

Quoted 5 lines

arch/x86/kernel/traps.c +5 -0

+void dotraplinkage do_intcc(struct pt_regs *regs, long error_code)
+{
+	/* Kernel code must never get here. */
+	if (!user_mode(regs))
+		BUG();

Nit: you can use BUG_ON() for that.

arch/x86/kernel/traps.c

Quoted 5 lines

arch/x86/kernel/traps.c +5 -0

+	local_irq_enable();
+
+	if (!in_vsyscall_page(regs->ip)) {
+		struct task_struct *tsk = current;
+		if (show_unhandled_signals && unhandled_signal(tsk, SIGSEGV) &&

Nit: please put an empty new line between local variable definitions and the first statement that follows - we do this for visual clarity.

A not-so-nit: i'd not limit this message to unhandled signals alone. An attacker could install a SIGSEGV handler, send a SIGSEGV and attempt the exploit right then - he'll get a free attempt with no logging performed, right?.

arch/x86/kernel/traps.c

Quoted 5 lines

arch/x86/kernel/traps.c +5 -0

+		    printk_ratelimit()) {
+			printk(KERN_INFO
+			       "%s[%d] illegal int $0xCC ip:%lx sp:%lx",
+			       tsk->comm, task_pid_nr(tsk),
+			       regs->ip, regs->sp);

I'd suggest putting the text 'exploit attempt?' into the printk somewhere - a sysadmin might not necessarily know what an illegal int $0xCC is..

Quoted 4 lines

arch/x86/kernel/traps.c +4 -0

+			print_vma_addr(" in ", regs->ip);
+			printk("\n");
+		}
+

arch/x86/kernel/traps.c

Quoted 10 lines

arch/x86/kernel/traps.c +10 -0

+		force_sig(SIGSEGV, current);
+		return;
+	}
+
+	if (current->seccomp.mode) {
+		do_exit(SIGKILL);
+		return;
+	}
+
+	regs->ax = sys_gettimeofday((struct timeval __user *)regs->di, NULL);

Does the vsyscall gettimeofday ignore the zone parameter too?

arch/x86/kernel/traps.c

Quoted 4 lines

arch/x86/kernel/traps.c +4 -0

+
+	local_irq_disable();
+	return;
+}

Nit: no need for a 'return;' at the end of a void function.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Now the only way to issue a syscall with side effects through the vsyscall page is to call a misaligned instruction. I haven't checked for that.

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/include/asm/traps.h    |    4 +++
 arch/x86/include/asm/vsyscall.h |    6 +++++
 arch/x86/kernel/entry_64.S      |    2 +
 arch/x86/kernel/traps.c         |    4 +++
 arch/x86/kernel/vsyscall_64.c   |   47 ++++++++++++++++++++++++++++++++++-----
 5 files changed, 57 insertions(+), 6 deletions(-)

Quoted 4 lines · Andy Lutomirski

Now the only way to issue a syscall with side effects through the vsyscall page is to call a misaligned instruction. I haven't checked for that.

Quoted 9 lines

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/include/asm/traps.h    |    4 +++
 arch/x86/include/asm/vsyscall.h |    6 +++++
 arch/x86/kernel/entry_64.S      |    2 +
 arch/x86/kernel/traps.c         |    4 +++
 arch/x86/kernel/vsyscall_64.c   |   47 ++++++++++++++++++++++++++++++++++-----
 5 files changed, 57 insertions(+), 6 deletions(-)

one very tiny nit below.

[...]

Quoted 8 lines

arch/x86/kernel/traps.c +0 -0

index b9b6716..d34894e 100644
@@ -872,6 +872,10 @@ void __init trap_init(void)
 	set_bit(SYSCALL_VECTOR, used_vectors);
 #endif
 

arch/x86/kernel/traps.c void __init trap_init(void) · line 877

Quoted 3 lines

arch/x86/kernel/traps.c +3 -0

+	set_system_intr_gate(0xCC, &intcc);
+	set_bit(0xCC, used_vectors);
+	printk(KERN_ERR "intcc gate isntalled\n");

Let's spell the error message correctly:

	printk(KERN_ERR "intcc gate installed\n");

Quoted 33 lines · Jesper Juhl

Quoted 4 lines · Andy Lutomirski

Now the only way to issue a syscall with side effects through the vsyscall page is to call a misaligned instruction.  I haven't checked for that.

Quoted 9 lines

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/include/asm/traps.h    |    4 +++ arch/x86/include/asm/vsyscall.h |    6 +++++ arch/x86/kernel/entry_64.S      |    2 +
 arch/x86/kernel/traps.c         |    4 +++ arch/x86/kernel/vsyscall_64.c   |   47 ++++++++++++++++++++++++++++++++++-----

 5 files changed, 57 insertions(+), 6 deletions(-)

one very tiny nit below.

[...]

arch/x86/kernel/traps.c void __init trap_init(void) · line 877

Quoted 11 lines

arch/x86/kernel/traps.c +3 -0

index b9b6716..d34894e 100644
@@ -872,6 +872,10 @@ void __init trap_init(void)
     set_bit(SYSCALL_VECTOR, used_vectors);
  #endif
 
+   set_system_intr_gate(0xCC, &intcc);
+   set_bit(0xCC, used_vectors);
+   printk(KERN_ERR "intcc gate isntalled\n");

Let's spell the error message correctly:

Quoted 2 lines

      printk(KERN_ERR "intcc gate installed\n");

Hmm, why is this KERN_ERR btw? Shouldn't it just be KERN_NOTICE or KERN_INFO ?

Quoted 35 lines · Jesper Juhl

Quoted 33 lines · Jesper Juhl

Quoted 4 lines · Andy Lutomirski

Now the only way to issue a syscall with side effects through the vsyscall page is to call a misaligned instruction.  I haven't checked for that.

Quoted 9 lines

Signed-off-by Andy Lutomirski <[email protected]>

---
 arch/x86/include/asm/traps.h    |    4 +++ arch/x86/include/asm/vsyscall.h |    6 +++++ arch/x86/kernel/entry_64.S      |    2 +
 arch/x86/kernel/traps.c         |    4 +++ arch/x86/kernel/vsyscall_64.c   |   47 ++++++++++++++++++++++++++++++++++-----

 5 files changed, 57 insertions(+), 6 deletions(-)

one very tiny nit below.

[...]

arch/x86/kernel/traps.c void __init trap_init(void) · line 877

Quoted 11 lines

arch/x86/kernel/traps.c +3 -0

index b9b6716..d34894e 100644
@@ -872,6 +872,10 @@ void __init trap_init(void)
     set_bit(SYSCALL_VECTOR, used_vectors);
  #endif
 
+   set_system_intr_gate(0xCC, &intcc);
+   set_bit(0xCC, used_vectors);
+   printk(KERN_ERR "intcc gate isntalled\n");

Let's spell the error message correctly:

Quoted 4 lines

Quoted 2 lines

      printk(KERN_ERR "intcc gate installed\n");

Hmm, why is this KERN_ERR btw? Shouldn't it just be KERN_NOTICE or KERN_INFO ?

IMO it shouldn't be there at all. It was a debugging leftover that I forgot to delete.

I lied about taking awhile to do this.

There are a bunch of syscall instructions in kernel space at fixed addresses that user code can execute.

One is a time() fallback. Patch 3/5 removes it.

Several are data that isn't marked NX. Patch 2/5 makes vvars NX and 5/5 makes the HPET NX.

The last one is the gettimeofday fallback. We need that, but it doesn't have to be a real syscall. Patch 3/5 adds int 0xCC (callable only from the vsyscall page) that implements the gettimeofday fallback and nothing else.

Patch 1/5 is just a dumb but harmless bug fix from the last vdso series.

I've only tested this in KVM with a hacked-up initramfs, but Ingo wanted it for 2.6.40, so here it is.

Andy Lutomirski (5):
x86-64: Fix alignment of jiffies variable
x86-64: Give vvars their own page
x86-64: Remove kernel.vsyscall64 sysctl
x86-64: Replace vsyscall gettimeofday fallback with int 0xcc
x86-64: Map the HPET NX

 arch/x86/include/asm/fixmap.h        |    1 +
 arch/x86/include/asm/pgtable_types.h |    6 ++-
 arch/x86/include/asm/traps.h         |    4 ++
 arch/x86/include/asm/vgtod.h         |    1 -
 arch/x86/include/asm/vsyscall.h      |    6 ++
 arch/x86/include/asm/vvar.h          |   24 ++++-----
 arch/x86/kernel/entry_64.S           |    2 +
 arch/x86/kernel/hpet.c               |    2 +-
 arch/x86/kernel/traps.c              |    4 ++
 arch/x86/kernel/vmlinux.lds.S        |   27 ++++++----
 arch/x86/kernel/vsyscall_64.c        |   86 ++++++++++++++++++---------------
 arch/x86/vdso/vclock_gettime.c       |   55 ++++++++-------------
 tools/power/x86/turbostat/turbostat  |  Bin 0 -> 29200 bytes
 13 files changed, 117 insertions(+), 101 deletions(-)
 create mode 100755 tools/power/x86/turbostat/turbostat

Btw., do you know CONFIG_X86_PTDUMP=y and /debug/kernel_page_tables? You could use that to double check that after your patches all executable (and fixed address) pages are removed [or are harmless].

Quoted 3 lines · Ingo Molnar

Btw., do you know CONFIG_X86_PTDUMP=y and /debug/kernel_page_tables? You could use that to double check that after your patches all executable (and fixed address) pages are removed [or are harmless].

Done. Now there's only one user-executable page and it's mostly harmless.

Maybe I'll try to get rid of vread_tsc and vread_hpet later on to make it even more harmless.

Quoted 6 lines · Andrew Lutomirski

Quoted 3 lines · Ingo Molnar

Btw., do you know CONFIG_X86_PTDUMP=y and /debug/kernel_page_tables? You could use that to double check that after your patches all executable (and fixed address) pages are removed [or are harmless].

Done.  Now there's only one user-executable page and it's mostly harmless.

ok. Will test your v3 series.

Quoted 2 lines

Maybe I'll try to get rid of vread_tsc and vread_hpet later on to make it even more harmless.

Yeah, that's a good idea. They need pushing into the INT 0xCC do_intcc() handler, that's all that's needed AFAICS - or can you see other complications with them?

[...] More importantly, vread_tsc contains an alternative and the vDSO can't currently contain alternative instructions. That can probably be fixed, but it'll take a bit of work.

Quoted 3 lines · Andrew Lutomirski

[...] More importantly, vread_tsc contains an alternative and the vDSO can't currently contain alternative instructions.  That can probably be fixed, but it'll take a bit of work.

You could start with picking the more compatible alternative instruction initially. I don't at all mind losing half a cycle of performance in that case ... this code should be secure first.

Thanks,

       Ingo

Quoted 3 lines

You could start with picking the more compatible alternative instruction initially. I don't at all mind losing half a cycle of performance in that case ... this code should be secure first.

The more compatible one is mfence, which in some cases could (I think) be a lot more than half a cycle.

Quoted 4 lines · Andrew Lutomirski

Quoted 3 lines

You could start with picking the more compatible alternative instruction initially. I don't at all mind losing half a cycle of performance in that case ... this code should be secure first.

Quoted 2 lines

The more compatible one is mfence, which in some cases could (I think) be a lot more than half a cycle.

I'd still suggest to do the mfence change now and remove the alternatives patching for now - if it's more than half a cycle then it sure will be implemented properly, right?

Thanks,

       Ingo