Re: [Xen-devel] [VMI] Possible race-condition in altp2m APIs

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

Hi Andrew,
thanks for helping brainstorming on this.

> How exactly does DRAKVUF go about injecting silent breakpoints?  It obviously 
> has to allocate a new gfn from somewhere to begin with.  Do the bifurcated 
> frames end up in two different altp2ms, or one in the host p2m and one in an 
> alternative?  Does #VE ever get used?

I've posted a blog entry about it a while ago, it's still accurate:
https://xenproject.org/2016/04/13/stealthy-monitoring-with-xen-altp2m.

You can't add new frames to only some of the altp2m's - at least not
with the current interfaces. All the shadow pages are added to the
hostp2m and then in the altp2m the GFN is remapped to the mfn of the
shadow page with an execute-only permissions. This way the breakpoint
can be written into the shadow-page and any attempt to read it can be
safely handled on a per-vCPU base by switching it back to the hostp2m
for the duration of a singlestep (with MTF). Setting up the shadow
pages is only safe to do during the initial setup while the altp2m
view is not used and the guest is paused. Once altp2m views are being
used adding new pages to the hostp2m results in losing all altp2m
settings. For the most part this limitation is not an issue because
all supported use-cases add the breakpoints once during the initial
setup and there are no breakpoints added later during runtime.

We've noticed that trapping MOV-TO-CR3 with the latest version of
Windows 10 has a lot of issues in terms of overhead when KPTI is used,
so as a band-aid solution it can be disabled to improve performance
(which Mathieu already did).

Also, this is all with external use of altp2m, #VE is not used.

> Given how many EPT flushing bugs I've already found in this area, I wouldn't 
> be surprised if there are further ones lurking.  If it is an EPT flushing 
> bug, this delta should make it go away, but it will come with a hefty perf 
> hit.

My understanding is that the VPID implementation in Xen is such that
effectively all VMEXITs will trigger assignment of a new VPID to the
vCPU - which is likely a performance issue in itself - so flushing the
EPT is likely not going to make a difference. But it's worth a shot,
maybe it does :)

Thanks,
Tamas

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