Upgrade to Intel SGX Linux 2.4 Release

[tomtau]

https://01.org/node/29957

[dingelish]

Hi @tomtau ,

I'm busy working with this but encountered a lot of problems. For example, v2.4 has some bugs and I just filed PR and waiting for response. And I have a pending PR at Rust to fix xargo build failure in most recent Rust nightly (issue here).

Here are a minimal solution for v2.4:

1. Install the 2.4 suite, and patch libsgx_tstdc.a as usual.
2. Use patch from this PR to generate a new aesm_service binary and copy it to /opt/intel/libsgx-enclave-common/aesm/aesm_service to overwrite.
3. Stay on nightly-2018-10-01. Do not upgrade to most recent nightly. (issue here).
4. When linking with trts, e.g. -l$(Trts_Library_Name), add another link flag to libsgx_tservice.a. For example, the new linking flag may be -l$(Trts_Library_Name) -l$(Service_Library_Name).

Plan:
After Intel fixessgx_report_attestation_status, and the patch to Rust merged, I'll release next version asap!

Best,
Yu

[dingelish]

Update: PR to Rust has been merged.

Still waiting for Intel's response.

[dingelish]

Update: found another linking problem when linking with libsgx_tstdc.a, about multiple definition of memcpy, memcmp and memset. The collision roots from Fortanix's recent commits and I've submitted a PR to fix. Waiting for Rust team's response.

[dingelish]

Update: the patch to compiler-builtins has been merged and compiler-builtins is upgraded to v1.0.4. On the Rust side, the dependency of compiler-builtins is maintained in Cargo.lock and the upgrade of compiler-builtin is approved and pending for merge.

[dingelish]

Update: all existing PRs to Rust has been merged and nightly-2019-01-09 works well on my unreleased version. Intel confirms that the problem of report checking is a bug, but the fix is being tested and has not been merged. So now I have two choices:

(1) wait until 2.4.1 and skip 2.4
(2) release with 2.4 support and add my own aesm patch. after the release of 2.4.1, upgrade to 2.4.1

Which one do you guys prefer?

[tomtau]

Probably wait for 2.4.1?

[elichai]

Yeah I'll say wait for 2.4.1,
Anyway each upgrade requires a lot of work on our sides too (I'll guess anyone who's using this have their own forks of stuff)
And I'll want to also try and see if using your version from crates.io works for us :)

[dingelish]

@tomtau @elichai
Seems that we'd better wait for 2.4.1 according to the security advisory
https://www.intel.com/content/www/us/en/security-center/advisory/INTEL-SA-00203.html

[elichai]

BTW, do you know if there's some mailing list or subscription that I can get notified for these vulnerabilities?

[tarcieri]

@elichai you should receive them if you're enrolled in the SGX Program (which you'll need to be in order to sign production enclaves)

[elichai]

@tarcieri I am enrolled, but all I get from them is some spam on compute vision lol

[elichai]

@dingelish Is there a way to know when 2.4.1 will be released? if not It might be better to use a patch because a couple of changes with unstable features getting stable (specifically const_fn) makes using some libraries a bit more difficult
(Or maybe you can release an update just to the compiler and dockers and wait for 2.4.1 for updating the sdk?)

[dingelish]

@elichai Yesterday I asked Intel the same question and they answered that the current 2.4 is exactly 2.4.100. There is no 2.4.1. It seems that the current 2.4 has already patched IPP bug (but not the sig verification bug which is fixed later).

I can provide a branch to support recent Rust nightly today. And I'll need another few days for documentation and rust-stable branch. Is this ok for you? I think the next v1.0.5 could be ready next week.