Re: [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver

[Jethro Beekman <jethro@fortanix.com>]

[-- Attachment #1: Type: text/plain, Size: 2739 bytes --]

On 2019-04-22 14:58, Sean Christopherson wrote:
> +Cc Jethro
> 
> On Wed, Apr 17, 2019 at 01:39:25PM +0300, Jarkko Sakkinen wrote:
>> Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
>> can be used by applications to set aside private regions of code and
>> data. The code outside the enclave is disallowed to access the memory
>> inside the enclave by the CPU access control.
>>
>> This commit adds the Linux SGX Enclave Driver that provides an ioctl API
>> to manage enclaves. The address range for an enclave, commonly referred
>> as ELRANGE in the documentation (e.g. Intel SDM), is reserved with
>> mmap() against /dev/sgx/enclave. After that a set ioctls is used to
>> build the enclave to the ELRANGE.
>>
>> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
>> Co-developed-by: Sean Christopherson <sean.j.christopherson@intel.com>
>> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
>> Co-developed-by: Serge Ayoun <serge.ayoun@intel.com>
>> Signed-off-by: Serge Ayoun <serge.ayoun@intel.com>
>> Co-developed-by: Shay Katz-zamir <shay.katz-zamir@intel.com>
>> Signed-off-by: Shay Katz-zamir <shay.katz-zamir@intel.com>
>> Co-developed-by: Suresh Siddha <suresh.b.siddha@intel.com>
>> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
>> ---
> 
> ...
> 
>> +#ifdef CONFIG_ACPI
>> +static struct acpi_device_id sgx_device_ids[] = {
>> +	{"INT0E0C", 0},
>> +	{"", 0},
>> +};
>> +MODULE_DEVICE_TABLE(acpi, sgx_device_ids);
>> +#endif
>> +
>> +static struct platform_driver sgx_drv = {
>> +	.probe = sgx_drv_probe,
>> +	.remove = sgx_drv_remove,
>> +	.driver = {
>> +		.name			= "sgx",
>> +		.acpi_match_table	= ACPI_PTR(sgx_device_ids),
>> +	},
>> +};
> 
> Where do we stand on removing the ACPI and platform_driver dependencies?
> Can we get rid of them sooner rather than later?

You know my position on this... 
https://www.spinics.net/lists/linux-sgx/msg00624.html . I don't really 
have any new arguments.

Considering the amount of planned changes for the driver post-merge, I 
think it's crucial that the driver part can be swapped out with 
alternative implementations.

> Now that the core SGX code is approaching stability, I'd like to start
> sending RFCs for the EPC virtualization and KVM bits to hash out that side
> of things.  The ACPI crud is the last chunk of code that would require
> non-trivial changes to the core SGX code for the proposed virtualization
> implementation.  I'd strongly prefer to get it out of the way before
> sending the KVM RFCs.

What kind of changes? Wouldn't KVM just be another consumer of the same 
API used by the driver?

--
Jethro Beekman | Fortanix


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3990 bytes --]