From f583aa9d30d2638bedc19cbb811997e3e9604d34 Mon Sep 17 00:00:00 2001 From: Mikko Ylinen Date: Wed, 4 Nov 2020 17:27:04 +0200 Subject: [PATCH] sgx: update virt EPC device path and docs Based on the LKML feedback, the devices under /dev/sgx/* are not justified. SGX RFC v40 moves the SGX device nodes to /dev/sgx_* and this is reflected in kvm-sgx (next branch) too. Update cloud-hypervisor code and documentation to follow this. Signed-off-by: Mikko Ylinen --- docs/intel_sgx.md | 10 +++++----- vmm/src/memory_manager.rs | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/intel_sgx.md b/docs/intel_sgx.md index 121b88af7..2f28fd122 100644 --- a/docs/intel_sgx.md +++ b/docs/intel_sgx.md @@ -8,7 +8,7 @@ the host kernel. The required Linux and KVM changes can be found in the [KVM SGX Tree](https://github.com/intel/kvm-sgx). Utilizing SGX in the guest requires a kernel/OS with SGX support, e.g. a kernel -built using the [SGX Linux Development Tree](https://github.com/jsakkine-intel/linux-sgx.git) +built using the [SGX Linux Development Tree](https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-sgx.git) or the [KVM SGX Tree](https://github.com/intel/kvm-sgx). Running KVM SGX as the guest kernel allows nested virtualization of SGX. @@ -19,7 +19,7 @@ following [instructions](https://github.com/intel/linux-sgx). ## Cloud-Hypervisor support -Assuming the host exposes `/dev/sgx/virt_epc`, we can pass SGX enclaves through +Assuming the host exposes `/dev/sgx_virt_epc`, we can pass SGX enclaves through the guest. In order to use SGX enclaves within a Cloud-Hypervisor VM, we must define one @@ -42,12 +42,12 @@ Once booted, and assuming your guest kernel contains the patches from the have been correctly created under `/dev/sgx`: ```bash -ls /dev/sgx -enclave provision virt_epc +ls /dev/sgx* +/dev/sgx_enclave /dev/sgx_provision /dev/sgx_virt_epc ``` From this point, it is possible to run any SGX application from the guest, as -it will access `/dev/sgx/enclave` device to create dedicated SGX enclaves. +it will access `/dev/sgx_enclave` device to create dedicated SGX enclaves. Note: There is only one contiguous SGX EPC region, which contains all SGX EPC sections. This region is exposed through ACPI and marked as reserved through diff --git a/vmm/src/memory_manager.rs b/vmm/src/memory_manager.rs index 1f8b77e87..98869f3a6 100644 --- a/vmm/src/memory_manager.rs +++ b/vmm/src/memory_manager.rs @@ -1348,7 +1348,7 @@ impl MemoryManager { let file = OpenOptions::new() .read(true) .write(true) - .open("/dev/sgx/virt_epc") + .open("/dev/sgx_virt_epc") .map_err(Error::SgxVirtEpcOpen)?; let prot = PROT_READ | PROT_WRITE; @@ -1359,7 +1359,7 @@ impl MemoryManager { // We can't use the vm-memory crate to perform the memory mapping // here as it would try to ensure the size of the backing file is - // matching the size of the expected mapping. The /dev/sgx/virt_epc + // matching the size of the expected mapping. The /dev/sgx_virt_epc // device does not work that way, it provides a file descriptor // which is not matching the mapping size, as it's a just a way to // let KVM know that an EPC section is being created for the guest.