| 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
| ||
|
Message-ID: <BYAPR21MB168841530BB5B793D7695991D7D79@BYAPR21MB1688.namprd21.prod.outlook.com>
Date: Fri, 3 Feb 2023 04:04:08 +0000
From: "Michael Kelley (LINUX)" <mikelley@...rosoft.com>
To: Zhi Wang <zhi.wang.linux@...il.com>,
Tianyu Lan <ltykernel@...il.com>
CC: "luto@...nel.org" <luto@...nel.org>,
"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>,
"x86@...nel.org" <x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>,
"seanjc@...gle.com" <seanjc@...gle.com>,
"pbonzini@...hat.com" <pbonzini@...hat.com>,
"jgross@...e.com" <jgross@...e.com>,
Tianyu Lan <Tianyu.Lan@...rosoft.com>,
"kirill@...temov.name" <kirill@...temov.name>,
"jiangshan.ljs@...group.com" <jiangshan.ljs@...group.com>,
"peterz@...radead.org" <peterz@...radead.org>,
"ashish.kalra@....com" <ashish.kalra@....com>,
"srutherford@...gle.com" <srutherford@...gle.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"anshuman.khandual@....com" <anshuman.khandual@....com>,
"pawan.kumar.gupta@...ux.intel.com"
<pawan.kumar.gupta@...ux.intel.com>,
"adrian.hunter@...el.com" <adrian.hunter@...el.com>,
"daniel.sneddon@...ux.intel.com" <daniel.sneddon@...ux.intel.com>,
"alexander.shishkin@...ux.intel.com"
<alexander.shishkin@...ux.intel.com>,
"sandipan.das@....com" <sandipan.das@....com>,
"ray.huang@....com" <ray.huang@....com>,
"brijesh.singh@....com" <brijesh.singh@....com>,
"michael.roth@....com" <michael.roth@....com>,
"thomas.lendacky@....com" <thomas.lendacky@....com>,
"venu.busireddy@...cle.com" <venu.busireddy@...cle.com>,
"sterritt@...gle.com" <sterritt@...gle.com>,
"tony.luck@...el.com" <tony.luck@...el.com>,
"samitolvanen@...gle.com" <samitolvanen@...gle.com>,
"fenghua.yu@...el.com" <fenghua.yu@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>
Subject: RE: [RFC PATCH V3 00/16] x86/hyperv/sev: Add AMD sev-snp enlightened
guest support on hyperv
From: Zhi Wang <zhi.wang.linux@...il.com> Sent: Thursday, February 2, 2023 3:01 PM
>
> On Sat, 21 Jan 2023 21:45:50 -0500
> Tianyu Lan <ltykernel@...il.com> wrote:
>
> 1) I am thinking if it is a good time to organize a common code path for
> enlightened VM on hyper-v.
>
> Wouldn't it be better to have a common flag for enlightened VM?
> Like bool hv_isolation_type_enlightened()
>
> Many of the decryption of the post msg page... are also required
> in the enlightened TDX guest, they are not AMD-specific.
>
> Then in the "TDX guest on hyper-V" patch set, Dexuan can save some LOCs instead
> of ending up with if (hv_isolation_type_en_snp() ||
> hv_isolation_type_en_tdx())...
I've had the same thought, and have briefly discussed the
idea with Dexuan and Tianyu. But there's some code coming
for a non-confidential VM scenario that hasn't yet been posted
upstream, and it adds yet more cases to consider. We were
thinking to wait a bit until all the cases were evident, and then
find the right simplification. If we try to do the simplification
now, we may need to do it again.
>
> 2) It seems the AMD SEV-SNP enlightened guest on hyper-V is implemented as
> CC_VENDOR_AMD, while TDX enlightened guest is still implemented as
> CC_VENDOR_HYPERV. I am curious about the reason.
Patch set [1] makes CC_VENDOR_HYPERV go away. Once that
happens, the TDX enlightened guest uses CC_VENDOR_INTEL.
Michael
[1] https://lore.kernel.org/linux-hyperv/1673559753-94403-1-git-send-email-mikelley@microsoft.com/T/#m4639d697e9a6619edfcdceffc1b0613a9016f601
>
> > From: Tianyu Lan <tiala@...rosoft.com>
> >
> > This patchset is to add AMD sev-snp enlightened guest
> > support on hyperv. Hyperv uses Linux direct boot mode
> > to boot up Linux kernel and so it needs to pvalidate
> > system memory by itself.
> >
> > In hyperv case, there is no boot loader and so cc blob
> > is prepared by hypervisor. In this series, hypervisor
> > set the cc blob address directly into boot parameter
> > of Linux kernel. If the magic number on cc blob address
> > is valid, kernel will read cc blob.
> >
> > Shared memory between guests and hypervisor should be
> > decrypted and zero memory after decrypt memory. The data
> > in the target address. It maybe smearedto avoid smearing
> > data.
> >
> > Introduce #HV exception support in AMD sev snp code and
> > #HV handler.
> >
> > Change since v2:
> > - Remove validate kernel memory code at boot stage
> > - Split #HV page patch into two parts
> > - Remove HV-APIC change due to enable x2apic from
> > host side
> > - Rework vmbus code to handle error of decrypt page
> > - Spilt memory and cpu initialization patch.
> >
> > Change since v1:
> > - Remove boot param changes for cc blob address and
> > use setup head to pass cc blob info
> > - Remove unnessary WARN and BUG check
> > - Add system vector table map in the #HV exception
> > - Fix interrupt exit issue when use #HV exception
> >
> > Ashish Kalra (2):
> > x86/sev: optimize system vector processing invoked from #HV exception
> > x86/sev: Fix interrupt exit code paths from #HV exception
> >
> > Tianyu Lan (14):
> > x86/hyperv: Add sev-snp enlightened guest specific config
> > x86/hyperv: Decrypt hv vp assist page in sev-snp enlightened guest
> > x86/hyperv: Set Virtual Trust Level in vmbus init message
> > x86/hyperv: Use vmmcall to implement Hyper-V hypercall in sev-snp
> > enlightened guest
> > clocksource/drivers/hyper-v: decrypt hyperv tsc page in sev-snp
> > enlightened guest
> > x86/hyperv: decrypt vmbus pages for sev-snp enlightened guest
> > drivers: hv: Decrypt percpu hvcall input arg page in sev-snp
> > enlightened guest
> > x86/hyperv: Initialize cpu and memory for sev-snp enlightened guest
> > x86/hyperv: SEV-SNP enlightened guest don't support legacy rtc
> > x86/hyperv: Add smp support for sev-snp guest
> > x86/hyperv: Add hyperv-specific hadling for VMMCALL under SEV-ES
> > x86/sev: Add a #HV exception handler
> > x86/sev: Add Check of #HV event in path
> > x86/sev: Initialize #HV doorbell and handle interrupt requests
> >
> > arch/x86/entry/entry_64.S | 82 ++++++
> > arch/x86/hyperv/hv_init.c | 43 +++
> > arch/x86/hyperv/ivm.c | 10 +
> > arch/x86/include/asm/cpu_entry_area.h | 6 +
> > arch/x86/include/asm/hyperv-tlfs.h | 4 +
> > arch/x86/include/asm/idtentry.h | 105 ++++++-
> > arch/x86/include/asm/irqflags.h | 10 +
> > arch/x86/include/asm/mem_encrypt.h | 2 +
> > arch/x86/include/asm/mshyperv.h | 56 +++-
> > arch/x86/include/asm/msr-index.h | 6 +
> > arch/x86/include/asm/page_64_types.h | 1 +
> > arch/x86/include/asm/sev.h | 13 +
> > arch/x86/include/asm/svm.h | 59 +++-
> > arch/x86/include/asm/trapnr.h | 1 +
> > arch/x86/include/asm/traps.h | 1 +
> > arch/x86/include/asm/x86_init.h | 2 +
> > arch/x86/include/uapi/asm/svm.h | 4 +
> > arch/x86/kernel/cpu/common.c | 1 +
> > arch/x86/kernel/cpu/mshyperv.c | 228 ++++++++++++++-
> > arch/x86/kernel/dumpstack_64.c | 9 +-
> > arch/x86/kernel/idt.c | 1 +
> > arch/x86/kernel/sev.c | 395 ++++++++++++++++++++++----
> > arch/x86/kernel/traps.c | 42 +++
> > arch/x86/kernel/vmlinux.lds.S | 7 +
> > arch/x86/kernel/x86_init.c | 4 +-
> > arch/x86/mm/cpu_entry_area.c | 2 +
> > drivers/clocksource/hyperv_timer.c | 2 +-
> > drivers/hv/connection.c | 1 +
> > drivers/hv/hv.c | 33 ++-
> > drivers/hv/hv_common.c | 26 +-
> > include/asm-generic/hyperv-tlfs.h | 19 ++
> > include/asm-generic/mshyperv.h | 2 +
> > include/linux/hyperv.h | 4 +-
> > 33 files changed, 1102 insertions(+), 79 deletions(-)
> >
Powered by blists - more mailing lists