From: Greg KH <greg@kroah.com>
To: Can Sun <cansun@arista.com>
Cc: stable@vger.kernel.org, Filipe Manana <fdmanana@suse.com>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@suse.de>
Subject: Re: [BACKPORT PATCH 5.10.y] x86/fpu: Prevent FPU state corruption
Date: Thu, 27 Apr 2023 10:27:39 +0200 [thread overview]
Message-ID: <2023042721-wise-puzzle-b8cd@gregkh> (raw)
In-Reply-To: <20230426223508.71750-1-cansun@arista.com>
On Wed, Apr 26, 2023 at 05:35:08PM -0500, Can Sun wrote:
> [ Upstream commit 59f5ede3bc0f00eb856425f636dab0c10feb06d8 ]
>
> The FPU usage related to task FPU management is either protected by
> disabling interrupts (switch_to, return to user) or via fpregs_lock() which
> is a wrapper around local_bh_disable(). When kernel code wants to use the
> FPU then it has to check whether it is possible by calling irq_fpu_usable().
>
> But the condition in irq_fpu_usable() is wrong. It allows FPU to be used
> when:
>
> !in_interrupt() || interrupted_user_mode() || interrupted_kernel_fpu_idle()
>
> The latter is checking whether some other context already uses FPU in the
> kernel, but if that's not the case then it allows FPU to be used
> unconditionally even if the calling context interrupted a fpregs_lock()
> critical region. If that happens then the FPU state of the interrupted
> context becomes corrupted.
>
> Allow in kernel FPU usage only when no other context has in kernel FPU
> usage and either the calling context is not hard interrupt context or the
> hard interrupt did not interrupt a local bottomhalf disabled region.
>
> It's hard to find a proper Fixes tag as the condition was broken in one way
> or the other for a very long time and the eager/lazy FPU changes caused a
> lot of churn. Picked something remotely connected from the history.
>
> This survived undetected for quite some time as FPU usage in interrupt
> context is rare, but the recent changes to the random code unearthed it at
> least on a kernel which had FPU debugging enabled. There is probably a
> higher rate of silent corruption as not all issues can be detected by the
> FPU debugging code. This will be addressed in a subsequent change.
>
> Fixes: 5d2bd7009f30 ("x86, fpu: decouple non-lazy/eager fpu restore from xsave")
> Reported-by: Filipe Manana <fdmanana@suse.com>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Tested-by: Filipe Manana <fdmanana@suse.com>
> Reviewed-by: Borislav Petkov <bp@suse.de>
> Cc: stable@vger.kernel.org
> Cc: Can Sun <cansun@arista.com>
When you send on a patch that you backported, you need to also sign-off
on the change.
Please fix that up and resend.
thanks,
greg k-h
next prev parent reply other threads:[~2023-04-27 8:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-26 22:35 [BACKPORT PATCH 5.10.y] x86/fpu: Prevent FPU state corruption Can Sun
2023-04-27 8:27 ` Greg KH [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-04-27 17:21 Can Sun
2023-04-28 7:33 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2023042721-wise-puzzle-b8cd@gregkh \
--to=greg@kroah.com \
--cc=bp@suse.de \
--cc=cansun@arista.com \
--cc=fdmanana@suse.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.