linux-kernel - Re: remove the ->mapping_error method from dma_map

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: <20181123104918.GE1586@8bytes.org>
Date:   Fri, 23 Nov 2018 11:49:18 +0100
From:   Joerg Roedel <joro@...tes.org>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux@...linux.org.uk, Christoph Hellwig <hch@....de>,
        linux-arch@...r.kernel.org, linux-alpha@...r.kernel.org,
        linux-ia64@...r.kernel.org, linux-parisc@...r.kernel.org,
        David Woodhouse <dwmw2@...radead.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        iommu@...ts.linux-foundation.org, jdmason@...zu.us,
        xen-devel@...ts.xenproject.org,
        linux-arm-kernel@...ts.infradead.org, m.szyprowski@...sung.com
Subject: Re: remove the ->mapping_error method from dma_map_ops V2

On Thu, Nov 22, 2018 at 05:52:15PM +0000, Robin Murphy wrote:
> Unfortunately, with things like the top-down IOVA allocator, and 32-bit
> systems in general, "the top 4095" values may well still be valid addresses
> - we're relying on a 1-byte mapping of the very top byte of memory/IOVA
> space being sufficiently ridiculous that no real code would ever do that,
> but even a 4-byte mapping of the top 4 bytes is within the realms of the
> plausible (I've definitely seen the USB layer make 8-byte mappings from any
> old offset within a page, for example).

But we can easily work around that by reserving the top 4k of the first
4GB of IOVA address space in the allocator, no? Then these values are
never returned as valid DMA handles.


Regards,

	Joerg