Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 06/29/2018 06:38 PM, Jan Beulich wrote:
>>>> On 28.06.18 at 15:00, <apop@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel