All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Christoph Hellwig <hch@infradead.org>
Cc: Tom Lendacky <thomas.lendacky@amd.com>, iommu@lists.linux-foundation.org
Subject: Re: Memory clearing in swiotlb_update_mem_attributes()
Date: Wed, 5 Jan 2022 18:58:47 +0300	[thread overview]
Message-ID: <20220105155847.gcx443z7al3dbsdq@box.shutemov.name> (raw)
In-Reply-To: <YdWnUmJsjPUYiycV@infradead.org>

On Wed, Jan 05, 2022 at 06:12:34AM -0800, Christoph Hellwig wrote:
> On Wed, Jan 05, 2022 at 08:06:10AM -0600, Tom Lendacky wrote:
> > On 1/4/22 4:49 PM, Kirill A. Shutemov wrote:
> > > Hi Tom,
> > > 
> > > For larger TDX VM, memset() after set_memory_decrypted() in
> > > swiotlb_update_mem_attributes() takes substantial portion of boot time.
> > > 
> > > It makes me wounder why do we need it there? Malicious VMM can mess with
> > > decrypted/shared buffer at any point and for normal use it will be
> > > populated with real data anyway.
> > > 
> > > Can we drop it?
> > 
> > Probably more a question for Christoph. Does SWIOTLB need to be initialized
> > to zeroes? If it does, then the memset after the set_memory_decrypted() is
> > required, otherwise it will appear as ciphertext to SWIOTLB.
> 
> While the traditional swiotlb initialization zeroes it I can't really
> see any reason why we would want to zero it.  If we really care about
> not leaking data to the device we'd need to zero the padding at mapping
> time.

Does the patch below look fine?

From ab1aa6abbdbba9e34ac7b86e5af1f9f488afaa07 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date: Wed, 5 Jan 2022 18:48:01 +0300
Subject: [PATCH] swiotlb: Do not zero buffer in set_memory_decrypted()

For larger TDX VM, memset() after set_memory_decrypted() in
swiotlb_update_mem_attributes() takes substantial portion of boot time.

Zeroing doesn't serve any functional purpose. Malicious VMM can mess
with decrypted/shared buffer at any point.

Remove the memset().

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 kernel/dma/swiotlb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 8e840fbbed7c..4546c834accb 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -172,7 +172,6 @@ void __init swiotlb_update_mem_attributes(void)
 	vaddr = phys_to_virt(mem->start);
 	bytes = PAGE_ALIGN(mem->nslabs << IO_TLB_SHIFT);
 	set_memory_decrypted((unsigned long)vaddr, bytes >> PAGE_SHIFT);
-	memset(vaddr, 0, bytes);
 }
 
 static void swiotlb_init_io_tlb_mem(struct io_tlb_mem *mem, phys_addr_t start,
-- 
 Kirill A. Shutemov
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2022-01-05 15:58 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 22:49 Memory clearing in swiotlb_update_mem_attributes() Kirill A. Shutemov
2022-01-05 14:06 ` Tom Lendacky via iommu
2022-01-05 14:12   ` Christoph Hellwig
2022-01-05 15:58     ` Kirill A. Shutemov [this message]
2022-01-10 15:58   ` Tom Lendacky via iommu

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=20220105155847.gcx443z7al3dbsdq@box.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=hch@infradead.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=thomas.lendacky@amd.com \
    /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 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.