submodules: update Intel repo URLs to canonical names to fix CI

[Hayao0819]

After #104 the intel-sdk and oe-sdk jobs have been failing at submodule fetch:

fatal: clone of 'https://github.com/01org/confidential-computing.tee.dcap.git' into submodule path '.../external/dcap_source' failed

linux-sgx v2.29 points to dcap_source via a relative URL (../confidential-computing.tee.dcap.git). Git resolves that against the parent submodule URL before following any HTTP redirects, so a parent URL of 01org/linux-sgx makes the sibling resolve to 01org/confidential-computing.tee.dcap, which doesn't exist. Earlier linux-sgx versions used an absolute URL here, which is why this only broke after #104.

Switching the linux-sgx submodule to Intel's current name (intel/confidential-computing.sgx) makes the sibling resolve to intel/confidential-computing.tee.dcap (HTTP 200), and git submodule update works again. linux-sgx-driver is updated to intel/linux-sgx-driver in the same commit for consistency; the old 01org/ URL still 301-redirects, so that part is cosmetic.

Sorry, I should have caught the relative-URL behavior when verifying #104.

[Hayao0819]

By the way, what should we do about the linux-sgx-driver? It has already been archived and fails to compile with the latest kernel. My fork ( https://github.com/Hayao0819/linux-sgx-driver ) was compatible with the latest kernel, but it has finally stopped working with the latest SGX SDK.

However, it works with other SDKs such as EGo and OpenEnclave, and you can continue to use it by patching the SGX SDK.

[jovanbulck]

Many thanks @Hayao0819 for the catch and detailed explanation! Merged.

By the way, what should we do about the linux-sgx-driver? It has already been archived and fails to compile with the latest kernel. My fork ( https://github.com/Hayao0819/linux-sgx-driver ) was compatible with the latest kernel

That's a good point. I should probably update the README and the submodule at some point. This is mostly/only relevant for older hardware though -- but it would be nice to remain compatible with such older machines if useful. maybe we can point the submodule to your fork if that's the official one doesn't work anymore and is not updated.

, but it has finally stopped working with the latest SGX SDK.

However, it works with other SDKs such as EGo and OpenEnclave, and you can continue to use it by patching the SGX SDK.

The plan on the short-term is to refactor SGX-Step to remove this SDK dependency and make it work with any SDK without requiring custom urts patches. The idea is to binary-patch the URTS at runtime/loadtime to intercept ENCLU[EENTER/ERESUME] instructions and add the custom logic there directly. See also: #28

So that will clean-up the repo a lot if the custom patched SDK is no longer a dependncy :)

[Hayao0819]

Thank you for merging them. Switching to my fork should be welcome news for users who rely on older hardware. Many consumer-grade motherboards do not support FLC and still require boot control via Launch Encvale.

I plan to continue maintaining this legacy driver for the foreseeable future, so I have no objection to it being referenced from this repository.