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

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Fri, Dec 8, 2017 at 5:42 AM, Razvan Cojocaru
<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.
>
> 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 personally don't see anything wrong adding this as an HVMOP. The
original idea with altp2m was that it will be used with VMFUNC where
there is a guest kernel-level component that is trusted and
coordinates with the hypervisor. With the setting I've added to the
altp2m config it is now possible to limit whether the guest actually
has the right to use the HVMOP or not, even without XSM. So adding
this doesn't really mean its "widening the badness", it's configurable
and could very well be appropriate depending on the use-case.

Tamas

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