linux-kernel - Re: [PATCH v13 020/113] KVM: TDX: initialize VM with TDX specific parameters

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230405185038.GH1112017@ls.amr.corp.intel.com>
Date:   Wed, 5 Apr 2023 11:50:38 -0700
From:   Isaku Yamahata <isaku.yamahata@...il.com>
To:     Zhi Wang <zhi.wang.linux@...il.com>
Cc:     isaku.yamahata@...el.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, isaku.yamahata@...il.com,
        Paolo Bonzini <pbonzini@...hat.com>, erdemaktas@...gle.com,
        Sean Christopherson <seanjc@...gle.com>,
        Sagi Shahar <sagis@...gle.com>,
        David Matlack <dmatlack@...gle.com>,
        Kai Huang <kai.huang@...el.com>,
        Xiaoyao Li <xiaoyao.li@...el.com>
Subject: Re: [PATCH v13 020/113] KVM: TDX: initialize VM with TDX specific
 parameters

On Tue, Apr 04, 2023 at 10:23:35PM +0300,
Zhi Wang <zhi.wang.linux@...il.com> wrote:

> On Sun, 12 Mar 2023 10:55:44 -0700
> isaku.yamahata@...el.com wrote:
> 
> > From: Isaku Yamahata <isaku.yamahata@...el.com>
> > 
> > TDX requires additional parameters for TDX VM for confidential execution to
> > protect its confidentiality of its memory contents and its CPU state from
> > any other software, including VMM. When creating guest TD VM before
> > creating vcpu, the number of vcpu, TSC frequency (that is same among
> > vcpus. and it can't be changed.) CPUIDs which is emulated by the TDX
>    ^ This sentence seems broken. "

Here is the revised one.

TDX requires additional parameters for TDX VM for confidential execution to
protect the confidentiality of its memory contents and CPU state from any
other software, including VMM.  When creating a guest TD VM before creating
vcpu, the number of vcpu, TSC frequency (the values are the same among
vcpus, and it can't change.)  CPUIDs which the TDX module emulates.  Guest
TDs can trust those CPUIDs and sha384 values for measurement.

Add a new subcommand, KVM_TDX_INIT_VM, to pass parameters for the TDX
guest.  It assigns an encryption key to the TDX guest for memory
encryption.  TDX encrypts memory per guest basis.  The device model, say
qemu, passes per-VM parameters for the TDX guest.  The maximum number of
vcpus, TSC frequency (TDX guest has fixed VM-wide TSC frequency, not per
vcpu.  The TDX guest can not change it.), attributes (production or debug),
available extended features (which configure guest XCR0, IA32_XSS MSR),
CPUIDs, sha384 measurements, etc.

Call this subcommand before creating vcpu and KVM_SET_CPUID2, i.e.  CPUID
configurations aren't available yet.  So CPUIDs configuration values need
to be passed in struct kvm_tdx_init_vm.  The device model's responsibility
to make this CPUID config for KVM_TDX_INIT_VM and KVM_SET_CPUID2.

> > diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
> > index af4c5bd0af1c..68e8d544afe5 100644
> > --- a/arch/x86/include/uapi/asm/kvm.h
> > +++ b/arch/x86/include/uapi/asm/kvm.h
> > @@ -565,6 +565,7 @@ struct kvm_pmu_event_filter {
> >  /* Trust Domain eXtension sub-ioctl() commands. */
> >  enum kvm_tdx_cmd_id {
> >  	KVM_TDX_CAPABILITIES = 0,
> > +	KVM_TDX_INIT_VM,
> >  
> >  	KVM_TDX_CMD_NR_MAX,
> >  };
> > @@ -610,4 +611,27 @@ struct kvm_tdx_capabilities {
> >  	struct kvm_tdx_cpuid_config cpuid_configs[0];
> >  };
> >  
> > +struct kvm_tdx_init_vm {
> > +	__u64 attributes;
> > +	__u64 mrconfigid[6];	/* sha384 digest */
> > +	__u64 mrowner[6];	/* sha384 digest */
> > +	__u64 mrownerconfig[6];	/* sha348 digest */
> > +	/*
> > +	 * For future extensibility to make sizeof(struct kvm_tdx_init_vm) = 8KB.
> > +	 * This should be enough given sizeof(TD_PARAMS) = 1024.
> > +	 * 8KB was chosen given because
> > +	 * sizeof(struct kvm_cpuid_entry2) * KVM_MAX_CPUID_ENTRIES(=256) = 8KB.
> > +	 */
> > +	__u64 reserved[1004];
> > +
> > +	/*
> > +	 * KVM_TDX_INIT_VM is called before vcpu creation, thus before
> > +	 * KVM_SET_CPUID2.
> > +	 * This configuration supersedes KVM_SET_CPUID2s for VCPUs. The user
> > +	 * space VMM, e.g. qemu, should make KVM_SET_CPUID2 consistent with this
> > +	 * values.
>                    ^
>                      It would be nice to have one more sentence to talk about the
> consequence if QEMU configures different CPUIDs in KVM_TDX_INIT_VM and the later
> SET_CPUID2.

Here is the updated one.
	/*
	 * Call KVM_TDX_INIT_VM before vcpu creation, thus before
	 * KVM_SET_CPUID2.
	 * This configuration supersedes KVM_SET_CPUID2s for VCPUs because the
	 * TDX module directly virtualizes those CPUIDs without VMM.  The user
	 * space VMM, e.g. qemu, should make KVM_SET_CPUID2 consistent with
	 * those values.  If it doesn't, KVM may have wrong idea of vCPUIDs of
	 * the guest, and KVM may wrongly emulate CPUIDs or MSRs that the TDX
	 * module doesn't virtualize.
	 */

-- 
Isaku Yamahata <isaku.yamahata@...il.com>