Re: [Publicity] Stealthy monitoring with Xen altp2m

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 01/04/2016 09:31 PM, Lengyel, Tamas wrote:
> Hi Razvan,
> thanks for chiming in!
> 
> On Jan 4, 2016 5:43 PM, "Razvan Cojocaru" <rcojocaru@xxxxxxxxxxxxxxx
> <mailto:rcojocaru@xxxxxxxxxxxxxxx>> wrote:
>>
>> 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,
> 
> Yes, that's a nicer way to state it.
> 
>> 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.
> 
> By default the only option is Xen's emulator so that's what I think
> should be discussed. Using another emulator, while probably possible,
> would certainly not be trivial.

Of course, but I wasn't referring to using a different emulator. I was
simply talking about this patch:

http://lists.xen.org/archives/html/xen-devel/2014-07/msg00309.html

a minor variation of which has been quite useful in practice so far.

>> 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.
> 
> I don't think it does either.

But then I have misread your statement that "However, this solution
(while supported) is not particularly ideal as it still creates
significant performance overhead." - I've read it to mean that the
significant performance overhead you're talking about applies to the
emulation case, as opposed to the better altp2m way - which, as it turns
out, neither of us believes.

>> 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.
> 
> Certainly, that's a use-case for which the emulation based solution is
> still suitable for. That however is beyond the point of simple
> monitoring and would be more like an IPS solution.

Maybe, but that possibility is there for the taking today (it's the
VM_EVENT_FLAG_EMULATE_NOWRITE reply), and it's not something that can be
done via altp2m. That's all I was saying.

>> There might also be issues with guests where the number of VCPUs is
>> bigger than 10, which is the maximum number of allowed EPTs.
> 
> You don't need a separate altp2m view for each vCPU. All you need is two
> views that can be interchanged in each vCPU independently.

Right. I had a more complicated use-case in mind, but indeed, you can
get by with two quite nicely. Thanks for the clarification!

> While the
>> altp2m solution might be simpler for your use-case, perhaps neither is
>> intrinsically superior.
> 
> For the usecase of monitoring arbitrary memory accesses and code
> execution on multi-vCPU systems it is the only readily available
> solution at the moment.  Using the emulator in this fashion
> unfortunately crashes the guest (that's the case you verified too, we
> should probably report that issue on xen-devel). But even if the
> emulator worked properly, provided the long list of bugs we have
> encountered in emulators in recent years I would not be surprised to
> find more issues. So if it can be avoided, it should be. And in this
> case it can be quite nicely.

I think the crash case should be brought up on xen-devel too - I had
assumed that you're still debugging the hypervisor / emulator on that
issue.notwithstanding

My experience has been the opposite - a few rogue instructions

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