All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
@ 2022-12-23 14:15 Igor Klochko
  2022-12-23 14:39 ` Christoph Hellwig
  0 siblings, 1 reply; 8+ messages in thread
From: Igor Klochko @ 2022-12-23 14:15 UTC (permalink / raw)
  To: hch; +Cc: iommu, robin.murphy, m.szyprowski


Hi, 

A small patch for __alloc_from_pool to clean the buffer before returning.
 
---
 arch/arm/mm/dma-mapping.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c135f6e37a00..bb2bb3ab497a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -366,6 +366,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
 
 		*ret_page = phys_to_page(phys);
 		ptr = (void *)val;
+		memset(ptr, 0, size);
 	}
 
 	return ptr;
-- 
2.39.0


Kind regards,
Igor Klochko

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
  2022-12-23 14:15 [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer Igor Klochko
@ 2022-12-23 14:39 ` Christoph Hellwig
  2022-12-23 22:51     ` Igor Klochko
  0 siblings, 1 reply; 8+ messages in thread
From: Christoph Hellwig @ 2022-12-23 14:39 UTC (permalink / raw)
  To: Igor Klochko; +Cc: hch, iommu, robin.murphy, m.szyprowski

On Fri, Dec 23, 2022 at 03:15:47PM +0100, Igor Klochko wrote:
> 
> Hi, 
> 
> A small patch for __alloc_from_pool to clean the buffer before returning.

This does look correct.  The "normal" allocators seems to do the
memset through __dma_clear_buffer, but the __alloc_from_pool seems to be
missing it.  Please write a proper changelog with a signoff, and
preferably a Fixes tag if you can find what introduced this.  Also
the ARM code needs to go to the ARM maintainer and arm mailing list.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
  2022-12-23 14:39 ` Christoph Hellwig
@ 2022-12-23 22:51     ` Igor Klochko
  0 siblings, 0 replies; 8+ messages in thread
From: Igor Klochko @ 2022-12-23 22:51 UTC (permalink / raw)
  To: Christoph Hellwig, linux
  Cc: iommu, robin.murphy, m.szyprowski, linux-arm-kernel

Thanks Christoph,

Added fixes and a changelog.
This issue is present in all current LTS versions.

----
Buffers allocated by __alloc_from_pool() should be zeroed out as done by other allocators.
Certain drivers expect a clean buffer and clearing the buffer is beneficial from the security point of view.
---
Fixes: 36d0fd2198da3 (*arm: use genalloc for the atomic pool*)
Signed-off-by: Igor Klochko <igor.klochko@gmail.com>
---
 arch/arm/mm/dma-mapping.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c135f6e37a00..bb2bb3ab497a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -366,6 +366,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
 
 		*ret_page = phys_to_page(phys);
 		ptr = (void *)val;
+		memset(ptr, 0, size);
 	}
 
 	return ptr;
-- 
2.39.0




Kind regards,
Igor Klochko




On 23/12/2022 15:39, Christoph Hellwig wrote:
> On Fri, Dec 23, 2022 at 03:15:47PM +0100, Igor Klochko wrote:
>>
>> Hi, 
>>
>> A small patch for __alloc_from_pool to clean the buffer before returning.
> 
> This does look correct.  The "normal" allocators seems to do the
> memset through __dma_clear_buffer, but the __alloc_from_pool seems to be
> missing it.  Please write a proper changelog with a signoff, and
> preferably a Fixes tag if you can find what introduced this.  Also
> the ARM code needs to go to the ARM maintainer and arm mailing list.

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
@ 2022-12-23 22:51     ` Igor Klochko
  0 siblings, 0 replies; 8+ messages in thread
From: Igor Klochko @ 2022-12-23 22:51 UTC (permalink / raw)
  To: Christoph Hellwig, linux
  Cc: iommu, robin.murphy, m.szyprowski, linux-arm-kernel

Thanks Christoph,

Added fixes and a changelog.
This issue is present in all current LTS versions.

----
Buffers allocated by __alloc_from_pool() should be zeroed out as done by other allocators.
Certain drivers expect a clean buffer and clearing the buffer is beneficial from the security point of view.
---
Fixes: 36d0fd2198da3 (*arm: use genalloc for the atomic pool*)
Signed-off-by: Igor Klochko <igor.klochko@gmail.com>
---
 arch/arm/mm/dma-mapping.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c135f6e37a00..bb2bb3ab497a 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -366,6 +366,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
 
 		*ret_page = phys_to_page(phys);
 		ptr = (void *)val;
+		memset(ptr, 0, size);
 	}
 
 	return ptr;
-- 
2.39.0




Kind regards,
Igor Klochko




On 23/12/2022 15:39, Christoph Hellwig wrote:
> On Fri, Dec 23, 2022 at 03:15:47PM +0100, Igor Klochko wrote:
>>
>> Hi, 
>>
>> A small patch for __alloc_from_pool to clean the buffer before returning.
> 
> This does look correct.  The "normal" allocators seems to do the
> memset through __dma_clear_buffer, but the __alloc_from_pool seems to be
> missing it.  Please write a proper changelog with a signoff, and
> preferably a Fixes tag if you can find what introduced this.  Also
> the ARM code needs to go to the ARM maintainer and arm mailing list.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
  2022-12-23 22:51     ` Igor Klochko
@ 2023-01-03  9:51       ` Russell King (Oracle)
  -1 siblings, 0 replies; 8+ messages in thread
From: Russell King (Oracle) @ 2023-01-03  9:51 UTC (permalink / raw)
  To: Igor Klochko
  Cc: Christoph Hellwig, iommu, robin.murphy, m.szyprowski, linux-arm-kernel

On Fri, Dec 23, 2022 at 11:51:43PM +0100, Igor Klochko wrote:
> Thanks Christoph,
> 
> Added fixes and a changelog.
> This issue is present in all current LTS versions.
> 
> ----
> Buffers allocated by __alloc_from_pool() should be zeroed out as done by other allocators.
> Certain drivers expect a clean buffer and clearing the buffer is beneficial from the security point of view.
> ---
> Fixes: 36d0fd2198da3 (*arm: use genalloc for the atomic pool*)
> Signed-off-by: Igor Klochko <igor.klochko@gmail.com>
> ---
>  arch/arm/mm/dma-mapping.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index c135f6e37a00..bb2bb3ab497a 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -366,6 +366,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
>  
>  		*ret_page = phys_to_page(phys);
>  		ptr = (void *)val;
> +		memset(ptr, 0, size);

I'm not up to speed with the current structure of the DMA implementation
on ARM, but isn't this going to make cache lines dirty for the returned
buffer, which will corrupt DMA on non-coherent devices?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
@ 2023-01-03  9:51       ` Russell King (Oracle)
  0 siblings, 0 replies; 8+ messages in thread
From: Russell King (Oracle) @ 2023-01-03  9:51 UTC (permalink / raw)
  To: Igor Klochko
  Cc: Christoph Hellwig, iommu, robin.murphy, m.szyprowski, linux-arm-kernel

On Fri, Dec 23, 2022 at 11:51:43PM +0100, Igor Klochko wrote:
> Thanks Christoph,
> 
> Added fixes and a changelog.
> This issue is present in all current LTS versions.
> 
> ----
> Buffers allocated by __alloc_from_pool() should be zeroed out as done by other allocators.
> Certain drivers expect a clean buffer and clearing the buffer is beneficial from the security point of view.
> ---
> Fixes: 36d0fd2198da3 (*arm: use genalloc for the atomic pool*)
> Signed-off-by: Igor Klochko <igor.klochko@gmail.com>
> ---
>  arch/arm/mm/dma-mapping.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> index c135f6e37a00..bb2bb3ab497a 100644
> --- a/arch/arm/mm/dma-mapping.c
> +++ b/arch/arm/mm/dma-mapping.c
> @@ -366,6 +366,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
>  
>  		*ret_page = phys_to_page(phys);
>  		ptr = (void *)val;
> +		memset(ptr, 0, size);

I'm not up to speed with the current structure of the DMA implementation
on ARM, but isn't this going to make cache lines dirty for the returned
buffer, which will corrupt DMA on non-coherent devices?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
  2023-01-03  9:51       ` Russell King (Oracle)
@ 2023-01-03 13:58         ` Robin Murphy
  -1 siblings, 0 replies; 8+ messages in thread
From: Robin Murphy @ 2023-01-03 13:58 UTC (permalink / raw)
  To: Russell King (Oracle), Igor Klochko
  Cc: Christoph Hellwig, iommu, m.szyprowski, linux-arm-kernel

On 03/01/2023 9:51 am, Russell King (Oracle) wrote:
> On Fri, Dec 23, 2022 at 11:51:43PM +0100, Igor Klochko wrote:
>> Thanks Christoph,
>>
>> Added fixes and a changelog.
>> This issue is present in all current LTS versions.
>>
>> ----
>> Buffers allocated by __alloc_from_pool() should be zeroed out as done by other allocators.
>> Certain drivers expect a clean buffer and clearing the buffer is beneficial from the security point of view.
>> ---
>> Fixes: 36d0fd2198da3 (*arm: use genalloc for the atomic pool*)
>> Signed-off-by: Igor Klochko <igor.klochko@gmail.com>
>> ---
>>   arch/arm/mm/dma-mapping.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index c135f6e37a00..bb2bb3ab497a 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -366,6 +366,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
>>   
>>   		*ret_page = phys_to_page(phys);
>>   		ptr = (void *)val;
>> +		memset(ptr, 0, size);
> 
> I'm not up to speed with the current structure of the DMA implementation
> on ARM, but isn't this going to make cache lines dirty for the returned
> buffer, which will corrupt DMA on non-coherent devices?

The virtual address of the pool, and thus VAs within the pool as 
returned by gen_pool_alloc(), should be a non-cacheable remap set up by 
atomic_pool_init(), so it looks appropriate to me. In fact "ptr" here 
appears to be the final return value propagated all the way back out to 
the caller of dma_alloc_coherent(), so if that were dodgy then there 
would already be problems afoot.

Robin.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer
@ 2023-01-03 13:58         ` Robin Murphy
  0 siblings, 0 replies; 8+ messages in thread
From: Robin Murphy @ 2023-01-03 13:58 UTC (permalink / raw)
  To: Russell King (Oracle), Igor Klochko
  Cc: Christoph Hellwig, iommu, m.szyprowski, linux-arm-kernel

On 03/01/2023 9:51 am, Russell King (Oracle) wrote:
> On Fri, Dec 23, 2022 at 11:51:43PM +0100, Igor Klochko wrote:
>> Thanks Christoph,
>>
>> Added fixes and a changelog.
>> This issue is present in all current LTS versions.
>>
>> ----
>> Buffers allocated by __alloc_from_pool() should be zeroed out as done by other allocators.
>> Certain drivers expect a clean buffer and clearing the buffer is beneficial from the security point of view.
>> ---
>> Fixes: 36d0fd2198da3 (*arm: use genalloc for the atomic pool*)
>> Signed-off-by: Igor Klochko <igor.klochko@gmail.com>
>> ---
>>   arch/arm/mm/dma-mapping.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
>> index c135f6e37a00..bb2bb3ab497a 100644
>> --- a/arch/arm/mm/dma-mapping.c
>> +++ b/arch/arm/mm/dma-mapping.c
>> @@ -366,6 +366,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
>>   
>>   		*ret_page = phys_to_page(phys);
>>   		ptr = (void *)val;
>> +		memset(ptr, 0, size);
> 
> I'm not up to speed with the current structure of the DMA implementation
> on ARM, but isn't this going to make cache lines dirty for the returned
> buffer, which will corrupt DMA on non-coherent devices?

The virtual address of the pool, and thus VAs within the pool as 
returned by gen_pool_alloc(), should be a non-cacheable remap set up by 
atomic_pool_init(), so it looks appropriate to me. In fact "ptr" here 
appears to be the final return value propagated all the way back out to 
the caller of dma_alloc_coherent(), so if that were dodgy then there 
would already be problems afoot.

Robin.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2023-01-03 16:54 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-12-23 14:15 [PATCH] arch/arm/mm/dma-mapping.c: fix __alloc_from_pool returning a dirty buffer Igor Klochko
2022-12-23 14:39 ` Christoph Hellwig
2022-12-23 22:51   ` Igor Klochko
2022-12-23 22:51     ` Igor Klochko
2023-01-03  9:51     ` Russell King (Oracle)
2023-01-03  9:51       ` Russell King (Oracle)
2023-01-03 13:58       ` Robin Murphy
2023-01-03 13:58         ` Robin Murphy

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.