From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C6874C33D8; Wed, 16 Sep 2026 16:30:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789576255; cv=none; b=bB0QzpGzq8Ljdk3u35D7DQq6bsF/5vf2n4ICcPfO68WbXeT9o6PbZmlTlRfcrFMnqRfQ1jVi4hEwubooja0Q2jUjbTg6hfZPLo3lHwQyIfPrRu4P9N4ct7TzIbJQMoTNfOchLqSMo4/CRC+RJD6viasm0g+fkT2eepaqPubY2QE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789576255; c=relaxed/simple; bh=GpR/9Wyih36StK+PYry4Qeuqz6DpEIpOVqgowvgJid8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=MWc7zHIH1xBUBiIEzfjykTeT+jaAle4fpS3e+trmi1qxatI1Sx/lr0kei0UgLdvlZbzK/tDz20aZQaqtWTRvMg94o8sCFZV1aauI7n/0Zamb4rqbythuMeUTKrbetJXzDnS6ybbi+7uaqe1fGEGd+o3v+2lzvW6tup4MW3/ljjo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QaLwMVew; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QaLwMVew" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B7A01F00893; Wed, 16 Sep 2026 16:30:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789576253; bh=ODT+t7xp89lxqSyYSz0cPUXtoch46ObqS7q3+uB/lnk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=QaLwMVewhdPZdmohVX1Jzp2I7Hd30CA6gLburQEePbixidMdJjINdjcxpKLCbGmv+ bcD9KJmhgFasn+q/iqDdcL8t3xZ8Jdlex7pvS5EeyOG0cW8dKs4tKusdnhT4J4O/4h DYecIVDZ4CtTJjPrNWPVXmdGs1Hr7zS2QQMEH6lJQWhDV480m3SFuBq5qZxaby+s0U rPM2zYcKkrypc1xzEkCJZBl+ryBMZQY3P+NWks+YmebJ9MandBLYQbW28IrO2lkC89 l29YajnZL3vZHLNX3KAtmEEBYk+PrQWVhD5PSebU/GKZbfE1WF8k7ls0NTsDdFp5f0 5Kb/vY687JXEg== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1x6sX5-00000009iN3-0lXB; Wed, 16 Sep 2026 16:30:51 +0000 Date: Wed, 16 Sep 2026 17:30:50 +0100 Message-ID: <86a4ph5fb9.wl-maz@kernel.org> From: Marc Zyngier To: Fuad Tabba Cc: oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, mark.rutland@arm.com, steven.price@arm.com, vdonnefort@google.com, qperret@google.com, tabba@google.com Subject: Re: [PATCH v3 15/18] KVM: arm64: Reject host access to protected VM private state In-Reply-To: <20260914113338.159227-16-fuad.tabba@linux.dev> References: <20260914113338.159227-1-fuad.tabba@linux.dev> <20260914113338.159227-16-fuad.tabba@linux.dev> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: fuad.tabba@linux.dev, oupton@kernel.org, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, mark.rutland@arm.com, steven.price@arm.com, vdonnefort@google.com, qperret@google.com, tabba@google.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Mon, 14 Sep 2026 12:33:35 +0100, Fuad Tabba wrote: > > A protected vCPU's register and debug state is no longer exposed to > the host. Host ioctls that would reach that state now fail rather > than operate on a copy that isn't the guest's: > > - KVM_GET_ONE_REG and KVM_SET_ONE_REG return -EPERM once the vCPU has > run: the copy then holds reset values plus what the exit handlers > marshal out. Pre-run access still builds the guest's boot state. > - KVM_ARM_VCPU_INIT returns -EPERM once the vCPU has run: it would > reset the host copy alone and rewrite mp_state, which EL2 reads > only at hyp vCPU creation, so a vCPU the guest powered off would > come back RUNNABLE. > - KVM_SET_VCPU_EVENTS rejects external-abort injection with -EPERM; > SError injection is forwarded and stays permitted. > - KVM_SET_GUEST_DEBUG returns -EPERM: a protected guest's debug state > is hypervisor-owned. > > The KVM_{GET,SET}_ONE_REG and KVM_ARM_VCPU_INIT checks are one filter > on the ioctl number in kvm_arch_vcpu_ioctl(), the only caller of the > three functions they were in. Its -EPERM now precedes the cases' > -EFAULT and the ONE_REG case's pending-reset handling, which the next > KVM_RUN performs. The external-abort check reads the payload, and > KVM_SET_GUEST_DEBUG has its own case in kvm_vcpu_ioctl(), so it never > reaches kvm_arch_vcpu_ioctl(): those two stay in their handlers. > > KVM_CHECK_EXTENSION returns 0 for KVM_CAP_ARM_INJECT_EXT_DABT and > KVM_CAP_SET_GUEST_DEBUG on a protected VM: kvm_pkvm_ext_allowed() > returns false on every capability it doesn't list, and the patch that > advertises the capabilities protected VMs support leaves these two > out. The two ioctl checks stay for a VMM that doesn't query > KVM_CHECK_EXTENSION. > > Signed-off-by: Fuad Tabba > --- > arch/arm64/kvm/arm.c | 21 +++++++++++++++++++++ > arch/arm64/kvm/guest.c | 11 +++++++++++ > 2 files changed, 32 insertions(+) > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > index ca6e109b3e5d6..0362f5f235e02 100644 > --- a/arch/arm64/kvm/arm.c > +++ b/arch/arm64/kvm/arm.c > @@ -1865,6 +1865,23 @@ static int kvm_arm_vcpu_set_events(struct kvm_vcpu *vcpu, > return __kvm_arm_vcpu_set_events(vcpu, events); > } > > +/* > + * Once a protected vCPU has run, the host copy is not the guest's state, > + * and EL2 has read mp_state, which it does only at hyp vCPU creation. > + */ > +static long pkvm_filter_vcpu_ioctl(struct kvm_vcpu *vcpu, unsigned int ioctl) > +{ > + switch (ioctl) { > + case KVM_ARM_VCPU_INIT: > + case KVM_SET_ONE_REG: > + case KVM_GET_ONE_REG: > + if (vcpu_is_protected(vcpu) && vcpu_has_run_once(vcpu)) > + return -EPERM; > + } > + > + return 0; > +} > + I'm not keen on returning -EPERM for the ONE_REG stuff. For a start, X0 *is* valid on MMIO, and when you want to support LD64B and co, you'll need to show the actual data there. I'd rather return what is in the host vcpu structure, as normal. M. -- Without deviation from the norm, progress is not possible.