Re: [PATCH v9 08/11] x86/entry: Clobber the Return Stack Buffer/Return Address Stack on entry to Xen

["Jan Beulich" <JBeulich@suse.com>]

>>> On 22.01.18 at 16:51, <andrew.cooper3@citrix.com> wrote:
> On 19/01/18 15:02, Jan Beulich wrote:
>>>>> On 19.01.18 at 15:24, <andrew.cooper3@citrix.com> wrote:
>>> On 19/01/18 12:47, Jan Beulich wrote:
>>>>>>> On 18.01.18 at 16:46, <andrew.cooper3@citrix.com> wrote:
>>>>> + * %rsp is preserved by using an extra GPR because a) we've got plenty spare,
>>>>> + * b) the two movs are shorter to encode than `add $32*8, %rsp`, and c) can be
>>>>> + * optimised with mov-elimination in modern cores.
>>>>> + */
>>>>> +    mov $16, %ecx   /* 16 iterations, two calls per loop */
>>>>> +    mov %rsp, %rax  /* Store the current %rsp */
>>>>> +
>>>>> +.L\@_fill_rsb_loop:
>>>>> +
>>>>> +    .rept 2         /* Unrolled twice. */
>>>>> +    call 2f         /* Create an RSB entry. */
>>>>> +1:  pause
>>>>> +    jmp 1b          /* Capture rogue speculation. */
>>>>> +2:
>>>> I won't further insist on changing away from numeric labels here, but
>>>> I'd still like to point out an example of a high risk use of such labels in
>>>> mainline code: There's a "jz 1b" soon after
>>>> exception_with_ints_disabled, leading across _two_ other labels and
>>>> quite a few insns and macro invocations. May I at the very least
>>>> suggest that you don't use 1 and 2 here?
>>> I spent ages trying to get .L labels working here, but they don't
>>> function inside a rept, as you end up with duplicate local symbols.
>>>
>>> Even using irp to inject a unique number into the loop doesn't appear to
>>> work, because the \ escape gets interpreted as a token separator. 
>>> AFAICT, \@ is special by virtue of the fact that it doesn't count as a
>>> token separator.
>>>
>>> If you've got a better suggestion then I'm all ears.
>>>
>>> Alternatively, I could manually unroll the loop, or pick some arbitrary
>>> other numbers to use.
>> Since the unroll number is just 2, this is what I would have
>> suggested primarily. .rept of course won't work, as it's not a
>> macro invocation, and hence doesn't increment the internal
>> counter. With .irp I can get things to work:
>>
>> 	.macro m
>> 	.irp n, 1, 2
>> .Lxyz_\@_\n:	mov	$\@, %eax
>> 	.endr
>> 	.endm
> 
> This appears to only work when \n is at the end of the label.  None of:
> 
> .Lxyz_\@_\n_:    mov    $\@, %eax
> .Lxyz_\@_\n\()_:    mov    $\@, %eax
> .Lxyz_\n\@:    mov    $\@, %eax
> 
> work.

.Lxyz_\n\(\)()_\(\)@: mov	$\@, %ecx

(There are two rounds of expansion, so \-s you want expanded
in the second round need escaping for the first one.

> Given this appears to be a corner case to begin with, how likely do you
> think it is to work with older assemblers?

The really old ones where macro handling was a mess will be a
problem irrespective of the above, I'm afraid. From the point on
where macros were made work sensibly I think not much has
changed. But yes, there's a risk.

Jan


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