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

Kai Huang
2021-01-07T01:51:29Z

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". :)