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 <andrew.cooper3@citrix.com>
---
CC: Jan Beulich <jbeulich@suse.com>
CC: Roger Pau Monné <roger.pau@citrix.com>
CC: Teddy Astie <teddy.astie@vates.tech>
---
 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

Le 09/04/2026 à 11:21, Andrew Cooper a écrit :
> 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 <andrew.cooper3@citrix.com>
> ---
> CC: Jan Beulich <jbeulich@suse.com>
> CC: Roger Pau Monné <roger.pau@citrix.com>
> CC: Teddy Astie <teddy.astie@vates.tech>
> ---
>   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.

Reviewed-by: Teddy Astie <teddy.astie@vates.tech>


--
Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech