This is slightly stale mentioning SWAPGS and not LKGS. However, take the opportunity to make the comment more general and less likely to bitrot.
It would be a serious vulnerability for operating systems generally if CPL3 could modify GS_SHADOW at all. No functional change. Signed-off-by: Andrew Cooper <[email protected]> --- CC: Jan Beulich <[email protected]> CC: Roger Pau Monné <[email protected]> CC: Teddy Astie <[email protected]> --- xen/arch/x86/domain.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c index 1151997758c6..592530e53bcc 100644 --- a/xen/arch/x86/domain.c +++ b/xen/arch/x86/domain.c @@ -1952,9 +1952,8 @@ static void load_segments(struct vcpu *n) * changes to bases can also be made with the WR{FS,GS}BASE instructions, when * enabled. * - * Guests however cannot use SWAPGS, so there is no mechanism to modify the - * inactive GS base behind Xen's back. Therefore, Xen's copy of the inactive - * GS base is still accurate, and doesn't need reading back from hardware. + * Guests cannot modify the inactive GS base behind Xen's back. Therefore + * Xen's copy is still accurate and doesn't need reading back. * * Under FRED, hardware automatically swaps GS for us, so SHADOW_GS is the * active GS from the guest's point of view. -- 2.39.5
