linux-kernel - Re: [PATCH 6.6 000/122] 6.6.28-rc1 review

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: <86r0f1r5i1.wl-maz@kernel.org>
Date: Fri, 19 Apr 2024 11:50:14 +0100
From: Marc Zyngier <maz@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Naresh Kamboju <naresh.kamboju@...aro.org>,
	Mark Brown <broonie@...nel.org>,
	stable@...r.kernel.org,
	patches@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org,
	akpm@...ux-foundation.org,
	linux@...ck-us.net,
	shuah@...nel.org,
	patches@...nelci.org,
	lkft-triage@...ts.linaro.org,
	pavel@...x.de,
	jonathanh@...dia.com,
	f.fainelli@...il.com,
	sudipm.mukherjee@...il.com,
	srw@...dewatkins.net,
	rwarsow@....de,
	conor@...nel.org,
	allen.lkml@...il.com,
	Yihuang Yu <yihyu@...hat.com>,
	Gavin Shan <gshan@...hat.com>,
	Ryan Roberts <ryan.roberts@....com>,
	Anshuman Khandual <anshuman.khandual@....com>,
	Shaoqin Huang <shahuang@...hat.com>,
	Will Deacon <will@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	Anders Roxell <anders.roxell@...aro.org>
Subject: Re: [PATCH 6.6 000/122] 6.6.28-rc1 review

On Fri, 19 Apr 2024 11:40:33 +0100,
Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
> On Thu, Apr 18, 2024 at 12:21:17PM +0100, Catalin Marinas wrote:
> > On Thu, Apr 18, 2024 at 12:07:35PM +0100, Marc Zyngier wrote:
> > > On Tue, 16 Apr 2024 18:28:10 +0100,
> > > Catalin Marinas <catalin.marinas@....com> wrote:
> > > > On Tue, Apr 16, 2024 at 02:22:07PM +0100, Marc Zyngier wrote:
> > > > > On Tue, 16 Apr 2024 14:07:30 +0100,
> > > > > Naresh Kamboju <naresh.kamboju@...aro.org> wrote:
> > > > > > On Tue, 16 Apr 2024 at 16:04, Mark Brown <broonie@...nel.org> wrote:
> > > > > > > On Mon, Apr 15, 2024 at 04:19:25PM +0200, Greg Kroah-Hartman wrote:
> > > > > > > > This is the start of the stable review cycle for the 6.6.28 release.
> > > > > > > > There are 122 patches in this series, all will be posted as a response
> > > > > > > > to this one.  If anyone has any issues with these being applied, please
> > > > > > > > let me know.
> > > > > > >
> > > > > > > The bisect of the boot issue that's affecting the FVP in v6.6 (only)
> > > > > > > landed on c9ad150ed8dd988 (arm64: tlb: Fix TLBI RANGE operand),
> > > > > > > e3ba51ab24fdd in mainline, as being the first bad commit - it's also in
> > > > > > > the -rc for v6.8 but that seems fine.  I've done no investigation beyond
> > > > > > > the bisect and looking at the commit log to pull out people to CC and
> > > > > > > note that the fix was explicitly targeted at v6.6.
> > > > > > 
> > > > > > Anders investigated this reported issues and bisected and also found
> > > > > > the missing commit for stable-rc 6.6 is
> > > > > > e2768b798a19 ("arm64/mm: Modify range-based tlbi to decrement scale")
> > > > > 
> > > > > Which is definitely *not* stable candidate. We need to understand why
> > > > > the invalidation goes south when the scale go up instead of down.
> > > > 
> > > > If you backport e3ba51ab24fd ("arm64: tlb: Fix TLBI RANGE operand")
> > > > which fixes 117940aa6e5f ("KVM: arm64: Define
> > > > kvm_tlb_flush_vmid_range()") but without the newer e2768b798a19
> > > > ("arm64/mm: Modify range-based tlbi to decrement scale"), it looks like
> > > > "scale" in __flush_tlb_range_op() goes out of range to 4. Tested on my
> > > > CBMC model, not on the actual kernel. It may be worth adding some
> > > > WARN_ONs in __flush_tlb_range_op() if scale is outside the 0..3 range or
> > > > num greater than 31.
> > > > 
> > > > I haven't investigated properly (and I'm off tomorrow, back on Thu) but
> > > > it's likely the original code was not very friendly to the maximum
> > > > range, never tested. Anyway, if one figures out why it goes out of
> > > > range, I think the solution is to also backport e2768b798a19 to stable.
> > > 
> > > I looked into this, and I came to the conclusion that this patch is
> > > pretty much incompatible with the increasing scale (even if you cap
> > > num to 30).
> > 
> > Thanks Marc for digging into this.
> > 
> > > So despite my earlier comment, it looks like picking e2768b798a19 is
> > > the right thing to do *if* we're taking e3ba51ab24fd into 6.6-stable.
> > > 
> > > Otherwise, we need a separate fix, which Ryan initially advocating for
> > > initially.
> > 
> > My preference would be to cherry-pick the two upstream commits than
> > coming up with an alternative fix for 6.6.
> 
> To be specific, which 2 commits, and what order?

That'd be:

e2768b798a19 ("arm64/mm: Modify range-based tlbi to decrement scale")

followed by:

e3ba51ab24fd ("arm64: tlb: Fix TLBI RANGE operand")

Thanks,

	M.

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