All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@intel.com>
To: Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	the arch/x86 maintainers <x86@kernel.org>
Cc: stable@vger.kernel.org,
	syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com
Subject: Re: [RFC v2 1/2] x86/fpu: Fix state corruption in __fpu__restore_sig()
Date: Tue, 1 Jun 2021 07:48:05 -0700	[thread overview]
Message-ID: <96d765be-7fd4-08c3-6c2e-4ca8341d11e7@intel.com> (raw)
In-Reply-To: <603011b5-9479-3aac-78ee-74b9b5a5ef7c@kernel.org>

> +static void sigusr1(int sig, siginfo_t *info, void *uc_void)
> +{
> +       ucontext_t *uc = uc_void;
> +       uint8_t *fpstate = (uint8_t *)uc->uc_mcontext.fpregs;
> +       uint64_t *xfeatures = (uint64_t *)(fpstate + 512);
> +
> +       printf("\tOriginal XFEATURES = 0x%lx\n", *xfeatures);
> +       *(xfeatures+2) = 0xfffffff;
> +       //*xfeatures = ~(uint64_t)0;
> +}

I was trying to think of something which might be more durable than
this, like if a new feature started using bytes 16->23 for something useful.

How about a memset() of the entire 64-byte header to 0xff?

On to

	[PATCH v3 2/5] x86/fpu: Fix state corruption in ...

> Instead of trying to give sensible semantics to the fpu clear functions
> in the presence of XSAVE header corruption, simply avoid corrupting the
> header in the first place by using copy_user_to_xstate().

Should we mention that the verbatim copying via __copy_from_user()
copies the (bad) reserved bit contents and how copy_user_to_xstate()
avoids it?

Maybe:

__copy_from_user() copies the entire user buffer into the kernel buffer,
verbatim.  This means that the kernel buffer may now contain entirely
invalid state on which XRSTOR will #GP.  validate_user_xstate_header()
can detect some of that corruption, but that leaves the onus on callers
to clear the buffer.

Avoid corruption of the kernel XSAVE buffer.  Use copy_user_to_xstate()
which validates the XSAVE header contents *BEFORE* copying the buffer
into the kernel.

Note: copy_user_to_xstate() was previously only called for
compacted-format kernel buffers.  It functions for both compacted and
non-compacted forms.  Using it for the non-compacted form will be slower
because of multiple __copy_from_user() operations in the
compacted-format code, but that cost is less important than simpler code
in an already slow path.

> --- a/arch/x86/kernel/fpu/signal.c
> +++ b/arch/x86/kernel/fpu/signal.c
> @@ -405,14 +405,7 @@ static int __fpu__restore_sig(void __user *buf, void __user *buf_fx, int size)
>         if (use_xsave() && !fx_only) {
>                 u64 init_bv = xfeatures_mask_user() & ~user_xfeatures;
>  
> -               if (using_compacted_format()) {
> -                       ret = copy_user_to_xstate(&fpu->state.xsave, buf_fx);
> -               } else {
> -                       ret = __copy_from_user(&fpu->state.xsave, buf_fx, state_size);
> -
> -                       if (!ret && state_size > offsetof(struct xregs_state, header))
> -                               ret = validate_user_xstate_header(&fpu->state.xsave.header);
> -               }
> +               ret = copy_user_to_xstate(&fpu->state.xsave, buf_fx);
>                 if (ret)
>                         goto err_out;
>  


  reply	other threads:[~2021-06-01 14:48 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1622351443.git.luto@kernel.org>
2021-05-30  5:12 ` [RFC v2 1/2] x86/fpu: Fix state corruption in __fpu__restore_sig() Andy Lutomirski
2021-05-30 22:02   ` Thomas Gleixner
2021-05-30 23:41     ` Andy Lutomirski
2021-05-31  9:03       ` Thomas Gleixner
2021-05-31 10:01   ` Thomas Gleixner
2021-05-31 18:56     ` Thomas Gleixner
2021-05-31 19:30       ` Andy Lutomirski
2021-05-31 22:46         ` Thomas Gleixner
2021-06-01  4:58           ` Andy Lutomirski
2021-06-01 14:48             ` Dave Hansen [this message]
2021-06-01 18:06             ` [PATCH v3 3/5] x86/fpu: Clean up the fpu__clear() variants Dave Hansen
2021-06-01 18:14               ` Andy Lutomirski
2021-06-01 18:35                 ` Dave Hansen
2021-06-01 22:44                   ` Andy Lutomirski
2021-06-01 18:25               ` Thomas Gleixner
2021-06-01 23:17           ` [RFC v2 1/2] x86/fpu: Fix state corruption in __fpu__restore_sig() Thomas Gleixner
2021-05-31 19:48       ` 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=96d765be-7fd4-08c3-6c2e-4ca8341d11e7@intel.com \
    --to=dave.hansen@intel.com \
    --cc=luto@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=syzbot+2067e764dbcd10721e2e@syzkaller.appspotmail.com \
    --cc=tglx@linutronix.de \
    --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.