On 06/29/2018 06:38 PM, Jan Beulich wrote:
>>>> On 28.06.18 at 15:00, <a...@bitdefender.com> wrote:
>> @@ -4666,6 +4667,23 @@ static int do_altp2m_op(
>> }
>> break;
>>
>> + case HVMOP_altp2m_get_mem_access:
>> + if ( a.u.mem_access.pad )
>> + rc = -EINVAL;
>> + else
>> + {
>> + xenmem_access_t access;
>> +
>> + rc = p2m_get_mem_access(d, _gfn(a.u.mem_access.gfn), &access,
>> + a.u.mem_access.view);
>> + if ( !rc )
>> + {
>> + a.u.mem_access.hvmmem_access = access;
>> + rc = __copy_to_guest(arg, &a, 1) ? -EFAULT : 0;
>
> __copy_field_to_guest()? Or wait, no, the function argument is still a
> handle of void.
>
> And then - here we are again: Is it reasonable to permit a domain inquiring
> for itself?
A good question. Perhaps the following are decision factors:
1. It is already possible for a domain to set mem_access restrictions
(via HVMOP_altp2m_set_mem_access) on itself.
2. Tamas' patch allows setting this externally:
https://patchwork.kernel.org/patch/9639779/
Specifically, we have altp2m = disabled, mixed, external and limited to
control who is allowed to do what:
https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
That being said, we don't specifically need this to be a HVMOP - we
intend to use this from a privileged-domain based userspace agent only.
Thanks,
Razvan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
