All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-22 19:14 ` Dexuan Cui via iommu
  0 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui @ 2022-06-22 19:14 UTC (permalink / raw)
  To: hch, m.szyprowski, robin.murphy, iommu, linux-kernel
  Cc: linux-hyperv, mikelley, Andrea.Parri, Tianyu.Lan, Dexuan Cui

The third parameter of dma_set_encrypted() is a size in bytes rather than
the number of pages.

Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
 kernel/dma/direct.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index e978f36e6be8..8d0b68a17042 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -357,7 +357,7 @@ void dma_direct_free(struct device *dev, size_t size,
 	} else {
 		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
 			arch_dma_clear_uncached(cpu_addr, size);
-		if (dma_set_encrypted(dev, cpu_addr, 1 << page_order))
+		if (dma_set_encrypted(dev, cpu_addr, size))
 			return;
 	}
 
@@ -392,7 +392,6 @@ void dma_direct_free_pages(struct device *dev, size_t size,
 		struct page *page, dma_addr_t dma_addr,
 		enum dma_data_direction dir)
 {
-	unsigned int page_order = get_order(size);
 	void *vaddr = page_address(page);
 
 	/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
@@ -400,7 +399,7 @@ void dma_direct_free_pages(struct device *dev, size_t size,
 	    dma_free_from_pool(dev, vaddr, size))
 		return;
 
-	if (dma_set_encrypted(dev, vaddr, 1 << page_order))
+	if (dma_set_encrypted(dev, vaddr, size))
 		return;
 	__dma_direct_free_pages(dev, page, size);
 }
-- 
2.25.1


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

* [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-22 19:14 ` Dexuan Cui via iommu
  0 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui via iommu @ 2022-06-22 19:14 UTC (permalink / raw)
  To: hch, m.szyprowski, robin.murphy, iommu, linux-kernel
  Cc: Dexuan Cui, linux-hyperv, Tianyu.Lan, Andrea.Parri, mikelley

The third parameter of dma_set_encrypted() is a size in bytes rather than
the number of pages.

Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
Signed-off-by: Dexuan Cui <decui@microsoft.com>
---
 kernel/dma/direct.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index e978f36e6be8..8d0b68a17042 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -357,7 +357,7 @@ void dma_direct_free(struct device *dev, size_t size,
 	} else {
 		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
 			arch_dma_clear_uncached(cpu_addr, size);
-		if (dma_set_encrypted(dev, cpu_addr, 1 << page_order))
+		if (dma_set_encrypted(dev, cpu_addr, size))
 			return;
 	}
 
@@ -392,7 +392,6 @@ void dma_direct_free_pages(struct device *dev, size_t size,
 		struct page *page, dma_addr_t dma_addr,
 		enum dma_data_direction dir)
 {
-	unsigned int page_order = get_order(size);
 	void *vaddr = page_address(page);
 
 	/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
@@ -400,7 +399,7 @@ void dma_direct_free_pages(struct device *dev, size_t size,
 	    dma_free_from_pool(dev, vaddr, size))
 		return;
 
-	if (dma_set_encrypted(dev, vaddr, 1 << page_order))
+	if (dma_set_encrypted(dev, vaddr, size))
 		return;
 	__dma_direct_free_pages(dev, page, size);
 }
-- 
2.25.1

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
  2022-06-22 19:14 ` Dexuan Cui via iommu
@ 2022-06-23  5:43   ` Christoph Hellwig
  -1 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23  5:43 UTC (permalink / raw)
  To: Dexuan Cui
  Cc: hch, m.szyprowski, robin.murphy, iommu, linux-kernel,
	linux-hyperv, mikelley, Andrea.Parri, Tianyu.Lan

On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> The third parameter of dma_set_encrypted() is a size in bytes rather than
> the number of pages.
> 
> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>

see:

commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag: dma-mapping-5.19-2022-05-25)
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Fri May 20 18:10:13 2022 +0100

    dma-direct: don't over-decrypt memory

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

* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23  5:43   ` Christoph Hellwig
  0 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23  5:43 UTC (permalink / raw)
  To: Dexuan Cui
  Cc: linux-hyperv, Tianyu.Lan, Andrea.Parri, linux-kernel, mikelley,
	iommu, robin.murphy, hch

On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> The third parameter of dma_set_encrypted() is a size in bytes rather than
> the number of pages.
> 
> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted helpers")
> Signed-off-by: Dexuan Cui <decui@microsoft.com>

see:

commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag: dma-mapping-5.19-2022-05-25)
Author: Robin Murphy <robin.murphy@arm.com>
Date:   Fri May 20 18:10:13 2022 +0100

    dma-direct: don't over-decrypt memory
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

* RE: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
  2022-06-23  5:43   ` Christoph Hellwig
@ 2022-06-23  7:00     ` Dexuan Cui via iommu
  -1 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui @ 2022-06-23  7:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: m.szyprowski, robin.murphy, iommu, linux-kernel, linux-hyperv,
	Michael Kelley (LINUX),
	Andrea Parri, Tianyu Lan

> From: Christoph Hellwig <hch@lst.de>
> Sent: Wednesday, June 22, 2022 10:44 PM
> To: Dexuan Cui <decui@microsoft.com>
>  ...
> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> > The third parameter of dma_set_encrypted() is a size in bytes rather than
> > the number of pages.
> >
> > Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
> helpers")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> 
> see:
> 
> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
> dma-mapping-5.19-2022-05-25)
> Author: Robin Murphy <robin.murphy@arm.com>
> Date:   Fri May 20 18:10:13 2022 +0100
> 
>     dma-direct: don't over-decrypt memory

It looks like commit 4a37f3dd9a831 fixed a different issue?

Here my patch is for the latest mainline:

In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
  out_encrypt_pages:
	  if (dma_set_encrypted(dev, page_address(page), size))

However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
I think the ' 1 << page_order' is incorrect and it should be 'size' as well?

Thanks,
-- Dexuan


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

* RE: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23  7:00     ` Dexuan Cui via iommu
  0 siblings, 0 replies; 11+ messages in thread
From: Dexuan Cui via iommu @ 2022-06-23  7:00 UTC (permalink / raw)
  To: Christoph Hellwig
  Cc: linux-hyperv, Tianyu Lan, Andrea Parri, linux-kernel,
	Michael Kelley (LINUX),
	iommu, robin.murphy

> From: Christoph Hellwig <hch@lst.de>
> Sent: Wednesday, June 22, 2022 10:44 PM
> To: Dexuan Cui <decui@microsoft.com>
>  ...
> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
> > The third parameter of dma_set_encrypted() is a size in bytes rather than
> > the number of pages.
> >
> > Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
> helpers")
> > Signed-off-by: Dexuan Cui <decui@microsoft.com>
> 
> see:
> 
> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
> dma-mapping-5.19-2022-05-25)
> Author: Robin Murphy <robin.murphy@arm.com>
> Date:   Fri May 20 18:10:13 2022 +0100
> 
>     dma-direct: don't over-decrypt memory

It looks like commit 4a37f3dd9a831 fixed a different issue?

Here my patch is for the latest mainline:

In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
  out_encrypt_pages:
	  if (dma_set_encrypted(dev, page_address(page), size))

However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
I think the ' 1 << page_order' is incorrect and it should be 'size' as well?

Thanks,
-- Dexuan

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
  2022-06-23  7:00     ` Dexuan Cui via iommu
@ 2022-06-23  9:01       ` Robin Murphy
  -1 siblings, 0 replies; 11+ messages in thread
From: Robin Murphy @ 2022-06-23  9:01 UTC (permalink / raw)
  To: Dexuan Cui, Christoph Hellwig
  Cc: m.szyprowski, iommu, linux-kernel, linux-hyperv,
	Michael Kelley (LINUX),
	Andrea Parri, Tianyu Lan

On 2022-06-23 08:00, Dexuan Cui wrote:
>> From: Christoph Hellwig <hch@lst.de>
>> Sent: Wednesday, June 22, 2022 10:44 PM
>> To: Dexuan Cui <decui@microsoft.com>
>>   ...
>> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
>>> The third parameter of dma_set_encrypted() is a size in bytes rather than
>>> the number of pages.
>>>
>>> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
>> helpers")
>>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>>
>> see:
>>
>> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
>> dma-mapping-5.19-2022-05-25)
>> Author: Robin Murphy <robin.murphy@arm.com>
>> Date:   Fri May 20 18:10:13 2022 +0100
>>
>>      dma-direct: don't over-decrypt memory
> 
> It looks like commit 4a37f3dd9a831 fixed a different issue?
> 
> Here my patch is for the latest mainline:
> 
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
>    out_encrypt_pages:
> 	  if (dma_set_encrypted(dev, page_address(page), size))
> 
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?

I think technically you're both right - these instances clearly have a 
history tracing back to the original bug that my patch addressed, but 
the refactoring then made them into their own distinct bug in terms of 
the internal dma_set_encrypted() interface, per the commit message here. 
Apparently I failed to spot this when forward-porting 4a37f3dd9a831 from 
5.10 (as the commit message says, don't ask... ;) ) - I guess I was only 
looking at where the set_memory_*() callsites had moved to. For this patch,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

Thanks
Robin.

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

* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23  9:01       ` Robin Murphy
  0 siblings, 0 replies; 11+ messages in thread
From: Robin Murphy @ 2022-06-23  9:01 UTC (permalink / raw)
  To: Dexuan Cui, Christoph Hellwig
  Cc: linux-hyperv, Tianyu Lan, Andrea Parri, linux-kernel,
	Michael Kelley (LINUX),
	iommu

On 2022-06-23 08:00, Dexuan Cui wrote:
>> From: Christoph Hellwig <hch@lst.de>
>> Sent: Wednesday, June 22, 2022 10:44 PM
>> To: Dexuan Cui <decui@microsoft.com>
>>   ...
>> On Wed, Jun 22, 2022 at 12:14:24PM -0700, Dexuan Cui wrote:
>>> The third parameter of dma_set_encrypted() is a size in bytes rather than
>>> the number of pages.
>>>
>>> Fixes: 4d0564785bb0 ("dma-direct: factor out dma_set_{de,en}crypted
>> helpers")
>>> Signed-off-by: Dexuan Cui <decui@microsoft.com>
>>
>> see:
>>
>> commit 4a37f3dd9a83186cb88d44808ab35b78375082c9 (tag:
>> dma-mapping-5.19-2022-05-25)
>> Author: Robin Murphy <robin.murphy@arm.com>
>> Date:   Fri May 20 18:10:13 2022 +0100
>>
>>      dma-direct: don't over-decrypt memory
> 
> It looks like commit 4a37f3dd9a831 fixed a different issue?
> 
> Here my patch is for the latest mainline:
> 
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
>    out_encrypt_pages:
> 	  if (dma_set_encrypted(dev, page_address(page), size))
> 
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?

I think technically you're both right - these instances clearly have a 
history tracing back to the original bug that my patch addressed, but 
the refactoring then made them into their own distinct bug in terms of 
the internal dma_set_encrypted() interface, per the commit message here. 
Apparently I failed to spot this when forward-porting 4a37f3dd9a831 from 
5.10 (as the commit message says, don't ask... ;) ) - I guess I was only 
looking at where the set_memory_*() callsites had moved to. For this patch,

Reviewed-by: Robin Murphy <robin.murphy@arm.com>

Thanks
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
  2022-06-23  7:00     ` Dexuan Cui via iommu
@ 2022-06-23 13:28       ` Christoph Hellwig
  -1 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23 13:28 UTC (permalink / raw)
  To: Dexuan Cui
  Cc: Christoph Hellwig, m.szyprowski, robin.murphy, iommu,
	linux-kernel, linux-hyperv, Michael Kelley (LINUX),
	Andrea Parri, Tianyu Lan

On Thu, Jun 23, 2022 at 07:00:58AM +0000, Dexuan Cui wrote:
> It looks like commit 4a37f3dd9a831 fixed a different issue?
> 
> Here my patch is for the latest mainline:
> 
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
>   out_encrypt_pages:
> 	  if (dma_set_encrypted(dev, page_address(page), size))
> 
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?

Indeed.  I've applied the patch now.

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

* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-23 13:28       ` Christoph Hellwig
  0 siblings, 0 replies; 11+ messages in thread
From: Christoph Hellwig @ 2022-06-23 13:28 UTC (permalink / raw)
  To: Dexuan Cui
  Cc: linux-hyperv, Tianyu Lan, Andrea Parri, linux-kernel,
	Michael Kelley (LINUX),
	iommu, robin.murphy, Christoph Hellwig

On Thu, Jun 23, 2022 at 07:00:58AM +0000, Dexuan Cui wrote:
> It looks like commit 4a37f3dd9a831 fixed a different issue?
> 
> Here my patch is for the latest mainline:
> 
> In dma_direct_alloc()'s error handling path, we pass 'size' to dma_set_encrypted():
>   out_encrypt_pages:
> 	  if (dma_set_encrypted(dev, page_address(page), size))
> 
> However, in dma_direct_free(), we pass ' 1 << page_order ' to dma_set_encrypted().
> I think the ' 1 << page_order' is incorrect and it should be 'size' as well?

Indeed.  I've applied the patch now.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

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

* Re: [PATCH] dma-direct: use the correct size for dma_set_encrypted()
@ 2022-06-28 22:07 kernel test robot
  0 siblings, 0 replies; 11+ messages in thread
From: kernel test robot @ 2022-06-28 22:07 UTC (permalink / raw)
  To: kbuild

[-- Attachment #1: Type: text/plain, Size: 21693 bytes --]

:::::: 
:::::: Manual check reason: "low confidence static check warning: kernel/dma/direct.c:325:15: warning: Value stored to 'page_order' during its initialization is never read [clang-analyzer-deadcode.DeadStores]"
:::::: 

CC: llvm(a)lists.linux.dev
CC: kbuild-all(a)lists.01.org
BCC: lkp(a)intel.com
In-Reply-To: <20220622191424.15777-1-decui@microsoft.com>
References: <20220622191424.15777-1-decui@microsoft.com>
TO: Dexuan Cui <decui@microsoft.com>

Hi Dexuan,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[cannot apply to v5.19-rc4 next-20220628]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/intel-lab-lkp/linux/commits/Dexuan-Cui/dma-direct-use-the-correct-size-for-dma_set_encrypted/20220623-031721
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git de5c208d533a46a074eb46ea17f672cc005a7269
:::::: branch date: 6 days ago
:::::: commit date: 6 days ago
config: s390-randconfig-c005-20220625 (https://download.01.org/0day-ci/archive/20220629/202206290627.5IxYSe6J-lkp(a)intel.com/config)
compiler: clang version 15.0.0 (https://github.com/llvm/llvm-project b0d6dd3905db145853c7c744ac92d49b00b1fa20)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install s390 cross compiling tool for clang build
        # apt-get install binutils-s390x-linux-gnu
        # https://github.com/intel-lab-lkp/linux/commit/2288b269c064b0b811fcb34ef45a306690456a7a
        git remote add linux-review https://github.com/intel-lab-lkp/linux
        git fetch --no-tags linux-review Dexuan-Cui/dma-direct-use-the-correct-size-for-dma_set_encrypted/20220623-031721
        git checkout 2288b269c064b0b811fcb34ef45a306690456a7a
        # save the config file
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 clang-analyzer 

If you fix the issue, kindly add following tag where applicable
Reported-by: kernel test robot <lkp@intel.com>


clang-analyzer warnings: (new ones prefixed by >>)
                                   ^~~~~~~~~~~~~~~~
   mm/memory.c:5465:5: note: Call to function 'memcpy' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memcpy_s' in case of C11
                                   copy_to_user_page(vma, page, addr,
                                   ^
   include/asm-generic/cacheflush.h:108:3: note: expanded from macro 'copy_to_user_page'
                   memcpy(dst, src, len); \
                   ^~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:385:26: note: expanded from macro 'memcpy'
   #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,                  \
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:378:2: note: expanded from macro '__fortify_memcpy_chk'
           __underlying_##op(p, q, __fortify_size);                        \
           ^~~~~~~~~~~~~~~~~
   note: expanded from here
   include/linux/fortify-string.h:45:29: note: expanded from macro '__underlying_memcpy'
   #define __underlying_memcpy     __builtin_memcpy
                                   ^~~~~~~~~~~~~~~~
   mm/memory.c:5469:5: warning: Call to function 'memcpy' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memcpy_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
                                   copy_from_user_page(vma, page, addr,
                                   ^
   include/asm-generic/cacheflush.h:115:2: note: expanded from macro 'copy_from_user_page'
           memcpy(dst, src, len)
           ^~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:385:26: note: expanded from macro 'memcpy'
   #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,                  \
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:378:2: note: expanded from macro '__fortify_memcpy_chk'
           __underlying_##op(p, q, __fortify_size);                        \
           ^~~~~~~~~~~~~~~~~
   note: expanded from here
   include/linux/fortify-string.h:45:29: note: expanded from macro '__underlying_memcpy'
   #define __underlying_memcpy     __builtin_memcpy
                                   ^~~~~~~~~~~~~~~~
   mm/memory.c:5469:5: note: Call to function 'memcpy' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memcpy_s' in case of C11
                                   copy_from_user_page(vma, page, addr,
                                   ^
   include/asm-generic/cacheflush.h:115:2: note: expanded from macro 'copy_from_user_page'
           memcpy(dst, src, len)
           ^~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:385:26: note: expanded from macro 'memcpy'
   #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,                  \
                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:378:2: note: expanded from macro '__fortify_memcpy_chk'
           __underlying_##op(p, q, __fortify_size);                        \
           ^~~~~~~~~~~~~~~~~
   note: expanded from here
   include/linux/fortify-string.h:45:29: note: expanded from macro '__underlying_memcpy'
   #define __underlying_memcpy     __builtin_memcpy
                                   ^~~~~~~~~~~~~~~~
   mm/memory.c:5530:25: warning: Dereference of null pointer [clang-analyzer-core.NullDereference]
           struct mm_struct *mm = current->mm;
                                  ^
   arch/s390/include/asm/current.h:17:45: note: expanded from macro 'current'
   #define current ((struct task_struct *const)S390_lowcore.current_task)
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~
   arch/s390/include/asm/lowcore.h:213:22: note: expanded from macro 'S390_lowcore'
   #define S390_lowcore (*((struct lowcore *) 0))
                        ^
   mm/memory.c:5530:25: note: Dereference of null pointer
           struct mm_struct *mm = current->mm;
                                  ^
   arch/s390/include/asm/current.h:17:45: note: expanded from macro 'current'
   #define current ((struct task_struct *const)S390_lowcore.current_task)
                                               ^~~~~~~~~~~~~~~~~~~~~~~~~
   arch/s390/include/asm/lowcore.h:213:22: note: expanded from macro 'S390_lowcore'
   #define S390_lowcore (*((struct lowcore *) 0))
                        ^
   Suppressed 65 warnings (53 in non-user code, 12 with check filters).
   Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
   42 warnings generated.
   Suppressed 42 warnings (42 in non-user code).
   Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
   55 warnings generated.
   Suppressed 55 warnings (43 in non-user code, 12 with check filters).
   Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
   58 warnings generated.
   kernel/dma/direct.c:302:2: warning: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
           memset(ret, 0, size);
           ^
   include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
   #define memset(p, c, s) __fortify_memset_chk(p, c, s,                   \
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
           __underlying_memset(p, c, __fortify_size);                      \
           ^~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
   #define __underlying_memset     __builtin_memset
                                   ^~~~~~~~~~~~~~~~
   kernel/dma/direct.c:302:2: note: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11
           memset(ret, 0, size);
           ^
   include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
   #define memset(p, c, s) __fortify_memset_chk(p, c, s,                   \
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
           __underlying_memset(p, c, __fortify_size);                      \
           ^~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
   #define __underlying_memset     __builtin_memset
                                   ^~~~~~~~~~~~~~~~
>> kernel/dma/direct.c:325:15: warning: Value stored to 'page_order' during its initialization is never read [clang-analyzer-deadcode.DeadStores]
           unsigned int page_order = get_order(size);
                        ^~~~~~~~~~   ~~~~~~~~~~~~~~~
   kernel/dma/direct.c:325:15: note: Value stored to 'page_order' during its initialization is never read
           unsigned int page_order = get_order(size);
                        ^~~~~~~~~~   ~~~~~~~~~~~~~~~
   kernel/dma/direct.c:383:2: warning: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11 [clang-analyzer-security.insecureAPI.DeprecatedOrUnsafeBufferHandling]
           memset(ret, 0, size);
           ^
   include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
   #define memset(p, c, s) __fortify_memset_chk(p, c, s,                   \
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
           __underlying_memset(p, c, __fortify_size);                      \
           ^~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
   #define __underlying_memset     __builtin_memset
                                   ^~~~~~~~~~~~~~~~
   kernel/dma/direct.c:383:2: note: Call to function 'memset' is insecure as it does not provide security checks introduced in the C11 standard. Replace with analogous functions that support length arguments or provides boundary checks such as 'memset_s' in case of C11
           memset(ret, 0, size);
           ^
   include/linux/fortify-string.h:288:25: note: expanded from macro 'memset'
   #define memset(p, c, s) __fortify_memset_chk(p, c, s,                   \
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:281:2: note: expanded from macro '__fortify_memset_chk'
           __underlying_memset(p, c, __fortify_size);                      \
           ^~~~~~~~~~~~~~~~~~~
   include/linux/fortify-string.h:47:29: note: expanded from macro '__underlying_memset'
   #define __underlying_memset     __builtin_memset
                                   ^~~~~~~~~~~~~~~~
   Suppressed 55 warnings (43 in non-user code, 12 with check filters).
   Use -header-filter=.* to display errors from all non-system headers. Use -system-headers to display errors from system headers as well.
   85 warnings generated.
   arch/s390/kernel/diag.c:130:2: warning: Dereference of null pointer [clang-analyzer-core.NullDereference]
           this_cpu_inc(diag_stat.counter[nr]);
           ^
   include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
   #define this_cpu_inc(pcp)               this_cpu_add(pcp, 1)
                                           ^
   include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
   #define this_cpu_add(pcp, val)          __pcpu_size_call(this_cpu_add_, pcp, val)
                                           ^
   include/linux/percpu-defs.h:379:11: note: expanded from macro '__pcpu_size_call'
                   case 4: stem##4(variable, __VA_ARGS__);break;           \
                           ^
   note: (skipping 4 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
   include/asm-generic/percpu.h:44:31: note: expanded from macro 'arch_raw_cpu_ptr'
   #define arch_raw_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, __my_cpu_offset)
                                 ^
   include/linux/percpu-defs.h:231:2: note: expanded from macro 'SHIFT_PERCPU_PTR'
           RELOC_HIDE((typeof(*(__p)) __kernel __force *)(__p), (__offset))
           ^
   include/linux/compiler.h:170:28: note: expanded from macro 'RELOC_HIDE'
       (typeof(ptr)) (__ptr + (off)); })
                              ^
   arch/s390/kernel/diag.c:217:2: note: Calling 'diag_stat_inc'
           diag_stat_inc(DIAG_STAT_X26C);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   arch/s390/kernel/diag.c:130:2: note: Loop condition is false.  Exiting loop
           this_cpu_inc(diag_stat.counter[nr]);
           ^
   include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
   #define this_cpu_inc(pcp)               this_cpu_add(pcp, 1)
                                           ^
   include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
   #define this_cpu_add(pcp, val)          __pcpu_size_call(this_cpu_add_, pcp, val)
                                           ^
   include/linux/percpu-defs.h:375:2: note: expanded from macro '__pcpu_size_call'
           __verify_pcpu_ptr(&(variable));                                 \
           ^
   include/linux/percpu-defs.h:217:37: note: expanded from macro '__verify_pcpu_ptr'
   #define __verify_pcpu_ptr(ptr)                                          \
                                                                           ^
   arch/s390/kernel/diag.c:130:2: note: Control jumps to 'case 4:'  at line 130
           this_cpu_inc(diag_stat.counter[nr]);
           ^
   include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
   #define this_cpu_inc(pcp)               this_cpu_add(pcp, 1)
                                           ^
   include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
   #define this_cpu_add(pcp, val)          __pcpu_size_call(this_cpu_add_, pcp, val)
                                           ^
   include/linux/percpu-defs.h:376:2: note: expanded from macro '__pcpu_size_call'
           switch(sizeof(variable)) {                                      \
           ^
   arch/s390/kernel/diag.c:130:2: note: Loop condition is false.  Exiting loop
           this_cpu_inc(diag_stat.counter[nr]);
           ^
   include/linux/percpu-defs.h:520:28: note: expanded from macro 'this_cpu_inc'
   #define this_cpu_inc(pcp)               this_cpu_add(pcp, 1)
                                           ^
   include/linux/percpu-defs.h:509:33: note: expanded from macro 'this_cpu_add'
   #define this_cpu_add(pcp, val)          __pcpu_size_call(this_cpu_add_, pcp, val)
                                           ^
   include/linux/percpu-defs.h:379:11: note: expanded from macro '__pcpu_size_call'
                   case 4: stem##4(variable, __VA_ARGS__);break;           \
                           ^
   note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to see all)
   arch/s390/include/asm/percpu.h:33:10: note: expanded from macro 'arch_this_cpu_to_op_simple'
           ptr__ = raw_cpu_ptr(&(pcp));                                    \
                   ^

vim +/page_order +325 kernel/dma/direct.c

a8463d4b0e47d1f lib/dma-noop.c      Christian Borntraeger 2016-02-02  321  
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  322  void dma_direct_free(struct device *dev, size_t size,
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  323  		void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
a8463d4b0e47d1f lib/dma-noop.c      Christian Borntraeger 2016-02-02  324  {
c10f07aa27dadf5 lib/dma-direct.c    Christoph Hellwig     2018-03-19 @325  	unsigned int page_order = get_order(size);
080321d3b3139b3 lib/dma-direct.c    Christoph Hellwig     2017-12-22  326  
849facea92fa68d kernel/dma/direct.c Christoph Hellwig     2020-10-07  327  	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
f4111e39a52aa5d kernel/dma/direct.c Claire Chang          2021-06-19  328  	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
849facea92fa68d kernel/dma/direct.c Christoph Hellwig     2020-10-07  329  		/* cpu_addr is a struct page cookie, not a kernel address */
849facea92fa68d kernel/dma/direct.c Christoph Hellwig     2020-10-07  330  		dma_free_contiguous(dev, cpu_addr, size);
849facea92fa68d kernel/dma/direct.c Christoph Hellwig     2020-10-07  331  		return;
849facea92fa68d kernel/dma/direct.c Christoph Hellwig     2020-10-07  332  	}
849facea92fa68d kernel/dma/direct.c Christoph Hellwig     2020-10-07  333  
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  334  	if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  335  	    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  336  	    !IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
3de18c865f504ab kernel/dma/direct.c Linus Torvalds        2021-09-03  337  	    !dev_is_dma_coherent(dev) &&
f4111e39a52aa5d kernel/dma/direct.c Claire Chang          2021-06-19  338  	    !is_swiotlb_for_alloc(dev)) {
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  339  		arch_dma_free(dev, size, cpu_addr, dma_addr, attrs);
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  340  		return;
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  341  	}
2f5388a29be82a6 kernel/dma/direct.c Christoph Hellwig     2020-08-17  342  
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  343  	if (IS_ENABLED(CONFIG_DMA_GLOBAL_POOL) &&
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  344  	    !dev_is_dma_coherent(dev)) {
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  345  		if (!dma_release_from_global_coherent(page_order, cpu_addr))
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  346  			WARN_ON_ONCE(1);
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  347  		return;
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  348  	}
faf4ef823ac5f3b kernel/dma/direct.c Christoph Hellwig     2021-06-23  349  
76a19940bd62a81 kernel/dma/direct.c David Rientjes        2020-04-14  350  	/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
849facea92fa68d kernel/dma/direct.c Christoph Hellwig     2020-10-07  351  	if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
76a19940bd62a81 kernel/dma/direct.c David Rientjes        2020-04-14  352  	    dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))
76a19940bd62a81 kernel/dma/direct.c David Rientjes        2020-04-14  353  		return;
76a19940bd62a81 kernel/dma/direct.c David Rientjes        2020-04-14  354  
f5ff79fddf0efec kernel/dma/direct.c Christoph Hellwig     2022-02-26  355  	if (is_vmalloc_addr(cpu_addr)) {
3acac065508f6cc kernel/dma/direct.c Christoph Hellwig     2019-10-29  356  		vunmap(cpu_addr);
5570449b6876f21 kernel/dma/direct.c Christoph Hellwig     2021-10-21  357  	} else {
5570449b6876f21 kernel/dma/direct.c Christoph Hellwig     2021-10-21  358  		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
999a5d1203baa7c kernel/dma/direct.c Christoph Hellwig     2020-02-21  359  			arch_dma_clear_uncached(cpu_addr, size);
2288b269c064b0b kernel/dma/direct.c Dexuan Cui            2022-06-22  360  		if (dma_set_encrypted(dev, cpu_addr, size))
a90cf3043748934 kernel/dma/direct.c Christoph Hellwig     2021-11-09  361  			return;
5570449b6876f21 kernel/dma/direct.c Christoph Hellwig     2021-10-21  362  	}
3acac065508f6cc kernel/dma/direct.c Christoph Hellwig     2019-10-29  363  
f4111e39a52aa5d kernel/dma/direct.c Claire Chang          2021-06-19  364  	__dma_direct_free_pages(dev, dma_direct_to_page(dev, dma_addr), size);
a8463d4b0e47d1f lib/dma-noop.c      Christian Borntraeger 2016-02-02  365  }
a8463d4b0e47d1f lib/dma-noop.c      Christian Borntraeger 2016-02-02  366  

-- 
0-DAY CI Kernel Test Service
https://01.org/lkp

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

end of thread, other threads:[~2022-06-28 22:07 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-06-22 19:14 [PATCH] dma-direct: use the correct size for dma_set_encrypted() Dexuan Cui
2022-06-22 19:14 ` Dexuan Cui via iommu
2022-06-23  5:43 ` Christoph Hellwig
2022-06-23  5:43   ` Christoph Hellwig
2022-06-23  7:00   ` Dexuan Cui
2022-06-23  7:00     ` Dexuan Cui via iommu
2022-06-23  9:01     ` Robin Murphy
2022-06-23  9:01       ` Robin Murphy
2022-06-23 13:28     ` Christoph Hellwig
2022-06-23 13:28       ` Christoph Hellwig
2022-06-28 22:07 kernel test robot

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.