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: <4835E6F5.5010801@zytor.com>
Date:	Thu, 22 May 2008 14:34:45 -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:
> 
> 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.

>> I don't think it is ... it's not overkill but rather "underkill"... it's 
>> a low-performance solution but it's guaranteed to be safe in the 
>> presence of virtualization of all its various ilk.  Note that you don't 
>> need to be able to *set* the format via prctl(), just *query* (get) it.
>>
>> Using prctl() allows us to make this personality-dependent if we ever 
>> need to.
>>
>>> While restoring from the user, kernel also need to find out what layout
>>> the user is passing. So it's bi-directional. I prefer the same mechanism
>>> (using cookies/magic numbers etc inaddition to uc_flags or cpuid checks) to
>>> interpret the fpstate for both user/kernel.
>> No, it really doesn't: the kernel only needs to be able to read the same 
>> format as it itself wrote.
> 
> But user can potentially change the _fpstate pointer in sigcontext struct.

If so, they get what they bargained for... I am not even sure the kernel 
will successfully clean up the stack frame if they do that.  I don't 
think it has ever been supported doing that, and as you have correctly 
pointed out, we don't check the magic number, so if we had had offenders 
we ought to have smoked them out a long time ago.

>>> ARM also seem to be using similar things while extending their ucontext_t,
>>> with out other kernel interfaces to indicate the layout.
>>>
>>> BTW, how come 32bit kernel doesn't have the X86_FXSR_MAGIC checks, while 
>>> restoring
>>> the extended fxsave data from _fpstate?
>> Again, the kernel already knows the format, so it doesn't need to check.
> 
> What happens with some old applications which change the _fpstate
> pointer. they may or may not be fxsave aware...

That is not, and has never been, supported.

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