linux-kernel - Re: next-20250702 WARNING iommu io-pgtable-arm.c at arm_lpae_map_pages qcom_iommu

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: <20250709172216.GH1599700@nvidia.com>
Date: Wed, 9 Jul 2025 14:22:16 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Naresh Kamboju <naresh.kamboju@...aro.org>,
	open list <linux-kernel@...r.kernel.org>, iommu@...ts.linux.dev,
	lkft-triage@...ts.linaro.org,
	Linux Regressions <regressions@...ts.linux.dev>,
	Nicolin Chen <nicolinc@...dia.com>,
	Jean-Philippe Brucker <jean-philippe@...aro.org>,
	Anders Roxell <anders.roxell@...aro.org>,
	Benjamin Copeland <benjamin.copeland@...aro.org>,
	Dan Carpenter <dan.carpenter@...aro.org>
Subject: Re: next-20250702 WARNING iommu io-pgtable-arm.c at
 arm_lpae_map_pages qcom_iommu_map

On Wed, Jul 09, 2025 at 06:50:02PM +0200, Arnd Bergmann wrote:
> On Wed, Jul 9, 2025, at 18:26, Jason Gunthorpe wrote:
> > On Wed, Jul 09, 2025 at 04:14:26PM +0530, Naresh Kamboju wrote:
> >
> > I believe the original text was a copy and pasto from an ARMv7s driver
> > (ie the 32 bit ARM page table) which uses that unique combination of
> > sizes. It is not a sane bitmap for HW with 64 bit page table support,
> > there is never a 1M option for instance.
> >
> > So this removes 64k page support, which maybe didn't even work?
> 
> My guess would be that this bug is specific to this SoC running
> in 32-bit mode.

Sorry, it was unclear.

This driver always uses the ARM page table format with 64 bit
entries. It uses the ARM_32_LPAE_S1 sub-flavour of it.

This is different from the ARM page table format with 32 bit entries
called ARM_V7S. Only this format uses the 'SZ_4K | SZ_64K | SZ_1M |
SZ_16M' bitmap.

Looking more closely when a driver selects ARM_32_LPAE_S1 it
calls arm_32_lpae_alloc_pgtable_s1() which does:

	cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);

So the 1 line patch looks OKish (maybe drop the SZ_2M to be
conservative), despite putting it in the bitmap 64K would have never
be used in the iommu no matter what the CPU is doing.

Jason