On 27/06/2017 18:12, Mihai Donțu wrote:
> The host should, indeed, control whether the introspection feature
> should be made available. I can see this being a checkbox in, say,
> virt-manager.
>
> Assuming the feature is enabled, the only policy we are interested in
> is whether our application should indeed try and introspect a guest,
> and this is connected to libvirt. For example, our management solution
> will query libvirt about running VM-s and then, depending on
> configuration made by an administrator, will tell our application which
> VM-s to actually introspect. This is where the UUID comes into play:
> the management solution refers to VM-s by their UUID and in turn the
> application must be able to convert those to an actual handle (a file
> descriptor or something else).
>
> The flow you described below seems to make room for this: during the
> initial handshake, qemu could tell our application the UUID of the
> guest and we'd keep a map of sorts. No need to put that in kernel.
Exactly. QEMU already knows the UUID.
>>
>> qemu --chardev socket,id=chardev0,type=vsock,cid=10,port=1234,nowait \
>> --object introspection chardev=chardev0,allow=all,id=kvmi \
>> --accel kvm,introspection=kvmi
>>
>> The policy is specified via kvmi-{allow,deny} parameters and passed to KVM
>> via ioctls together with the socket file descriptor.
>
> I understand from this that the policy controls whether a certain VM
> can be introspected. I'd imagine that it will be default "false" and
> set to "true" respectively whenever an "introspection" object is
> specified.
It also controls what operations can be intercepted for introspection
purposes. For example a VM may be okay with allowing memory access, but
would not be okay with allowing the introspector to trap instructions or
page faults. (Or vice versa, since memory access to an untrusted
introspector effectively breaks security).
>> QEMU supports socket reconnection, so you don't need KVMI_GET_GUESTS either.
>> If KVM cannot write to the socket, it should exit to userspace with a new
>> KVM_EXIT_KVMI vmexit (which can have multiple subcodes, one of them being
>> KVM_EXIT_KVMI_SOCKET_ERROR).
>
> If I understand all of the above correctly, qemu will initiate the
> connection to the introspection tool and after a handshake pass the
> file descritor to KVM thus making further communication take place only
> between the tool and the host kernel (no need to pass through the host
> user space).
Right, though host user space is invoked at least for the error case, in
order to reconnect to the introspector. This is useful in case the
introspector is restarted after an update or crash.
I'm not sure if other cases will need userspace cooperation. We'll see!
Paolo
