[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2 1/2] x86/pv: Fix consistency of 64bit segment bases



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.cooper3@xxxxxxxxxx>

Reviewed-by: Jan Beulich <jbeulich@xxxxxxxx>




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.