[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 4/4] xen: select grant interface version



On 12/09/17 20:54, Andrew Cooper wrote:
> On 08/09/17 15:48, Juergen Gross wrote:
>>  static void gnttab_request_version(void)
>>  {
>> -    int rc;
>> +    long rc;
>>      struct gnttab_set_version gsv;
>>  
>> -    gsv.version = 1;
>> +    rc = HYPERVISOR_memory_op(XENMEM_maximum_ram_page, NULL);
> 
> This hypercall is information leak and layering violation.  Please can
> we avoid adding more dependence on its presence?  (I'm got a
> proto-series which strips various corners off the hypervisor for attack
> surface reduction purposes, and this hypercall is one victim which is
> restricted to privileged domains only.)
> 
> For translated guests, it is definitely not the right number to check. 
> What matters is the maximum frame inside the translated guest, not on
> the host.

Oh, right.

> For PV guests, I'm not sure what to suggest, but the result of
> XENMEM_maximum_ram_page isn't applicable.  Xen's max_page can increase
> at runtime through memory hotplug, after which ballooning operations can
> leave Linux with a frame it wishes to grant which exceeds the limit
> calculated here.

We need a way to decide whether V2 is to be selected.

Is there a way to determine which is the highest physical address being
available for memory hotplug on a system? Something in ACPI tables
perhaps?


Juergen

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.