Message ID | 20250314183346.77356-1-andrew.cooper3@citrix.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | x86/traps: Drop incorrect BUILD_BUG_ON() and comment in load_system_tables() | expand |
diff --git a/xen/arch/x86/cpu/common.c b/xen/arch/x86/cpu/common.c index e8d4ca3203be..698abb7086d8 100644 --- a/xen/arch/x86/cpu/common.c +++ b/xen/arch/x86/cpu/common.c @@ -900,8 +900,6 @@ void load_system_tables(void) wrmsrl(MSR_INTERRUPT_SSP_TABLE, (unsigned long)ist_ssp); } - BUILD_BUG_ON(sizeof(*tss) <= 0x67); /* Mandated by the architecture. */ - _set_tssldt_desc(gdt + TSS_ENTRY, (unsigned long)tss, sizeof(*tss) - 1, SYS_DESC_tss_avail); if ( IS_ENABLED(CONFIG_PV32) )
It is only the hardware task switching mechanism which cares about a TSS being at least 0x67 bytes long. Furthermore, since this check was added, the limit is now 0x6b if CET-SS is active. Nevertheless, task switches, being a relic of the 32-bit days, aren't relevant to Xen. LTR is is perfectly possible to load a shorter TSS, and indeed we will be doing so with FRED active. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> --- CC: Jan Beulich <JBeulich@suse.com> CC: Roger Pau Monné <roger.pau@citrix.com> In principle this is Fixes: 788844062561 ("x86/xpti: Don't leak TSS-adjacent percpu data via Meltdown"), but I don't feel it's really a correct tag to give. --- xen/arch/x86/cpu/common.c | 2 -- 1 file changed, 2 deletions(-)