[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 11.12.17 at 13:50, <george.dunlap@xxxxxxxxxx> wrote:
> On 12/11/2017 12:12 PM, Jan Beulich wrote:
>>>>> On 11.12.17 at 12:06, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> 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.

Hmm, maybe I'm mis-reading the code, but
mem_access.c:set_mem_access() looks to be using the requested
access rights verbatim, i.e. without applying tool stack imposed
restrictions (hypervisor ones look to be honored by deriving
base permissions from the p2m type first).

> 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.
Even for altp2m as a whole I don't think it's mature enough for
us to not be able to declare parts of it not security supported.

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

Ah - indeed I had searched for altp2m only.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.