Re: [Xen-devel] [PATCH 1/2] x86/traps: guard top-of-stack reads

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 07.06.19 at 19:51, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 31/05/2019 10:17, Jan Beulich wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -484,16 +484,23 @@ static void _show_trace(unsigned long sp
>>  
>>  static void show_trace(const struct cpu_user_regs *regs)
>>  {
>> -    unsigned long *sp = ESP_BEFORE_EXCEPTION(regs);
>> +    unsigned long *sp = ESP_BEFORE_EXCEPTION(regs), tos = 0;
>>  
>>      printk("Xen call trace:\n");
>>  
> 
> /* Probe the stack for readability. */

That's not an appropriate comment for this code fragment, at least
not with my (non-native) understanding of "probe". To me the verb
does not include reading actual data, yet that's what we do here.
If anything is needed at all, then maybe "Guarded read of the stack
top"?

>> +    asm ( "1: mov %2,%0; 2:\n"
>> +          ".pushsection .fixup,\"ax\"\n"
>> +          "3: xor %k1,%k1; jmp 2b\n"
> 
> Can we use some named parameters, so the asm can actually be followed?

Sure. I did consider doing so, but then thought the one here would
be simple enough.

> Also, you can't do this by zeroing sp, because it aliases with "sp was
> at zero and readable".  A better option would be to get an explicit
> fault boolean out of the asm.

Hmm, this was actually deliberate: A zero %rsp is a clear sign of the
stack being bad, and better not getting dumped from.

>> @@ -501,12 +508,15 @@ static void show_trace(const struct cpu_
>>       * return address; print it and skip past so _show_trace() doesn't print
>>       * it again.
>>       */
>> -    else
>> +    else if ( sp )
>>      {
>> -        printk("   [<%p>] %pS\n", _p(*sp), _p(*sp));
>> +        printk("   [<%p>] %pS\n", _p(tos), _p(tos));
>>          sp++;
>>      }
>>  
>> +    if ( !sp )
>> +        return;
> 
> Along with the alias mentioned above, this also has a boundary case when
> sp is -8, due to the sp++ above.

Hmm, yes, until the next patch.

> It would probably be better to fit an
> 
> else if ( fault )
> {
>     printk("   [Fault on access]\n");
>     return;
> }
> 
> into the middle of the existing if/else.

Well, okay, I'll add such a separate boolean then. I wanted to avoid
further hampering readability of the asm()...

Jan



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