linux-kernel - Re: [RFC/RFT][PATCH] dma-mapping: set default segment_boundary_mask to ULONG

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: <c984d2ea-6036-a8ae-97df-b5178a2a9ab9@arm.com>
Date:   Mon, 6 Apr 2020 14:48:13 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     Nicolin Chen <nicoleotsuka@...il.com>, m.szyprowski@...sung.com,
        hch@....de
Cc:     linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org
Subject: Re: [RFC/RFT][PATCH] dma-mapping: set default segment_boundary_mask
 to ULONG_MAX

On 2020-04-05 1:51 am, Nicolin Chen wrote:
> The default segment_boundary_mask was set to DMA_BIT_MAKS(32)
> a decade ago by referencing SCSI/block subsystem, as a 32-bit
> mask was good enough for most of the devices.
> 
> Now more and more drivers set dma_masks above DMA_BIT_MAKS(32)
> while only a handful of them call dma_set_seg_boundary(). This
> means that most drivers have a 4GB segmention boundary because
> DMA API returns a 32-bit default value, though they might not
> really have such a limit.
> 
> The default segment_boundary_mask should mean "no limit" since
> the device doesn't explicitly set the mask. But a 32-bit mask
> certainly limits those devices capable of 32+ bits addressing.
> 
> And this 32-bit boundary mask might result in a situation that
> when dma-iommu maps a DMA buffer (size > 4GB), iommu_map_sg()
> cuts the IOVA region into discontiguous pieces, and creates a
> faulty IOVA mapping that overlaps some physical memory outside
> the scatter list, which might lead to some random kernel panic
> after DMA overwrites that faulty IOVA space.

Once again, get rid of this paragraph - it doesn't have much to do with 
the *default* value since it describes a behaviour general to any 
boundary mask. Plus it effectively says "if a driver uses a DMA-mapped 
scatterlist incorrectly, this change can help paper over the bug", which 
is rather the opposite of a good justification.

(for example most SATA devices end up with a 64KB boundary mask, such 
that padding the IOVAs to provide the appropriate alignment happens very 
frequently, and they've been working just fine for years now)

Robin.

> So this patch sets default segment_boundary_mask to ULONG_MAX.
> 
> Signed-off-by: Nicolin Chen <nicoleotsuka@...il.com>
> ---
>   include/linux/dma-mapping.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 330ad58fbf4d..ff8cefe85f30 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -736,7 +736,7 @@ static inline unsigned long dma_get_seg_boundary(struct device *dev)
>   {
>   	if (dev->dma_parms && dev->dma_parms->segment_boundary_mask)
>   		return dev->dma_parms->segment_boundary_mask;
> -	return DMA_BIT_MASK(32);
> +	return ULONG_MAX;
>   }
>   
>   static inline int dma_set_seg_boundary(struct device *dev, unsigned long mask)
>