linux-kernel - Re: [PATCH] fsl_pamu: Use 40-bits for addressing where appropriate

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: <20250422234305.GE1213339@ziepe.ca>
Date: Tue, 22 Apr 2025 20:43:05 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: iommu@...ts.linux.dev, Joerg Roedel <joro@...tes.org>,
	Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
	linux-kernel@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH] fsl_pamu: Use 40-bits for addressing where appropriate

On Tue, Apr 22, 2025 at 06:21:32PM -0400, Ben Collins wrote:
> On Tue, Apr 22, 2025 at 04:09:21PM -0500, Jason Gunthorpe wrote:
> > On Mon, Apr 21, 2025 at 10:46:19PM -0400, Ben Collins wrote:
> > > diff --git a/drivers/iommu/fsl_pamu_domain.c b/drivers/iommu/fsl_pamu_domain.c
> > > index 30be786bff11e..a4bc6482a00f7 100644
> > > --- a/drivers/iommu/fsl_pamu_domain.c
> > > +++ b/drivers/iommu/fsl_pamu_domain.c
> > > @@ -214,9 +214,10 @@ static struct iommu_domain *fsl_pamu_domain_alloc(unsigned type)
> > >  	INIT_LIST_HEAD(&dma_domain->devices);
> > >  	spin_lock_init(&dma_domain->domain_lock);
> > >  
> > > -	/* default geometry 64 GB i.e. maximum system address */
> > > +	/* Set default geometry based on physical address limit. */
> > >  	dma_domain->iommu_domain. geometry.aperture_start = 0;
> > > -	dma_domain->iommu_domain.geometry.aperture_end = (1ULL << 36) - 1;
> > > +	dma_domain->iommu_domain.geometry.aperture_end =
> > > +		(1ULL << PAMU_MAX_PHYS_BITS) - 1;
> > >  	dma_domain->iommu_domain.geometry.force_aperture = true;
> > 
> > What on earth does this even do? There is no map_range() callback in
> > this driver, so nothing should be reading geometry..
> 
> I dunno, but your "FIXME this is broken" comments are all over it from a
> year and a half ago:

Yes, I know, but you are changing this - are you changing it because
something is broken without making this change, if so what, or are you
changing it because it looked like it needed changing?

> The logic hasn't really been touched in 10 years.

Yeah, so I'm surprised someone still cares about it :)

Jason