On 03/01/2020 13:36, Jan Beulich wrote: > On 02.01.2020 15:59, Andrew Cooper wrote: >> @@ -111,26 +109,6 @@ trampoline_protmode_entry: >> start64: >> /* Jump to high mappings. */ >> movabs $__high_start, %rdi >> - >> -#ifdef CONFIG_INDIRECT_THUNK >> - /* >> - * If booting virtualised, or hot-onlining a CPU, sibling threads >> can >> - * attempt Branch Target Injection against this jmp. >> - * >> - * We've got no usable stack so can't use a RETPOLINE thunk, and are >> - * further than disp32 from the high mappings so couldn't use >> - * JUMP_THUNK even if it was a non-RETPOLINE thunk. Furthermore, an >> - * LFENCE isn't necessarily safe to use at this point. >> - * >> - * As this isn't a hotpath, use a fully serialising event to reduce >> - * the speculation window as much as possible. %ebx needs >> preserving >> - * for __high_start. >> - */ >> - mov %ebx, %esi >> - cpuid >> - mov %esi, %ebx >> -#endif >> - >> jmpq *%rdi > I can see this being unneeded when running virtualized, as you said > in reply to Wei. However, for hot-onlining (when other CPUs may run > random vCPU-s) I don't see how this can safely be dropped. There's > no similar concern for S3 resume, as thaw_domains() happens only > after enable_nonboot_cpus().
I covered that in the same reply. Any guest which can use branch target injection against this jmp can also poison the regular branch predictor and get at data that way. Once again, we get to CPU Hotplug being an unused feature in practice, which is completely evident now with Intel MCE behaviour. A guest can't control/guess when a hotplug even might occur, or where exactly this branch is in memory (after all - it is variable based on the position of the trampoline), and core scheduling mitigates the risk entirely. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
