The documentation currently specifies SGX_SIGNER_KEY as the parameter to
enable Graphene to find your keys.
Some examples don't use this environment parameter, this commit fixes
that.
This commit completely reworks VMA subsystem along with its usages.
New version should be: cleaner (easier to maintain), faster and allow
for bookkeeping requests from Pal.
It also fixes some bugs and inconsistencies found in the process and
changes brk and mmap/munmap implementations (at least partially).
Clear Linux ships with Glibc built with `-Wp,-DFORTIFY_SOURCE=2`.
This overwrites Graphene's `-UFORTIFY_SOURCE` because of the quirk
in how GCC applies arguments (first without Wp, then with Wp).
This commit updates Makefiles to use `-Wp,-UFORTIFY_SOURCE`.
GCC 9.3 adds more static checks on C headers and sources. This
commit fixes all detected issues (mainly possible NULL pointer
dereferences and VLAs on stack).
On Ubuntu 'which' finds 'cp' in '/bin/cp' and on Fedora in
'/usr/bin/cp'. Rather than hard-coding the path '/bin', use
$(EXECDIR) and derive its value from the dirname of the path of the
executable, i.e., either '/bin' or '/usr/bin'.
Adapt the python constants so that python-simple also works on
Fedora 31. python-scipy-insecure misses some shared libraries on
Fedora 31, so it does not work there yet.
Adapt Scripts/Makefile.configs so that we can build and test on
Fedora. Most of the tests in Examples are now also runable on
Fedora. Also add a dependency installation target for Fedora to
TensorFlow example.
Unescape the '\n' as a newline when writing it into the nginx config
file rather than writing it as '\n'. Use printf rather than
`/bin/echo -e` since this seems to work for all distros.
Extend Makefile.configs and define several variables for make to use
derived from 'gcc -dumpmachine'. In particular:
- ARCH as the architecture, e.g., x86_64
- ARCH_LONG as the long version of the architecture, e.g., x86_64-linux-gnu
- ARCH_LIBDIR as the directory where libraries are located,
e.g., /lib/x86_64-linux-gnu
In Makefiles and manifest templates, replace the hard-coded
x86_64-linux_gnu and /lib/x86_64-linux-gnu through these variables.
Extend the already existing sed scripts to replace the necessary
variables.
Currently various flags in file and memory syscalls work mostly by an
accident, because values of some of them align with corresponding Linux
syscall flags. Some APIs weren't that lucky though - e.g.
DkStreamOpen(..., /*options=*/PAL_OPTION_CLOEXEC) deletes file contents
(sic!) intead of opening it with O_CLOEXEC. This is because
PAL_OPTION_CLOEXEC == O_TRUNC.
This commit fixes all this mess and also adds asserts to check validity
of flags passed to Dk* handlers.
Because GDB is awesome this isn't actually configurable in .gdbinit (or
at least I couldn't find any way to do this) and we need to fix it via
the commandline.
Linux-SGX PAL uses mbedTLS sessions for encrypted IPC. This requires
a TLS handshake on pipe/socketpair creation. Previously, if the pipe
was created with O_NONBLOCK, read/write callbacks for mbedTLS session
could return EAGAIN or EWOULDBLOCK if the pipe was occupied. We
forgot to check for these error codes, and TLS handshake failed as a
result on the first EAGAIN/EWOULDBLOCK (detected on NodeJS example).
These error codes are actually benign, and Graphene should simply
ask mbedTLS to retry read/write.
Previously, we forced PIE executables to be located at address
0x00400000 (4MB). However, there is a bug in the ELF relocation code
in LibOS that leads to double-relocation. To circumvent this bug,
relocation code checks if the offset was already relocated. But if
the offset itself exceeds the base address of PIE executable (i.e.,
exceeds 4MB), then the offset is not relocated and segfaults follow.
This commit changes base address from 0x00400000 to 0x555555554000,
similar to what Linux does.
This commit adds a new subdirectory in the /dev pseudo-FS and
new pseudo-files to allow applications and helper libraries on
top of Graphene to perform attestation. The currently exposed
primitives are tailored to the Intel SGX local and remote EPID
attestation. App developer writes attestation logic against
this pseudo-FS interface by opening and reading/writing the
following files:
- /dev/attestation/user_report_data: write user-provided report
data used in `report` and `quote` pseudo-files
- /dev/attestation/target_info: write target info used in
`report` and `quote` pseudo-files
- /dev/attestation/my_target_info: read this enclave's target info
- /dev/attestation/report: read report (for local attestation)
- /dev/attestation/quote: read quote (for remote attestation)
This commit also adds a corresponding LibOS test `attestation`.
Previously, the PAL layer would put an executable at a first unoccupied
address range if the executable was position-independent (PIE). This
could lead to the same executable being located at different addresses
across forks (Graphene correctly checkpoints shared libraries but
has separate handling for the executable). This is a rare scenario
since the PAL initialization code is typically deterministic across
forks. However, rarely there would be small difference in allocations
which would lead to different base addresses for executable segments
in parent and child processes, and segfaults and data corruptions
happened (this was the case for Nginx on Ubuntu 18.04 with change in
the manifest file processing). This commit simply forces executables
to always be loaded at a predefined address (currently 0x00400000).
Previously, `verify_quote()` had bug: it errored out on incorrect SGX
measurements only in verbose mode. This led to silently accepting
incorrect measurements if this function was executed in silent mode.
Previously, APIs `verify_ias_report()`, `verify_quote()`,
`ias_verify_quote()` used hex/decimal strings as arguments and
saved IAS response contents to files. This is not convenient for
library usage. This commit allows to pass raw-data arguments to
`verify_ias_report()` and `verify_quote()`, as well as adds
`ias_verify_quote_raw()` to output IAS response contents in memory.
Also, `hexdump_mem_to_buffer()` utility is added.
mbedTLS configuration used in Graphene is not thread-safe (because
this would require the use of a threading library like pthread which
is not possible in the LibOS/Pal layers). However, some mbedTLS
functions use shared state, in particular TLS context initialization
functions. This led to data races during encrypted-pipe creation,
since it requires two threads performing a TLS handshake. This commit
refactors TLS init into SSLInit (not thread-safe) and SSLHandshake
(thread-safe) and adds spinlocks around SSLInit to protect the racy
mbedTLS logic.
Emil Hemdal