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