linux-kernel - Re: Question about reserved

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] [day] [month] [year] [list]

Message-ID: <d35d86c2-76ae-98e9-5c27-c0284c52e15b@arm.com>
Date:   Wed, 21 Jun 2023 12:30:42 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Alexander Duyck <alexander.duyck@...il.com>,
        Jason Gunthorpe <jgg@...dia.com>
Cc:     "Tian, Kevin" <kevin.tian@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>,
        Baolu Lu <baolu.lu@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-pci <linux-pci@...r.kernel.org>,
        "iommu@...ts.linux.dev" <iommu@...ts.linux.dev>
Subject: Re: Question about reserved_regions w/ Intel IOMMU

On 2023-06-20 18:47, Alexander Duyck wrote:
> On Tue, Jun 20, 2023 at 9:55 AM Jason Gunthorpe <jgg@...dia.com> wrote:
>>
>> On Tue, Jun 20, 2023 at 07:57:57AM -0700, Alexander Duyck wrote:
>>
>>> I think this may have gone off down a rathole as my original question
>>> wasn't anything about adding extra reserved regions. It was about
>>> exposing what the IOVA is already reserving so it could be user
>>> visible.
>>
>> Your question points out that dma-iommu.c uses a different set of
>> reserved regions than everything else, and its set is closer to
>> functionally correct.
>>
>> IMHO the resolution to what you are talking about is not to add more
>> debugging to dma-iommu but to make the set of reserved regions
>> consistently correct for everyone, which will make them viewable in
>> sysfs.
> 
> Okay, that makes sense to me, and I agree. If we had a consistent set
> of reserved regions then it would make it easier to understand.

It would also be wrong, unfortunately, because it's conflating multiple 
different things (there are overlapping notions of "reserve" at play 
here...). IOMMU API reserved regions are specific things that the IOMMU 
driver knows are special and all IOMMU domain users definitely need to 
be aware of. iommu-dma is merely one of those users; it is another layer 
on top of the API which manages its own IOVA space how it sees fit, just 
like VFIO or other IOMMU-aware drivers. It honours those reserved 
regions (via iommu_group_create_direct_mappings()), but it also carves 
out plenty of IOVA space which is probably perfectly usable - some of 
which is related to possible upstream bus constraints, to save the 
hassle of checking; some purely for its own convenience, like the page 
at IOVA 0 - but it still *doesn't* carve out more IOVA regions which are 
also unusable overall due to other upstream bus or endpoint constraints, 
since those are handled dynamically in its allocator instead (dma_mask, 
bus_dma_limit etc.)

> If
> nothing else my request would be to expose the iova reserved regions
> and then most likely the other ones could be deprecated since they
> seem to all be consolidated in the IOVA anyway.

FWIW there's no upstream provision for debugging iommu-dma from 
userspace since it's not something that anyone other than me has ever 
had any apparent need to do, and you can get an idea of how long it's 
been since even I thought about that from when I seem to have given up 
rebasing my local patches for it[1] :)

Thanks,
Robin.

[1] https://gitlab.arm.com/linux-arm/linux-rm/-/commits/iommu/misc/