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] [day] [month] [year] [list]
Message-ID: <aUWxLp2GUk2_p58e@kernel.org>
Date: Fri, 19 Dec 2025 12:10:22 -0800
From: Oliver Upton <oupton@...nel.org>
To: Ben Horgan <ben.horgan@....com>
Cc: amitsinght@...vell.com, baisheng.gao@...soc.com,
	baolin.wang@...ux.alibaba.com, carl@...amperecomputing.com,
	dave.martin@....com, david@...nel.org, dfustini@...libre.com,
	fenghuay@...dia.com, gshan@...hat.com, james.morse@....com,
	jonathan.cameron@...wei.com, kobak@...dia.com, lcherian@...vell.com,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	peternewman@...gle.com, punit.agrawal@....qualcomm.com,
	quic_jiles@...cinc.com, reinette.chatre@...el.com,
	rohit.mathew@....com, scott@...amperecomputing.com,
	sdonthineni@...dia.com, tan.shaopeng@...itsu.com,
	xhao@...ux.alibaba.com, catalin.marinas@....com, will@...nel.org,
	corbet@....net, maz@...nel.org, joey.gouly@....com,
	suzuki.poulose@....com, kvmarm@...ts.linux.dev
Subject: Re: [PATCH v2 13/45] KVM: arm64: Force guest EL1 to use user-space's
 partid configuration

On Fri, Dec 19, 2025 at 06:11:15PM +0000, Ben Horgan wrote:
> From: James Morse <james.morse@....com>
> 
> While we trap the guest's attempts to read/write the MPAM control
> registers, the hardware continues to use them. Guest-EL0 uses KVM's
> user-space's configuration, as the value is left in the register, and
> guest-EL1 uses either the host kernel's configuration, or in the case of
> VHE, the UNKNOWN reset value of MPAM1_EL1.
> 
> We want to force the guest-EL1 to use KVM's user-space's MPAM
> configuration. On nVHE rely on MPAM0_EL1 and MPAM1_EL1 always being
> programmed the same and on VHE copy MPAM0_EL1 into the guest's
> MPAM1_EL1. There is no need to restore as this is out of context once TGE
> is set.
> 
> Signed-off-by: James Morse <james.morse@....com>
> Signed-off-by: Ben Horgan <ben.horgan@....com>
> ---
> Changes since rfc:
> Drop the unneeded __mpam_guest_load() in nvhre and the MPAM1_EL1 save restore
> Defer EL2 handling until next patch
> ---
>  arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm64/kvm/hyp/vhe/sysreg-sr.c b/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> index f28c6cf4fe1b..a2e8f6187675 100644
> --- a/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> +++ b/arch/arm64/kvm/hyp/vhe/sysreg-sr.c
> @@ -183,6 +183,16 @@ void sysreg_restore_guest_state_vhe(struct kvm_cpu_context *ctxt)
>  }
>  NOKPROBE_SYMBOL(sysreg_restore_guest_state_vhe);
>  
> +/*
> + * The _EL0 value was written by the host's context switch and belongs to the
> + * VMM. Copy this into the guest's _EL1 register.
> + */
> +static inline void __mpam_guest_load(void)
> +{
> +	if (system_supports_mpam())
> +		write_sysreg_el1(read_sysreg_s(SYS_MPAM0_EL1), SYS_MPAM1);

nit: I'd prefer using a mask to extract the fields of interest, guarding
against future architecture doing something silly with the RES0 fields
of these registers.

Thanks,
Oliver

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ