From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 952D0316905; Thu, 11 Dec 2025 16:21:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765470083; cv=none; b=ohKHvj22dVn3u/MzDAhTFRTaawEhsf4R1L02dEet00A6JkQniZwERAtU2Zpgs4YvjhprfLZKQJ9gUR+LTywr1hP46R6D0Pa+CIYCNxXrrSPJ6ir7rKLu3EV0f+DbpZAdw3tJGyloOIivcWYVx1xlMhAtzh9858HkoWbFUwMgm+g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765470083; c=relaxed/simple; bh=y8xi0690kj7eN8efJPQZwJp2vdnwY7JF6oRnrBCl3Ok=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=F2ddtNHPXKpUaxdCtS4FAP7B7la1lWj8stHyrKJfBwrhgeqlE1qQ0MtybtMbUXL5uO9mB5veTNB0tjx2H+cxCBF5J2wfS5utC7Ylfx4fFZvv1ROZvUmHDz0qQRONLTLQCeJvTczp1xo2O7a0OV2pkJq3FPR6QLyiZeoK6u4gf40= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AOsdhLFf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AOsdhLFf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10CCEC4CEF7; Thu, 11 Dec 2025 16:21:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1765470083; bh=y8xi0690kj7eN8efJPQZwJp2vdnwY7JF6oRnrBCl3Ok=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AOsdhLFfM0i6K1tw759EzzvDKigMReMknnQ51pDwJTgL8vBmFHWja9Q1+Uk9RIOPE 5xl1eB1PtkjWQS2i0ypbyQBvnyN5ZPy8CnJzODJAbPji1lPskRWzs0PSHrTRyvTTle y+JFqp7GHHfJs4KigManI3RpjfVZfTkqpyf0DAW108oU+K9cVeItCMV8SkPJl0dTjl XEoHWVFE+9ShjGwm1Zj4TkFRsiBk/7Pew6oTh2objlQh20mf7G7c7BmnZH3gSMA4t/ dfsBzcAbwoo58r94H3b8XDTfBBXg9/ouIFkoTEyt6oFc6ZYz6sEu2RpJfXovIrnUfl Ge32hZzbSNCxQ== 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 1vTjPs-0000000C2ld-3FmR; Thu, 11 Dec 2025 16:21:20 +0000 Date: Thu, 11 Dec 2025 16:21:20 +0000 Message-ID: <86tsxxng5b.wl-maz@kernel.org> From: Marc Zyngier To: Joey Gouly Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Suzuki K Poulose , Oliver Upton , Zenghui Yu , Alexandru Elisei , Sascha Bischoff , Quentin Perret , Fuad Tabba , Sebastian Ene Subject: Re: [PATCH v2 6/6] KVM: arm64: Honor UX/PX attributes for EL2 S1 mappings In-Reply-To: <20251211151810.GA867614@e124191.cambridge.arm.com> References: <20251210173024.561160-1-maz@kernel.org> <20251210173024.561160-7-maz@kernel.org> <20251211151810.GA867614@e124191.cambridge.arm.com> 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: kvm@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: joey.gouly@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, alexandru.elisei@arm.com, Sascha.Bischoff@arm.com, qperret@google.com, tabba@google.com, sebastianene@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 Thu, 11 Dec 2025 15:18:51 +0000, Joey Gouly wrote: > > Question, > > On Wed, Dec 10, 2025 at 05:30:24PM +0000, Marc Zyngier wrote: > > Now that we potentially have two bits to deal with when setting > > execution permissions, make sure we correctly handle them when both > > when building the page tables and when reading back from them. > > > > Reported-by: Alexandru Elisei > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/include/asm/kvm_pgtable.h | 12 +++--------- > > arch/arm64/kvm/hyp/pgtable.c | 24 +++++++++++++++++++++--- > > 2 files changed, 24 insertions(+), 12 deletions(-) > > > > diff --git a/arch/arm64/include/asm/kvm_pgtable.h b/arch/arm64/include/asm/kvm_pgtable.h > > index be68b89692065..095e6b73740a6 100644 > > --- a/arch/arm64/include/asm/kvm_pgtable.h > > +++ b/arch/arm64/include/asm/kvm_pgtable.h > > @@ -87,15 +87,9 @@ typedef u64 kvm_pte_t; > > > > #define KVM_PTE_LEAF_ATTR_HI_SW GENMASK(58, 55) > > > > -#define __KVM_PTE_LEAF_ATTR_HI_S1_XN BIT(54) > > -#define __KVM_PTE_LEAF_ATTR_HI_S1_UXN BIT(54) > > -#define __KVM_PTE_LEAF_ATTR_HI_S1_PXN BIT(53) > > - > > -#define KVM_PTE_LEAF_ATTR_HI_S1_XN \ > > - ({ cpus_have_final_cap(ARM64_KVM_HVHE) ? \ > > - (__KVM_PTE_LEAF_ATTR_HI_S1_UXN | \ > > - __KVM_PTE_LEAF_ATTR_HI_S1_PXN) : \ > > - __KVM_PTE_LEAF_ATTR_HI_S1_XN; }) > > +#define KVM_PTE_LEAF_ATTR_HI_S1_XN BIT(54) > > +#define KVM_PTE_LEAF_ATTR_HI_S1_UXN BIT(54) > > +#define KVM_PTE_LEAF_ATTR_HI_S1_PXN BIT(53) > > > > #define KVM_PTE_LEAF_ATTR_HI_S2_XN GENMASK(54, 53) > > > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c > > index e0bd6a0172729..97c0835d25590 100644 > > --- a/arch/arm64/kvm/hyp/pgtable.c > > +++ b/arch/arm64/kvm/hyp/pgtable.c > > @@ -342,6 +342,9 @@ static int hyp_set_prot_attr(enum kvm_pgtable_prot prot, kvm_pte_t *ptep) > > if (!(prot & KVM_PGTABLE_PROT_R)) > > return -EINVAL; > > > > + if (!cpus_have_final_cap(ARM64_KVM_HVHE)) > > + prot &= ~KVM_PGTABLE_PROT_UX; > > Trying to understand this part. We don't consider KVM_PGTABLE_PROT_UX below > when !HVHE, and we don't set it in kvm_pgtable_hyp_pte_prot() when !HVHE > either, so can it ever actually be set? Because KVM_PGTABLE_PROT_X, which is directly passed by the high-level code, is defined as such: KVM_PGTABLE_PROT_X = KVM_PGTABLE_PROT_PX | KVM_PGTABLE_PROT_UX, We *could* make that value dependent on HVHE, but since that's in an enum, it is pretty ugly to do (not impossible though). But it is in the following code that this becomes useful... > > Otherwise LGTM! > > Thanks, > Joey > > > + > > if (prot & KVM_PGTABLE_PROT_X) { > > if (prot & KVM_PGTABLE_PROT_W) > > return -EINVAL; ... here. If you were passed UX (and only that), and that you're !HVHE, you won't have execution at all, and can allow writes. Does that make sense? M. -- Without deviation from the norm, progress is not possible.