lkml.org 
[lkml]   [2017]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [Xen-devel] [PATCH 4/4] xen: select grant interface version
From
Date
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

\
 
 \ /
  Last update: 2017-09-13 11:24    [W:0.099 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site