linux-kernel - Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20080812182811.GA646@linux-os.sc.intel.com>
Date:	Tue, 12 Aug 2008 11:28:11 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Wolfgang Walter <wolfgang.walter@...m.de>,
	"Siddha, Suresh B" <suresh.b.siddha@...el.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>,
	"viro@...IV.linux.org.uk" <viro@...iv.linux.org.uk>,
	"vegard.nossum@...il.com" <vegard.nossum@...il.com>
Subject: Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem with fpu state changes

On Tue, Aug 12, 2008 at 05:02:13AM -0700, Herbert Xu wrote:
> On Tue, Aug 12, 2008 at 01:43:22PM +0200, Wolfgang Walter wrote:
> >
> > * Works fine, machine is up since 61 minutes.
> 
> Thanks a lot for testing this Wolfgang!

Thanks indeed.

> > * Performance:
> >
> > Routing performance over esp-tunnels seems unchanged here compared to 2.6.25
> > (this was also the case with the "kernel_fpu_begin" patch).
> >
> > tcrypt mode=200 shows exactly the same performance penalty compared to 2.6.25
> > as the "kernel_fpu_begin" patch.
> 
> That's not surprising since tcrypt runs with BH off so it'll
> do pretty much the same thing as before.

Ok. In the real world usage, where we use these instructions both from
process and softirq context, we will probably not see much penality,
as the process context's first access will always endup doing full fp restore
(and also we kick in the context switch FP optimization, which will
proactively restore fp state if we touch FPU in 5 consecutive task slices).

> This also shows that
> reading CR0 doesn't impose any extra overhead compared to what
> was done in kernel_fpu_begin.

As there are no further objections, Herbert/Ingo not sure who among you
will push this patch to Linus tree and  2.6.26 -stable tree aswell.

thanks,
suresh
--
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/