linux-kernel - Re: [PATCH v4] iommu: Optimise PCI SAC address trick

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: <b940e9f5-5770-73a4-d139-06af82fb482f@arm.com>
Date:   Wed, 24 May 2023 15:56:57 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Joerg Roedel <joro@...tes.org>
Cc:     will@...nel.org, iommu@...ts.linux.dev,
        linux-kernel@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jakub Kicinski <kuba@...nel.org>,
        John Garry <john.g.garry@...cle.com>
Subject: Re: [PATCH v4] iommu: Optimise PCI SAC address trick

On 23/05/2023 5:06 pm, Joerg Roedel wrote:
> On Fri, Apr 14, 2023 at 06:45:57PM +0100, Robin Murphy wrote:
>> Sounds good - I'm considerably more confident in this approach, but although
>> it should not be able to break any scenario which wasn't already broken, it
>> could potentially still make such a breakage more noticeable. Thus in all
>> honesty I'd feel happiest giving it a full cycle of -next coverage as well.
> 
> I had some second thoughts on this, wouldn't it be better to change the
> allocator to allocate from lowest addresses first? Then we can just
> remove the SAC trick and rely on dma-masks only.
> 
> Thoughts?

Yes, in the long term I definitely would like to have a more flexible 
allocator - this is more of a stop-gap measure that's an easy win with 
what we have now.

Top-down allocation is nice in that it makes for easily recognisable DMA 
addresses, and does do a great job of flushing out bugs, but having the 
option of bottom-up allocation would definitely be useful in various 
cases - realistically it's pretty much a prerequisite for converting 
arch/arm to use iommu-dma. However, given all the other scalability 
issues that keep coming to light, I think that's going to be the tipping 
point for ripping up the existing code and giving it a major overhaul, 
which I would love to be able to get stuck in to, but don't have the 
capacity for at the moment.

Thanks,
Robin.