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:	Mon, 19 May 2008 09:57:35 -0700
From:	Suresh Siddha <suresh.b.siddha@...el.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Mikael Pettersson <mikpe@...uu.se>,
	Suresh Siddha <suresh.b.siddha@...el.com>, mingo@...e.hu,
	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 09:29:01AM -0700, H. Peter Anvin wrote:
> Mikael Pettersson wrote:
> >
> >My problem with the OSXAVE flag is that it's a very indirect way of
> >communicating the layout of sigframes and sigcontexts. These structures
> >should, if at all possible, be self-describing. A single flag bit in
> >the sigcontext could handle both structures (since a sigframe always
> >includes a sigcontext).
> >
> 
> It's also wrong, since OSXSAVE indicates that the CPU can do it, not 
> that the kernel can.

OSXSAVE indicates the OS support and XSAVE indicates the cpu support.

> >>>struct _fpstate has a 'magic' field which distinguishes x87-only
> >>>from x87+FXSR structs. Could that field also be used to indicate XSAVE?
> >>I don't think we can use the existing 'magic' field.
> >
> >Hmm, right now it seems this field has a de-facto ABI of being
> >either 0xffff (plain) or 0x0000 (fxsr). Using other values would
> >confuse at least one application I know of. Sad.
> >
> 
> Well, arguably it is the right thing to use since we're talking about a 
> new format.  The difference is that the new format *does* extend 
> backwards to match the old format.

There might be some old applications, which just care about FP/SSE and
just check for  0xffff (plain) or 0x0000 (fxsr). We should extend this
in a backward compatible manner.

> >>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.
> 
> All we need is a single field -- a single byte -- reserved indefinitely 
> for software use.  Existing FXSAVE kernels will have set it to zero.
> 
> There might be fields the existing FXSAVE format which can be equally 
> abused, even.  I will do some looking.

All the reserved fields at the end of fxsave format are zeroed and
presented as such to the user. If HW makes some of these fields SW available,
then we can use those (will check). If there is any scope with the
existing format it self, that will be much better.

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/