All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@redhat.com>
To: Eric Biggers <ebiggers3@gmail.com>, x86@kernel.org
Cc: linux-kernel@vger.kernel.org,
	kernel-hardening@lists.openwall.com,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Fenghua Yu <fenghua.yu@intel.com>, Ingo Molnar <mingo@kernel.org>,
	Kevin Hao <haokexin@gmail.com>, Oleg Nesterov <oleg@redhat.com>,
	Wanpeng Li <wanpeng.li@hotmail.com>,
	Yu-cheng Yu <yu-cheng.yu@intel.com>,
	Michael Halcrow <mhalcrow@google.com>,
	Eric Biggers <ebiggers@google.com>
Subject: Re: [kernel-hardening] [PATCH v3 3/3] x86/fpu: reinitialize FPU registers if restoring FPU state fails
Date: Thu, 21 Sep 2017 16:41:29 -0400	[thread overview]
Message-ID: <1506026489.5486.25.camel@redhat.com> (raw)
In-Reply-To: <20170921185239.88398-4-ebiggers3@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]

On Thu, 2017-09-21 at 11:52 -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> Userspace can change the FPU state of a task using the ptrace() or
> rt_sigreturn() system calls.  Because reserved bits in the FPU state
> can
> cause the XRSTOR instruction to fail, the kernel has to carefully
> validate that no reserved bits or other invalid values are being set.
> 
> Unfortunately, there have been bugs in this validation code.  For
> example, we were not checking that the 'xcomp_bv' field in the
> xstate_header was 0.  As-is, such bugs are exploitable to read the
> FPU
> registers of other processes on the system.  To do so, an attacker
> can
> create a task, assign to it an invalid FPU state, then spin in a loop
> and monitor the values of the FPU registers.  Because the task's FPU
> registers are not being restored, sometimes the FPU registers will
> have
> the values from another process.
> 

Reviewed-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2017-09-21 20:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-21 18:52 [kernel-hardening] [PATCH v3 0/3] x86/fpu: prevent leaking FPU registers via invalid FPU state Eric Biggers
2017-09-21 18:52 ` Eric Biggers
2017-09-21 18:52 ` [kernel-hardening] [PATCH v3 1/3] x86/fpu: don't let userspace set bogus xcomp_bv Eric Biggers
2017-09-21 18:52   ` Eric Biggers
2017-09-21 19:59   ` [kernel-hardening] " Rik van Riel
2017-09-21 18:52 ` [kernel-hardening] [PATCH v3 2/3] x86/fpu: tighten validation of user-supplied xstate_header Eric Biggers
2017-09-21 18:52   ` Eric Biggers
2017-09-21 20:21   ` [kernel-hardening] " Rik van Riel
2017-09-21 18:52 ` [kernel-hardening] [PATCH v3 3/3] x86/fpu: reinitialize FPU registers if restoring FPU state fails Eric Biggers
2017-09-21 18:52   ` Eric Biggers
2017-09-21 20:41   ` Rik van Riel [this message]
2017-09-22  5:33 ` [kernel-hardening] Re: [PATCH v3 0/3] x86/fpu: prevent leaking FPU registers via invalid FPU state Ingo Molnar
2017-09-22  5:33   ` Ingo Molnar
2017-09-22 17:07   ` [kernel-hardening] " Eric Biggers
2017-09-22 17:07     ` Eric Biggers
2017-09-23 10:17     ` [kernel-hardening] [PATCH] x86/fpu: Simplify fpu__activate_fpstate_read() Ingo Molnar
2017-09-23 10:17       ` Ingo Molnar
2017-09-23 11:29       ` [kernel-hardening] " Ingo Molnar
2017-09-23 11:29         ` Ingo Molnar
2017-09-23 18:28         ` [kernel-hardening] " Eric Biggers
2017-09-23 18:28           ` Eric Biggers

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=1506026489.5486.25.camel@redhat.com \
    --to=riel@redhat.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dvyukov@google.com \
    --cc=ebiggers3@gmail.com \
    --cc=ebiggers@google.com \
    --cc=fenghua.yu@intel.com \
    --cc=haokexin@gmail.com \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhalcrow@google.com \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=wanpeng.li@hotmail.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 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.