From: Chao Gao <chao.gao@intel.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Marc Zyngier <maz@kernel.org>,
Oliver Upton <oliver.upton@linux.dev>,
Paolo Bonzini <pbonzini@redhat.com>,
<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Adrian Hunter <adrian.hunter@intel.com>,
Vishal Annapurve <vannapurve@google.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Nikolay Borisov <nik.borisov@suse.com>
Subject: Re: [PATCH 3/5] KVM: Reject ioctls only if the VM is bugged, not simply marked dead
Date: Wed, 30 Jul 2025 09:20:57 +0800 [thread overview]
Message-ID: <aIlzeT+yFG2Tvb3/@intel.com> (raw)
In-Reply-To: <20250729193341.621487-4-seanjc@google.com>
On Tue, Jul 29, 2025 at 12:33:38PM -0700, Sean Christopherson wrote:
>Relax the protection against interacting with a buggy KVM to only reject
>ioctls if the VM is bugged, i.e. allow userspace to invoke ioctls if KVM
>deliberately terminated the VM. Drop kvm.vm_dead as there are no longer
>any readers, and KVM shouldn't rely on vm_dead for functional correctness.
>The only functional guarantees provided by kvm_vm_dead() come by way of
>KVM_REQ_VM_DEAD, which ensures that vCPU won't re-enter the guest.
If ioctls are allowed for dead VMs, would it be possible for userspace to
create a new vCPU and attempt to enter a dead VM? is this something KVM
should prevent?
>
>Practically speaking, this only affects x86, which uses kvm_vm_dead() to
>prevent running a VM whose resources have been partially freed or has run
>one or more of its vCPUs into an architecturally defined state. In these
^^^ undefined?
>cases, there is no (known) danger to KVM, the goal is purely to prevent
>entering the guest.
>
>As evidenced by commit ecf371f8b02d ("KVM: SVM: Reject SEV{-ES} intra host
>migration if vCPU creation is in-flight"), the restriction on invoking
>ioctls only blocks _new_ ioctls. I.e. KVM mustn't rely on blocking ioctls
>for functional safety (whereas KVM_REQ_VM_DEAD is guaranteed to prevent
>vCPUs from entering the guest).
next prev parent reply other threads:[~2025-07-30 1:21 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-29 19:33 [PATCH 0/5] KVM: Drop vm_dead, pivot on vm_bugged for -EIO Sean Christopherson
2025-07-29 19:33 ` [PATCH 1/5] KVM: Never clear KVM_REQ_VM_DEAD from a vCPU's requests Sean Christopherson
2025-07-29 19:33 ` [PATCH 2/5] KVM: TDX: Exit with MEMORY_FAULT on unexpected pending S-EPT Violation Sean Christopherson
2025-07-29 22:27 ` Edgecombe, Rick P
2025-07-29 22:54 ` Sean Christopherson
2025-07-29 22:58 ` Edgecombe, Rick P
2025-07-29 23:08 ` Sean Christopherson
2025-07-29 23:13 ` Edgecombe, Rick P
2025-07-30 5:45 ` Yan Zhao
2025-07-30 5:55 ` Yan Zhao
2025-07-30 12:59 ` Edgecombe, Rick P
2025-07-30 2:07 ` Xiaoyao Li
2025-07-30 6:04 ` Yan Zhao
2025-07-29 19:33 ` [PATCH 3/5] KVM: Reject ioctls only if the VM is bugged, not simply marked dead Sean Christopherson
2025-07-30 1:20 ` Chao Gao [this message]
2025-07-29 19:33 ` [PATCH 4/5] KVM: selftests: Use for-loop to handle all successful SEV migrations Sean Christopherson
2025-07-29 19:33 ` [PATCH 5/5] KVM: TDX: Add sub-ioctl KVM_TDX_TERMINATE_VM Sean Christopherson
2025-08-01 13:56 ` Adrian Hunter
2025-08-01 16:44 ` Sean Christopherson
2025-08-03 17:41 ` Adrian Hunter
2025-08-06 6:06 ` Chao Gao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aIlzeT+yFG2Tvb3/@intel.com \
--to=chao.gao@intel.com \
--cc=adrian.hunter@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=nik.borisov@suse.com \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=vannapurve@google.com \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.