Re: [PATCH 00/18] Introducing Core Building Blocks for Hyper-V VSM Emulation

[Nicolas Saenz Julienne <nsaenz@amazon.com>]

On Fri Sep 13, 2024 at 7:19 PM UTC, Sean Christopherson wrote:
> On Sun, Jun 09, 2024, Nicolas Saenz Julienne wrote:
> > This series introduces core KVM functionality necessary to emulate Hyper-V's
> > Virtual Secure Mode in a Virtual Machine Monitor (VMM).
>
> ...
>
> > As discussed at LPC2023 and in our previous RFC [2], we decided to model each
> > VTL as a distinct KVM VM. With this approach, and the RWX memory attributes
> > introduced in this series, we have been able to implement VTL memory
> > protections in a non-intrusive way, using generic KVM APIs. Additionally, each
> > CPU's VTL is modeled as a distinct KVM vCPU, owned by the KVM VM tracking that
> > VTL's state. VTL awareness is fully removed from KVM, and the responsibility
> > for VTL-aware hypercalls, VTL scheduling, and state transfer is delegated to
> > userspace.
> >
> > Series overview:
> > - 1-8: Introduce a number of Hyper-V hyper-calls, all of which are VTL-aware and
> >        expected to be handled in userspace. Additionally an new VTL-specifc MP
> >        state is introduced.
> > - 9-10: Pass the instruction length as part of the userspace fault exit data
> >         in order to simplify VSM's secure intercept generation.
> > - 11-17: Introduce RWX memory attributes as well as extend userspace faults.
> > - 18: Introduces the main VSM CPUID bit which gates all VTL configuration and
> >       runtime hypercalls.
>
> Aside from the RWX attributes, which to no one's surprise will need a lot of work
> to get them performant and functional, are there any "big" TODO items that you see
> in KVM?

Aside from VTLs and VTL switching, there is bunch of KVM features we
still need to be fully compliant with the VSM spec:
- KVM_TRANSLATE2, which Nikolas Wipper posted a week ago [1].
  Technically we can do this in user-space, but it's way simpler to
  re-use KVM's page-walker.

- Hv's TlbFlushInhibit, it allows VTL1 to block VTL0 vCPUs from issuing
  TLB Flushes, and blocks them until uninhibited. Note this only applies
  to para-virtualized TLB flushes:
  HvFlushVirtualAddress{Space,SpaceEx,List,ListEx}, so it's 100% Hyper-V
  specific.

- CPU register pinning/intecepting, we plan on reusing what HEKI
  proposed some time ago, and expose it through an IOCTL using ONE_REG
  to represent registers.

- MBEC aware memory attributes, we don't plan on enabling support for
  these with the first RWX memattrs submission. We'll do it as a follow
  up, especially as not every Windows VBS feature requires it
  (Credential Guard doesn't need it, HVCI does).

> If this series is more or less code complete, IMO modeling VTLs as distinct VM
> structures is a clear win.

I agree.

> Except for the "idle VTL" stuff, which I think we can simplify, this
> series is quite boring, and I mean that in the best possible way :-)

:)

Thanks,
Nicolas

[1] https://lore.kernel.org/kvm/20240910152207.38974-1-nikwip@amazon.de