Re: [Xen-devel] [PATCH] vmx/monitor: CPUID events

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/07/16 17:59, Tamas K Lengyel wrote:
> On Fri, Jul 8, 2016 at 10:49 AM, Andrew Cooper
> <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 08/07/16 16:44, Tamas K Lengyel wrote:
>>> On Fri, Jul 8, 2016 at 3:33 AM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
>>> wrote:
>>>> On 08/07/16 03:31, Tamas K Lengyel wrote:
>>>>> This patch implements sending notification to a monitor subscriber when an
>>>>> x86/vmx guest executes the CPUID instruction.
>>>>>
>>>>> Signed-off-by: Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>
>>>> Is it wise having an on/off control without any further filtering?  (I
>>>> suppose that it is at least a fine first start).
>>> What type of extra filtering do you have in mind?
>> Not sure.  What are you intending to use this facility for?
> Primarily to detect malware that is fingerprinting it's environment by
> looking for hypervisor leafs and/or doing timing based detection by
> benchmarking cpuid with rdtsc.
>
>> Given that the hypervisor is already in complete control of what a guest
>> gets to see via cpuid, mutating the results via the monitor framework
>> doesn't seem like a useful thing to do.
> Indeed, the hypervisor is in control and to a certain extant the user
> is via overriding some leafs in the domain config. However, there are
> CPUID leafs Xen adds that the user is unable to override with the
> domain config. For example in malware analysis it may be very useful
> to be able to hide all hypervisor leafs from the guest, which
> currently requires us to recompile Xen completely. By being able to
> put the monitor system inline of CPUID it can decide which process it
> wants to allow to see what leafs and when. It's very handy.

Fair enough.

For the record, my planned further work for cpuid will make things far
more configurable.  The current abilities of a toolstack, and the
in-hypervisor auditing are woeful.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel