linux-kernel - Re: [RFC] x86: xsave/xrstor support, ucontext

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:	Thu, 22 May 2008 18:33:53 -0700 (PDT)
From:	Roland McGrath <roland@...hat.com>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Mikael Pettersson <mikpe@...uu.se>,
	Andi Kleen <andi@...stfloor.org>, mingo@...e.hu,
	tglx@...utronix.de, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, drepper@...hat.com,
	Hongjiu.lu@...el.com, linux-kernel@...r.kernel.org,
	arjan@...ux.intel.com, rmk+lkml@....linux.org.uk, dan@...ian.org,
	asit.k.mallick@...el.com
Subject: Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions

> What I was doing in the RFC is: restore the state what ever that was
> present and init the state that was not present in the stack frame.

That is consistent in spirit with the existing treatment of FPU data.
That is, if the sigcontext.fpstate pointer is NULL, the thread's FPU
state is reset to default.  (And despite what hpa said about being
"supported", the facts in the code are that sigreturn just follows the
sigcontext.fpstate pointer, whatever it is.  On 32-bit, the pointer is
NULL in the context saved when the thread had not used the FPU, so
modifying the sigcontext to include FP state when it didn't before
requires putting in some user-chosen pointer.  There in fact may well be
existing code that does user-level coroutine switching using sigreturn
and relies on this, for all we know.)

Thanks,
Roland
--
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/