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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 26 Nov 2017 12:10:03 -0500
From:   Boris Ostrovsky <>
To:     Andy Lutomirski <>
Cc:     Juergen GroƟ <>,
        xen-devel <>,
        "" <>
Subject: Xen PV breakage after IRQ stack code refactoring


(Can't find the original patch in my mailbox)

This hunk from 1d3e53e8624a ("x86/entry/64: Refactor IRQ stacks and make 
them NMI-safe")

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index a9a8027..0d4483a 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -447,6 +447,59 @@ ENTRY(irq_entries_start)

+       pushfq
+       testl $X86_EFLAGS_IF, (%rsp)
+       jz .Lokay_\@
+       ud2
+       addq $8, %rsp

makes Xen PV guests somewhat unhappy because IF flag will be set.

I was hoping to use ALTERNATIVE instruction but when we hit this for the 
first time we haven't rewritten instructions yet. Moving check_bugs() a 
bit higher helps but because this is common code I don't know how well 
it will work on other architectures (and, in fact, whether it is even 
safe on x86 in general, although that can be verified).

Another option is to also add a parameter to DEBUG_ENTRY_ASSERT_IRQS_OFF 
(or to ENTER_IRQ_STACK) from xen_do_hypervisor_callback (which is where 
the failure happens) but this looks pretty fragile in that it assumes 
that xen_do_hypervisor_callback is the only place where we use this 
codepath before alt instructions are set.

Any other suggestions?


Powered by blists - more mailing lists