linux-kernel - Re: IOVA address range

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: <3fc50cc1-e4b1-49f9-a0f3-cc527d942e00@arm.com>
Date:   Tue, 31 Oct 2023 11:46:47 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Bjorn Helgaas <helgaas@...nel.org>,
        Eric Pilmore <epilmore@...aio.com>
Cc:     linux-pci@...r.kernel.org, dmaengine@...r.kernel.org,
        Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
        iommu@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: IOVA address range

On 2023-10-30 6:19 pm, Bjorn Helgaas wrote:
> [+cc folks from ./scripts/get_maintainer.pl -f drivers/iommu]
> 
> On Fri, Oct 27, 2023 at 12:17:17PM -0700, Eric Pilmore wrote:
>> Need a little IOVA/IOMMU help.
>>
>> Is it correct that the IOVA address range for a device goes from
>> address 0x0 up to the dma-mask of the respective device?
>>
>> Is it correct to assume that the base of the IOVA address space for a
>> device will always be zero (0x0)? Is there any reason to think that
>> this has changed in some newer iteration of the kernel, perhaps 5.10,
>> and that the base could be non-zero?
>>
>> I realize an IOVA itself can be non-zero. I'm trying to verify what
>> the base address is of the IOVA space as a whole on a per device
>> basis.

In short, "No."

In detail, it depends on the architecture, since there are still a 
number of different IOMMU-based DMA API backends. Off-hand I do know 
that 32-bit Arm allocates upwards from 0, since there are some drivers 
annoyingly relying on that behaviour. I've never looked too closely at 
what the likes of Alpha, Sparc and PowerPC do. The generic IOVA 
allocator used by iommu-dma on x86, arm64, and soon s390, allocates 
top-down, but for historical reasons has a special behaviour for PCI 
devices where it tries to stay below the 32-bit boundary and only goes 
up to the full DMA mask (if larger) once that space is full. iommu-dma 
also always reserves 0 as an invalid IOVA - initially this was more of a 
convenience measure to help catch certain potential bugs, but it's long 
since also been relied upon as a special value in the internal caching 
mechanism. Note also that any device may have holes reserved anywhere in 
its otherwise-usable address space, and/or its entire notion of usable 
ranges constrained as described by firmware (e.g. a devicetree 
"dma-ranges" property or ACPI "_DMA" method).

Thanks,
Robin.