linux-kernel - Re: linux-next: manual merge of the arm64 tree with the origin tree

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

Message-ID: <86h5s8bca4.wl-maz@kernel.org>
Date: Mon, 26 Jan 2026 15:53:55 +0000
From: Marc Zyngier <maz@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: Mark Brown <broonie@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux Next Mailing List <linux-next@...r.kernel.org>,
	Oliver Upton <oupton@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: linux-next: manual merge of the arm64 tree with the origin tree

On Mon, 26 Jan 2026 15:23:32 +0000,
Will Deacon <will@...nel.org> wrote:
> 
> On Mon, Jan 26, 2026 at 03:11:27PM +0000, Mark Brown wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the arm64 tree got a conflict in:
> > 
> >   arch/arm64/kvm/hyp/entry.S
> > 
> > between commit:
> > 
> >   86364832ba6f2 ("KVM: arm64: Don't blindly set set PSTATE.PAN on guest exit")
> > 
> > from the origin tree and commit:
> > 
> >   018a231b0260e ("arm64: Unconditionally enable PAN support")
> > 
> > from the arm64 tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
> > 
> > [Took the version from Linus' tree.]
> 
> Hmm, I suspect that's not quite right because CONFIG_ARM64_PAN doesn't
> exist anymore in the arm64 tree and so the hunk in
> arch/arm64/kvm/va_layout.c probably needs tweaking.

The whole function in va_layout.c should simply disappear and whatever
is in arm64 be kept. That's what I did when I merged
arm64/for-next/cpufeature and kvm-arm64/vtcr in kvmarm/next.

But I now realise that because all these changes happen only in the
kvmarm/next branch (what was added is now removed), nobody sees that
outside of that tree, and next ends up with something that isn't quite
right.

> Marc -- how would you prefer to handle this? I could bring back
> CONFIG_ARM64_PAN as a hidden Kconfig option =y and then we could clean
> up the stragglers at -rc1?

As long as entry.S reflects what is in arm64 tree, we don't need this.
We just have a dangling patch function that is never called, and we
can cull that later. But if entry.S stays with Linus' version, then we
definitely need something of the sort.

FWIW, my own resolution is below.

Thanks,

	M.

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index ce516d8187b1b..a1ad12c72ebf1 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -300,8 +300,6 @@ void kvm_get_kimage_voffset(struct alt_instr *alt,
 	__le32 *origptr, __le32 *updptr, int nr_inst);
 void kvm_compute_final_ctr_el0(struct alt_instr *alt,
 	__le32 *origptr, __le32 *updptr, int nr_inst);
-void kvm_pan_patch_el2_entry(struct alt_instr *alt,
-			     __le32 *origptr, __le32 *updptr, int nr_inst);
 void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr, u64 elr_virt,
 	u64 elr_phys, u64 par, uintptr_t vcpu, u64 far, u64 hpfar);
 
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index d1ccddf9e87d9..11a10d8f5beb2 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -126,9 +126,7 @@ SYM_INNER_LABEL(__guest_exit, SYM_L_GLOBAL)
 
 	add	x1, x1, #VCPU_CONTEXT
 
-	alternative_cb ARM64_ALWAYS_SYSTEM, kvm_pan_patch_el2_entry
-	nop
-	alternative_cb_end
+	ALTERNATIVE(nop, SET_PSTATE_PAN(1), ARM64_HAS_PAN)
 
 	// Store the guest regs x2 and x3
 	stp	x2, x3,   [x1, #CPU_XREG_OFFSET(2)]
diff --git a/arch/arm64/kvm/va_layout.c b/arch/arm64/kvm/va_layout.c
index bf888d150dc79..91b22a014610b 100644
--- a/arch/arm64/kvm/va_layout.c
+++ b/arch/arm64/kvm/va_layout.c
@@ -296,31 +296,3 @@ void kvm_compute_final_ctr_el0(struct alt_instr *alt,
 	generate_mov_q(read_sanitised_ftr_reg(SYS_CTR_EL0),
 		       origptr, updptr, nr_inst);
 }
-
-void kvm_pan_patch_el2_entry(struct alt_instr *alt,
-			     __le32 *origptr, __le32 *updptr, int nr_inst)
-{
-	/*
-	 * If we're running at EL1 without hVHE, then SCTLR_EL2.SPAN means
-	 * nothing to us (it is RES1), and we don't need to set PSTATE.PAN
-	 * to anything useful.
-	 */
-	if (!is_kernel_in_hyp_mode() && !cpus_have_cap(ARM64_KVM_HVHE))
-		return;
-
-	/*
-	 * Leap of faith: at this point, we must be running VHE one way or
-	 * another, and FEAT_PAN is required to be implemented. If KVM
-	 * explodes at runtime because your system does not abide by this
-	 * requirement, call your favourite HW vendor, they have screwed up.
-	 *
-	 * We don't expect hVHE to access any userspace mapping, so always
-	 * set PSTATE.PAN on enty. Same thing if we have PAN enabled on an
-	 * EL2 kernel. Only force it to 0 if we have not configured PAN in
-	 * the kernel (and you know this is really silly).
-	 */
-	if (cpus_have_cap(ARM64_KVM_HVHE) || IS_ENABLED(CONFIG_ARM64_PAN))
-		*updptr = cpu_to_le32(ENCODE_PSTATE(1, PAN));
-	else
-		*updptr = cpu_to_le32(ENCODE_PSTATE(0, PAN));
-}

-- 
Without deviation from the norm, progress is not possible.