On hardware supporting the fsgsbase feature, 64bit PV guests can set and
clear the applicable control bit in its virtualised %cr4, but the
feature remains fully active in hardware. Therefore, the associated
instructions are actually usable.
Linux, which does not currently support this feature, has various
optimisations in its context switch path which justifiably assume that
userspace can't actually make changes without a system call.
Xen's behaviour of having this feature active behind the guest kernel's
back undermines the correctness of any context switch logic which
depends on the feature being disabled.
Userspace can therefore corrupt fsbase or gsbase (commonly used for
Thread Local Storage) in the next thread to be scheduled on the
Created xen tracking bugs for this issue:
Affects: fedora-all [bug 1685577]