LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-kernel@vger.kernel.org, linux-tip-commits@vger.kernel.org,
	Yu-cheng Yu <yu-cheng.yu@intel.com>, Borislav Petkov <bp@suse.de>,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	Jann Horn <jannh@google.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"Ravi V. Shankar" <ravi.v.shankar@intel.com>,
	Rik van Riel <riel@surriel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Tony Luck <tony.luck@intel.com>, x86-ml <x86@kernel.org>
Subject: Re: [tip: x86/fpu] x86/fpu: Deactivate FPU state after failure during state load
Date: Tue, 7 Jan 2020 22:11:34 +0100
Message-ID: <20200107211134.tckhc5knkthmjsj6@linutronix.de> (raw)
In-Reply-To: <FA0D2929-63D0-4473-A492-42227D7A5D98@amacapital.net>

On 2020-01-07 10:41:52 [-1000], Andy Lutomirski wrote:
> Wow, __fpu__restore_sig is a mess. We have __copy_from... that is
> Obviously Incorrect (tm) even though it’s not obviously exploitable.
> (It’s wrong because the *wrong pointer* is checked with access_ok().).
> We have a fast path that will execute just enough of the time to make
> debugging the slow path really annoying. (We should probably delete
> the fast path.)  There are pagefault_disable() call in there mostly to
> confuse people. (So we take a fault and sleep — big deal.  We have
> temporarily corrupt state, but no one will ever read it.  The retry
> after sleeping will clobber xstate, but lazy save is long gone and
> this should be fine now.  The real issue is that, if we’re preempted
> after a successful a successful restore, then the new state will get
> lost.)

There is preempt_disable() as part of FPU locking since we can't change
the content of the FPU registers (CPU's or within task's state) and get
interrupted by task preemption. With disabled preemption we can't take a
page fault.

We need to load the page from userland which may fault. The context
switch saves _current_ FPU state only if TIF_NEED_FPU_LOAD is cleared.
This needs to happen atomic.

The fast path may fail if stack is not faulted-in (custom stack,
madvise(,, MADV_DONTNEED))

> So either we should delete the fast path or we should make it work
> reliably and delete the slow path.  And we should get rid of the
> __copy. And we should have some test cases.

without the fastpath the average case is too slow.
People-complained-about-this-slow. That is why we ended up with the
fastpath in the last revision of the series.

The go people contirbuted a testcase. Maybe I should hack up it up so
that we trigger each path and post since it obviously did not happen.
Boris, do you remember why we did not include their testcase yet?
 
> BTW, how was the bug in here discovered?  It looks like it only
> affects signal restore failure, which is usually not survivable unless
> the user program is really trying.

The glibc test suite.

Sebastian

  parent reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-12 21:08 [PATCH v2 0/3] Fix small issues in XSAVES Yu-cheng Yu
2019-12-12 21:08 ` [PATCH v2 1/3] x86/fpu/xstate: Fix small issues before adding supervisor xstates Yu-cheng Yu
2019-12-20 20:19   ` Sebastian Andrzej Siewior
2020-01-06 18:15   ` [tip: x86/fpu] x86/fpu/xstate: Fix small issues tip-bot2 for Yu-cheng Yu
2019-12-12 21:08 ` [PATCH v2 2/3] x86/fpu/xstate: Make xfeature_is_supervisor()/xfeature_is_user() return bool Yu-cheng Yu
2019-12-20 20:19   ` Sebastian Andrzej Siewior
2019-12-20 20:33     ` Yu-cheng Yu
2020-01-06 18:15   ` [tip: x86/fpu] " tip-bot2 for Yu-cheng Yu
2019-12-12 21:08 ` [PATCH v2 3/3] x86/fpu/xstate: Invalidate fpregs when __fpu_restore_sig() fails Yu-cheng Yu
2019-12-18 15:54   ` Sebastian Andrzej Siewior
2019-12-18 20:53     ` Yu-cheng Yu
2019-12-19 14:22       ` Sebastian Andrzej Siewior
2019-12-19 16:44         ` Yu-cheng Yu
2019-12-19 17:16           ` Sebastian Andrzej Siewior
2019-12-19 17:40             ` Yu-cheng Yu
2019-12-20 19:59               ` [PATCH] x86/fpu: Deacticate FPU state after failure during state load Sebastian Andrzej Siewior
2020-01-07 12:52                 ` [tip: x86/fpu] x86/fpu: Deactivate " tip-bot2 for Sebastian Andrzej Siewior
2020-01-07 20:41                   ` Andy Lutomirski
2020-01-07 20:38                     ` Yu-cheng Yu
2020-01-07 21:11                     ` Sebastian Andrzej Siewior [this message]
2020-01-08 11:45                       ` Borislav Petkov
2020-01-08 11:46                     ` Borislav Petkov
2019-12-20 20:16               ` [PATCH v2 3/3] x86/fpu/xstate: Invalidate fpregs when __fpu_restore_sig() fails Sebastian Andrzej Siewior
2019-12-20 20:32                 ` 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=20200107211134.tckhc5knkthmjsj6@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ravi.v.shankar@intel.com \
    --cc=riel@surriel.com \
    --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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git