netdev - 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Sat, 9 Aug 2008 11:12:19 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Wolfgang Walter <wolfgang.walter@...m.de>
Cc:	Herbert Xu <herbert@...dor.apana.org.au>,
	"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 Sat, Aug 09, 2008 at 08:57:32AM -0700, Wolfgang Walter wrote:
> On Saturday 09 August 2008, Herbert Xu wrote:
> > On Fri, Aug 08, 2008 at 04:11:21PM -0700, Suresh Siddha wrote:
> > >
> > > With out the recent dynamic fpu allocation changes, while we don't see
> oops,
> > > there is a possible race still present in older kernels(for example,
> > > while kernel is using kernel_fpu_begin() in some optimized clear/copy
> > > page and an interrupt/softirq happens which uses these padlock
> > > instructions generating DNA fault).
> >
> > No this wasn't a problem because kernel_fpu_begin clears TS and
> > therefore we don't get faults on SSE instructions.
> >
> > However, with your patch it will become a problem due to the
> > fact that it wasn't designed to be nested.
> >
> I don't exactly understand this. You think that
> 
> kernel_fpu_begin();
> XCRYPT....
> kernel_fpu_end();
> 
> is a problem and wasn't before?

Wolf, kernel_fpu_begin() and kernel_fpu_end() only saves the user
state from getting corrupted with the kernel state. But it doesn't
help if kernel has nesting fpu usage.

In this padlock case with the patch, we may encounter a nested
kernel_fpu_begin() and end()
but this is ok, as the padlock is not actually touching fpu/sse registers.

Yes, we do have a problem when the interrupt handlers also use SSE
registers and if there is a nesting inside the kernel. Today we don't
have any such usage.

> If XCRYPT may be interrupted and the interrupt code again uses this optimized
> memcpy implementation and so nesting kernel_fpu_begin then why should this
> not happen with the other alg.
> 
> How could any kernel code use MMX/SSE/FPU when the interrupt case isn't
> handled?

Today we don't have any nesting, for example, fast memcpy, if in interrupt
will use the slow version and doesnt use the optimized version.

thanks,
suresh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html