[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |