> -----Original Message----- > From: Mihai Donțu [mailto:mdontu@xxxxxxxxxxxxxxx] > Sent: 4 August, 2017 18:30 > To: Paolo Bonzini <pbonzini@xxxxxxxxxx> > Cc: Radim Krčmář <rkrcmar@xxxxxxxxxx>; Jan Kiszka > <jan.kiszka@xxxxxxxxxxx>; Stefan Hajnoczi <stefanha@xxxxxxxxxx>; > Adalbert Lazar <alazar@xxxxxxxxxxxxxxx>; kvm@xxxxxxxxxxxxxxx; Tamas K > Lengyel <tamas.k.lengyel@xxxxxxxxx>; Andrei Vlad LUTAS > <vlutas@xxxxxxxxxxxxxxx> > Subject: Re: [RFC PATCH v2 1/1] kvm: Add documentation and ABI/API > header for VM introspection > > On Fri, 2017-08-04 at 10:35 +0200, Paolo Bonzini wrote: > > On 02/08/2017 16:17, Mihai Donțu wrote: > > > On Wed, 2017-08-02 at 15:51 +0200, Paolo Bonzini wrote: > > > > On 02/08/2017 15:32, Mihai Donțu wrote: > > > > > We have currently identified three cases: > > > > > > > > > > * initial hooking of a guest > > > > > > > > What triggers the initial hooking, and how is it done? > > > > > > There are two types o hooks: dynamic (the guest is hooked as it > > > boots) and static (a fully booted guest is being hooked). They both > > > start with a notification from qemu or some other application that a > > > guest is available for introspection. After that we poke its vCPU-s > > > a few times to determine what type of hooking to continue with. I > > > belive the syscall entry point MSR-s are key here. > > > > Reads need not be transactional here, and the syscall entry point MSRs > > are generally immutable so I think it is fine not to pause. > > I might be misunderstanding. Entry point MSR-s (and maybe others) are > generally immutable in well behaving guests. We are, however, looking for > signs that something is breaking this pattern. > > > I'm curious how the introspector decides that the guest is ready to be > > hooked in, that is, that it's far enough in the boot process. > > I will let Andrei add some details here. > The first steps of enabling the protection for a guest depends on hardware events (like Mihai said, MSR writes, to give one example). Depending on what MSRs are written & the values they are written with, HVI will be able to identify, based on analyzing the guest memory, the type of the running OS (Windows x86, Windows x64, Linux, etc.) - of course, how exactly the protection is enabled from that point on (analyzing the SYSCALL/interrupt handlers, other events such as XSETBV, etc.) is OS dependent, and there isn't a single correct answer. The necessity to pause the running VCPUs for short intervals of time comes in several cases: - when receiving the first relevant events, such as the SYSCALL MSR writes, we want to ensure no other VCPU could be running that might interfere with memory that we analyse (that might include not-yet-known writable pages) - when establishing certain intercepts inside the guest memory, we need to briefly modify it, and to do so safely, we pause all the VCPUs, to make sure we don't race with the guest - when ensuring the integrity of certain structures that already lie inside writable pages (so intercepting writes via an EPT/NPT is not doable, because the induced performance overhead would be huge), so that no other VCPU modifies the said pages while we make sure they haven't been tampered with Of course, just how Paolo suggested, we can place finer-grained intercepts (such as execute-protect a page in order to ensure no VCPU runs code from it while we modify it), but this is a more complicated solution and we've never had to think for something other than simply pausing the VCPUs, since that was always available so far. Hope this piece of info helps. > > I think a command to "pause" KVM_RUN is okay to add. That is, if in > > KVM_RUN it would e.g. return 1, trigger a 'paused' event immediately > > and halt the vCPU. If not in KVM_RUN, the command would return 0 and > > trigger the 'paused' event as soon as the hypervisor invokes KVM_RUN. > > > > The introspector then can decide whether to wait if the commands > > return 0. There is no need for an "unpause" command, as that is > > achieved simply by completing the 'paused' event. > > This mechanism will allow exposing a KVMI_PAUSE_VCPU to introspectors, > something that maybe some future users can leverage. I, however, was > trying to justify a "slow" KVMI_PAUSE_VM and "fast" kvm_pause_vcpu(), > the latter existing only in KVM (kernel). The event-based mecanism for > pausing a vCPU feels like it has too much overhead for what one usually > needs it (read some registers). > > > > > Have you thought about monitoring hardware registers, for example > > > > in order to check that IOMMU page tables protect from overwriting the > kernel? > > > > > > Sorry, but I'm not sure I understand: are you thinking at a way to > > > make sure none of the IOMMU grups are configured with a "too > > > generous" DMA window? > > > > Yes, exactly. Optional, of course. > > We could add a command that returns the list of DMA ranges which can then > be used by an introspector to check if the OS has made a mistake and placed > sensible data in that rage. > > Also, I belive we have refined a number of ideas on this thread and more > remain to clarify. I would like to update the design document with what we > have agreed on so far, add some more details to what felt 'under explained' > and continue again from there. Is it OK for you? > > Regards, > > -- > Mihai Donțu > > > ________________________ > This email was scanned by Bitdefender Best regards, Andrei. ________________________ This email was scanned by Bitdefender
