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 02:58 PM, Jan Beulich wrote:
>>>> On 11.12.17 at 15:50, <george.dunlap@xxxxxxxxxx> wrote:
>> On 12/11/2017 01:36 PM, Jan Beulich wrote:
>>>>>> On 11.12.17 at 13:50, <george.dunlap@xxxxxxxxxx> wrote:
>>>> 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.
>>>
>>> It's quite the opposite to me - I don't see the similarity. On this
>>> thread we're talking about new functionality, and how far to
>>> expose it. PV linear page tables had been there (and considered
>>> supported) for years, so removing the functionality or even only
>>> calling it unsupported all of the sudden didn't seem right at all.
>>
>> Well the idea of calling it unsupported was assuming that there weren't
>> many people using it; finding out that NetWare, and in particular
>> NetBSD, still used it changes the situation quite a bit.
>>
>> What I remember you actually saying at the time was, "We have
>> functionality already, I don't see why we don't make it secure rather
>> than removing it."  The same kind of argument would seem to apply here:
>> We have functionality that allows a guest agent to manipulate its altp2m
>> access rights; why we don't make it secure rather than removing it?
> 
> That's a good option, but the patch here doesn't do so. Instead it
> increases the amount of code that will later need auditing /
> altering.

Right, but that's because their goal isn't to get guest support working.
 It doesn't sound like they particularly care about HVMOP / DOMCTL at
all; rather, it's Andy who has insisted that it be extended in line with
the current interface, for such a time as someone wants to use the guest
altp2m hypercalls.

First of all, I agree with Andy, that we should make interfaces
consistent.  If we have altp2m_set_mem_access is an HVMOP, then
altp2m_set_mem_access_multi should be an HVMOP.  If on the other hand we
don't want altp2m_set_mem_access_multi as an HVMOP, then we should
change altp2m_set_mem_access into a DOMCTL as well.

At the moment I prefer the first option, because one of Xen's historical
"niches" is support for quirky additional security features.  It seems
to me that having a functioning, but non-audited / security supported
feature in place, such that people can come along and fix it up (rather
than implementing it from scratch) puts us in a better position --
providing, of course, that having the functionality available in "tech
preview" status doesn't add significant risk to normal users.

 -George

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