Re: [Xen-devel] Windows SMP

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 29/12/2008 09:03, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:

>> You could get similar results by putting static
> Windows-kernel-specific
>> fixup tables in your drivers,
> 
> As in 'write bytes to offset x into kernel function y', with x depending
> on the exact kernel build? Wouldn't the rootkit detectors complain about
> that?

I'm not actually sure on rootkit-detector compatibility with this approach.
I know that the built-in tripwire capabilities of some 64-bit Windows
versions would be a problem, but then they tend to have lazy TPR, and also
they write to the TPR with MOV CR8, which can usually be handled efficiently
by HVM-capable CPUs anyway, so no patching is required.

Any software-based approach is going to involve patching, so I'd cross the
rootkit-detector bridge when/if we come to it. I haven't heard or read of
any complaints in this regard so far.

>> or I'd be open to having a KVM type of
>> interaction between Xen and your GPLPV drivers. Putting the payload in
> the
>> generic virtual BIOS seemed kind of gross to me.
> 
> Is it possible for a virtualised DomU to trap the MMIO write itself, or
> can it only be trapped by the hypervisor?

It could, by trapping all accesses to the APIC page (remove mapping, hook
page-fault handler). It's going to be much easier to get help from the
hypervisor!

> Btw, is it the vmexit that is slow about these TPR writes, or is it the
> writes themselves?

Both. As well as the VMEXIT you have a run through the instruction emulator
and into the apic device model. It sucks pretty bad if you do it often.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel