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]

Message-ID: <20080520015723.GD30034@linux-os.sc.intel.com>
Date:	Mon, 19 May 2008 18:57:24 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	Mikael Pettersson <mikpe@...uu.se>
Cc:	Suresh Siddha <suresh.b.siddha@...el.com>, mingo@...e.hu,
	hpa@...or.com, tglx@...utronix.de, torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org, andi@...stfloor.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

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.

We can use some of these fields, to represent the extended state
presence with a cookie, save area size, mask of the state
stored. If needed, we can include the start address of the fpstate pointer
(also as part of the cookie), so that we can detect the situation,
where apps are just memcopying sizeof(struct _fpstate) from the fpstate
pointer (but not aware of the extended state).

we don't need any ucontext_t extensions any more and just
use the fpstate pointer to indicate the extended state aswell, right?

In addition, we need to make sure that for 32bit non-rt sigframes, we
don't modify the extramask[] offset.

thanks,
suresh
--
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/