lkml.org 
[lkml]   [2019]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v20 15/28] x86/sgx: Add the Linux SGX Enclave Driver
    Date
    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

    [unhandled content-type:application/pkcs7-signature]
    \
     
     \ /
      Last update: 2019-04-24 01:29    [W:3.265 / U:0.504 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site