You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The in-tree Linux kernel SGX driver creates the enclave device at /dev/sgx_enclave and the provisioning device at /dev/sgx_provision. In contrast, the out-of-tree DCAP driver used to create those devices nested below an sgx subdirectory, i.e., /dev/sgx/enclave and /dev/sgx/provision.
For backward compatibility, linux-sgx today ships udev rules to create symlinks from /dev/sgx/enclave to /dev/sgx_enclave and /dev/sgx/provision to /dev/sgx_provision. This seems reasonable; however, most—if not all—of the linux-sgx code still seems to reference the enclave and provision devices below /dev/sgx/:
The comments suggest that the in-tree Linux driver creates the devices within /dev/sgx/ which is clearly not the case.
The current behavior causes all SGX applications to fail if the executing host uses the in-tree driver without a symbolic link /dev/sgx/enclave -> ../sgx_enclave.
This is very relevant as systemd decided to not provide a symlink: systemd/systemd#18944 (comment). Also, NixOS does not install any of the udev rules provided in this repository (too permissive). As far as I can tell, the SDK/PSW routines should try opening /dev/sgx_{enclave,provision} instead of /dev/sgx/{enclave,provision}*. At least, they should also try the actual path of the SGX kernel devices, i.e., /dev/sgx_enclave and /dev/sgx_provision.
The text was updated successfully, but these errors were encountered:
Thanks for reporting this issue. We have already updated the related modules to fix this in the internal repo some time ago. It will be included in the next release. Please stay tuned.
The in-tree Linux kernel SGX driver creates the enclave device at
/dev/sgx_enclave
and the provisioning device at/dev/sgx_provision
. In contrast, the out-of-tree DCAP driver used to create those devices nested below ansgx
subdirectory, i.e.,/dev/sgx/enclave
and/dev/sgx/provision
.For backward compatibility,
linux-sgx
today ships udev rules to create symlinks from/dev/sgx/enclave
to/dev/sgx_enclave
and/dev/sgx/provision
to/dev/sgx_provision
. This seems reasonable; however, most—if not all—of thelinux-sgx
code still seems to reference theenclave
andprovision
devices below/dev/sgx/
:linux-sgx/psw/urts/linux/edmm_utility.cpp
Line 102 in 2ee53db
linux-sgx/psw/urts/linux/edmm_utility.cpp
Line 152 in 2ee53db
linux-sgx/psw/enclave_common/sgx_enclave_common.cpp
Lines 472 to 474 in 2ee53db
The comments suggest that the in-tree Linux driver creates the devices within
/dev/sgx/
which is clearly not the case.The current behavior causes all SGX applications to fail if the executing host uses the in-tree driver without a symbolic link
/dev/sgx/enclave -> ../sgx_enclave
.This is very relevant as systemd decided to not provide a symlink: systemd/systemd#18944 (comment). Also, NixOS does not install any of the udev rules provided in this repository (too permissive). As far as I can tell, the SDK/PSW routines should try opening
/dev/sgx_{enclave,provision}
instead of/dev/sgx/{enclave,provision}*
. At least, they should also try the actual path of the SGX kernel devices, i.e.,/dev/sgx_enclave
and/dev/sgx_provision
.The text was updated successfully, but these errors were encountered: