From: Rick Edgecombe <rick.p.edgecombe@intel.com>
To: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com,
luto@kernel.org, peterz@infradead.org,
kirill.shutemov@linux.intel.com, elena.reshetova@intel.com,
isaku.yamahata@intel.com, seanjc@google.com,
Michael Kelley <mikelley@microsoft.com>,
thomas.lendacky@amd.com, decui@microsoft.com,
sathyanarayanan.kuppuswamy@linux.intel.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org
Cc: rick.p.edgecombe@intel.com, Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@linux.ibm.com>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Sven Schnelle <svens@linux.ibm.com>,
Dave Hansen <dave.hansen@intel.com>
Subject: [PATCH 01/10] mm: Add helper for freeing decrypted memory
Date: Tue, 17 Oct 2023 13:24:56 -0700 [thread overview]
Message-ID: <20231017202505.340906-2-rick.p.edgecombe@intel.com> (raw)
In-Reply-To: <20231017202505.340906-1-rick.p.edgecombe@intel.com>
When freeing decrypted memory to the page allocator the memory needs to be
manually re-encrypted beforehand. If this step is skipped, then the next
user of those pages will have the contents inadvertently exposed to
the guest, or cause the guest to crash if the page is used in way
disallowed by HW (i.e. for executable code or as a page table).
Unfortunately, there are many instance of patterns like:
set_memory_encrypted(pages);
free_pages(pages);
...or...
if (set_memory_decrypted(addr, 1))
free_pages(pages);
This is a problem because set_memory_encrypted() and
set_memory_decrypted() can be failed by the untrusted host in such a way
that an error is returned and the resulting memory is shared.
To aid in a tree-wide cleanup of these callers, add a
free_decrypted_pages() function that will first try to encrypt the pages
before returning them. If it is not successful, have it leak the pages and
warn about this. This is preferable to returning shared pages to allocator
or panicking.
In some cases the code path's for freeing decrypted memory handle both
encrypted and decrypted pages. In this case, rely on set_memory() to
handle being asked to convert memory to the state it is already in.
Going forward, rely on cross-arch callers to find and use
free_decrypted_pages() instead of resorting to more heavy handed solutions
like terminating the guest when nasty VMM behavior is observed.
To make s390's arch set_memory_XXcrypted() definitions available in
linux/set_memory.h, add include for s390's asm version of set_memory.h.
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: linux-s390@vger.kernel.org
Suggested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
arch/s390/include/asm/set_memory.h | 1 +
include/linux/set_memory.h | 13 +++++++++++++
2 files changed, 14 insertions(+)
diff --git a/arch/s390/include/asm/set_memory.h b/arch/s390/include/asm/set_memory.h
index 06fbabe2f66c..09d36ebd64b5 100644
--- a/arch/s390/include/asm/set_memory.h
+++ b/arch/s390/include/asm/set_memory.h
@@ -3,6 +3,7 @@
#define _ASMS390_SET_MEMORY_H
#include <linux/mutex.h>
+#include <linux/mem_encrypt.h>
extern struct mutex cpa_mutex;
diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
index 95ac8398ee72..a898b14b6b1f 100644
--- a/include/linux/set_memory.h
+++ b/include/linux/set_memory.h
@@ -5,6 +5,8 @@
#ifndef _LINUX_SET_MEMORY_H_
#define _LINUX_SET_MEMORY_H_
+#include <linux/gfp.h>
+
#ifdef CONFIG_ARCH_HAS_SET_MEMORY
#include <asm/set_memory.h>
#else
@@ -78,4 +80,15 @@ static inline int set_memory_decrypted(unsigned long addr, int numpages)
}
#endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */
+static inline void free_decrypted_pages(unsigned long addr, int order)
+{
+ int ret = set_memory_encrypted(addr, 1 << order);
+
+ if (ret) {
+ WARN_ONCE(1, "Failed to re-encrypt memory before freeing, leaking pages!\n");
+ return;
+ }
+ free_pages(addr, order);
+}
+
#endif /* _LINUX_SET_MEMORY_H_ */
--
2.34.1
next prev parent reply other threads:[~2023-10-17 20:25 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 20:24 [PATCH 00/10] Handle set_memory_XXcrypted() errors Rick Edgecombe
2023-10-17 20:24 ` Rick Edgecombe [this message]
2023-10-17 20:24 ` [PATCH 02/10] x86/mm/cpa: Reject incorrect encryption change requests Rick Edgecombe
2023-10-18 8:44 ` Ingo Molnar
2023-10-18 15:53 ` Edgecombe, Rick P
2023-10-17 20:24 ` [PATCH 03/10] kvmclock: Use free_decrypted_pages() Rick Edgecombe
2023-10-18 5:20 ` Kuppuswamy Sathyanarayanan
2023-10-18 15:57 ` Edgecombe, Rick P
2023-10-17 20:24 ` [PATCH 04/10] swiotlb: " Rick Edgecombe
2023-10-18 4:43 ` Christoph Hellwig
2023-10-18 15:55 ` Edgecombe, Rick P
2023-10-31 10:43 ` Petr Tesařík
2023-10-31 15:54 ` Edgecombe, Rick P
2023-10-31 17:13 ` Petr Tesařík
2023-10-31 17:29 ` Edgecombe, Rick P
2023-11-01 6:27 ` Petr Tesařík
2023-11-01 14:40 ` Edgecombe, Rick P
2023-10-17 20:25 ` [PATCH 05/10] ptp: " Rick Edgecombe
2023-10-17 20:25 ` [PATCH 06/10] dma: " Rick Edgecombe
2023-10-18 6:24 ` Christoph Hellwig
2023-10-18 17:09 ` Edgecombe, Rick P
2023-10-18 17:42 ` Robin Murphy
2023-10-23 16:46 ` Edgecombe, Rick P
2023-10-23 17:22 ` Robin Murphy
2023-10-23 17:27 ` Edgecombe, Rick P
2023-10-17 20:25 ` [RFC 07/10] hv: " Rick Edgecombe
2023-10-17 20:25 ` [RFC 08/10] hv: Track decrypted status in vmbus_gpadl Rick Edgecombe
2023-10-17 20:25 ` [RFC 09/10] hv_nstvsc: Don't free decrypted memory Rick Edgecombe
2023-10-17 20:25 ` [RFC 10/10] uio_hv_generic: " Rick Edgecombe
2023-10-19 17:05 ` [PATCH 00/10] Handle set_memory_XXcrypted() errors Michael Kelley (LINUX)
2023-10-19 19:13 ` Dave Hansen
2023-10-23 16:47 ` Michael Kelley (LINUX)
2023-10-23 16:57 ` Dave Hansen
2023-10-23 17:01 ` Edgecombe, Rick P
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=20231017202505.340906-2-rick.p.edgecombe@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=agordeev@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=elena.reshetova@intel.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=hpa@zytor.com \
--cc=isaku.yamahata@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mikelley@microsoft.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--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