Re: [Xen-devel] [PATCH RFC] x86/HVM: also stuff RSB upon exit to guest

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 03.09.18 at 18:20, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 27/07/18 15:20, Jan Beulich wrote:
>> In order to mostly eliminate abuse of what Xen leaves in the RSB by
>> guest level attackers, fill the RSB with almost-NULL pointers right
>> before entering guest context.
> 
> How do you envisage an attacker using what Xen leaves in the RSB?  An
> attacker doesn't have much/any control of the callgraph Xen makes.

Just utilize occasional overlaps between Xen and guest kernel addresses.

>> TBD: Obviously using NULL here has the downside of reads through NULL
>>      not going to fault anymore.
> 
> This alone is sufficient justification to not use this route.  Ideally,
> we should have no mappings within disp32 of 0.
> 
> In principle, there are other better addresses which could be used, such
> as the page immediately below the canonical boundary, or TSEG/HSEG, but...

Iirc there was at least one erratum requiring no mapping right
below the canonical boundary.

As to TSEG/HSEG - they are physical addresses, aren't they?

>> +
>> +        ptr = __map_domain_page(pg);
>> +        memset(ptr, -1, PAGE_SIZE);
>> +        memcpy(ptr + addr, do_overwrite_rsb, size);
>> +        unmap_domain_page(ptr);
>> +
>> +        smp_wmb();
> 
> What is this barrier for?

To make sure everything ahead of it happens before ...

>> +        hvm_overwrite_rsb = (void *)addr;

... this assignment.

>> --- a/xen/include/asm-x86/spec_ctrl_asm.h
>> +++ b/xen/include/asm-x86/spec_ctrl_asm.h
>> @@ -249,6 +249,8 @@
>>  
>>  /* Use when exiting to HVM guest context. */
>>  #define SPEC_CTRL_EXIT_TO_HVM                                           \
>> +    mov hvm_overwrite_rsb(%rip), %rcx;                                  \
>> +    ALTERNATIVE "", "INDIRECT_CALL %rcx", X86_FEATURE_SC_RSB_HVM;       \
> 
> ... there are two reasons why I didn't do any RSB stuffing along these
> lines.
> 
> First, this is racy with NMIs/etc.

This is understood, and could either be fixed or tolerated as even
less controllable by an attacker.

> Secondly, SMM mode does exactly the same to the whole system (outside of
> Xens control) with a call tree in HSEG/TSEG.

And they could do similar stuffing.

> Overall, given the holes in the available mechanism, and the fact that
> Xen's current callgraph is actually pretty good (wrt RSB) for current
> operating systems, I didn't think it was worth doing anything special.

Well, okay, I just wanted the option discussed. I'll drop the patch.

Jan



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