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:	Tue, 20 May 2008 15:19:58 +0200
From:	Mikael Pettersson <mikpe@...uu.se>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>,
	Mikael Pettersson <mikpe@...uu.se>, mingo@...e.hu,
	hpa@...or.com, tglx@...utronix.de, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, roland@...hat.com, 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

Andi Kleen writes:
 > Suresh Siddha wrote:
 > > On Mon, May 19, 2008 at 04:52:01PM +0200, Mikael Pettersson wrote:
 > >>> But we can
 > >>> use some what similar magic, if the fxsave/fxrstor give away
 > >>> some of the fields at the end of fxsave image (today it is reserved
 > >>> and ignored during fxsave/fxrstor) for software use.
 > >>> We can then use these fields at the end of fpstate, to indicate the presence of
 > >>> xstate. But this requires some architecture changes like giving
 > >>> away this space for SW use. We can take this to architects and
 > >>> see what they think.
 > >> If the HW doesn't store anything valuable there, we could store
 > >> SW flags/cookies there on signal delivery, and clear them before
 > >> fxrstor (unless the HW is known to ignore those fields).
 > >> But it depends on how forgiving the HW is.
 > > 
 > > Ok. CPU folks are planning to make some of the bytes at the end of fxsave
 > > image, SW usable.
 > 
 > Are they always zeroed in earlier CPUs though?  If not that wouldn't
 > work 100% reliably because whatever cookie you put in could have been
 > there before by chance.

I wrote a test program (fill an area with zeroes, fxsave, inspect
reserved fields, then fill it with ones, fxsave, inspect again),
and all processors appear to just not write anything to the reserved
fields after the last xmm register. (Tested on an old Mobile Athlon64,
Opteron 280, P4 Xeon, Pentium-D, and C2 Xeon E5345.)

So the question now is what if anything has the Linux kernel written
to those reserved fields. (Looking..) Hmm, signal delivery on x86-64
seems to do fxsave directly to the fxsave area in the user's sigframe,
which would imply that the reserved fields have unpredictable values.

/Mikael
--
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/