Re: [PATCH v2] x86/altp2m: Allow setting the #VE info page for an arbitrary VCPU

[George Dunlap <dunlapg@umich.edu>]

On Tue, Sep 4, 2018 at 6:00 AM Adrian Pop <apop@bitdefender.com> wrote:
>
> In a classic HVI + Xen setup, the introspection engine would monitor
> legacy guest page-tables by marking them read-only inside the EPT; this
> way any modification explicitly made by the guest or implicitly made by
> the CPU page walker would trigger an EPT violation, which would be
> forwarded by Xen to the SVA and thus the HVI agent.  The HVI agent would
> analyse the modification, and act upon it - for example, a virtual page
> may be remapped (its guest physical address changed inside the
> page-table), in which case the introspection logic would update the
> protection accordingly (remove EPT hook on the old gpa, and place a new
> EPT hook on the new gpa).  In other cases, the modification may be of no
> interest to the introspection engine - for example, the accessed/dirty
> bits may be cleared by the operating system or the accessed/dirty bits
> may be set by the CPU page walker.
>
> In our tests we discovered that the vast majority of guest page-table
> modifications fall in the second category (especially on Windows 10 RS4
> x64 - more than 95% of ALL the page-table modifications are irrelevant to
> us) - they are of no interest to the introspection logic, but they
> trigger a very costly EPT violation nonetheless.  Therefore, we decided
> to make use of the new #VE & VMFUNC features in recent Intel CPUs to
> accelerate the guest page-tables monitoring in the following way:
>
> 1. Each monitored page-table would be flagged as being convertible
>    inside the EPT, thus enabling the CPU to deliver a virtualization
>    exception to he guest instead of generating a traditional EPT
>    violation.
> 2. We inject a small filtering driver inside the protected guest VM,
>    which would intercept the virtualization exception in order to handle
>    guest page-table modifications.
> 3. We create a dedicated EPT view (altp2m) for the in-guest agent, which
>    would isolate the agent from the rest of the operating system; the
>    agent will switch in and out of the protected EPT view via the VMFUNC
>    instruction placed inside a trampoline page, thus making the agent
>    immune to malicious code inside the guest.
>
> This way, all the page-table accesses would generate a
> virtualization-exception inside the guest instead of a costly EPT
> violation; the #VE agent would emulate and analyse the modification, and
> decide whether it is relevant for the main introspection logic; if it is
> relevant, it would do a VMCALL and notify the introspection engine
> about the modification; otherwise, it would resume normal instruction
> execution, thus avoiding a very costly VM exit.
>
> Signed-off-by: Adrian Pop <apop@bitdefender.com>

I don't have any objections to the code; I think it can stay in the
tree as far as I'm concerned.

I do have a comment on the commit message, just for future reference
at this point.  It goes into a lot of detail about the architecture of
what you're trying to accomplish, but not what this patch actually
does.  I think something like "Allow a dom0 agent to enable
vcpu_notify on guest vcpus, to enable an out-of-guest introspection
agent to insert an in-guest agent into a guest" would have been
enough.

I do have a question about your proposed use case.  You're running
this in 'mixed' mode, right, and using the altp2m to hide a secure bit
of code from the operating system?  What's to stop a rogue operating
system that doesn't want to be introspected from calling
HVMOP_altp2m_vcpu_enable_notify with INVALID_GFN to disable this?

 -George

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