Re: [Xen-devel] [PATCH] x86/boot: Clean up the trampoline transition into Long mode

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.01.2020 15:25, Andrew Cooper wrote:
> On 03/01/2020 13:52, Jan Beulich wrote:
>> On 03.01.2020 14:44, Andrew Cooper wrote:
>>> 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.
>> Aren't you implying then that retpolines could also be dropped?
> 
> No.  It is a simple risk vs complexity tradeoff.
> 
> Guests running on a sibling *can already* attack this branch with BTI,
> because CPUID isn't a fix to bad BTB speculation, and the leakage gadget
> need only be a single instruction.
> 
> Such a guest can also attack Xen in general with Spectre v1.
> 
> As I said - this was introduced because of paranoia, back while the few
> people who knew about the issues (only several hundred at the time) were
> attempting to figure out what exactly a speculative attack looked like,
> and was applying duct tape to everything suspicious because we had 0
> time to rewrite several core pieces of system handling.

Well, okay then:
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

>>> Once again, we get to CPU Hotplug being an unused feature in practice,
>>> which is completely evident now with Intel MCE behaviour.
>> What does Intel's MCE behavior have to do with whether CPU hotplug
>> (or hot-onlining) is (un)used in practice?
> 
> The logical consequence of hotplug breaking MCEs.
> 
> If hotplug had been used in practice, the MCE behaviour would have come
> to light much sooner, when MCEs didn't work in practice.
> 
> Given that MCEs really did work in practice even before the L1TF days,
> hotplug wasn't in common-enough use for anyone to notice the MCE behaviour.

Or systems where CPU hotplug was actually used on were of good
enough quality to never surface #MC (personally I don't think
I've seen more than a handful of non-reproducible #MC instances)?
Or people having run into the bad behavior simply didn't have the
resources to investigate why their system shut down silently
(perhaps giving entirely random appearance of the behavior)?

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel