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: <48362FD0.9030104@zytor.com>
Date:	Thu, 22 May 2008 19:45:36 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Suresh Siddha <suresh.b.siddha@...el.com>
CC:	Mikael Pettersson <mikpe@...uu.se>,
	Andi Kleen <andi@...stfloor.org>, mingo@...e.hu,
	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 Thu, May 22, 2008 at 02:34:45PM -0700, H. Peter Anvin wrote:
>> Suresh Siddha wrote:
>>> can you please elaborate? even in presence of virtualization, appropriate
>>> cpuid bits need to be set/visible for application, for xsave/xrstor to work
>>> properly.
>>>
>> For many paravirtualization solutions, CPUID "leak" from the hypervisor. 
>>  The fact that CPUID cannot be disabled (made ring 0 only) is a major 
>> flaw in the architecture.
>>
>> Therefore, relying on CPUID is too dangerous.
> 
> hmm.. so the kernel needs to export all the cpuid info (that the kernel enables
> and supports) to the user through some mechanism then?

Not really.  Most of the CPUID information doesn't have a OS-dependent 
portion, but the parts that do cause problems (there are other issues, 
like the hypervisor wanting to limit the feature set available to the 
client, but there is no real solution to that, and certainly it would be 
out of scope for this discussion.)

> atleast in the xsave case, hypervisor can completely control the
> OSXSAVE flag. I am still not convinced whether I need to add prctl()
> to indicate the layout. If I have to add, then it should not just
> be about whether xsave information is included in _fpstate or not, it should also
> be about the whole cpuid information provided by the xsave architecture. Because
> the user potentially needs all that information, to make sense out of
> the data layout included in the extended state area.

Agreed that this information is needed, although it probably would be 
better to leave it in the frame itself; that way at least the rt frames 
would stand on their own.  I'm worried about using the reserved fields 
since they could be messed up by ptrace, but you could also argue that 
if you have the ability to trace the process you can do anything else to 
it; that way we could use a reserved field to signal the presence of the 
XSAVE information in the frame; I would hope that that XSAVE information 
would be self-describing (perhaps a linked list of blocks or a separate 
chain of descriptors.)

In other words, we know of a place to stash the presence flag for rt 
signal frames, the uc_flags field; we effectively need to find a place 
to stash the uc_flags field for the non-rt frame.

Michael, you wrote:

> 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.

... could you share what application that is?  This otherwise would be 
ideal.

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