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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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.

Jan



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