[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1696011549-28036-6-git-send-email-mikelley@microsoft.com>
Date: Fri, 29 Sep 2023 11:19:09 -0700
From: Michael Kelley <mikelley@...rosoft.com>
To: kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
decui@...rosoft.com, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, hpa@...or.com,
luto@...nel.org, peterz@...radead.org, thomas.lendacky@....com,
sathyanarayanan.kuppuswamy@...ux.intel.com,
kirill.shutemov@...ux.intel.com, seanjc@...gle.com,
rick.p.edgecombe@...el.com, linux-kernel@...r.kernel.org,
linux-hyperv@...r.kernel.org, x86@...nel.org
Cc: mikelley@...rosoft.com
Subject: [PATCH 5/5] x86/mm: Add comments about errors in set_memory_decrypted()/encrypted()
The functions set_memory_decrypted()/encrypted() may leave the input
memory range in an inconsistent state if an error occurs. Add comments
describing the situation and what callers must be aware of. Also add
comments in __set_memory_enc_dec() with more details on the issues and
why further investment in error handling is not likely to be useful.
No functional change.
Suggested-by: Rick Edgecombe <rick.p.edgecombe@...el.com>
Signed-off-by: Michael Kelley <mikelley@...rosoft.com>
---
arch/x86/mm/pat/set_memory.c | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index 1578077..9d07d4e 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -2133,6 +2133,24 @@ int set_memory_global(unsigned long addr, int numpages)
/*
* __set_memory_enc_dec() is used for the hypervisors that get
* informed about "encryption" status via page tables.
+ *
+ * If an error occurs in making the transition between encrypted and
+ * decrypted, the transitioned memory is left in an indeterminate state.
+ * The encryption status in the guest page tables may not match the
+ * hypervisor's view of the encryption status, making the memory unusable.
+ * If the memory consists of multiple pages, different pages may be in
+ * different indeterminate states.
+ *
+ * It is difficult to recover from errors such that we can ensure
+ * consistency between the page tables and hypervisor view of the encryption
+ * state. It may not be possible to back out of changes, particularly if the
+ * failure occurs in communicating with the hypervisor. Given this limitation,
+ * further work on the error handling is not likely to meaningfully improve
+ * the reliablity or usability of the system.
+ *
+ * Any errors are likely to soon render the VM inoperable, but we return
+ * an error rather than panic'ing so that the caller can decide how best
+ * to shutdown cleanly.
*/
static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
{
@@ -2203,6 +2221,14 @@ static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc)
return set_memory_p(&addr, numpages);
}
+/*
+ * If set_memory_encrypted()/decrypted() returns an error, the input memory
+ * range is left in an indeterminate state. The encryption status of pages
+ * may be inconsistent, so the memory is unusable. The caller should not try
+ * to do further operations on the memory, or return it to the free list.
+ * The memory must be leaked, and the caller should take steps to shutdown
+ * the system as cleanly as possible as something is seriously wrong.
+ */
int set_memory_encrypted(unsigned long addr, int numpages)
{
return __set_memory_enc_dec(addr, numpages, true);
--
1.8.3.1
Powered by blists - more mailing lists