On 04.09.2020 15:52, Andrew Cooper wrote:
> The comments in save_segments(), _toggle_guest_pt() and write_cr() are false.
> The %fs and %gs bases can be updated at any time by the guest.
>
> As a consequence, Xen's fs_base/etc tracking state is always stale when the
> vcpu is in context, and must not be used to complete MSR_{FS,GS}_BASE reads,
> etc.
>
> In particular, a sequence such as:
>
> wrmsr(MSR_FS_BASE, 0x1ull << 32);
> write_fs(__USER_DS);
> base = rdmsr(MSR_FS_BASE);
>
> will return the stale base, not the new base. This may cause guest a guest
> kernel's context switching of userspace to malfunction.
>
> Therefore:
> * Update save_segments(), _toggle_guest_pt() and read_msr() to always read
> the segment bases from hardware.
> * Update write_cr(), write_msr() and do_set_segment_base() to not not waste
> time caching data which is instantly going to become stale again.
> * Provide comments to explaining when the tracking state is and isn't stale.
>
> This bug has been present for 14 years, but several bugfixes since have built
> on and extended the original flawed logic.
>
> Fixes: ba9adb737ba ("Apply stricter checking to RDMSR/WRMSR emulations.")
> Fixes: c42494acb2f ("x86: fix FS/GS base handling when using the fsgsbase
> feature")
> Fixed: eccc170053e ("x86/pv: Don't have %cr4.fsgsbase active behind a guest
> kernels back")
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
Reviewed-by: Jan Beulich <jbeul...@suse.com>
