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]

Message-ID: <489D0F69.9050307@zytor.com>
Date:	Fri, 08 Aug 2008 20:30:49 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Wolfgang Walter <wolfgang.walter@...m.de>
CC:	Herbert Xu <herbert@...dor.apana.org.au>,
	Suresh Siddha <suresh.b.siddha@...el.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,
	vegard.nossum@...il.com
Subject: Re: Kernel oops with 2.6.26, padlock and ipsec: probably problem
 with fpu state changes

Wolfgang Walter wrote:
> 
> These FPU changes are already in 2.6.26. Undoing them, would that be accepted 
> for 2.6.26 stable?
> 
> Maybe the following solution would be possible: if a processor with padlock is 
> detected the memory for xstate is always allocated when the thread is created 
> instead "lazy"?
> 

That will effectively happen, so it doesn't really matter.

The true optimization would be to recognize that the state doesn't have 
to be saved, and track when we did so, and so on and so forth.

VIA really did their customers a disservice tying this to CR0.TS.

	-hpa
--
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