Messages in this thread | | | Date | Wed, 16 Oct 2013 08:50:54 -0700 | Subject | Re: [PATCH, RFC] x86-64: properly handle FPU code/data selectors | From | Linus Torvalds <> |
| |
On Wed, Oct 16, 2013 at 8:36 AM, Jan Beulich <JBeulich@suse.com> wrote: > > In that case we use a 32-bit operand size [F]XRSTOR, and hence > the upper halves get treated as selectors, and the offsets get > zero-extended from the low halves, i.e. we preserve even more > state for such a 64-bit environment now too (albeit I doubt any > 64-bit code actually cares)
No, it does *not* preserve "more state".
It preserves *less* state, because the upper 32 bits of rip are now corrupted. Any 64-bit application that actually looks at the FP rip/rdp fields now get the WRONG VALUES.
The "upper bits zero" mode may be used just for JIT'ed code, for example. It doesn't mean that you'd never have full 64-bit addresses, so writing to the top half of the register *corrupts* that information, because the top half bits are still relevant in general, even if perhaps _one_ particular floating point exception happened with the bits clear.
Now anybody looking at the FP state on the stack gets the wrong results.
More bits set is *not* "more state", when those bits are wrong.
Linus
| |