Re: [Xen-devel] Ubuntu 16.04.1 LTS kernel 4.4.0-57 over-allocation and xen-access fail

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Tue, Jan 10, 2017 at 8:35 AM, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> wrote:

>>> What I meant was taking out this call:
>>>
>>>     /* Remove the ring_pfn from the guest's physmap */
>>>     rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
>>> &ring_pfn);
>>>     if ( rc1 != 0 )
>>>         PERROR("Failed to remove ring page from guest physmap");
>>>
>>> To leave the frame in the guest physmap.  The issue is fundamentally
>>> that after this frame has been taken out, something kicks the VM to
>>> realise it has an extra frame of balloonable space, which it clearly
>>> compensates for.
>>>
>>> You can work around the added attack surface by marking it RO in EPT;
>>> neither Xen's nor dom0's mappings are translated via EPT, so they can
>>> still make updates, but the guest won't be able to write to it.
>>>
>>> I should say that this is all a gross hack, and is in desperate need of
>>> a proper API to make rings entirely outside of the gfn space, but this
>>> hack should work for now.
>> Thanks! So far, it seems to work like a charm like this:
>
> Great.
>
>>
>> diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
>> index 2fef96a..5dd00a6 100644
>> --- a/tools/libxc/xc_vm_event.c
>> +++ b/tools/libxc/xc_vm_event.c
>> @@ -130,9 +130,17 @@ void *xc_vm_event_enable(xc_interface *xch, domid_t
>> domain_id, int param,
>>      }
>>
>>      /* Remove the ring_pfn from the guest's physmap */
>> +    /*
>>      rc1 = xc_domain_decrease_reservation_exact(xch, domain_id, 1, 0,
>> &ring_pfn);
>>      if ( rc1 != 0 )
>>          PERROR("Failed to remove ring page from guest physmap");
>> +    */
>> +
>> +    if ( xc_set_mem_access(xch, domain_id, XENMEM_access_r, mmap_pfn, 1) )
>> +    {
>> +        PERROR("Could not set ring page read-only\n");
>> +        goto out;
>> +    }
>>
>>   out:
>>      saved_errno = errno;
>>
>> Should I send this as a patch for mainline as well?
>
> Probably a good idea, although I would include a code comment explaining
> what is going on, because this is subtle if you don't know the context.

Will do, I'll send a patch out as soon as we've done a few more rounds
of testing.

(replying to all): I'm not in favor of this patch mainly because it is not stealthy. A malicious kernel could easily track what events are being sent on the ring. With DRAKVUF I could work around this using altp2m pfn-remapping, but for other tools this is can be a serious information leak.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel