[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] x86/kexec: Fix crash on transition to a 32bit kernel on AMD hardware


  • To: Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • Date: Fri, 29 Oct 2021 00:26:58 +0100
  • Authentication-results: esa1.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Ian Jackson <iwj@xxxxxxxxxxxxxx>
  • Delivery-date: Thu, 28 Oct 2021 23:27:43 +0000
  • Ironport-data: A9a23:sMYEC6JozSlDze2iFE+RNZIlxSXFcZb7ZxGr2PjKsXjdYENShWcOm jEfWWmAPffYZTT2eNFwYIji9E4EuZaHx9VrGwNlqX01Q3x08seUXt7xwmUcns+xwm8vaGo9s q3yv/GZdJhcokcxIn5BC5C5xZVG/fjgqoHUVaiUZUideSc+EH140Eo5y7Zi6mJVqYPR7z2l6 IuaT/L3YDdJ6xYsWo7Dw/vewP/HlK2aVAIw5jTSV9gS1LPtvyB94KYkDbOwNxPFrrx8RYZWc QphIIaRpQs19z91Yj+sfy2SnkciGtY+NiDW4pZatjTLbrGvaUXe345iXMfwZ3u7hB3Ug8Fo6 McXj6WpEwV3FaPppvYabB1HRnQW0a1uoNcrIFC6uM2XiUbHb2Ht07NlC0Re0Y8wo7gtRzsUr LpBdW5LPkvra+GemdpXTsFFgMg5IdatF4QYonx6lhnSDOo8QICFSKLPjTNd9Gpv3pgWQKaED yYfQSNJPDWHQFpJBlI4MZAQkdm2nXDvdjIN/Tp5ooJoujOOnWSdyoPFL979atGMA8JPkS6wp 33E13T0BAkAM96SwibD9Wij7sffkCW+VI8MGbmQ8v9xnEbV1mEVEAcRV1awvb++kEHWc/B1J lEQ+yEuhbMv70HtRd74NyBUu1bd4ERaAYAJVbRntkfdkcI4/jp1GEBZUi9YSM58jvYvHz50/ VGsocHuOjhw5ej9pW2myp+Yqja7OC4wJGAEZDMZQQZt3+QPsL3fnTqUEY49SP/dYsndXGiqm WjT/XdWa6A71JZTj82GEUb7byVAT3QjZjU+4RnLRSqb5wd9aZ/Ni2eAuAWDs6gowGp0SDC8U Jk4dyq2sL9m4XKlznXlrAAx8FeBvavt3Nr02gcHInXZ327xk0NPhKgJiN2EGG9nM9wfZRjia 1LJtAVa6fd7ZSXxMPMrPd/sW51yl8AM8OgJsNiOM7KihbAqLWe6ENxGPxbMjwgBbmB1ycnTx qt3ge7zVC1HWMyLPRK9RvsH0K9D+8zN7Ti7eHwP9Dz+ieD2TCfMEd8taQLSBshkvPLsiFiEq L53aprVoyizpcWjO0E7B6ZIdgtURZX6bLirw/FqmhmreVs4ST54Ua+BndvMueVNxsxoqwsBx VnlMmcw9bY1rSevxdyiZi8xZbXxc4x4qH5nbyUgMUzxgyooYJq17bdZfJwyJOF1+OtmxP9yb v8EZ8TfXagfFmWZo2wQPcvnsYhvVBW3ngbSbSCrVycyIsx7TAvT9966Iga2rHsSDjC6vNcVq qG70l+JWoIKQglvVZ6EaP+mw16rk2IaneZ+AxnBLtVJIR2++4l2MS3hyPQwJphUexnEwzKb0 SeQAAsZ+raR89NkroGRiPnd/YmzEuZ4Ek5LJEXh7O67ZXvA426u4Y5cS+LULzrTY3z5pfe5b uJPwvCibPBexARWs5BxGqpAxL4l44e9vKdTywlpESmZb1mvDb88cHCK0dMW6/9Iz75d/wC3R liO6p9RPrDQYJHpF1sYJQwEaOWf1K5LxmmOvKpteEiqtjVq+LenUFlJO0jegSNQG7J5LYc5z Lpzo8UR8QG+1kInP9vuYvq4LIhQwqjsi5kai6w=
  • Ironport-hdrordr: A9a23:/aOxAK97VcxScLwVWLZuk+DUI+orL9Y04lQ7vn2YSXRuHPBw8P re+8jztCWE7Ar5N0tBpTntAsW9qBDnhPtICOsqTNSftWDd0QPCRuxfBOPZslvd8kbFl9K1u5 0OT0EHMqyTMWRH
  • Ironport-sdr: Finsqbu55MIkTc0MulkVXNihMwDdrxruU2ptGip3ug7VUhWBEm0cJsnxlHoRQK/P/7EGevjUEY 01n3FB21VX5BsHSx6JjJ+dSpxJIt7yLuh5DWVh7sXo5LgasSxCDDxTUSszXdBLBf39t/lnBT8k OOYCLRj2Q9gkiy4vQHm7lmaftuFadOG/MBciGnMeH4spEzHMEVYhpLLHGai1qYZW2HmjuUdc6V VGzP7rKtnNVD+kV4GyNAET/cXHOWfm/Z45ygxifac/Cdh2TzH5Mze0Fmvt0zk10j5vsbx9Up6T QD4650j2nPhiQae0JeodVE07
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

The `ljmp *mem` instruction is (famously?) not binary compatible between Intel
and AMD CPUS.  The AMD-compatible version would require .long to be .quad in
the second hunk.

Switch to using lretq, which is compatible between Intel and AMD, as well as
being less logic overall.

Fixes: 5a82d5cf352d ("kexec: extend hypercall with improved load/unload ops")
Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
---
CC: Jan Beulich <JBeulich@xxxxxxxx>
CC: Roger Pau Monné <roger.pau@xxxxxxxxxx>
CC: Wei Liu <wl@xxxxxxx>
CC: Ian Jackson <iwj@xxxxxxxxxxxxxx>

For 4.16.  This is a bugfix for rare (so rare it has probably never been
exercised) but plain-broken usecase.

One argument against taking it says that this has been broken for 8 years
already, so what's a few extra weeks.  Another is that this patch is only
compile tested because I don't have a suitable setup to repro, nor the time to
try organising one.

On the other hand, I specifically used the point of binary incompatibility to
persuade Intel to drop Call Gates out of the architecture in the forthcoming
FRED spec.

The lretq pattern used here matches x86_32_switch() in
xen/arch/x86/boot/head.S, and this codepath is executed on every MB2+EFI
xen.gz boot, which from XenServer alone is a very wide set of testing.
---
 xen/arch/x86/x86_64/kexec_reloc.S | 13 ++++---------
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/xen/arch/x86/x86_64/kexec_reloc.S 
b/xen/arch/x86/x86_64/kexec_reloc.S
index d488d127cfb9..a93f92b19248 100644
--- a/xen/arch/x86/x86_64/kexec_reloc.S
+++ b/xen/arch/x86/x86_64/kexec_reloc.S
@@ -86,12 +86,11 @@ call_32_bit:
         movq    %rax, (compat_mode_gdt_desc + 2)(%rip)
         lgdt    compat_mode_gdt_desc(%rip)
 
-        /* Relocate compatibility mode entry point address. */
-        leal    compatibility_mode(%rip), %eax
-        movl    %eax, compatibility_mode_far(%rip)
-
         /* Enter compatibility mode. */
-        ljmp    *compatibility_mode_far(%rip)
+        lea     compatibility_mode(%rip), %rax
+        push    $0x10
+        push    %rax
+        lretq
 
 relocate_pages:
         /* %rdi - indirection page maddr */
@@ -171,10 +170,6 @@ compatibility_mode:
         ud2
 
         .align 4
-compatibility_mode_far:
-        .long 0x00000000             /* set in call_32_bit above */
-        .word 0x0010
-
 compat_mode_gdt_desc:
         .word .Lcompat_mode_gdt_end - compat_mode_gdt -1
         .quad 0x0000000000000000     /* set in call_32_bit above */
-- 
2.11.0




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.