Re: [PATCH v3 3/3] tools: introduce parameter max_wp_ram_ranges.

["Yu, Zhang" <yu.c.zhang@linux.intel.com>]

On 2/2/2016 7:12 PM, Jan Beulich wrote:
>>>> On 02.02.16 at 11:56, <yu.c.zhang@linux.intel.com> wrote:
>> I understand your concern, and to be honest, I do not think
>> this is an optimal solution. But I also have no better idea
>> in mind.  :(
>> Another option may be: instead of opening this parameter to
>> the tool stack, we use a XenGT flag, which set the rangeset
>> limit to a default value. But like I said, this default value
>> may not always work on future XenGT platforms.
>
> Assuming that you think of something set e.g. by hypervisor
> command line option: How would that work? I.e. how would
> that limit the resource use for all VMs not using XenGT? Or if
> you mean a flag settable in the domain config - how would you
> avoid a malicious admin to set this flag for all the VMs created
> in the controlled partition of the system?
>

Well, I am not satisfied with this new parameter, because:
1> exposing an option like max_wp_ram_ranges to the user seems too
detailed;
2> but if not, using a XenGT flag means it would be hard for hypervisor
to find a default value which can work in all situations theoretically,
although in practice, 8K is already a big enough one.

However, as to the security concern you raised, I can not fully
understand. :) E.g. I believe a malicious admin can also breach the
system even without this patch. This argument may not be convincing to 
you, but as to this specific case, even if an admin set XenGT flag to
all VMs, what harm will this action do? It only means the ioreq server 
can at most allocate 8K ranges, will that consume all the Xen heaps, 
especially for 64 bit Xen?

Anyway, despite different opinions, I still need to say thank you
for your explanation. Upstreaming XenGT features is my task, it is 
painfully rewarding, to receive suggestions from community maintainers,
which helps a newbie like me better understand the virtualization
technology. :)

Thanks
Yu