linux-kernel - Re: [v3 PATCH] iommu/arm-smmu-v3: Fix L1 stream table index calculation for 32-bit sid size

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: <20241008174119.GA11091@willie-the-truck>
Date: Tue, 8 Oct 2024 18:41:20 +0100
From: Will Deacon <will@...nel.org>
To: Yang Shi <yang@...amperecomputing.com>
Cc: Jason Gunthorpe <jgg@...pe.ca>, nicolinc@...dia.com,
	james.morse@....com, robin.murphy@....com,
	linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [v3 PATCH] iommu/arm-smmu-v3: Fix L1 stream table index
 calculation for 32-bit sid size

On Tue, Oct 08, 2024 at 10:04:50AM -0700, Yang Shi wrote:
> On 10/8/24 8:15 AM, Jason Gunthorpe wrote:
> > On Tue, Oct 08, 2024 at 02:34:58PM +0100, Will Deacon wrote:
> > 
> > > This all looks a bit messy to me. The architecture guarantees that
> > > 2-level stream tables are supported once we hit 7-bit SIDs and, although
> > > the driver relaxes this to > 8-bit SIDs, we'll never run into overflow
> > > problems in the linear table code above.
> > My original point was about the confidential compute position (sigh)
> > that the untrusted hypverisor should not corrupt the driver.
> > 
> > So your statement is architecturally true, but we never check that
> > IDR0_ST_LVL_2LVL is set if IDR1_SIDSIZE > 2**7, and so we can get into
> > this situation where the hypervisor could trigger some kind of bad
> > behavior.
> 
> Jason's concern seems valid to me IMHO. But if the simpler version is
> preferred, I'd suggest add some comments at least or the check suggested by
> Jason to make the architecture guarantee more clear. Just in case someone
> else won't repeat what we had done just because they see "1ULL" in 2lvl code
> but not in linear code.

In principle, I'm not opposed to hardening the driver against malicious
virtual hardware, but I don't think we need to add comments everywhere
where we're relying on architectural behaviour. The hardening should
also be done separately from fixing a bug affecting users with real
hardware.

Will