Re: [RFC PATCH 00/23] KVM SGX virtualization support

From: Kai Huang <kai.huang@intel.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: <linux-sgx@vger.kernel.org>, <kvm@vger.kernel.org>,
	<x86@kernel.org>, <seanjc@google.com>, <jarkko@kernel.org>,
	<luto@kernel.org>, <haitao.huang@intel.com>,
	<pbonzini@redhat.com>, <bp@alien8.de>, <tglx@linutronix.de>,
	<mingo@redhat.com>, <hpa@zytor.com>, <jethro@fortanix.com>,
	<b.thiel@posteo.de>, <jmattson@google.com>, <joro@8bytes.org>,
	<vkuznets@redhat.com>, <wanpengli@tencent.com>, <corbet@lwn.net>
Subject: Re: [RFC PATCH 00/23] KVM SGX virtualization support
Date: Thu, 7 Jan 2021 14:50:26 +1300	[thread overview]
Message-ID: <20210107145026.a8f593323ab9ae34874250ed@intel.com> (raw)
In-Reply-To: <d586730e-d02f-8059-0a81-cbfd762deacf@intel.com>

On Wed, 6 Jan 2021 16:48:58 -0800 Dave Hansen wrote:
> On 1/6/21 4:34 PM, Kai Huang wrote:
> > On Wed, 6 Jan 2021 09:07:13 -0800 Dave Hansen wrote:
> >> Does the *ABI* here preclude doing oversubscription in the future?
> > 
> > I am Sorry what *ABI* do you mean?
> 
> Oh boy.
> 
> https://en.wikipedia.org/wiki/Application_binary_interface
> 
> In your patch set that you are posting, /dev/sgx_virt_epc is a new
> interface: a new ABI.  If we accept your contribution, programs will be
> build around and expect Linux to support this ABI.  An ABI is a contract
> between software written to use it and the kernel.  The kernel tries
> *really* hard to never break its contracts with applications.

Thanks.

> 
> OK, now that we have that out of the way, I'll ask my question in
> another way:
> 
> Your series adds some new interfaces, including /dev/sgx_virt_epc.  If
> the kernel wants to add oversubscription in the future, will old binary
> application users of /dev/sgx_virt_epc be able to support
> oversubscription?  Or, would users of /dev/sgx_virt_epc need to change
> to support oversubscription?

Oversubscription will be completely done in kernel/kvm, and will be
transparent to userspace, so it will not impact ABI.

> 
> >> Also, didn't we call this "Flexible Launch Control"?
> > 
> > I am actually a little bit confused about all those terms here. I don't think
> > from spec's perspective, there's such thing "Flexible Launch Control", but I
> > think everyone knows what does it mean. But I am not sure whether it is
> > commonly used by community. 
> > 
> > I think using FLC is fine if we only want to mention unlocked mode. But if you
> > want to mention both, IMHO it would be better to specifically use LC locked
> > mode and unlocked mode, since technically there's third case that LC is not
> > present at all.
> 
> Could you go over the changelogs from Jarkko's patches and at least make
> these consistent with those?

I'll dig into them.

[...]

> >>> - Restricit SGX guest access to provisioning key
> >>>
> >>> To grant guest being able to fully use SGX, guest needs to be able to create
> >>> provisioning enclave.
> >>
> >> "enclave" or "enclaves"?
> > 
> > I think should be "enclave", inside one VM, there should only be one
> > provisioning enclave.
> 
> This is where the language becomes important.  Is the provisioning
> enclave a one-shot deal?  You create one per guest and can never create
> another?  Or, can you restart it?  Can you architecturally have more
> than one active at once?  Or, can you only create one once the first one
> dies?
> 
> You'll write that sentence differently based on the answers.
> 

I think I can just change to "guest needs to be able to access provisioning
key". :)