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
I can successfully reproduce the SGX AE build for 2.22 and 2.23, but when I attempt to reproduce the AE build using the 2.24 release and its declared NixOX package versions, it fails.
Upon investigating this I've found that the build process is not in fact correctly using the glibc and binutils versions declared in the Dockerfile.
Code is being assembled with binutils 2.40, NOT 2.38.
This is because the update to GCC 9.5.0 has pulled in binutils 2.40, despite the NixOS config requesting 2.38. In fact both 2.38 and 2.40 appear to be installed in parallel, but 2.40 is the version being used.
We can see what is in $PATH, which matches the Dockerfile request for binutils 2.38:
$ which as
/nix/store/v72qcv0mz67akqxm2j8n799j3fvrxg9r-wp7kc5y840ldi5sd8j81fj4dabccff2d-binutils-wrapper-2.38/bin/as
$ as --version
GNU assembler (GNU Binutils) 2.38
Copyright (C) 2022 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-unknown-linux-gnu'.
Actually running GCC though tells us the truth about what is used:
$ cat > hello.c
void foo(void) {}
$ gcc -v -c hello.c 2>&1 | grep -E '(/as|Binutils)'
/nix/store/95nvd0v2xzf9vcv3kk4nmkjlcalc1jn7-gcc-wrapper-9.5.0/bin/as -v --64 -o /tmp/cchCB1RW.o /tmp/ccXEP3BW.s
GNU assembler version 2.40 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.40
$ ls -al /nix/store/95nvd0v2xzf9vcv3kk4nmkjlcalc1jn7-gcc-wrapper-9.5.0/bin/as
lrwxrwxrwx 1 user user 72 Jan 1 1970 /nix/store/95nvd0v2xzf9vcv3kk4nmkjlcalc1jn7-gcc-wrapper-9.5.0/bin/as -> /nix/store/505l13qqnpp0rvrja5s7rgwz5nzir579-binutils-wrapper-2.40/bin/as
IOW, GCC is using the binutils version symlinked from the gcc-wrapper-9.5.0 directory, not the version in $PATH requested in the SGX Dockerfile.
IPP Crypto is being built with older glibc 2.34, while the rest of SGX code is built with newer glibc 2.38
In this case the build output clearly shows an explicit include for glibc 2.34 -I/nix/store/dwsi3wsqpqm0hpzdm9fsxc7q732p9xwi-glibc-2.34-210-dev/include:
This glibc 2.34 is not what the Dockerfile requested, which was 2.38
Looking at the -save-temps output for other parts of the build shows the glibc 2.38 is correctly being used
After some investigation I found the cause is the file external/ippcp_internal/ipp-crypto/sources/ippcp/CMakeLists.txt which references CMAKE_SYSTEM_INCLUDE_PATH:
I'm pretty surprised that IPP Crypto and SGXSSL were allowed to reference glibc system headers at all, given that they're intended to be used in enclaves with the custom SDK C library. None the less, having them use different glibc system headers in the same SGX reproducible build feels like a bad idea.
I'm unclear what the reasons were for updating glibc and gcc, but NOT updating binutils, in 2.24 release, but I'd at least expect the reprodicible build process to be using the versions declared in linux/reproducibility/Dockerfile rather than different versions pulled in as a side-effect of other packages.
It looks like the root cause here is the attempt to cherry-pick updates for just a subset of the build toolchain components. If all of cmake, gcc, binutils, glibc, nasm were updated to the same point in time for NixOS, then they would likely be a consistent set.
The text was updated successfully, but these errors were encountered:
I'm unclear what the reasons were for updating glibc and gcc, but NOT updating binutils, in 2.24 release, but I'd at least expect the reprodicible build process to be using the versions declared in linux/reproducibility/Dockerfile rather than different versions pulled in as a side-effect of other packages
The Dockerfile change in 2.24 is caused by the IPP-crypto upgrade ( OpenSSL 3.x is required and an upgraded glibc is required ). Will check the details and back here.
In 2.23 the SGX build env Dockerfile was referencing:
In 2.24 the SGX build env Dockerfile shows changes for GCC, NASM and GLibC versions:
With the changes between 2.23 and 2.24 build env shown by this diff
I can successfully reproduce the SGX AE build for 2.22 and 2.23, but when I attempt to reproduce the AE build using the 2.24 release and its declared NixOX package versions, it fails.
Upon investigating this I've found that the build process is not in fact correctly using the glibc and binutils versions declared in the Dockerfile.
Code is being assembled with binutils 2.40, NOT 2.38.
This is because the update to GCC 9.5.0 has pulled in binutils 2.40, despite the NixOS config requesting 2.38. In fact both 2.38 and 2.40 appear to be installed in parallel, but 2.40 is the version being used.
We can see what is in $PATH, which matches the Dockerfile request for binutils 2.38:
Actually running GCC though tells us the truth about what is used:
IOW, GCC is using the binutils version symlinked from the gcc-wrapper-9.5.0 directory, not the version in $PATH requested in the SGX Dockerfile.
IPP Crypto is being built with older glibc 2.34, while the rest of SGX code is built with newer glibc 2.38
In this case the build output clearly shows an explicit include for glibc 2.34
-I/nix/store/dwsi3wsqpqm0hpzdm9fsxc7q732p9xwi-glibc-2.34-210-dev/include
:This glibc 2.34 is not what the Dockerfile requested, which was 2.38
Looking at the -save-temps output for other parts of the build shows the glibc 2.38 is correctly being used
After some investigation I found the cause is the file
external/ippcp_internal/ipp-crypto/sources/ippcp/CMakeLists.txt
which references CMAKE_SYSTEM_INCLUDE_PATH:And the version of cmake requested in NixOS has harcoded this to glibc 2.34
I'm pretty surprised that IPP Crypto and SGXSSL were allowed to reference glibc system headers at all, given that they're intended to be used in enclaves with the custom SDK C library. None the less, having them use different glibc system headers in the same SGX reproducible build feels like a bad idea.
I'm unclear what the reasons were for updating glibc and gcc, but NOT updating binutils, in 2.24 release, but I'd at least expect the reprodicible build process to be using the versions declared in
linux/reproducibility/Dockerfile
rather than different versions pulled in as a side-effect of other packages.It looks like the root cause here is the attempt to cherry-pick updates for just a subset of the build toolchain components. If all of cmake, gcc, binutils, glibc, nasm were updated to the same point in time for NixOS, then they would likely be a consistent set.
The text was updated successfully, but these errors were encountered: