linux-kernel - Re: [PATCH 5/5] Documentation: kvm: introduce "VM plane" concept

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] [day] [month] [year] [list]

Message-ID: <D77YUMCRT8A8.1QZOJD3EQG58W@amazon.com>
Date: Tue, 21 Jan 2025 18:34:56 +0000
From: Nicolas Saenz Julienne <nsaenz@...zon.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Paolo Bonzini <pbonzini@...hat.com>, <linux-kernel@...r.kernel.org>,
	<kvm@...r.kernel.org>, <roy.hopkins@...e.com>, <michael.roth@....com>,
	<ashish.kalra@....com>, <jroedel@...e.de>, <thomas.lendacky@....com>,
	<anelkz@...zon.de>, <oliver.upton@...ux.dev>, <isaku.yamahata@...el.com>,
	<maz@...nel.org>, <steven.price@....com>, <kai.huang@...el.com>,
	<rick.p.edgecombe@...el.com>, <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH 5/5] Documentation: kvm: introduce "VM plane" concept

On Tue Jan 21, 2025 at 5:20 PM UTC, Sean Christopherson wrote:
> On Tue, Jan 21, 2025, Nicolas Saenz Julienne wrote:
>> On Fri Jan 17, 2025 at 9:48 PM UTC, Sean Christopherson wrote:
>> > On Wed, Oct 23, 2024, Paolo Bonzini wrote:
>> >> @@ -6398,6 +6415,46 @@ the capability to be present.
>> >>  `flags` must currently be zero.
>> >> +.. _KVM_CREATE_PLANE:
>> >> +
>> >> +4.144 KVM_CREATE_PLANE
>> >> +----------------------
>> >> +
>> >> +:Capability: KVM_CAP_PLANE
>> >> +:Architectures: none
>> >> +:Type: vm ioctl
>> >> +:Parameters: plane id
>> >> +:Returns: a VM fd that can be used to control the new plane.
>> >> +
>> >> +Creates a new *plane*, i.e. a separate privilege level for the
>> >> +virtual machine.  Each plane has its own memory attributes,
>> >> +which can be used to enable more restricted permissions than
>> >> +what is allowed with ``KVM_SET_USER_MEMORY_REGION``.
>> >> +
>> >> +Each plane has a numeric id that is used when communicating
>> >> +with KVM through the :ref:`kvm_run <kvm_run>` struct.  While
>> >> +KVM is currently agnostic to whether low ids are more or less
>> >> +privileged, it is expected that this will not always be the
>> >> +case in the future.  For example KVM in the future may use
>> >> +the plane id when planes are supported by hardware (as is the
>> >> +case for VMPLs in AMD), or if KVM supports accelerated plane
>> >> +switch operations (as might be the case for Hyper-V VTLs).
>> >> +
>> >> +4.145 KVM_CREATE_VCPU_PLANE
>> >> +---------------------------
>> >> +
>> >> +:Capability: KVM_CAP_PLANE
>> >> +:Architectures: none
>> >> +:Type: vm ioctl (non default plane)
>> >> +:Parameters: vcpu file descriptor for the default plane
>> >> +:Returns: a vCPU fd that can be used to control the new plane
>> >> +          for the vCPU.
>> >> +
>> >> +Adds a vCPU to a plane; the new vCPU's id comes from the vCPU
>> >> +file descriptor that is passed in the argument.  Note that
>> >> + because of how the API is defined, planes other than plane 0
>> >> +can only have a subset of the ids that are available in plane 0.
>> >
>> > Hmm, was there a reason why we decided to add KVM_CREATE_VCPU_PLANE, as opposed
>> > to having KVM_CREATE_PLANE create vCPUs?  IIRC, we talked about being able to
>> > provide the new FD, but that would be easy enough to handle in KVM_CREATE_PLANE,
>> > e.g. with an array of fds.
>>
>> IIRC we mentioned that there is nothing in the VSM spec preventing
>> higher VTLs from enabling a subset of vCPUs. That said, even the TLFS
>> mentions that doing so is not such a great idea (15.4 VTL Enablement):
>>
>> "Enable the target VTL on one or more virtual processors. [...] It is
>>  recommended that all VPs have the same enabled VTLs. Having a VTL
>>  enabled on some VPs (but not all) can lead to unexpected behavior."
>>
>> One thing I've been meaning to research is moving device emulation into
>> guest execution context by using VTLs. In that context, it might make
>> sense to only enable VTLs on specific vCPUs. But I'm only speculating.
>
> Creating vCPUs for a VTL in KVM doesn't need to _enable_ that VTL, and AIUI
> shouldn't enable the VTL, because HvCallEnablePartitionVtl "only" enables the VTL
> for the VM, HvCallEnableVpVtl is what fully enables the VTL for a given vCPU.

Yes.

> What I am proposing is to create the KVM vCPU object(s) at KVM_CREATE_PLANE,
> purely to help avoid NULL pointer dereferences.  Actually, since KVM will likely
> need uAPI to let userspace enable a VTL for a vCPU even if the vCPU object is
> auto-created, we could have KVM auto-create the objects transparently, i.e. still
> provide KVM_CREATE_VCPU_PLANE, but under the hood it would simply enable a flag
> and install the vCPU's file descriptor.

Sounds good. I like the idea of keeping KVM_CREATE_VCPU_PLANE around. It
also leaves the door open to creating the objects at that stage if it
ever necessary.

Nicolas