From: "Lendacky, Thomas" <Thomas.Lendacky@amd.com>
To: Thiago Jung Bauermann <bauerman@linux.ibm.com>,
"x86@kernel.org" <x86@kernel.org>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Christoph Hellwig" <hch@lst.de>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, "Ram Pai" <linuxram@us.ibm.com>
Subject: Re: [PATCH 1/2] dma-direct: set_memory_{en,de}crypted() take number of pages
Date: Tue, 22 Jan 2019 21:40:16 +0000 [thread overview]
Message-ID: <bc09628a-d329-bb95-d737-b7c618860c6a@amd.com> (raw)
In-Reply-To: <20190122211758.8317-1-bauerman@linux.ibm.com>
On 1/22/19 3:17 PM, Thiago Jung Bauermann wrote:
> From: Ram Pai <linuxram@us.ibm.com>
>
> set_memory_encrypted() and set_memory_decrypted() expect the number of
> PAGE_SIZE pages to encrypt or decrypt. dma_direct_alloc() and
> dma_direct_free() instead pass number of bytes. This encrypts/decrypts a
> huge number of pages resulting in data corruption.
That is not what it is doing. See comments below.
>
> Fixed it.
>
> [ bauermann: Slightly reworded commit message and added Fixes: tag. ]
> Fixes: d7b417fa08d1 ("x86/mm: Add DMA support for SEV memory encryption")
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
> ---
> kernel/dma/direct.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> Notes:
>
> 1. This was tested on powerpc with patches adding support for running
> under the ultravisor, which are not yet upstream.
>
> 2. The lines changed in this patch were added by commit c10f07aa27da
> ("dma/direct: Handle force decryption for DMA coherent buffers in
> common code"), but it only moves the code from an x86-specific file.
> Therefore the Fixes tag references the commit that first introduced
> the code.
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 355d16acee6d..bc78c37220ba 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -166,7 +166,7 @@ void *dma_direct_alloc_pages(struct device *dev, size_t size,
>
> ret = page_address(page);
> if (force_dma_unencrypted()) {
> - set_memory_decrypted((unsigned long)ret, 1 << get_order(size));
> + set_memory_decrypted((unsigned long)ret, 1);
The get_order() function will return the order for the specified size. To
then get the number of pages you perform the shift as is being done. The
change is definitely wrong since you are now hardcoding the page count to
1. The call to __dma_direct_alloc_pages() will allocate more than one page
if the size is greater than a page.
> *dma_handle = __phys_to_dma(dev, page_to_phys(page));
> } else {
> *dma_handle = phys_to_dma(dev, page_to_phys(page));
> @@ -186,10 +186,8 @@ void __dma_direct_free_pages(struct device *dev, size_t size, struct page *page)
> void dma_direct_free_pages(struct device *dev, size_t size, void *cpu_addr,
> dma_addr_t dma_addr, unsigned long attrs)
> {
> - unsigned int page_order = get_order(size);
> -
> if (force_dma_unencrypted())
> - set_memory_encrypted((unsigned long)cpu_addr, 1 << page_order);
> + set_memory_encrypted((unsigned long)cpu_addr, 1);
Same comment here as above.
Thanks,
Tom
> __dma_direct_free_pages(dev, size, virt_to_page(cpu_addr));
> }
>
>
next prev parent reply other threads:[~2019-01-22 21:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 21:17 [PATCH 1/2] dma-direct: set_memory_{en,de}crypted() take number of pages Thiago Jung Bauermann
2019-01-22 21:17 ` [PATCH 2/2] x86/kvmclock: set_memory_decrypted() takes " Thiago Jung Bauermann
2019-01-22 21:43 ` Lendacky, Thomas
2019-01-22 21:40 ` Lendacky, Thomas [this message]
2019-01-22 22:38 ` [PATCH 1/2] dma-direct: set_memory_{en,de}crypted() take " Thiago Jung Bauermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bc09628a-d329-bb95-d737-b7c618860c6a@amd.com \
--to=thomas.lendacky@amd.com \
--cc=bauerman@linux.ibm.com \
--cc=bp@alien8.de \
--cc=hch@lst.de \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxram@us.ibm.com \
--cc=m.szyprowski@samsung.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox