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 9B91236605E; Thu, 17 Sep 2026 08:06:28 +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=1789632389; cv=none; b=bbUXfI2mm7D7QDBF8XW+G+gIIWECO3omhpGMx4Mn+Z+gNvtulSguWuqGTtxRgDtwnzU+T4/LHNmE/hUxHkNIpMF0T23cteu/croCxE/PtzNWYSByEoD9+eY+68qO/OSLZdXH2BQcpRCECA0PaU4iiVUdHFoO6gls8swToqTnjC4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1789632389; c=relaxed/simple; bh=u7ObQVolWw9MKblkaJPHsSE7Whev9cReNutxD+1DSgc=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=SxF/jRSOOYb/NsaoFu92G7QQFylIUX5b2exz1kWGozM6ewAp2lEX8aSzl8Oukg67r4y5n00IduWiIYwNYaJHq+OWjdNwkdubBknPaYVfzzI4kcK86HS6wa8PtdXcO5v4JCxxnTd2UvzrO+cdCJ8qSPEuf9I4z1S5lymvTXj8jxs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HqwdTew+; 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="HqwdTew+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 371F91F000FF; Thu, 17 Sep 2026 08:06:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1789632388; bh=EL9YHt+j6bfoBIX/4XS2nc2u2ndOQPJF/fEXKcashqg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=HqwdTew+DukHgkmSJw55733JWnBazNPruvtiHneZv8a2uLcAGrp0oNLuwWWF+H6jW 0yetHujE6u7CjBYLS73qk3uUwNK3PK9WIiUL76fGkxSgszDPTkhoNFDAGHIJ85eDsy DJTHKJ7WTMdD92FVw/K9hFSmOqpoETVDAWrozQg6grzaIenZ7Lmf6pz5XOsK5qpKjj NeQp2p1MNOExBFN5IPUjZmd8UvTNp0TQUlhxgYlX4PU13kP7lbHtyYtPUd4bjCZ0ne eMJHZOi3R2m0drfv7Gp6XuxykvD95aYpUh33v3QHsMwOPkCxpN+pb9yuyWdNQcWSw+ yZROMS3hn/f6w== 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 1x778T-00000009yhL-3xfv; Thu, 17 Sep 2026 08:06:26 +0000 Date: Thu, 17 Sep 2026 09:06:25 +0100 Message-ID: <865x045mke.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 Subject: Re: [PATCH v3 15/18] KVM: arm64: Reject host access to protected VM private state In-Reply-To: References: <20260914113338.159227-1-fuad.tabba@linux.dev> <20260914113338.159227-16-fuad.tabba@linux.dev> <86a4ph5fb9.wl-maz@kernel.org> 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 X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Wed, 16 Sep 2026 20:07:28 +0100, Fuad Tabba wrote: > > Hi Marc, > > On Wed, 16 Sept 2026 at 17:30, Marc Zyngier wrote: > [...] > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > [...] > > > +/* > > > + * 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. > > I think we should keep the error, for the reason s390 returns -EINVAL > from ONE_REG on a protected vCPU and x86 does from the register ioctls > for protected VM types: News flash, this is not x86, nor s390. I don't feel constrained by other architecture, and we deviate *everywhere* already. > once the vCPU has run, the copy is the VMM's > boot state plus what the exit handlers copy out, and the VMM can't > distinguish them. x0 on MMIO is one of those fields, but the VMM reads > it from kvm_run->mmio. For LD64B, EL2 would copy the operands out the > same way and the error could be relaxed to those registers. Loosening > later breaks nobody. The comment and the message do overstate it by > calling the copy "not the guest's state", and I'll reword both in v4. > More on the kvmtool thread [1]. A protected-aware VMM already knows it cannot obtain the registers. I don't want to have to revisit the userspace interface once you have to relax it, because I know for sure that you will have to. As far as LD64B is concerned, there is no place to copy anything in the run structure, and the relaxation would require to cover all the GPRs, ESR, and FAR. At this stage, returning whatever is there is the correct thing to do IMO. Thanks, M. -- Without deviation from the norm, progress is not possible.