Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp402969pxb; Thu, 14 Jan 2021 08:36:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJyvmJiSGV8mskLtjVcZryGEA9j+2fepex0817/Py3YPa5aA/LudO3vkCw5KTq6fyTOagzLh X-Received: by 2002:a17:907:d8b:: with SMTP id go11mr5831694ejc.303.1610642188019; Thu, 14 Jan 2021 08:36:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610642188; cv=none; d=google.com; s=arc-20160816; b=pdWjAkz8x898eKaLQ6NTQoF0pBuG2OKdb9AtM61ikQ08pFwdrIZn1O+m9ZaNaC6Acb pcFN8V/L+PeHmY6Zcpp6p3h3+3rVEB11AlH0RPWlh4IaR4ex8pc1WSdQ575Gs+GlT1AN RIzROAbw3zbFY5xHmT2RUJP4AlD0g471feXxpPdKDbnZLXrCioyJ1wAM1zK8bBXO5A85 ks7U5aBCIVwu61QdkE5IGxRtvr1gNictpBvVgnimUQlzJnDx2vVrfYqUyfyA4ZPAmnEa R5LpPzvbIq18O1UPlhYb3GH22vEYjcfwg8jy+2dlgX8/CIHxBg7K6JDMGv3c82LHnHVG qt1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=O6+lVjayjq88klf0ZQagg0tohhcFJ3vGOJkwNkEVYlU=; b=G+hdcYcg62Ib6SJxGpuoUYjqocUmCHxYENmYLC5Rib0YwlUMTRx6vTjuzz+SQf9Vs4 B3/8W+BETi9XG1ODt3bhDU4ZLHH0ebCKGta2FY/eQCW57OwZIXmYLjVdLg/QtsEXQ3Mb PCwc6RDay9jiSbMpP6kpja7XAiYCkdgM1QCGJucV1JMKWUIpJtpIgEVdNHhS46AbEAoj Mhd61N47at4+Uhw7oCT62YLYGWF3q9U5jDO7qI31LJ7mJVT/GYQiDl2VERI7fgccAs+C XSw0dBMkCHJeAKw9XFdB1tnhMnVsoIw6x0lvmRyAD7KNiYoVPTAfCOyt+HVYKpRY633P kOCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=L1hQdNiv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j14si2628763ejy.327.2021.01.14.08.36.03; Thu, 14 Jan 2021 08:36:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=L1hQdNiv; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726468AbhANQcY (ORCPT + 99 others); Thu, 14 Jan 2021 11:32:24 -0500 Received: from mail.kernel.org ([198.145.29.99]:47704 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726419AbhANQcX (ORCPT ); Thu, 14 Jan 2021 11:32:23 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 21B2C23B46 for ; Thu, 14 Jan 2021 16:31:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610641903; bh=wb1kG1KOAEcolwpdR+/yk6//aiweBGIjXCPqYQo31CI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=L1hQdNive443MYwW0uH9ce6vVzRF6OcQFXFGgQJZyN785v0EYJfgUqfJCLGT5FgcJ r2ccGbv8njQ6XjKSKynPJOsUkYSKjLIS1pns303WPc5AMfP3OV9Sg5Q1BHYJ84Chgz G9EhsI7y4R23G0Bk+DEkn4eVGRtA9lKuggAMduWRCvC51gH7Bay4GHJ63xRhk5M0I7 sWGL5Hs1s0TuvEkJORPBmNr5IytdAgZFkiLQElg1ub3dOkev/pqAJNYbRPipuiDj+o zgvjGVRyzDesWaJ7E5GBbcVpO9yd0OHEdkhzCPYAawYL0RKgObq25ouEscQwYjIxhg BqeayE1Puo3qw== Received: by mail-ed1-f46.google.com with SMTP id dj23so3760020edb.13 for ; Thu, 14 Jan 2021 08:31:43 -0800 (PST) X-Gm-Message-State: AOAM532bGSXZtyNSW3afGgl56FUmpsSDgZGJFN6Ny/z+tDbDUKYvCiwZ CrXI+uXNFnY+GyKGITKtTJbtTtoDn6DDstGsMVNeNA== X-Received: by 2002:aa7:ca55:: with SMTP id j21mr6223884edt.172.1610641901633; Thu, 14 Jan 2021 08:31:41 -0800 (PST) MIME-Version: 1.0 References: <20201228160631.32732-1-krzysiek@podlesie.net> <20210112000923.GK25645@zn.tnic> <20210114092218.GA26786@shrek.podlesie.net> <20210114094425.GA12284@zn.tnic> <20210114123657.GA6358@shrek.podlesie.net> <20210114140737.GD12284@zn.tnic> <20210114145105.GA17363@shrek.podlesie.net> In-Reply-To: <20210114145105.GA17363@shrek.podlesie.net> From: Andy Lutomirski Date: Thu, 14 Jan 2021 08:31:30 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] x86/lib: don't use MMX before FPU initialization To: Krzysztof Mazur , "Jason A. Donenfeld" Cc: Borislav Petkov , Thomas Gleixner , Ingo Molnar , X86 ML , LKML , stable Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 14, 2021 at 6:51 AM Krzysztof Mazur wrote: > > On Thu, Jan 14, 2021 at 03:07:37PM +0100, Borislav Petkov wrote: > > On Thu, Jan 14, 2021 at 01:36:57PM +0100, Krzysztof Mazur wrote: > > > The OSFXSR must be set only on CPUs with SSE. There > > > are some CPUs with 3DNow!, but without SSE and FXSR (like AMD > > > Geode LX, which is still used in many embedded systems). > > > So, I've changed that to: > > > > > > if (unlikely(in_interrupt()) || (boot_cpu_has(X86_FEATURE_XMM) && > > > unlikely(!(cr4_read_shadow() & X86_CR4_OSFXSR)))) > > > > Why? > > > > X86_CR4_OSFXSR won't ever be set on those CPUs but the test will be > > performed anyway. So there's no need for boot_cpu_has(). > > Because the MMX version should be always used on those CPUs, even without > OSFXSR set. If the CPU does not support SSE, it is safe to > call kernel_fpu_begin() without OSFXSR set. > "!(cr4_read_shadow() & X86_CR4_OSFXSR)" will be always true on > those CPUs, and without boot_cpu_has() MMX version will be never used. > > There are two cases: > > 3DNow! without SSE always use MMX version > 3DNow! + SSE (K7) use MMX version only if FXSR is enabled > > Thanks. > > Best regards, > Krzysiek > -- >8 -- > Subject: [PATCH] x86/lib: don't use mmx_memcpy() too early > > The MMX 3DNow! optimized memcpy() is used very early, > even before FPU is initialized in the kernel. It worked fine, but commit > 7ad816762f9bf89e940e618ea40c43138b479e10 ("x86/fpu: Reset MXCSR > to default in kernel_fpu_begin()") broke that. After that > commit the kernel_fpu_begin() assumes that FXSR is enabled in > the CR4 register on all processors with SSE. Because memcpy() is used > before FXSR is enabled, the kernel crashes just after "Booting the kernel." > message. It affects all kernels with CONFIG_X86_USE_3DNOW (enabled when > some AMD/Cyrix processors are selected) on processors with SSE > (like AMD K7, which supports both MMX 3DNow! and SSE). > > Fixes: 7ad816762f9b ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()") > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: "H. Peter Anvin" > Cc: # 5.8+ > Signed-off-by: Krzysztof Mazur > --- > arch/x86/lib/mmx_32.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/lib/mmx_32.c b/arch/x86/lib/mmx_32.c > index 4321fa02e18d..70aa769570e6 100644 > --- a/arch/x86/lib/mmx_32.c > +++ b/arch/x86/lib/mmx_32.c > @@ -25,13 +25,20 @@ > > #include > #include > +#include > > void *_mmx_memcpy(void *to, const void *from, size_t len) > { > void *p; > int i; > > - if (unlikely(in_interrupt())) > + /* > + * kernel_fpu_begin() assumes that FXSR is enabled on all processors > + * with SSE. Thus, MMX-optimized version can't be used > + * before the kernel enables FXSR (OSFXSR bit in the CR4 register). > + */ > + if (unlikely(in_interrupt()) || (boot_cpu_has(X86_FEATURE_XMM) && > + unlikely(!(cr4_read_shadow() & X86_CR4_OSFXSR)))) This is gross. I realize this is only used for old CPUs that we don't care about perf-wise, but this code is nonsense -- it makes absolutely to sense to put this absurd condition here to work around kernel_fpu_begin() bugs. If we want to use MMX, we should check MMX. And we should also check the correct condition re: irqs. So this code should be: if (boot_cpu_has(X86_FEATURE_XMM) && irq_fpu_usable()) { kernel_fpu_begin_mask(FPU_MASK_XMM); ... or we could improve code gen by adding a try_kernel_fpu_begin_mask() so we can do a single call instead of two. This also mostly fixes our little performance regression -- we'd make kernel_fpu_begin() be an inline wrapper around kernel_fpu_begin_mask(FPU_MASK_DEFAULTFP), and *that* would be FPU_MASK_XYZMM on 64-bit and FPU_MASK_387 on 32-bit. (Okay, XYZMM isn't a great name, but whatever.) And the EFI code can become completely explicit: kernel_fpu_begin(FPU_MASK_ALL). What do you all think? If you're generally in favor, I can write the code and do a quick audit for other weird cases in the kernel. Or we could flip the OSFSXR bit very early, I suppose. --Andy