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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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)?

> 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