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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>> On 11.12.17 at 12:06, <andrew.cooper3@xxxxxxxxxx> wrote:
>> 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.
> 
> IOW you mean that such guests would be considered "trusted", i.e.
> whatever bad they can do is by definition not a security concern.

I'm not sure what you mean by "trusted".  If implemented correctly,
altp2m and mem_access shouldn't give the guest any more permissions than
it has already.  The main risk would be if there were bugs in the
functionality that allowed security issues.

You argued that we should keep PV linear pagetables, before knowing that
NetBSD used them, in spite of having discovered two *actual*
vulnerabilities in the implementation.  I don't really see how this is
different.

We obviously need to go though the code with a fine-toothed comb before
we say that we'll give security support to the mode where we allow a
guest agent to modify altp2m access.  Since we can control whether this
functionality is exposed to the guest or not, we can specify whether we
provide security support for toolstack altp2m access vs guest altp2m access.

> If so, that's fine of course, provided the default mode is secure
> (which it looks like it is by virtue of altp2m being disabled altogether
> by default). Yet I don't think I know of a place where this is being
> spelled out.

SUPPORT.md has "Alternative p2m" listed as "tech preview", which would
mean "not security supported".  Maybe that needs an "altp2m" tag
somewhere so it's easier to grep for?

 -George

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