From: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
To: mhklinux@outlook.com, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, kirill.shutemov@linux.intel.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
luto@kernel.org, peterz@infradead.org, akpm@linux-foundation.org,
urezki@gmail.com, hch@infradead.org, lstoakes@gmail.com,
thomas.lendacky@amd.com, ardb@kernel.org, jroedel@suse.de,
seanjc@google.com, rick.p.edgecombe@intel.com,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
linux-hyperv@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v3 3/3] x86/hyperv: Make encrypted/decrypted changes safe for load_unaligned_zeropad()
Date: Mon, 8 Jan 2024 10:37:28 -0800 [thread overview]
Message-ID: <a559406d-acd5-40eb-906e-2b8b11739e9e@linux.intel.com> (raw)
In-Reply-To: <20240105183025.225972-4-mhklinux@outlook.com>
On 1/5/2024 10:30 AM, mhkelley58@gmail.com wrote:
> From: Michael Kelley <mhklinux@outlook.com>
>
> In a CoCo VM, when transitioning memory from encrypted to decrypted, or
> vice versa, the caller of set_memory_encrypted() or set_memory_decrypted()
> is responsible for ensuring the memory isn't in use and isn't referenced
> while the transition is in progress. The transition has multiple steps,
> and the memory is in an inconsistent state until all steps are complete.
> A reference while the state is inconsistent could result in an exception
> that can't be cleanly fixed up.
>
> However, the kernel load_unaligned_zeropad() mechanism could cause a stray
> reference that can't be prevented by the caller of set_memory_encrypted()
> or set_memory_decrypted(), so there's specific code to handle this case.
> But a CoCo VM running on Hyper-V may be configured to run with a paravisor,
> with the #VC or #VE exception routed to the paravisor. There's no
> architectural way to forward the exceptions back to the guest kernel, and
> in such a case, the load_unaligned_zeropad() specific code doesn't work.
>
> To avoid this problem, mark pages as "not present" while a transition
> is in progress. If load_unaligned_zeropad() causes a stray reference, a
> normal page fault is generated instead of #VC or #VE, and the
> page-fault-based fixup handlers for load_unaligned_zeropad() resolve the
> reference. When the encrypted/decrypted transition is complete, mark the
> pages as "present" again.
Change looks good to me. But I am wondering why are adding it part of prepare
and finish callbacks instead of directly in set_memory_encrypted() function.
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
>
> Signed-off-by: Michael Kelley <mhklinux@outlook.com>
> ---
> arch/x86/hyperv/ivm.c | 49 ++++++++++++++++++++++++++++++++++++++++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
> index 8ba18635e338..5ad39256a5d2 100644
> --- a/arch/x86/hyperv/ivm.c
> +++ b/arch/x86/hyperv/ivm.c
> @@ -15,6 +15,7 @@
> #include <asm/io.h>
> #include <asm/coco.h>
> #include <asm/mem_encrypt.h>
> +#include <asm/set_memory.h>
> #include <asm/mshyperv.h>
> #include <asm/hypervisor.h>
> #include <asm/mtrr.h>
> @@ -502,6 +503,31 @@ static int hv_mark_gpa_visibility(u16 count, const u64 pfn[],
> return -EFAULT;
> }
>
> +/*
> + * When transitioning memory between encrypted and decrypted, the caller
> + * of set_memory_encrypted() or set_memory_decrypted() is responsible for
> + * ensuring that the memory isn't in use and isn't referenced while the
> + * transition is in progress. The transition has multiple steps, and the
> + * memory is in an inconsistent state until all steps are complete. A
> + * reference while the state is inconsistent could result in an exception
> + * that can't be cleanly fixed up.
> + *
> + * But the Linux kernel load_unaligned_zeropad() mechanism could cause a
> + * stray reference that can't be prevented by the caller, so Linux has
> + * specific code to handle this case. But when the #VC and #VE exceptions
> + * routed to a paravisor, the specific code doesn't work. To avoid this
> + * problem, mark the pages as "not present" while the transition is in
> + * progress. If load_unaligned_zeropad() causes a stray reference, a normal
> + * page fault is generated instead of #VC or #VE, and the page-fault-based
> + * handlers for load_unaligned_zeropad() resolve the reference. When the
> + * transition is complete, hv_vtom_set_host_visibility() marks the pages
> + * as "present" again.
> + */
> +static bool hv_vtom_clear_present(unsigned long kbuffer, int pagecount, bool enc)
> +{
> + return !set_memory_np(kbuffer, pagecount);
> +}
> +
> /*
> * hv_vtom_set_host_visibility - Set specified memory visible to host.
> *
> @@ -521,7 +547,7 @@ static bool hv_vtom_set_host_visibility(unsigned long kbuffer, int pagecount, bo
>
> pfn_array = kmalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL);
> if (!pfn_array)
> - return false;
> + goto err_set_memory_p;
>
> for (i = 0, pfn = 0; i < pagecount; i++) {
> /*
> @@ -545,14 +571,30 @@ static bool hv_vtom_set_host_visibility(unsigned long kbuffer, int pagecount, bo
> }
> }
>
> - err_free_pfn_array:
> +err_free_pfn_array:
> kfree(pfn_array);
> +
> +err_set_memory_p:
> + /*
> + * Set the PTE PRESENT bits again to revert what hv_vtom_clear_present()
> + * did. Do this even if there is an error earlier in this function in
> + * order to avoid leaving the memory range in a "broken" state. Setting
> + * the PRESENT bits shouldn't fail, but return an error if it does.
> + */
> + if (set_memory_p(kbuffer, pagecount))
> + result = false;
> +
> return result;
> }
>
> static bool hv_vtom_tlb_flush_required(bool private)
> {
> - return true;
> + /*
> + * Since hv_vtom_clear_present() marks the PTEs as "not present"
> + * and flushes the TLB, they can't be in the TLB. That makes the
> + * flush controlled by this function redundant, so return "false".
> + */
> + return false;
> }
>
> static bool hv_vtom_cache_flush_required(void)
> @@ -615,6 +657,7 @@ void __init hv_vtom_init(void)
> x86_platform.hyper.is_private_mmio = hv_is_private_mmio;
> x86_platform.guest.enc_cache_flush_required = hv_vtom_cache_flush_required;
> x86_platform.guest.enc_tlb_flush_required = hv_vtom_tlb_flush_required;
> + x86_platform.guest.enc_status_change_prepare = hv_vtom_clear_present;
> x86_platform.guest.enc_status_change_finish = hv_vtom_set_host_visibility;
>
> /* Set WB as the default cache mode. */
--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer
next prev parent reply other threads:[~2024-01-08 18:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 18:30 [PATCH v3 0/3] x86/hyperv: Mark CoCo VM pages not present when changing encrypted state mhkelley58
2024-01-05 18:30 ` [PATCH v3 1/3] x86/hyperv: Use slow_virt_to_phys() in page transition hypervisor callback mhkelley58
2024-01-08 13:07 ` kirill.shutemov
2024-01-12 1:20 ` Edgecombe, Rick P
2024-01-12 15:07 ` Michael Kelley
2024-01-12 17:17 ` Edgecombe, Rick P
2024-01-12 19:24 ` Michael Kelley
2024-01-15 10:00 ` kirill.shutemov
2024-01-05 18:30 ` [PATCH v3 2/3] x86/mm: Regularize set_memory_p() parameters and make non-static mhkelley58
2024-01-08 13:10 ` kirill.shutemov
2024-01-12 0:56 ` Edgecombe, Rick P
2024-01-05 18:30 ` [PATCH v3 3/3] x86/hyperv: Make encrypted/decrypted changes safe for load_unaligned_zeropad() mhkelley58
2024-01-08 18:37 ` Kuppuswamy Sathyanarayanan [this message]
2024-01-08 19:13 ` Michael Kelley
2024-01-08 19:24 ` Kuppuswamy Sathyanarayanan
2024-01-12 0:26 ` Edgecombe, Rick P
2024-01-12 3:19 ` Michael Kelley
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=a559406d-acd5-40eb-906e-2b8b11739e9e@linux.intel.com \
--to=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jroedel@suse.de \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-coco@lists.linux.dev \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lstoakes@gmail.com \
--cc=luto@kernel.org \
--cc=mhklinux@outlook.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rick.p.edgecombe@intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=urezki@gmail.com \
--cc=wei.liu@kernel.org \
--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