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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

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.

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.

The bigger problem is the uncertainty of the (by now quite venerable)
debate - I think we all agree that we need a final decision on this so
as to be able to constructively move forward. It looks like the
designers of the original code have moved on.


Thank you,
Razvan

[1]
https://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01319.html

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