| Message ID | d8561c46-a6df-3f64-78df-f84c649a99b4@suse.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | x86: some assembler macro rework | expand |
On 28.09.2020 14:30, Jan Beulich wrote: > Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had > to introduce a number of #ifdef-s to make the build work with older tool > chains. Introduce an assembler macro covering for tool chains not > knowing of CET-SS, allowing some conditionals where just SETSSBSY is the > problem to be dropped again. > > No change to generated code. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> > --- > Now that I've done this I'm no longer sure which direction is better to > follow: On one hand this introduces dead code (even if just NOPs) into > CET-SS-disabled builds. A possible compromise here might be to ... > --- a/xen/include/asm-x86/asm-defns.h > +++ b/xen/include/asm-x86/asm-defns.h > @@ -7,3 +7,9 @@ > .byte 0x0f, 0x01, 0xcb > .endm > #endif > + > +#ifndef CONFIG_HAS_AS_CET_SS > +.macro setssbsy > + .byte 0xf3, 0x0f, 0x01, 0xe8 > +.endm > +#endif ... comment out this macro's body. If we went this route, incssp and wrssp could be dealt with in similar ways, to allow dropping further #ifdef-s. Jan
On 28/09/2020 13:30, Jan Beulich wrote: > Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had > to introduce a number of #ifdef-s to make the build work with older tool > chains. Introduce an assembler macro covering for tool chains not > knowing of CET-SS, allowing some conditionals where just SETSSBSY is the > problem to be dropped again. > > No change to generated code. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> > --- > Now that I've done this I'm no longer sure which direction is better to > follow: On one hand this introduces dead code (even if just NOPs) into > CET-SS-disabled builds. Otoh this is a step towards breaking the tool > chain version dependency of the feature. I've said before. You cannot break the toolchain dependency without hardcoding memory operands. I'm not prepared to let that happen. There is no problem requiring newer toolchains for newer features (you're definitely not having CET-IBT, for example), and there is a (unacceptably, IMO) large cost to this work. ~Andrew
On 13.10.2020 13:20, Andrew Cooper wrote: > On 28/09/2020 13:30, Jan Beulich wrote: >> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had >> to introduce a number of #ifdef-s to make the build work with older tool >> chains. Introduce an assembler macro covering for tool chains not >> knowing of CET-SS, allowing some conditionals where just SETSSBSY is the >> problem to be dropped again. >> >> No change to generated code. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> >> --- >> Now that I've done this I'm no longer sure which direction is better to >> follow: On one hand this introduces dead code (even if just NOPs) into >> CET-SS-disabled builds. Otoh this is a step towards breaking the tool >> chain version dependency of the feature. > > I've said before. You cannot break the toolchain dependency without > hardcoding memory operands. I'm not prepared to let that happen. > > There is no problem requiring newer toolchains for newer features > (you're definitely not having CET-IBT, for example), and there is a > (unacceptably, IMO) large cost to this work. I'm aware of your view. What remains unclear to me is whether your reply is merely a remark on this post-commit-message comment, or whether it is an objection to the tidying (as I view it) the patch does. Jan
On 28/09/2020 13:37, Jan Beulich wrote: > On 28.09.2020 14:30, Jan Beulich wrote: >> Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had >> to introduce a number of #ifdef-s to make the build work with older tool >> chains. Introduce an assembler macro covering for tool chains not >> knowing of CET-SS, allowing some conditionals where just SETSSBSY is the >> problem to be dropped again. >> >> No change to generated code. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> >> --- >> Now that I've done this I'm no longer sure which direction is better to >> follow: On one hand this introduces dead code (even if just NOPs) into >> CET-SS-disabled builds. > A possible compromise here might be to ... > >> --- a/xen/include/asm-x86/asm-defns.h >> +++ b/xen/include/asm-x86/asm-defns.h >> @@ -7,3 +7,9 @@ >> .byte 0x0f, 0x01, 0xcb >> .endm >> #endif >> + >> +#ifndef CONFIG_HAS_AS_CET_SS >> +.macro setssbsy >> + .byte 0xf3, 0x0f, 0x01, 0xe8 >> +.endm >> +#endif > ... comment out this macro's body. If we went this route, incssp > and wrssp could be dealt with in similar ways, to allow dropping > further #ifdef-s. No, because how you've got something which reads as a real instruction which sometimes disappears into nothing. (Interestingly, zero length alternatives do appear to compile, and this is clearly a bug.) The thing which matters is the clarity of code in its surrounding context, and this isn't an improvement. ~Andrew
On 13.10.2020 13:40, Andrew Cooper wrote: > (Interestingly, zero length > alternatives do appear to compile, and this is clearly a bug.) Why? The replacement code may be intended to be all NOPs. Jan
--- a/xen/arch/x86/boot/x86_64.S +++ b/xen/arch/x86/boot/x86_64.S @@ -31,7 +31,6 @@ ENTRY(__high_start) jz .L_bsp /* APs. Set up shadow stacks before entering C. */ -#ifdef CONFIG_XEN_SHSTK testl $cpufeat_mask(X86_FEATURE_XEN_SHSTK), \ CPUINFO_FEATURE_OFFSET(X86_FEATURE_XEN_SHSTK) + boot_cpu_data(%rip) je .L_ap_shstk_done @@ -55,7 +54,6 @@ ENTRY(__high_start) mov $XEN_MINIMAL_CR4 | X86_CR4_CET, %ecx mov %rcx, %cr4 setssbsy -#endif .L_ap_shstk_done: call start_secondary --- a/xen/arch/x86/setup.c +++ b/xen/arch/x86/setup.c @@ -668,7 +668,7 @@ static void __init noreturn reinit_bsp_s stack_base[0] = stack; memguard_guard_stack(stack); - if ( IS_ENABLED(CONFIG_XEN_SHSTK) && cpu_has_xen_shstk ) + if ( cpu_has_xen_shstk ) { wrmsrl(MSR_PL0_SSP, (unsigned long)stack + (PRIMARY_SHSTK_SLOT + 1) * PAGE_SIZE - 8); --- a/xen/arch/x86/x86_64/compat/entry.S +++ b/xen/arch/x86/x86_64/compat/entry.S @@ -197,9 +197,7 @@ ENTRY(cr4_pv32_restore) /* See lstar_enter for entry register state. */ ENTRY(cstar_enter) -#ifdef CONFIG_XEN_SHSTK ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK -#endif /* sti could live here when we don't switch page tables below. */ CR4_PV32_RESTORE movq 8(%rsp),%rax /* Restore %rax. */ --- a/xen/arch/x86/x86_64/entry.S +++ b/xen/arch/x86/x86_64/entry.S @@ -236,9 +236,7 @@ iret_exit_to_guest: * %ss must be saved into the space left by the trampoline. */ ENTRY(lstar_enter) -#ifdef CONFIG_XEN_SHSTK ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK -#endif /* sti could live here when we don't switch page tables below. */ movq 8(%rsp),%rax /* Restore %rax. */ movq $FLAT_KERNEL_SS,8(%rsp) @@ -272,9 +270,7 @@ ENTRY(lstar_enter) jmp test_all_events ENTRY(sysenter_entry) -#ifdef CONFIG_XEN_SHSTK ALTERNATIVE "", "setssbsy", X86_FEATURE_XEN_SHSTK -#endif /* sti could live here when we don't switch page tables below. */ pushq $FLAT_USER_SS pushq $0 --- a/xen/include/asm-x86/asm-defns.h +++ b/xen/include/asm-x86/asm-defns.h @@ -7,3 +7,9 @@ .byte 0x0f, 0x01, 0xcb .endm #endif + +#ifndef CONFIG_HAS_AS_CET_SS +.macro setssbsy + .byte 0xf3, 0x0f, 0x01, 0xe8 +.endm +#endif
Commit b586a81b7a90 ("x86/CET: Fix build following c/s 43b98e7190") had to introduce a number of #ifdef-s to make the build work with older tool chains. Introduce an assembler macro covering for tool chains not knowing of CET-SS, allowing some conditionals where just SETSSBSY is the problem to be dropped again. No change to generated code. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Roger Pau Monné <roger.pau@citrix.com> --- Now that I've done this I'm no longer sure which direction is better to follow: On one hand this introduces dead code (even if just NOPs) into CET-SS-disabled builds. Otoh this is a step towards breaking the tool chain version dependency of the feature. I've also dropped conditionals around bigger chunks of code; while I think that's preferable, I'm open to undo those parts.