From: Thomas Gleixner <tglx@linutronix.de>
To: Andrei Vagin <avagin@gmail.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
Andrei Vagin <avagin@google.com>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
LKML <linux-kernel@vger.kernel.org>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH] x86/fpu: verify xstate buffer size according with requested features
Date: Mon, 22 Jan 2024 14:26:02 +0100 [thread overview]
Message-ID: <87v87lebyt.ffs@tglx> (raw)
In-Reply-To: <CANaxB-zaa0nMFmep9jtJh_QDdAj=2K9G5PAKF4iTuNbNnYj4bg@mail.gmail.com>
On Sun, Jan 21 2024 at 19:58, Andrei Vagin wrote:
> On Thu, Jan 18, 2024 at 2:11 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>> >> After staring more at it, it's arguable to pass fpstate->user_size to
>> >> fault_in_readable() and ignore fx_sw->xstate_size completely.
>> >>
>> >> That's a guaranteed to be reliable size which prevents endless loops
>> >> because arguably that's the maximum size which can be touched by XRSTOR,
>> >> no?
>
> fpstate->user_size isn't constant. It can be modified from the XFD #NM
> handler. For example, it happens when a process invokes one of amx
> instructions for the first time. It means we have to be able to restore
> an fpu state from signal frames generated with a smaller
> fpstate->user_size. Can it trigger any issues?
I know, but the #NM handler does not run in the signal restore
path. fpstate->user_size is guaranteed to be correct at that point.
The untested below should just work.
Thanks,
tglx
---
--- a/arch/x86/kernel/fpu/signal.c
+++ b/arch/x86/kernel/fpu/signal.c
@@ -274,8 +274,7 @@ static int __restore_fpregs_from_user(vo
* Attempt to restore the FPU registers directly from user memory.
* Pagefaults are handled and any errors returned are fatal.
*/
-static bool restore_fpregs_from_user(void __user *buf, u64 xrestore,
- bool fx_only, unsigned int size)
+static bool restore_fpregs_from_user(void __user *buf, u64 xrestore, bool fx_only)
{
struct fpu *fpu = ¤t->thread.fpu;
int ret;
@@ -309,7 +308,7 @@ static bool restore_fpregs_from_user(voi
if (ret != X86_TRAP_PF)
return false;
- if (!fault_in_readable(buf, size))
+ if (!fault_in_readable(buf, fpu->fpstate->user_size))
goto retry;
return false;
}
@@ -339,7 +338,6 @@ static bool __fpu_restore_sig(void __use
struct user_i387_ia32_struct env;
bool success, fx_only = false;
union fpregs_state *fpregs;
- unsigned int state_size;
u64 user_xfeatures = 0;
if (use_xsave()) {
@@ -349,17 +347,14 @@ static bool __fpu_restore_sig(void __use
return false;
fx_only = !fx_sw_user.magic1;
- state_size = fx_sw_user.xstate_size;
user_xfeatures = fx_sw_user.xfeatures;
} else {
user_xfeatures = XFEATURE_MASK_FPSSE;
- state_size = fpu->fpstate->user_size;
}
if (likely(!ia32_fxstate)) {
/* Restore the FPU registers directly from user memory. */
- return restore_fpregs_from_user(buf_fx, user_xfeatures, fx_only,
- state_size);
+ return restore_fpregs_from_user(buf_fx, user_xfeatures, fx_only);
}
/*
next prev parent reply other threads:[~2024-01-22 13:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 19:31 [PATCH] x86/fpu: verify xstate buffer size according with requested features Dave Hansen
2024-01-17 19:34 ` Dave Hansen
2024-01-17 22:30 ` Andrei Vagin
2024-01-17 23:52 ` Dave Hansen
2024-01-18 7:59 ` Andrei Vagin
2024-01-18 18:27 ` Dave Hansen
2024-01-18 19:54 ` Thomas Gleixner
2024-01-18 22:02 ` Dave Hansen
2024-01-18 22:11 ` Thomas Gleixner
2024-01-22 3:58 ` Andrei Vagin
2024-01-22 13:26 ` Thomas Gleixner [this message]
2024-01-18 19:07 ` Thomas Gleixner
2024-01-22 6:43 ` Andrei Vagin
-- strict thread matches above, loose matches on Subject: below --
2024-01-17 18:55 Dave Hansen
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=87v87lebyt.ffs@tglx \
--to=tglx@linutronix.de \
--cc=avagin@gmail.com \
--cc=avagin@google.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=x86@kernel.org \
/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.