Re: [Publicity] Stealthy monitoring with Xen altp2m

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 01/04/2016 04:26 PM, Lengyel, Tamas wrote:
> However, this solution (while supported) is not particularly ideal as it
> still creates significant performance overhead. Moreover, emulation in
> Xen is known to be buggy, so creating security tools that ultimately
> rely on an emulator is just asking for trouble.

That's debatable. The emulator is not as much buggy as it is incomplete,
and there are ways around that - see the emulator bypass patch in our
initial series back in 2014. I do concede that the Xen emulator does
have a way to go.

As for the performance overhead, if the security tool chooses the
restricted pages wisely then it is more than acceptable. Of course, if
all the guest's pages have restricted access rights then the guest will
be noticeably impaired.

And still on the performance issue, with emulation we have:

1. receive page fault event;
2. reply to the hypervisor with emulate flags on;
3. get a new page fault within the hypervisor (page restrictions have
not been lifted) - but not hypervisor <-> userspace context switch);
4. emulate.

With altp2m we have:

1. receive page fault event;
2. switch altp2m view in the vm_event reply + set singlestepping on
(hypercalls, thus context switching);
3. get singlestep event from the hypervisor / guest (more context
switching);
4. switch altp2m view again + set singlestepping off (again context
switching / hypercalls).

This is definitely not a very detailed analysis of what's happening, but
I would think that the latter process takes at least as much time as the
former. In other words, I don't see how the altp2m case improves
performance.

Further on you say "By having multiple EPTs we can have differing access
permissions defined in each table, which can be swapped around at will.
When the guest makes a memory access that is monitored, instead of
having to relax the access permission, Xen can simply switch to an EPT
(called a view) that allows the operation to continue."

However, that is now an all-or-none operating procedure - either allow
or deny the operation that triggered the event. You can't, for example,
allow the operation but disallow its actual write, so that you can
continue to observe malicious activity without the malware being able to
actually do what it wants to do.

There might also be issues with guests where the number of VCPUs is
bigger than 10, which is the maximum number of allowed EPTs.

Both solutions have advantages and disadvantages, and having them both
makes Xen a great platform for the discerning developer. While the
altp2m solution might be simpler for your use-case, perhaps neither is
intrinsically superior.


Cheers,
Razvan

_______________________________________________
Publicity mailing list
Publicity@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/publicity