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

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Tue, 23 Apr 2019 23:29:24 +0000
From:   Jethro Beekman <jethro@...tanix.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>,
        "linux-sgx@...r.kernel.org" <linux-sgx@...r.kernel.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "dave.hansen@...el.com" <dave.hansen@...el.com>,
        "nhorman@...hat.com" <nhorman@...hat.com>,
        "npmccallum@...hat.com" <npmccallum@...hat.com>,
        "serge.ayoun@...el.com" <serge.ayoun@...el.com>,
        "shay.katz-zamir@...el.com" <shay.katz-zamir@...el.com>,
        "haitao.huang@...el.com" <haitao.huang@...el.com>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "kai.svahn@...el.com" <kai.svahn@...el.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "josh@...htriplett.org" <josh@...htriplett.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "kai.huang@...el.com" <kai.huang@...el.com>,
        "rientjes@...gle.com" <rientjes@...gle.com>
Subject: Re: [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver

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@...ux.intel.com>
>> Co-developed-by: Sean Christopherson <sean.j.christopherson@...el.com>
>> Signed-off-by: Sean Christopherson <sean.j.christopherson@...el.com>
>> Co-developed-by: Serge Ayoun <serge.ayoun@...el.com>
>> Signed-off-by: Serge Ayoun <serge.ayoun@...el.com>
>> Co-developed-by: Shay Katz-zamir <shay.katz-zamir@...el.com>
>> Signed-off-by: Shay Katz-zamir <shay.katz-zamir@...el.com>
>> Co-developed-by: Suresh Siddha <suresh.b.siddha@...el.com>
>> Signed-off-by: Suresh Siddha <suresh.b.siddha@...el.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


Download attachment "smime.p7s" of type "application/pkcs7-signature" (3990 bytes)