linux-kernel - Re: [PATCH 1/1] x86/fpu: math_state_restore() should not blindly disable irqs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 7 Mar 2015 11:36:13 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Dave Hansen <dave.hansen@...el.com>,
	Borislav Petkov <bp@...e.de>, Pekka Riikonen <priikone@....fi>,
	Rik van Riel <riel@...hat.com>,
	Suresh Siddha <sbsiddha@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Yu, Fenghua" <fenghua.yu@...el.com>,
	Quentin Casasnovas <quentin.casasnovas@...cle.com>
Subject: Re: [PATCH 1/1] x86/fpu: math_state_restore() should not blindly
 disable irqs


* Andy Lutomirski <luto@...capital.net> wrote:

> On Fri, Mar 6, 2015 at 2:00 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > On Fri, Mar 6, 2015 at 11:23 AM, Andy Lutomirski <luto@...capital.net> wrote:
> >>
> >> Please don't.  IMO it's really nice that we don't use trap gates at
> >> all on x86_64, and I find the conditional_sti thing much nicer than
> >> having to audit all of the entry code to see whether it's safe to run
> >> it with IRQs on.
> >
> > So I'm not sure I see much difference, but I'd certainly be ok with
> > just moving the "conditional_sti()" up unconditionally to be the first
> > thing in do_device_not_available().
> 
> I'd be fine with that.  The important difference is that it's after swapgs.

The thing is, we have to be careful about NMI contexts anyway. So how 
about being careful in irq contexts as well?

We could shave a good 10 cycles from the FPU trap overhead, maybe 
more?

We could save the same 10 cycles from page fault overhead as well, 
AFAICS.

Hm?

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/