Re: [Xen-devel] [PATCH v8] x86/altp2m: support for setting restrictions for an array of pages

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 11/12/17 09:14, Jan Beulich wrote:
>>>> On 08.12.17 at 13:42, <rcojocaru@xxxxxxxxxxxxxxx> wrote:
>> On 12/08/2017 02:18 PM, Jan Beulich wrote:
>>>>>> On 24.10.17 at 12:19, <ppircalabu@xxxxxxxxxxxxxxx> wrote:
>>>> HVMOP_altp2m_set_mem_access_multi has been added as a HVMOP (as opposed to 
>>>> a
>>>> DOMCTL) for consistency with its HVMOP_altp2m_set_mem_access counterpart 
>>>> (and
>>>> hence with the original altp2m design, where domains are allowed - with the
>>>> proper altp2m access rights - to alter these settings), in the absence of 
>>>> an
>>>> official position on the issue from the original altp2m designers.
>>> I continue to disagree with this reasoning. I'm afraid I'm not really
>>> willing to allow widening the badness, unless altp2m was formally
>>> documented security-unsupported.
>> Going the DOMCTL route here would have been the (much easier) solution,
>> and in fact, as stated before, there has been an attempt to do so -
>> however, IIRC Andrew has insisted that we should take care to use
>> consistent access privilege across altp2m operations.
> Andrew, is that the case (I don't recall anything like that)?

My suggestion was that we don't break usecases.  The Intel usecase
specifically is for an in-guest entity to have full control of all
altp2m functionality, and this is fine (security wise) when permitted to
do so by the toolstack.

~Andrew

>
>> This was followed by a lengthy xen-devel discussion and several
>> unsuccessful attempts to obtain an official position from the original
>> contributors, at which point (after several months), as also discussed
>> at the Xen Developer Summit in Budapest, we decided to press on in the
>> direction that had seemed the most compatible with the original altp2m
>> design. (Please correct me if I'm misremembering or misunderstanding
>> something.)
>>
>> So at this point it looks like we're stuck again: we're happy to go in
>> any direction the maintainers decide is the best, but we do need to
>> decide on one.
>>
>> FWIW, Tamas (CC added) has added code to restrict where altp2m calls can
>> come from (although that's not XSM code).
>>
>> Please let us know how to proceed.
> I've given my suggestion already: Now that we have SUPPORT.md,
> submit a patch to add altp2m there (not sure if it was in the part of
> George's series that was left out for the moment), stating it's
> security unsupported. With that's I still wouldn't like the addition by
> this patch, but I also wouldn't object to this widening of an already
> bad situation anymore: Anyone wanting to alter that support status
> would first need to deal with the too wide exposure of some of the
> operations.
>
> Jan
>


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