linux-kernel - Re: [PATCH V18 2/9] KVM: arm64: Explicitly handle BRBE traps as UNDEFINED

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]

Date: Mon, 17 Jun 2024 08:41:06 +0100
From: Marc Zyngier <maz@...nel.org>
To: Anshuman Khandual <anshuman.khandual@....com>
Cc: linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	will@...nel.org,
	catalin.marinas@....com,
	mark.rutland@....com,
	Mark Brown <broonie@...nel.org>,
	James Clark <james.clark@....com>,
	Rob Herring <robh@...nel.org>,
	Suzuki Poulose <suzuki.poulose@....com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	linux-perf-users@...r.kernel.org,
	Oliver Upton <oliver.upton@...ux.dev>,
	James Morse <james.morse@....com>,
	kvmarm@...ts.linux.dev
Subject: Re: [PATCH V18 2/9] KVM: arm64: Explicitly handle BRBE traps as UNDEFINED

On Mon, 17 Jun 2024 07:27:13 +0100,
Anshuman Khandual <anshuman.khandual@....com> wrote:
> On 6/14/24 18:39, Marc Zyngier wrote:
> > On Fri, 14 Jun 2024 13:33:37 +0100,
> >
> > Actually, to disable the *instructions*, a similar hack must be
> > applied to HFGITR_EL2. The resulting patch should be something like:
> > 
> > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > index ee33f5467ce5..49d86dae8d80 100644
> > --- a/arch/arm64/kvm/sys_regs.c
> > +++ b/arch/arm64/kvm/sys_regs.c
> > @@ -4964,6 +4964,15 @@ void kvm_init_sysreg(struct kvm_vcpu *vcpu)
> >  		kvm->arch.fgu[HAFGRTR_GROUP] |= ~(HAFGRTR_EL2_RES0 |
> >  						  HAFGRTR_EL2_RES1);
> >  
> > +	if (!kvm_has_feat(kvm, ID_AA64DFR0_EL1, BRBE, IMP)) {
> > +		kvm->arch.fgu[HDFGRTR_GROUP] |= (HDFGRTR_nBRBDATA  |
> > +						 HDFGRTR_nBRBCTL   |
> > +						 HDFGRTR_nBRBIDR);

Obviously, this needs to be spelled HDFGRTR_EL2_nBRB* so that it
actually compiles.

> > +		kvm->arch.fgu[HFGITR_GROUP] |= (HFGITR_EL2_nBRBINJ |
> > +						HFGITR_EL2_nBRBIALL);
> > +	}
> > +
> > +
> >  	set_bit(KVM_ARCH_FLAG_FGU_INITIALIZED, &kvm->arch.flags);
> >  out:
> >  	mutex_unlock(&kvm->arch.config_lock);
> 
> This makes sense, will remove all the changes to sys_reg table and
> instead fold the above suggestion into the patch.
> 
> > 
> > The implicit dependency here is that FGT is always present on a system
> > that implements BRBE. The architecture supports this assertion:
> > 
> > - BRBE is not available before ARMv9.1
> > - FGT is mandatory from ARMv8.6
> > 
> > Given that v9.1 is congruent to v8.6, we have the required overlap.
> 
> So this overlap need not be asserted in software again ?

I don't think there's a need for that.

We went through the same thing with SME (which has the exact same
dependency), and concluded that there was no need to paper over broken
implementations at the moment (only QEMU was affected, and that was
quickly fixed). If we find an implementation in the wild that didn't
get the memo, we can add a workaround at that time.

	M.

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