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@lists.xen.org
https://lists.xen.org/xen-devel
