On 27/07/2017 19:06, Mihai Donțu wrote:
>>> +
>>> + struct kvmi_xsave_info_reply {
>>> + __s32 err;
>>> + __u32 size;
>>> + };
>>> +
>>> +Returns the xstate size for the specified vCPU.
>> Could this be replaced by a generic CPUID accessor?
>
> Absolutely. I wonder if we should only made certain leafs acessible,
> part of the whole "make the least amount of information available"
> security philosophy, though I'm not aware of any attacks that can be
> mounted on the host just by knowing too many things about a guest.
That should be safe.
>> Also, it should be noted here that the spte flags are ANDed with
>> whatever is provided by userspace, because there could be readonly
>> memslots, and that some access combinations could fail (--x) or will
>> surely fail (-wx for example).
> We are closely looking into how KVM's MMU works and see how we'd go
> about extending it so as to make everyone happy (qemu and a possible
> introspection tool).
>
> As for the permitted page access flags, we have (thus far) kept away
> from invalid combinations on older arch-es (--x on pre-SandyBridge, for
> example). However, it would be very nice to have arch-specific code
> that does a validation ahead of time (ie. before the guest is re-
> entered) so that an introspection tool can use an alternative approach.
We can make the command fail if you end up with --x (and it is not
supported) or -wx.
>> Does KVMI_EVENT_ACTION_SET_REGS bypass the hypercall? Why is
>> KVMI_EVENT_ACTION_ALLOW not allowed? As before, I'd prefer
>> SKIP/RETRY/ALLOW/CRASH as the actions.
>
> No, we use SET_REGS only as a means to communicate with the guest code
> that did the hypercall. We don't specify an action because, in our
> specific case, saw no use for it.
Ok, I'd prefer the usual set of actions just for consistency. ALLOW
would fall through to KVM's handling of the hypercall.
> Apropos: if possible, we'd like to keep the Xen convention for this
> hypercall. It doesn't appear to interfere with either KVM or Hyper-V
> (rax = 34 [__HYPERVISOR_hvm_op], rbx/rdi = 24
> [HVMOP_guest_request_vm_event] - depends on wether long mode is
> enabled).
I was actually thinking that you'd trap all hypercalls to the
introspector, hence SKIP/RETRY/ALLOW/CRASH. Reserving RAX = 34 for you
is fine (but please document the ABI and subfunctions).
Paolo
