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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 07/02/2018 09:34 AM, Jan Beulich wrote:
>>>> On 29.06.18 at 18:39, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> 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.
> 
> Which, as before, I consider a flaw.
> 
>> 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 
> 
> Indeed this has at least made the situation less bad.

Should we then switch this to a DOMCTL? Tamas, any thoughts on this?
For us at least a DOMCTL is sufficient.


Thanks,
Razvan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel