Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions

From: H. Peter Anvin
Date: Thu May 22 2008 - 17:42:30 EST

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

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at