From: Ingo Molnar <mingo@kernel.org>
To: riel@redhat.com
Cc: linux-kernel@vger.kernel.org, luto@kernel.org,
yu-cheng.yu@intel.com, dave.hansen@linux.intel.com, bp@suse.de
Subject: Re: [PATCH 1/2] x86/fpu: move copyout_from_xsaves bounds check before the copy
Date: Thu, 26 Jan 2017 10:47:33 +0100 [thread overview]
Message-ID: <20170126094733.GA22486@gmail.com> (raw)
In-Reply-To: <20170126094044.GA24499@gmail.com>
* Ingo Molnar <mingo@kernel.org> wrote:
> So this code:
>
> static inline int xstate_copyout(unsigned int pos, unsigned int count,
> void *kbuf, void __user *ubuf,
> const void *data, const int start_pos,
> const int end_pos)
> {
> if ((count == 0) || (pos < start_pos))
> return 0;
>
> if (end_pos < 0 || pos < end_pos) {
> unsigned int copy = (end_pos < 0 ? count : min(count, end_pos - pos));
>
> if (kbuf) {
> memcpy(kbuf + pos, data, copy);
> } else {
> if (__copy_to_user(ubuf + pos, data, copy))
> return -EFAULT;
> }
> }
> return 0;
> }
>
> Is, after all the cleanups and fixes is in reality equivalent to:
>
> static inline int
> __copy_xstate_to_kernel(void *kbuf, const void *data,
> unsigned int offset, unsigned int size)
> {
> memcpy(kbuf + offset, data, size);
>
> return 0;
> }
>
> !!!
Note that it's not entirely true - for the degenerate case of ptrace() requesting
a very small and partial buffer that cannot even fit the headers, this check is
still required - so we end up with something like:
static inline int
__copy_xstate_to_kernel(void *kbuf, const void *data,
unsigned int offset, unsigned int size, unsigned int size_total)
{
if (offset < size_total) {
unsigned int copy = min(size, size_total - offset);
memcpy(kbuf + offset, data, copy);
}
return 0;
}
But it's still an inconsistent mess: we'll do a partial copy in headers but not
for xstate components?
I believe the right solution is to allow partial copies only if they are at
precise xstate (and legacy) component boundaries, and apply this to the header
portion as well.
This allows user-space to request only the FPU bits for example - but doesn't
force the kernel to handle really weird partial copy cases that very few people
are testing ...
(Unless there's some ABI pattern from debugging applications that I missed?)
Thanks,
Ingo
next prev parent reply other threads:[~2017-01-26 9:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 1:57 [PATCH 0/2] x86/fpu: copyout_from_xsaves & copyin_to_xsaves fixes riel
2017-01-26 1:57 ` [PATCH 1/2] x86/fpu: move copyout_from_xsaves bounds check before the copy riel
2017-01-26 9:40 ` Ingo Molnar
2017-01-26 9:47 ` Ingo Molnar [this message]
2017-01-26 1:57 ` [PATCH 2/2] x86/fpu: copy MXCSR & MXCSR_FLAGS with SSE/YMM state riel
2017-01-26 8:14 ` Ingo Molnar
2017-01-26 8:21 ` [PATCH] x86/fpu: Rename copyin_to_xsaves()/copyout_from_xsaves() to copy_user_to_xstate()/copy_xstate_to_user() Ingo Molnar
2017-01-26 10:26 ` Ingo Molnar
2017-01-26 15:03 ` [PATCH 2/2] x86/fpu: copy MXCSR & MXCSR_FLAGS with SSE/YMM state Dave Hansen
2017-01-30 17:34 ` Yu-cheng Yu
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=20170126094733.GA22486@gmail.com \
--to=mingo@kernel.org \
--cc=bp@suse.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=riel@redhat.com \
--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;
as well as URLs for NNTP newsgroup(s).