From: Borislav Petkov <bp@alien8.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Tony Luck <tony.luck@intel.com>,
Yu-cheng Yu <yu-cheng.yu@intel.com>,
stable@vger.kernel.org
Subject: Re: [patch 3/8] x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer
Date: Wed, 2 Jun 2021 17:06:29 +0200 [thread overview]
Message-ID: <YLeedfdsnsKqcbGx@zn.tnic> (raw)
In-Reply-To: <20210602101618.627715436@linutronix.de>
On Wed, Jun 02, 2021 at 11:55:46AM +0200, Thomas Gleixner wrote:
> From: Andy Lutomirski <luto@kernel.org>
>
> If XRSTOR fails due to sufficiently complicated paging errors (e.g.
> concurrent TLB invalidation),
I can't connect "concurrent TLB invalidation" to "sufficiently
complicated paging errors". Can you elaborate pls?
> it may fault with #PF but still modify
> portions of the user extended state.
Yikes, leaky leaky insn.
> If this happens in __fpu_restore_sig() with a victim task's FPU registers
> loaded and the task is preempted by the victim task,
This is probably meaning another task but the only task mentioned here
is a "victim task"?
> the victim task
> resumes with partially corrupt extended state.
>
> Invalidate the FPU registers when XRSTOR fails to prevent this scenario.
>
> Fixes: 1d731e731c4c ("x86/fpu: Add a fastpath to __fpu__restore_sig()")
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: stable@vger.kernel.org
> ---
> arch/x86/kernel/fpu/signal.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -369,6 +369,27 @@ static int __fpu__restore_sig(void __use
> fpregs_unlock();
> return 0;
> }
> +
> + if (test_thread_flag(TIF_NEED_FPU_LOAD)) {
> + /*
> + * The FPU registers do not belong to current, and
> + * we just did an FPU restore operation, restricted
Please get rid of the "we"-personal pronouns formulations.
> + * to the user portion of the register file, and
"register file"? That sounds like comment which belongs in microcode but
not in software. :-)
> + * failed. In the event that the ucode was
> + * unfriendly and modified the registers at all, we
> + * need to make sure that we aren't corrupting an
> + * innocent non-current task's registers.
> + */
> + __cpu_invalidate_fpregs_state();
> + } else {
> + /*
> + * As above, we may have just clobbered current's
> + * user FPU state. We will either successfully
> + * load it or clear it below, so no action is
> + * required here.
> + */
> + }
I'm wondering if that comment can simply be above the TIF_NEED_FPU_LOAD
testing, standalone, instead of having it in an empty else? And then get
rid of that else.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-06-02 15:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-02 9:55 [patch 0/8] x86/fpu: Mop up XSAVES and related damage Thomas Gleixner
2021-06-02 9:55 ` [patch 1/8] selftests/x86: Test signal frame XSTATE header corruption handling Thomas Gleixner
2021-06-02 12:38 ` Borislav Petkov
2021-06-02 14:15 ` Thomas Gleixner
2021-06-03 13:16 ` Shuah Khan
2021-06-02 15:59 ` [patch V2 " Thomas Gleixner
2021-06-02 16:02 ` [patch V2a " Thomas Gleixner
2021-06-02 9:55 ` [patch 2/8] x86/fpu: Prevent state corruption in __fpu__restore_sig() Thomas Gleixner
2021-06-02 13:12 ` Borislav Petkov
2021-06-02 14:46 ` Thomas Gleixner
2021-06-02 15:58 ` [patch V2 " Thomas Gleixner
2021-06-02 9:55 ` [patch 3/8] x86/fpu: Invalidate FPU state after a failed XRSTOR from a user buffer Thomas Gleixner
2021-06-02 15:06 ` Borislav Petkov [this message]
2021-06-03 17:30 ` Andy Lutomirski
2021-06-03 19:28 ` Borislav Petkov
2021-06-02 9:55 ` [patch 4/8] x86/fpu: Limit xstate copy size in xstateregs_set() Thomas Gleixner
2021-06-02 17:44 ` Borislav Petkov
2021-06-02 9:55 ` [patch 5/8] x86/fpu: Sanitize xstateregs_set() Thomas Gleixner
2021-06-02 16:01 ` [patch V2 " Thomas Gleixner
2021-06-03 11:32 ` Borislav Petkov
2021-06-03 17:24 ` [patch " Andy Lutomirski
2021-06-02 9:55 ` [patch 6/8] x86/fpu: Add address range checks to copy_user_to_xstate() Thomas Gleixner
2021-06-02 9:55 ` [patch 7/8] x86/fpu: Clean up the fpu__clear() variants Thomas Gleixner
2021-06-02 9:55 ` [patch 8/8] x86/fpu: Deduplicate copy_xxx_to_xstate() Thomas Gleixner
2021-06-03 16:56 ` Andy Lutomirski
2021-06-02 21:28 ` [patch 0/8] x86/fpu: Mop up XSAVES and related damage Yu, Yu-cheng
2021-06-04 14:05 ` Thomas Gleixner
2021-06-04 16:27 ` Yu, Yu-cheng
2021-06-04 17:46 ` Dave Hansen
2021-06-04 18:14 ` Thomas Gleixner
2021-06-04 22:04 ` Dave Hansen
2021-06-05 10:18 ` Thomas Gleixner
2021-06-05 11:56 ` Thomas Gleixner
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=YLeedfdsnsKqcbGx@zn.tnic \
--to=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.com \
/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