linux-kernel - [PATCH] x86/lib: don't use MMX before FPU initialization

lists.openwall.net		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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20201228160631.32732-1-krzysiek@podlesie.net>
Date:   Mon, 28 Dec 2020 17:06:31 +0100
From:   Krzysztof Mazur <krzysiek@...lesie.net>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        Krzysztof Mazur <krzysiek@...lesie.net>, stable@...r.kernel.org
Subject: [PATCH] x86/lib: don't use MMX before FPU initialization

When enabled, the MMX 3DNow! optimized memcpy() is used very early,
even before FPU is initialized. It worked fine, but commit
7ad816762f9bf89e940e618ea40c43138b479e10 ("x86/fpu: Reset MXCSR
to default in kernel_fpu_begin()") broke that. After that commit
the kernel crashes just after "Booting the kernel." message.
It affects all kernels with CONFIG_X86_USE_3DNOW=y (enabled when
some AMD/Cyrix processors are selected). So, enable MMX 3DNow!
optimized memcpy() later.

Cc: <stable@...r.kernel.org> # 5.8+
Signed-off-by: Krzysztof Mazur <krzysiek@...lesie.net>
---
Hi,

this patch fixes a kernel crash during boot observed on AMD Athlon XP
(with CONFIG_MK7=y).

The static key adds 5 byte NOP in the "fast" path. The 3DNow! usage
can be enabled earlier, but arch_initcall should be ok.
The static_cpu_has() does not work because the kernel with
CONFIG_X86_USE_3DNOW=y assumes that 3DNOW! is available,
so a static key is used instead. "Alternatives" should
also work, as long they not assume that required features
(REQUIRED_MASK*) are available early.

Similar bugs are possible. For easier debugging, maybe
kernel_fpu_begin() should catch such cases and print something?

Thanks,
Krzysiek

 arch/x86/lib/mmx_32.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/x86/lib/mmx_32.c b/arch/x86/lib/mmx_32.c
index 4321fa02e18d..375bf0798993 100644
--- a/arch/x86/lib/mmx_32.c
+++ b/arch/x86/lib/mmx_32.c
@@ -26,12 +26,14 @@
 #include <asm/fpu/api.h>
 #include <asm/asm.h>

+static __ro_after_init DEFINE_STATIC_KEY_FALSE(use_mmx);
+
 void *_mmx_memcpy(void *to, const void *from, size_t len)
 {
 	void *p;
 	int i;

-	if (unlikely(in_interrupt()))
+	if (unlikely(in_interrupt()) || !static_branch_likely(&use_mmx))
 		return __memcpy(to, from, len);

 	p = to;
@@ -376,3 +378,11 @@ void mmx_copy_page(void *to, void *from)
 		fast_copy_page(to, from);
 }
 EXPORT_SYMBOL(mmx_copy_page);
+
+static int __init mmx_32_init(void)
+{
+	static_branch_enable(&use_mmx);
+	return 0;
+}
+
+arch_initcall(mmx_32_init);
-- 
2.27.0.rc1.207.gb85828341f