lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 13 Nov 2022 16:01:45 +0000 From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com> To: Tom Lendacky <thomas.lendacky@....com>, "hpa@...or.com" <hpa@...or.com>, KY Srinivasan <kys@...rosoft.com>, Haiyang Zhang <haiyangz@...rosoft.com>, "wei.liu@...nel.org" <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>, "luto@...nel.org" <luto@...nel.org>, "peterz@...radead.org" <peterz@...radead.org>, "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>, "lpieralisi@...nel.org" <lpieralisi@...nel.org>, "robh@...nel.org" <robh@...nel.org>, "kw@...ux.com" <kw@...ux.com>, "bhelgaas@...gle.com" <bhelgaas@...gle.com>, "arnd@...db.de" <arnd@...db.de>, "hch@...radead.org" <hch@...radead.org>, "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>, "robin.murphy@....com" <robin.murphy@....com>, "brijesh.singh@....com" <brijesh.singh@....com>, "tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>, "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, Tianyu Lan <Tianyu.Lan@...rosoft.com>, "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>, "sathyanarayanan.kuppuswamy@...ux.intel.com" <sathyanarayanan.kuppuswamy@...ux.intel.com>, "ak@...ux.intel.com" <ak@...ux.intel.com>, "isaku.yamahata@...el.com" <isaku.yamahata@...el.com>, "Williams, Dan J" <dan.j.williams@...el.com>, "jane.chu@...cle.com" <jane.chu@...cle.com>, "seanjc@...gle.com" <seanjc@...gle.com>, "tony.luck@...el.com" <tony.luck@...el.com>, "x86@...nel.org" <x86@...nel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "iommu@...ts.linux.dev" <iommu@...ts.linux.dev> Subject: RE: [PATCH v2 05/12] x86/hyperv: Change vTOM handling to use standard coco mechanisms From: Tom Lendacky <thomas.lendacky@....com> Sent: Friday, November 11, 2022 10:50 AM > > On 11/11/22 00:21, Michael Kelley wrote: [snip] > > diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c > > index 06eb8910..024fbf4 100644 > > --- a/arch/x86/mm/pat/set_memory.c > > +++ b/arch/x86/mm/pat/set_memory.c > > @@ -2126,10 +2126,8 @@ static int __set_memory_enc_pgtable(unsigned long > addr, int numpages, bool enc) > > > > static int __set_memory_enc_dec(unsigned long addr, int numpages, bool enc) > > { > > - if (hv_is_isolation_supported()) > > - return hv_set_mem_host_visibility(addr, numpages, !enc); > > - > > - if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) > > + if (cc_platform_has(CC_ATTR_MEM_ENCRYPT) || > > + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT)) > > This seems kind of strange since CC_ATTR_MEM_ENCRYPT is supposed to mean > either HOST or GUEST memory encryption, but then you check for GUEST > memory encryption directly. Can your cc_platform_has() support be setup to > handle the CC_ATTR_MEM_ENCRYPT attribute in some way? > > Thanks, > Tom Current upstream code for Hyper-V guests with vTOM enables only CC_ATTR_GUEST_MEM_ENCRYPT. I had been wary of also enabling CC_ATTR_MEM_ENCRYPT because that would enable other code paths that Might not be right for the vTOM case. But looking at it more closely, enabling CC_ATTR_MEM_ENCRYPT may work. There are two problems with Hyper-V vTOM enabling CC_ATTR_MEM_ENCRYPT, but both are fixable: 1) The call to mem_encrypt_init() happens a little bit too soon. Hyper-V is fully initialized and hypercalls become possible after start_kernel() calls late_time_init(). mem_encrypt_init() needs to happen after the call to late_time_init() so that marking the swiotlb memory as decrypted can make the hypercalls to sync the page state change with the host. Moving mem_encrypt_init() a few lines later in start_kernel() works in my case, but I can't test all the cases that you probably have. This change also has the benefit of removing the call to swiotlb_update_mem_attributes() at the end of hyperv_init(), which always seemed like a hack. 2) mem_encrypt_free_decrypted_mem() is mismatched with sme_postprocess_startup() in its handling of bss decrypted memory. The decryption is done if sme_me_mask is non-zero, while the re-encryption is done if CC_ATTR_MEM_ENCRYPT is true, and those conditions won't be equivalent in a Hyper-V vTOM VM if we enable CC_ATTR_MEM_ENCRYPT (sme_me_mask is always zero in a Hyper-V vTOM VM). Changing mem_encrypt_free_decrypted_mem() to do re-encryption only if sme_me_mask is non-zero solves that problem. Note that there doesn't seem to be a way for a Hyper-V vTOM VM to have decrypted bss, since there's no way to sync the page state change with the host that early in the boot process, but I don't think there's a requirement for such, so all is good. With the above two changes, Hyper-V vTOM VMs can enable CC_ATTR_MEM_ENCRYPT. The Hyper-V hack in __set_memory_enc_dec() still goes away, and there's no change to the condition for invoking __set_memory_enc_pgtable(). Thoughts? Have I missed anything? Overall, I'm persuaded that this is a better approach and can submit a v3 patch series with these changes if you agree. Michael
Powered by blists - more mailing lists