linux-kernel - Re: [RFC][PATCH] dma-mapping: align default segment_boundary_mask with dma

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]

Date:   Mon, 16 Mar 2020 13:46:52 +0100
From:   Christoph Hellwig <hch@....de>
To:     Robin Murphy <robin.murphy@....com>
Cc:     Nicolin Chen <nicoleotsuka@...il.com>, m.szyprowski@...sung.com,
        hch@....de, linux-kernel@...r.kernel.org,
        iommu@...ts.linux-foundation.org
Subject: Re: [RFC][PATCH] dma-mapping: align default segment_boundary_mask
 with dma_mask

On Mon, Mar 16, 2020 at 12:12:08PM +0000, Robin Murphy wrote:
> On 2020-03-14 12:00 am, Nicolin Chen wrote:
>> More and more drivers set dma_masks above DMA_BIT_MAKS(32) while
>> only a handful of drivers call dma_set_seg_boundary(). This means
>> that most drivers have a 4GB segmention boundary because DMA API
>> returns DMA_BIT_MAKS(32) as a default value, though they might be
>> able to handle things above 32-bit.
>
> Don't assume the boundary mask and the DMA mask are related. There do exist 
> devices which can DMA to a 64-bit address space in general, but due to 
> descriptor formats/hardware design/whatever still require any single 
> transfer not to cross some smaller boundary. XHCI is 64-bit yet requires 
> most things not to cross a 64KB boundary. EHCI's 64-bit mode is an example 
> of the 4GB boundary (not the best example, admittedly, but it undeniably 
> exists).

Yes, which is what the boundary is for.  But why would we default to
something restrictive by default even if the driver didn't ask for it?