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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.07.18 at 16:05, <George.Dunlap@xxxxxxxxxx> wrote:
>> On Jul 2, 2018, at 7:34 AM, Jan Beulich <JBeulich@xxxxxxxx> 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.
> 
> How many times do we have to go over this?  Here is my recollection from the 
> last time we had a discussion on this topic:
> 
> * The original authors of this code probably thought having guests set their 
> own memaccess would be a potential use case
> * The maintainers and main users of the code (Tamas and Razvan) think it’s a 
> useful use case
> * The MM maintainer (me) and one of the x86 maintainers (Andy) think it’s a 
> useful use case.
> 
> (Correct me if I’ve misremembered anywhere.)
> 
> Do we need to have a formal vote by the committers for you to accept that 
> this should be a supported use case, and stop making objections any time 
> someone wants to improve it?

There's no need for a vote, since - as before - I won't object to the
addition, but I consider it to widen the badness (once again). In all
the "think it's a valid use case" it was never really made clear to me
how this "valid" implies "still secure".

Jan


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