On 18/04/2023 12:00 pm, Jan Beulich wrote: > On 18.04.2023 11:24, Roger Pau Monne wrote: >> Some of the assembly entry points cannot be safely patched until it's >> safe to use jmp, as livepatch can replace a whole block with a jmp to >> a new address, and that won't be safe until speculative mitigations >> have been applied. > Isn't the issue only with indirect JMP, whereas livepatch uses only > direct ones?
We already have direct jumps prior to speculation safety logic. Livepatching putting more in doesn't change our safety. >> --- a/xen/arch/x86/include/asm/config.h >> +++ b/xen/arch/x86/include/asm/config.h >> @@ -44,6 +44,20 @@ >> /* Linkage for x86 */ >> #ifdef __ASSEMBLY__ >> #define ALIGN .align 16,0x90 >> +#ifdef CONFIG_LIVEPATCH >> +#define START_LP(name) \ >> + jmp name; \ >> + .pushsection .text.name, "ax", @progbits; \ > In how far is livepatch susceptible to two .text.* sections of the same > name? This can result here and perhaps also for static C functions. Well - the section is the unit of binary-diffing noticing a difference. If we have a naming collision here, then I expect the linker will merge the two section, and the livepatch will end up bigger than it strictly needs to be. ~Andrew
