From: Ingo Molnar <mingo@elte.hu>
To: Suresh Siddha <suresh.b.siddha@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"x86@kernel.org" <x86@kernel.org>,
"andi@firstfloor.org" <andi@firstfloor.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"stable@kernel.org" <stable@kernel.org>
Subject: Re: [patch] x64, fpu: fix possible FPU leakage in error conditions
Date: Sat, 26 Jul 2008 16:37:56 +0200 [thread overview]
Message-ID: <20080726143756.GK4401@elte.hu> (raw)
In-Reply-To: <20080725010755.GQ14380@linux-os.sc.intel.com>
* Suresh Siddha <suresh.b.siddha@intel.com> wrote:
> On Thu, Jul 24, 2008 at 03:43:44PM -0700, Linus Torvalds wrote:
> > So how about this patch as a starting point? This is the RightThing(tm) to
> > do regardless, and if it then makes it easier to do some other cleanups,
> > we should do it first. What do you think?
>
> Linus, Attached is my last attempt for the day. Please review. Thanks.
> ---
>
> restore_fpu_checking() calls init_fpu() in error conditions. While
> this is wrong(as our main intention is to clear the fpu state of the
> thread), this was benign before the commit
> 92d140e21f1ce8cf99320afbbcad73879128e6dc.
>
> Post commit 92d140e21f1ce8cf99320afbbcad73879128e6dc, live FPU
> registers may not belong to this process at this error scenario.
>
> In the error condition for restore_fpu_checking() (especially during
> the 64bit signal return), we are doing init_fpu(), which saves the
> live FPU register state (possibly belonging to some other process
> context) into the thread struct (through unlazy_fpu() in init_fpu()).
> This is wrong and can leak the FPU data.
>
> For the signal handler restore error condition in restore_i387(),
> clear the fpu state present in the thread struct(before ultimately
> sending a SIGSEGV for badframe).
>
> For the paranoid error condition check in math_state_restore(), send a
> SIGSEGV, if we fail to restore the state.
i've applied your patch to tip/x86/fpu for further testing. I suspect
once it proves reliable we can merge it into v2.6.27, after -rc1.
Ingo
prev parent reply other threads:[~2008-07-26 14:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-24 18:04 [patch] x64, fpu: fix possible FPU leakage in error conditions Suresh Siddha
2008-07-24 18:31 ` Linus Torvalds
2008-07-24 18:50 ` Suresh Siddha
2008-07-24 18:59 ` Linus Torvalds
2008-07-24 20:27 ` Suresh Siddha
2008-07-24 20:30 ` Linus Torvalds
2008-07-24 21:23 ` Suresh Siddha
2008-07-24 21:54 ` Linus Torvalds
2008-07-24 22:25 ` Suresh Siddha
2008-07-24 22:43 ` Linus Torvalds
2008-07-24 23:02 ` Suresh Siddha
2008-07-24 23:06 ` Suresh Siddha
2008-07-24 23:16 ` Linus Torvalds
2008-07-25 1:07 ` Suresh Siddha
2008-07-26 14:37 ` Ingo Molnar [this message]
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=20080726143756.GK4401@elte.hu \
--to=mingo@elte.hu \
--cc=andi@firstfloor.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=torvalds@linux-foundation.org \
--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.