From ac6a1ed6eb14c20489f927dac2536ef94ecf1f5a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20B=C3=A4chler?= Date: Sun, 7 Dec 2014 09:22:03 +0000 Subject: [PATCH] linux: Use proper patches from git instead of manually modifying them. --- ...code-Update-BSPs-microcode-on-resume.patch | 48 ++++++++++ ...mit-the-microcode-reloading-to-64-bi.patch | 55 +++++++++++ PKGBUILD | 10 +- fix_CPU0_microcode_on_resume.patch | 92 ------------------- 4 files changed, 110 insertions(+), 95 deletions(-) create mode 100644 0001-x86-microcode-Update-BSPs-microcode-on-resume.patch create mode 100644 0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch delete mode 100644 fix_CPU0_microcode_on_resume.patch diff --git a/0001-x86-microcode-Update-BSPs-microcode-on-resume.patch b/0001-x86-microcode-Update-BSPs-microcode-on-resume.patch new file mode 100644 index 0000000..45c5b1b --- /dev/null +++ b/0001-x86-microcode-Update-BSPs-microcode-on-resume.patch @@ -0,0 +1,48 @@ +From fb86b97300d930b57471068720c52bfa8622eab7 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Tue, 18 Nov 2014 10:46:57 +0100 +Subject: [PATCH] x86, microcode: Update BSPs microcode on resume +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +In the situation when we apply early microcode but do *not* apply late +microcode, we fail to update the BSP's microcode on resume because we +haven't initialized the uci->mc microcode pointer. So, in order to +alleviate that, we go and dig out the stashed microcode patch during +early boot. It is basically the same thing that is done on the APs early +during boot so do that too here. + +Tested-by: alex.schnaidt@gmail.com +Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001 +Cc: Henrique de Moraes Holschuh +Cc: Fenghua Yu +Cc: # v3.9 +Signed-off-by: Borislav Petkov +Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic +Signed-off-by: Thomas Gleixner +--- + arch/x86/kernel/cpu/microcode/core.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c +index dd9d619..2ce9051 100644 +--- a/arch/x86/kernel/cpu/microcode/core.c ++++ b/arch/x86/kernel/cpu/microcode/core.c +@@ -465,6 +465,14 @@ static void mc_bp_resume(void) + + if (uci->valid && uci->mc) + microcode_ops->apply_microcode(cpu); ++ else if (!uci->mc) ++ /* ++ * We might resume and not have applied late microcode but still ++ * have a newer patch stashed from the early loader. We don't ++ * have it in uci->mc so we have to load it the same way we're ++ * applying patches early on the APs. ++ */ ++ load_ucode_ap(); + } + + static struct syscore_ops mc_syscore_ops = { +-- +2.1.3 + diff --git a/0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch b/0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch new file mode 100644 index 0000000..83e8095 --- /dev/null +++ b/0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch @@ -0,0 +1,55 @@ +From 02ecc41abcea4ff9291d548f6f846b29b354ddd2 Mon Sep 17 00:00:00 2001 +From: Borislav Petkov +Date: Sun, 30 Nov 2014 14:26:39 +0100 +Subject: [PATCH] x86, microcode: Limit the microcode reloading to 64-bit for + now +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001 + +The problem there was that microcode patches are not being reapplied +after suspend-to-ram. It was important to reapply them, though, because +of for example Haswell's TSX erratum which disabled TSX instructions +with a microcode patch. + +A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode +on resume") but, as it is often the case, simple fixes are too +simple. This one causes 32-bit resume to fail: + +https://bugzilla.kernel.org/show_bug.cgi?id=88391 + +Properly fixing this would require more involved changes for which it +is too late now, right before the merge window. Thus, limit this to +64-bit only temporarily. + +Signed-off-by: Borislav Petkov +Link: http://lkml.kernel.org/r/1417353999-32236-1-git-send-email-bp@alien8.de +Signed-off-by: Thomas Gleixner +--- + arch/x86/kernel/cpu/microcode/core.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c +index 2ce9051..08fe6e8 100644 +--- a/arch/x86/kernel/cpu/microcode/core.c ++++ b/arch/x86/kernel/cpu/microcode/core.c +@@ -465,6 +465,7 @@ static void mc_bp_resume(void) + + if (uci->valid && uci->mc) + microcode_ops->apply_microcode(cpu); ++#ifdef CONFIG_X86_64 + else if (!uci->mc) + /* + * We might resume and not have applied late microcode but still +@@ -473,6 +474,7 @@ static void mc_bp_resume(void) + * applying patches early on the APs. + */ + load_ucode_ap(); ++#endif + } + + static struct syscore_ops mc_syscore_ops = { +-- +2.1.3 + diff --git a/PKGBUILD b/PKGBUILD index bf4217b..c663286 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -18,7 +18,8 @@ source=("https://www.kernel.org/pub/linux/kernel/v3.x/${_srcname}.tar.xz" # standard config files for mkinitcpio ramdisk 'linux.preset' 'change-default-console-loglevel.patch' - 'fix_CPU0_microcode_on_resume.patch' + '0001-x86-microcode-Update-BSPs-microcode-on-resume.patch' + '0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch' ) sha256sums=('f5153ec93c5fcd41b247950e6a9bcbc63fa87beafd112c133a622439a0f76251' '435a8a3c4faad53b5f9f0349629358a7d273e6ca94ffeb226c1d360787cc7278' @@ -26,7 +27,8 @@ sha256sums=('f5153ec93c5fcd41b247950e6a9bcbc63fa87beafd112c133a622439a0f76251' '66fc95823d3c99167532f37c07e9582d305961103997fcc61cfc7f6a86b34130' 'f0d90e756f14533ee67afda280500511a62465b4f76adcc5effa95a40045179c' '1256b241cd477b265a3c2d64bdc19ffe3c9bbcee82ea3994c590c2c76e767d99' - 'fa48f83498bbef85dbe4b39eb88f89aac4dd2591232a3f13ec029fc44b0f497a') + 'fb120d3031886afd86a2054f551545898758b18f8bad1f6fee1c49e1ce23a760' + '529ffe2f52cba3ce8d7ab07bd85361d804d377464ee878ac085d6032336e4918') _kernelname=${pkgbase#linux} @@ -46,7 +48,9 @@ prepare() { # Fix FS#42689 # https://bugzilla.kernel.org/show_bug.cgi?id=88001 - patch -p1 -i "${srcdir}/fix_CPU0_microcode_on_resume.patch" + # + patch -p1 -i "${srcdir}/0001-x86-microcode-Update-BSPs-microcode-on-resume.patch" + patch -p1 -i "${srcdir}/0002-x86-microcode-Limit-the-microcode-reloading-to-64-bi.patch" if [ "${CARCH}" = "x86_64" ]; then cat "${srcdir}/config.x86_64" > ./.config diff --git a/fix_CPU0_microcode_on_resume.patch b/fix_CPU0_microcode_on_resume.patch deleted file mode 100644 index b3fe338..0000000 --- a/fix_CPU0_microcode_on_resume.patch +++ /dev/null @@ -1,92 +0,0 @@ -From fb86b97300d930b57471068720c52bfa8622eab7 Mon Sep 17 00:00:00 2001 -From: Borislav Petkov -Date: Tue, 18 Nov 2014 10:46:57 +0100 -Subject: x86, microcode: Update BSPs microcode on resume - -In the situation when we apply early microcode but do *not* apply late -microcode, we fail to update the BSP's microcode on resume because we -haven't initialized the uci->mc microcode pointer. So, in order to -alleviate that, we go and dig out the stashed microcode patch during -early boot. It is basically the same thing that is done on the APs early -during boot so do that too here. - -Tested-by: alex.schnaidt@gmail.com -Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88001 -Cc: Henrique de Moraes Holschuh -Cc: Fenghua Yu -Cc: # v3.9 -Signed-off-by: Borislav Petkov -Link: http://lkml.kernel.org/r/20141118094657.GA6635@pd.tnic -Signed-off-by: Thomas Gleixner - -diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c -index dd9d619..2ce9051 100644 ---- a/arch/x86/kernel/cpu/microcode/core.c -+++ b/arch/x86/kernel/cpu/microcode/core.c -@@ -465,6 +465,14 @@ static void mc_bp_resume(void) - - if (uci->valid && uci->mc) - microcode_ops->apply_microcode(cpu); -+ else if (!uci->mc) -+ /* -+ * We might resume and not have applied late microcode but still -+ * have a newer patch stashed from the early loader. We don't -+ * have it in uci->mc so we have to load it the same way we're -+ * applying patches early on the APs. -+ */ -+ load_ucode_ap(); - } - - static struct syscore_ops mc_syscore_ops = { --- -cgit v0.10.1 - -From 02ecc41abcea4ff9291d548f6f846b29b354ddd2 Mon Sep 17 00:00:00 2001 -From: Borislav Petkov -Date: Sun, 30 Nov 2014 14:26:39 +0100 -Subject: x86, microcode: Limit the microcode reloading to 64-bit for now - -First, there was this: https://bugzilla.kernel.org/show_bug.cgi?id=88001 - -The problem there was that microcode patches are not being reapplied -after suspend-to-ram. It was important to reapply them, though, because -of for example Haswell's TSX erratum which disabled TSX instructions -with a microcode patch. - -A simple fix was fb86b97300d9 ("x86, microcode: Update BSPs microcode -on resume") but, as it is often the case, simple fixes are too -simple. This one causes 32-bit resume to fail: - -https://bugzilla.kernel.org/show_bug.cgi?id=88391 - -Properly fixing this would require more involved changes for which it -is too late now, right before the merge window. Thus, limit this to -64-bit only temporarily. - -Signed-off-by: Borislav Petkov -Link: http://lkml.kernel.org/r/1417353999-32236-1-git-send-email-bp@alien8.de -Signed-off-by: Thomas Gleixner - -diff --git a/arch/x86/kernel/cpu/microcode/core.c b/arch/x86/kernel/cpu/microcode/core.c -index 2ce9051..08fe6e8 100644 ---- a/arch/x86/kernel/cpu/microcode/core.c -+++ b/arch/x86/kernel/cpu/microcode/core.c -@@ -465,6 +465,7 @@ static void mc_bp_resume(void) - - if (uci->valid && uci->mc) - microcode_ops->apply_microcode(cpu); -+#ifdef CONFIG_X86_64 - else if (!uci->mc) - /* - * We might resume and not have applied late microcode but still -@@ -473,6 +474,7 @@ static void mc_bp_resume(void) - * applying patches early on the APs. - */ - load_ucode_ap(); -+#endif - } - - static struct syscore_ops mc_syscore_ops = { --- -cgit v0.10.1 -