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

[Will Deacon <will@kernel.org>]

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