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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <D47UPV0JIIMY.35CRZ8ZNZCGA1@amazon.com>
Date: Mon, 16 Sep 2024 16:32:43 +0000
From: Nicolas Saenz Julienne <nsaenz@...zon.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: <linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>,
	<pbonzini@...hat.com>, <vkuznets@...hat.com>, <linux-doc@...r.kernel.org>,
	<linux-hyperv@...r.kernel.org>, <linux-arch@...r.kernel.org>,
	<linux-trace-kernel@...r.kernel.org>, <graf@...zon.de>,
	<dwmw2@...radead.org>, <paul@...zon.com>, <mlevitsk@...hat.com>,
	<jgowans@...zon.com>, <corbet@....net>, <decui@...rosoft.com>,
	<tglx@...utronix.de>, <mingo@...hat.com>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <x86@...nel.org>, <amoorthy@...gle.com>
Subject: Re: [PATCH 00/18] Introducing Core Building Blocks for Hyper-V VSM Emulation

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