From: Greg KH <gregkh@linuxfoundation.org>
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: Fri, 28 Apr 2023 09:33:28 +0200 [thread overview]
Message-ID: <2023042821-irritable-persecute-969c@gregkh> (raw)
In-Reply-To: <20230427172134.75628-1-cansun@arista.com>
On Thu, Apr 27, 2023 at 12:21:34PM -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
> Signed-off-by: Can Sun <cansun@arista.com>
> Link: https://lore.kernel.org/r/20220501193102.588689270@linutronix.de
Now queued up, thanks.
greg k-h
next prev parent reply other threads:[~2023-04-28 7:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 17:21 [BACKPORT PATCH 5.10.y] x86/fpu: Prevent FPU state corruption Can Sun
2023-04-28 7:33 ` Greg KH [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-04-26 22:35 Can Sun
2023-04-27 8:27 ` 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=2023042821-irritable-persecute-969c@gregkh \
--to=gregkh@linuxfoundation.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox