Pre-built architectural enclaves contain redundant NixOS ld-linux path #1040
Comments
|
@berrange The AE reproducibility build is based on the provided docker file with Nix env. So we assume the reproducibility verification is also based on the same environment from the provided docker. |
I'm aiming to distribute the pre-built AE's in Fedora, but as a pre-requisite for proposing that be allowed by Fedora, I need to be able to reproduce their build process within Fedora, not NixOS. This isn't easy, as obviously you've never expected/intended for this to be done. The three biggest issues that affect reproducibility which I'm having to patch
I've not had time to investigate whether there's an easy way to avoid the absolute files paths in the last 2 cases, so I've not filed any issues requesting changes for those yet. FYI, I've currently got reproducibility succeeding for SGX 2.22 release, and now working on 2.24 release for the qve.so AE that was re-issued. https://gitlab.com/berrange/fedora-sgx-ng-copr/-/tree/main/linux-sgx-enclaves-2_22?ref_type=heads Of course this all relies on me packaging the same versions of GCC, binutils, nasm that your NixOS env uses, which I've done in that same git repo. |
The enclaves are getting built as ELF executables, and thus the linker
will embed the current ld-linux.so path for the host OS environment
in the binary:
$ readelf -a libsgx_pce.signed.so | grep interpreter
[Requesting program interpreter: /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib/ld-linux-x86-64.so.2]
The SGX enclaves are never loaded using ld-linux.so, as SGX has custom
code for loading enclaves in the required manner.
This embedded ld-linux.so path thus serves no functional purpose, while
also making it harder to do a reproducible build of the enclaves outside
of the NixOS environment.
This patch blanks out the NixOX interpretor path, by setting it to the
empty string.
Fixes: intel#1040
Signed-off-by: Daniel P. Berrangé <[email protected]>
The enclaves are getting built as ELF executables, and thus the linker
will embed the current ld-linux.so path for the host OS environment
in the binary:
$ readelf -a libsgx_tdqe.signed.so | grep interpreter
[Requesting program interpreter: /nix/store/xmprbk52mlcdsljz66m8yf7cf0xf36n1-glibc-2.38-44/lib/ld-linux-x86-64.so.2]
The SGX enclaves are never loaded using ld-linux.so, as SGX has custom
code for loading enclaves in the required manner.
This embedded ld-linux.so path thus serves no functional purpose, while
also making it harder to do a reproducible build of the enclaves outside
of the NixOS environment.
This patch blanks out the NixOX interpretor path, by setting it to the
empty string.
Related: intel/linux-sgx#1040
Signed-off-by: Daniel P. Berrangé <[email protected]>
Attempting to reproduce the architectural enclaves on a non-NixOS platform fails, despite having the same toolchain versions. Debugging revealed that this is a result of the built enclaves containing a reference to the NixOS ld-linux path.
This can be easily seen by querying the INTERP section of the binaries
IIUC, the ld-linux interpretor is irrelevant for SGX, since the SGX SDK contains native logic for loading code into the enclaves. If this is indeed the case, then I'd request that the reference to the NixOX ld-linux is removed from future pre-built enclave binaries.
Looking at the build system this could potentially be achieved by extending the 'strip' command usage to also purge the '.interp' section of the ELF binary.
Alternatively the
-Wl,-dynamic-linkerarg could be used to set the .interp section contents to some dummy value to indicate it is redundant / unused e.g.There are probably other options too - I don't mind as long as this (apparently) redundant NixOS path can be removed from future pre-built enclave binaries.
The text was updated successfully, but these errors were encountered: