From nobody Wed Dec 17 09:50:19 2025 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5ACA529AD; Tue, 16 Jan 2024 02:20:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZCykdmhL" Received: by mail-pl1-f175.google.com with SMTP id d9443c01a7336-1d5dfda4319so2686595ad.0; Mon, 15 Jan 2024 18:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705371630; x=1705976430; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=WMHKxJ/T5Ct44oYlSE+LYrzOvXToXwBp+RoVB/ApQnM=; b=ZCykdmhLScgfeqb281iOMeUrZMW4PUe2S+xqz/V10DHHmGI+QWxsmEY6eHMIErddtC SquMAIRSHz9auI0PWAOyfZ9g2GqO2TtBDhE06EvyEU0+mbCZj7QwVxRWXVAks91dN41b 5dElEkitgj1l5QFdfB8VsT/173ACtlBN2PnP3v0Gb0KL7dBO2GLDhrxiqlwlV30tjjjn G+BjUgKIlEeXNb34BHZO/dyjjmCoWoDjfdyR6Wf2ipQnjfI8mmob8vtvhu0oaNrPxD6H xnt/iUg9uFHBvC6I0+IptHhEMMFep73VdkmRNlVVGaulGjbnyEPaKL/xwAehdiAbAXNq eByw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705371630; x=1705976430; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=WMHKxJ/T5Ct44oYlSE+LYrzOvXToXwBp+RoVB/ApQnM=; b=sNAvadX+4ztSUX1+veRcMetXfB6jkVy1nTouuHODuLMiVCD/bBTopPm2827YwQWxif QlU5gx7M6eJhKHot5qKFannoXAdackSW95Zdolqf+q2eatsHciiRcacwUmGZjkqIndB+ cx6D63l0HUi8N4OYbhlNhGHkS3Q/KFVup0N2E7xENvy6E91Gewj+5FfIU+af+oXVsZ8O H9h/oresRuzjO6IGj9v9YrKGZyiwWxw0IIV2B6I41nTeW7ZqfC5nGbnzuzZ08HtopJpF cWxIpS3SV8ruzefBIJImfX1Lfo2duu5rhAEezl1vPVlvyqFO7DnGX2m3k9AhdkUdmhUi kefQ== X-Gm-Message-State: AOJu0YyfRLiZuKgE1bGkwbDtI2arpyMPwxreQpLR8KRtxWwJq3DDQb13 sL12w/VGCR1kBR3oCWTWUBg= X-Google-Smtp-Source: AGHT+IGKhIpxJK9risAw80iB9x8SFXIfFEzqHrHFHgbziciGN/6OZbZls+x7EV8Jy+UwtVv+JbHLlQ== X-Received: by 2002:a17:903:2808:b0:1d4:75c6:9560 with SMTP id kp8-20020a170903280800b001d475c69560mr2742635plb.59.1705371630377; Mon, 15 Jan 2024 18:20:30 -0800 (PST) Received: from localhost.localdomain (c-73-254-87-52.hsd1.wa.comcast.net. [73.254.87.52]) by smtp.gmail.com with ESMTPSA id kn14-20020a170903078e00b001d1d1ef8be5sm8193379plb.173.2024.01.15.18.20.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 18:20:30 -0800 (PST) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: 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, sathyanarayanan.kuppuswamy@linux.intel.com, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v4 1/3] x86/hyperv: Use slow_virt_to_phys() in page transition hypervisor callback Date: Mon, 15 Jan 2024 18:20:06 -0800 Message-Id: <20240116022008.1023398-2-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240116022008.1023398-1-mhklinux@outlook.com> References: <20240116022008.1023398-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michael Kelley In preparation for temporarily marking pages not present during a transition between encrypted and decrypted, use slow_virt_to_phys() in the hypervisor callback. As long as the PFN is correct, slow_virt_to_phys() works even if the leaf PTE is not present. The existing functions that depend on vmalloc_to_page() all require that the leaf PTE be marked present, so they don't work. Update the comments for slow_virt_to_phys() to note this broader usage and the requirement to work even if the PTE is not marked present. Signed-off-by: Michael Kelley Acked-by: Kirill A. Shutemov Reviewed-by: Rick Edgecombe --- arch/x86/hyperv/ivm.c | 12 +++++++++++- arch/x86/mm/pat/set_memory.c | 12 ++++++++---- 2 files changed, 19 insertions(+), 5 deletions(-) diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c index 02e55237d919..851107c77f4d 100644 --- a/arch/x86/hyperv/ivm.c +++ b/arch/x86/hyperv/ivm.c @@ -515,6 +515,8 @@ static bool hv_vtom_set_host_visibility(unsigned long k= buffer, int pagecount, bo enum hv_mem_host_visibility visibility =3D enc ? VMBUS_PAGE_NOT_VISIBLE : VMBUS_PAGE_VISIBLE_READ_WRITE; u64 *pfn_array; + phys_addr_t paddr; + void *vaddr; int ret =3D 0; bool result =3D true; int i, pfn; @@ -524,7 +526,15 @@ static bool hv_vtom_set_host_visibility(unsigned long = kbuffer, int pagecount, bo return false; =20 for (i =3D 0, pfn =3D 0; i < pagecount; i++) { - pfn_array[pfn] =3D virt_to_hvpfn((void *)kbuffer + i * HV_HYP_PAGE_SIZE); + /* + * Use slow_virt_to_phys() because the PRESENT bit has been + * temporarily cleared in the PTEs. slow_virt_to_phys() works + * without the PRESENT bit while virt_to_hvpfn() or similar + * does not. + */ + vaddr =3D (void *)kbuffer + (i * HV_HYP_PAGE_SIZE); + paddr =3D slow_virt_to_phys(vaddr); + pfn_array[pfn] =3D paddr >> HV_HYP_PAGE_SHIFT; pfn++; =20 if (pfn =3D=3D HV_MAX_MODIFY_GPA_REP_COUNT || i =3D=3D pagecount - 1) { diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c index bda9f129835e..e76ac64b516e 100644 --- a/arch/x86/mm/pat/set_memory.c +++ b/arch/x86/mm/pat/set_memory.c @@ -755,10 +755,14 @@ pmd_t *lookup_pmd_address(unsigned long address) * areas on 32-bit NUMA systems. The percpu areas can * end up in this kind of memory, for instance. * - * This could be optimized, but it is only intended to be - * used at initialization time, and keeping it - * unoptimized should increase the testing coverage for - * the more obscure platforms. + * Note that as long as the PTEs are well-formed with correct PFNs, this + * works without checking the PRESENT bit in the leaf PTE. This is unlike + * the similar vmalloc_to_page() and derivatives. Callers may depend on + * this behavior. + * + * This could be optimized, but it is only used in paths that are not perf + * sensitive, and keeping it unoptimized should increase the testing cover= age + * for the more obscure platforms. */ phys_addr_t slow_virt_to_phys(void *__virt_addr) { --=20 2.25.1 From nobody Wed Dec 17 09:50:19 2025 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3D319567D; Tue, 16 Jan 2024 02:20:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="k4uDZkcN" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-1d3f2985425so44576845ad.3; Mon, 15 Jan 2024 18:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705371631; x=1705976431; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=c4vfRMdoaViI6HxDtxXy2GwJGspyIYSCzcn+j2z7kh4=; b=k4uDZkcNwgelhv8HFf9nmioP4dIoTWC45t1pAGzvsA86QqktpEMy/9NuCURb1aVa8/ /xCB41ND7GEQS6+nUf7LGkJHTVI38zj/Uw5PSpRD+tSJotap4UAVEuQ57CiQW5GzTkr/ 4uxlT7Fa1f0zG3pMe95oYcptBOeaVIpXwBfWuXs+4BVbzO7bht9HpF9Va9P+psKU4y7X 3aRuSvdQX7tJr49cT+YTzg8wwq3ktGk2DEZYg2zUf1dni54HwAHSs9Zb8DOf+qdT6SuJ fLWhlqhq4EANvg4naXgm749CNKg0GMpXAVeonJNd2Zp4m/uBUriyF2okaWKujl6aKIkh dsEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705371631; x=1705976431; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=c4vfRMdoaViI6HxDtxXy2GwJGspyIYSCzcn+j2z7kh4=; b=G/E76C2tHyt30lzTNBH0IIxfNRyaXxtmTIYajazC/TMZmgO/GC7izy2belKKynlPRh uXydUuuhQ1rkQwP5pIHGon9NETy+lAfr9xPDbyWoIo2y/ON8DF/85YLKlmRAIOVIZ8mD VON8rSLjv06P6mY7JQROdWTLxVbxoY3riuVLRJk80v1TC/vspi09Mu6uT63rQ8LanyV4 ziwPPCLUhwlJE+23gIQOq0p51gHH4IDIOsLypDYFjBlFM4Omp5Yyaq2giBidtEQuamGE ItTUbgZ8ShEvquscjSq3Lqeu0cOpOlvHDES29tceQ1c8+XwmLKf1s+G/nup/Is1SM6hf tHHw== X-Gm-Message-State: AOJu0YyX5nhevSBR0bmCXtluJqPhY4V3frs7GNt7bVsB0SteWlO0zBw+ 9AETX1ds/OpzWPE4aw91YQI= X-Google-Smtp-Source: AGHT+IFRVMIEFLp+rPfL0OtTdnRiBOnM5nFlc0pFAGcjr3KeEtvte2JqdiXRGVdv5FquDNd/HY+qHQ== X-Received: by 2002:a17:902:cec8:b0:1d5:c558:164d with SMTP id d8-20020a170902cec800b001d5c558164dmr1779308plg.74.1705371631546; Mon, 15 Jan 2024 18:20:31 -0800 (PST) Received: from localhost.localdomain (c-73-254-87-52.hsd1.wa.comcast.net. [73.254.87.52]) by smtp.gmail.com with ESMTPSA id kn14-20020a170903078e00b001d1d1ef8be5sm8193379plb.173.2024.01.15.18.20.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 18:20:31 -0800 (PST) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: 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, sathyanarayanan.kuppuswamy@linux.intel.com, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v4 2/3] x86/mm: Regularize set_memory_p() parameters and make non-static Date: Mon, 15 Jan 2024 18:20:07 -0800 Message-Id: <20240116022008.1023398-3-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240116022008.1023398-1-mhklinux@outlook.com> References: <20240116022008.1023398-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michael Kelley set_memory_p() is currently static. It has parameters that don't match set_memory_p() under arch/powerpc and that aren't congruent with the other set_memory_* functions. There's no good reason for the difference. Fix this by making the parameters consistent, and update the one existing call site. Make the function non-static and add it to include/asm/set_memory.h so that it is completely parallel to set_memory_np() and is usable in other modules. No functional change. Signed-off-by: Michael Kelley Reviewed-by: Rick Edgecombe Acked-by: Kirill A. Shutemov --- arch/x86/include/asm/set_memory.h | 1 + arch/x86/mm/pat/set_memory.c | 12 ++++++------ 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_m= emory.h index a5e89641bd2d..9aee31862b4a 100644 --- a/arch/x86/include/asm/set_memory.h +++ b/arch/x86/include/asm/set_memory.h @@ -47,6 +47,7 @@ int set_memory_uc(unsigned long addr, int numpages); int set_memory_wc(unsigned long addr, int numpages); int set_memory_wb(unsigned long addr, int numpages); int set_memory_np(unsigned long addr, int numpages); +int set_memory_p(unsigned long addr, int numpages); int set_memory_4k(unsigned long addr, int numpages); int set_memory_encrypted(unsigned long addr, int numpages); int set_memory_decrypted(unsigned long addr, int numpages); diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c index e76ac64b516e..164d32029424 100644 --- a/arch/x86/mm/pat/set_memory.c +++ b/arch/x86/mm/pat/set_memory.c @@ -2045,17 +2045,12 @@ int set_mce_nospec(unsigned long pfn) return rc; } =20 -static int set_memory_p(unsigned long *addr, int numpages) -{ - return change_page_attr_set(addr, numpages, __pgprot(_PAGE_PRESENT), 0); -} - /* Restore full speculative operation to the pfn. */ int clear_mce_nospec(unsigned long pfn) { unsigned long addr =3D (unsigned long) pfn_to_kaddr(pfn); =20 - return set_memory_p(&addr, 1); + return set_memory_p(addr, 1); } EXPORT_SYMBOL_GPL(clear_mce_nospec); #endif /* CONFIG_X86_64 */ @@ -2108,6 +2103,11 @@ int set_memory_np_noalias(unsigned long addr, int nu= mpages) CPA_NO_CHECK_ALIAS, NULL); } =20 +int set_memory_p(unsigned long addr, int numpages) +{ + return change_page_attr_set(&addr, numpages, __pgprot(_PAGE_PRESENT), 0); +} + int set_memory_4k(unsigned long addr, int numpages) { return change_page_attr_set_clr(&addr, numpages, __pgprot(0), --=20 2.25.1 From nobody Wed Dec 17 09:50:19 2025 Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B2D46FD0; Tue, 16 Jan 2024 02:20:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RFmxPSlS" Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-5c65ca2e1eeso4180740a12.2; Mon, 15 Jan 2024 18:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705371633; x=1705976433; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bse0/qXZQoiuVJq8kHe7VoVGITL3RsI555OnNeb2YB0=; b=RFmxPSlSwG2En+JVP0XLnnym7mG+pfWo7SJThANNtXQmp/HnQiBMu7uUQU3DbHMCMD 1FebT01evkMFwSLUGhUM7kB4gNMIZ214f2ErDwD5DAaNQYsL4m/nPsM1hgPY3nLcn6KO oeg8agVfNoSCcekXX4VzZRKWFIz8xfmbvHVZAKYncGQL26CXV+IGdivwSfpHspeefyoL GbxDK+XcDm5aRM0foW9m1poD/hycKUJsH0h3rHcOo7PLESluQWGr3mAZz7onYmXz2eLi uBFFPNeo0wuRaQRYhzEcSapWCND8bXkwxbjYtbilc30YKC964rFAFVRGHWcw/ZR0cOYP 9RIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705371633; x=1705976433; h=content-transfer-encoding:mime-version:reply-to:references :in-reply-to:message-id:date:subject:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bse0/qXZQoiuVJq8kHe7VoVGITL3RsI555OnNeb2YB0=; b=G0aYv5jZCkRUnBXi4s3jxLKWTp7wHQg97rWL9yoLQHUDCj0krzRWsG2xGPt9Abvg4I cXDOzRikOj54cQSPH0G1hvguNHbVszfWIHAiTDKDeOgKFstiAXj+UbQRa+kZnBMRytnE vJ3cfuqvKCQVjwy7Vxv2XYRRIo15lANSvFCxkVI5CpH7/wmzMvygGXiDtE3/Tsz3+pBv TZE+EiLMaV41viHqF9jcpveNVc310056fX/kdqTSWDVlPV2uxT4kbXLPUIAnRgwJ9Ab2 xx/m7d7SGO0Tkjdu+NtuXV8qgidcI+2kQGksM0qIs0U5VW6YTvNomFtDgv5lFjq2hv++ y85g== X-Gm-Message-State: AOJu0Yz87pxOEnnVcu/zX2u5iTSwa98yUdZnN0k04dCWm/KHm1VJwdBK RS554n4ITHhGQRz35/xYh+o= X-Google-Smtp-Source: AGHT+IEr2+CDYGS0V8/X7I1MGszR2ZNlclrOwLdx0/MeFP/gOuYxw/HddIq+C+XRl375qrBivD1cYQ== X-Received: by 2002:a05:6a20:e618:b0:19b:1da3:bafc with SMTP id my24-20020a056a20e61800b0019b1da3bafcmr760682pzb.4.1705371632710; Mon, 15 Jan 2024 18:20:32 -0800 (PST) Received: from localhost.localdomain (c-73-254-87-52.hsd1.wa.comcast.net. [73.254.87.52]) by smtp.gmail.com with ESMTPSA id kn14-20020a170903078e00b001d1d1ef8be5sm8193379plb.173.2024.01.15.18.20.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jan 2024 18:20:32 -0800 (PST) From: mhkelley58@gmail.com X-Google-Original-From: mhklinux@outlook.com To: 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, sathyanarayanan.kuppuswamy@linux.intel.com, linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, linux-hyperv@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v4 3/3] x86/hyperv: Make encrypted/decrypted changes safe for load_unaligned_zeropad() Date: Mon, 15 Jan 2024 18:20:08 -0800 Message-Id: <20240116022008.1023398-4-mhklinux@outlook.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20240116022008.1023398-1-mhklinux@outlook.com> References: <20240116022008.1023398-1-mhklinux@outlook.com> Reply-To: mhklinux@outlook.com Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michael Kelley 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. Signed-off-by: Michael Kelley Reviewed-by: Kuppuswamy Sathyanarayanan --- arch/x86/hyperv/ivm.c | 53 +++++++++++++++++++++++++++++++++++++++---- 1 file changed, 49 insertions(+), 4 deletions(-) diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c index 851107c77f4d..95036feb95e7 100644 --- a/arch/x86/hyperv/ivm.c +++ b/arch/x86/hyperv/ivm.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include #include @@ -502,6 +503,31 @@ static int hv_mark_gpa_visibility(u16 count, const u64= pfn[], return -EFAULT; } =20 +/* + * 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, bo= ol enc) +{ + return !set_memory_np(kbuffer, pagecount); +} + /* * hv_vtom_set_host_visibility - Set specified memory visible to host. * @@ -522,8 +548,10 @@ static bool hv_vtom_set_host_visibility(unsigned long = kbuffer, int pagecount, bo int i, pfn; =20 pfn_array =3D kmalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL); - if (!pfn_array) - return false; + if (!pfn_array) { + result =3D false; + goto err_set_memory_p; + } =20 for (i =3D 0, pfn =3D 0; i < pagecount; i++) { /* @@ -548,14 +576,30 @@ static bool hv_vtom_set_host_visibility(unsigned long= kbuffer, int pagecount, bo } } =20 - 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 =3D false; + return result; } =20 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; } =20 static bool hv_vtom_cache_flush_required(void) @@ -618,6 +662,7 @@ void __init hv_vtom_init(void) x86_platform.hyper.is_private_mmio =3D hv_is_private_mmio; x86_platform.guest.enc_cache_flush_required =3D hv_vtom_cache_flush_requi= red; x86_platform.guest.enc_tlb_flush_required =3D hv_vtom_tlb_flush_required; + x86_platform.guest.enc_status_change_prepare =3D hv_vtom_clear_present; x86_platform.guest.enc_status_change_finish =3D hv_vtom_set_host_visibili= ty; =20 /* Set WB as the default cache mode. */ --=20 2.25.1