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: <4832A173.6020203@firstfloor.org>
Date:	Tue, 20 May 2008 12:01:23 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
CC:	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

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 don't see anything in the SDM guaranteeing zeroing.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ