Re: [Xen-devel] [PATCH] x86/altp2m: Add a subop for obtaining the mem access of a page

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Thu, Jul 5, 2018 at 9:22 AM Razvan Cojocaru
<rcojocaru@xxxxxxxxxxxxxxx> wrote:
>
> On 07/05/2018 05:35 PM, Tamas K Lengyel wrote:
> > Jan's comment here about the too broad exposure is not without a
> > point. For a security application to point in using altp2m and
> > memaccess is to have memory protections that the guest can't alter, so
> > even if the guest kernel gets compromised, some security checks remain
> > in place. Otherwise using the in-guest pagetables would be better in
> > every way - faster, less complexity, etc. #VE and VMFUNC blur this
> > picture a bit by allowing a guest agent to filter some of the events
> > that result from EPT violations. This may already be seen as
> > "weakening" the security of the approach but IMHO that's just the
> > tradeoff between security and performance. It can be configured on
> > which page can the in-guest agent act as a filter and which pages go
> > to the external agent, so at least that tradeoff can be fine-tuned (in
> > theory). So with that in mind, I would certainly consider an in-guest
> > application less of a security concern if it was only able to filter
> > events for which it was explicitly permitted to do so instead of being
> > able to both see all page permissions and also setting (ie removing
> > them) at will. The current altp2m interface is certainly not suitable
> > for making such a fine-grained distinction, and XSM doesn't help with
> > this either. But that's a separate problem, once we allow a guest
> > kernel to set these permissions, also allowing it get them makes very
> > little difference. Perhaps what we should be discussing is splitting
> > altp2m hvmop into two ops, one that's required for EPTP switching and
> > receiving #VE events, and one that adds the "rest" in case it's needed
> > during development/testing.
>
> That's true, the principle of least possible access is probably best.
> However, I believe Andrew's initial objection in the
> xc_altp2m_set_mem_access_multi() discussion was that altp2m seems to
> have been designed with the specific goal of allowing several operations
> to happen from the guest. From Intel's original design text [1]:
>
> "- Hypercalls for altp2m
>
> Altp2m mode introduces a new set of hypercalls for altp2m management
> from software agents operating in Xen HVM guests.
>
> The hypercalls are as follows:
>
> Enable or Disable altp2m mode for domain
> Create a new alternate p2m
> Edit permissions for a specific GPA within an alternate p2m
> Destroy an existing alternate p2m"
>
> Since that has obviously been accepted upon upstreaming the altp2m
> series, and since these new operations do respect that text exactly and,
> as George has pointed out, neither increase the complexity of the code,
> nor introduce a design inconsistency (with regard to what the in-guest
> agent is allowed to do), and furthermore is even more restricted by your
> later code, I would argue that simply extending the existing HVMOPs is
> what looks the most consistent.

Agree.

>
> However, our particular application is only interested in setting (and
> querying) page restrictions from userspace (from the dom0 agent). It
> will also need to be able to set the convertible bit of guest pages from
> the dom0 agent as well (patches pending). So we're also fine with a
> "DOMCTL if nobody wants it as a HVMOP" policy, if polluting the DOMCTLs
> (possibly temporarily) is an option.
>
> We could also (at least between Tamas and us) come up with current /
> likely use-cases and downgrade all altp2m HVMOPs that could be DOMCTLs
> in all the scenarios to DOMCTLs.

Aye. There is really just one HVMOP that the guest absolutely needs
access to so that it can use #VE, and that's
HVMOP_altp2m_vcpu_enable_notify. AFAIU everything else could be just a
DOMCTL.

Tamas

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