It turns out that our guard pages were incorrectly handled (i.e. not re-
added to LibOS VMA list) on SGX when execve was optimized to re-use the
same enclave, which caused exec_same test to crash from time to time
(when ASLR put heap on a guard page).
Static guard pages aren't too useful and introduce unnecessary
complexity to our code, so we decided to just delete them in order to
fix this bug.
Changes:
- `make all` previously rebuilt everything each time, now it
doesn't.
- Using out-of-tree build.
- Unfortunately we have to build the whole LTP now (minus modules),
so the build is slower.
- But: `make -jX` works, previously was broken because of missing
dependencies.
- Not using symlinks as targets anymore - Make is broken and checks
the timestamp of the *destination*, not the symlink itself.
Previously the links were recreated on each `make` call.
- `make regression` printed:
/bin/sh: 1: test: Illegal number:
and now it doesn't.
This commit adds the ability to provision the wrap (master) key for
protected files at runtime (in contrast to previous approach of
hard-coding `protected_files_key` in the manifest as a temporary
solution). This is achieved as follows:
- New PAL API `DkSetProtectedFilesKey()` is added.
- New writable pseudo-file `/dev/attestation/protected_files_key` is
added. It calls `DkSetProtectedFilesKey()` after it was written to.
- New `SECRET_PROVISION_SET_PF_KEY` option is added to the Secret
Provisioning library. If it is set, the library assumes that the
first provisioned secret is the wrap key for PF and writes it into
the new pseudo-file.
The Secret Provisioning example `ra-tls-secret-prov` is updated to
include the new protected-files client. This client receives the wrap
key for PF via secret provisioning and reads & outputs the protected
file `files/input.txt`.
*NOTE*: The current implementation of provisioning the wrap key does
not work for `loader.argv_src_file` and `loader.env_src_file` if they
point to protected files (because provisioning happens after setting
up arguments and environment variables).
Under SGX PAL, if the CPU doesn't support RDTSC/RDTSCP inside SGX
enclave, Graphene uses trap-and-emulate on these instructions.
Previously, Graphene only emulated RDTSC and not RDTSCP. Moreover,
Graphene emulated RDTSC by simply returning zeros, which could lead
to faults in applications not expecting a zero value. This commit
emulates (imprecisely) both RDTSC and RDTSCP via gettime() syscall.
New LibOS test is added (SGX-only).
Protected files (PF) are a new type of file that can be specified in
the manifest (SGX only). They are encrypted on disk and transparently
decrypted when accessed by the Graphene payload.
Other features:
- data is integrity protected (tamper resistance)
- file swap protection (a PF can only be accessed when in a specific path)
- transparency (Graphene payload sees PFs as regular files, no need to modify
the payload)
See Linux-SGX/protected-files directory for implementation. PF format is
based on protected files from the SGX SDK:
https://github.com/intel/linux-sgx/tree/master/sdk/protected_fs
The following new manifest elements are added:
sgx.protected_files_key = <16-byte hex value>
sgx.protected_files.<name> = file:<host path>
sgx.protected_files_key specifies the encryption key and is only a temporary
implementation. This key should be provisioned with local/remote attestation
in the future.
Paths specifying PF entries can be files or directories. If a directory is
specified, all files/directories within are registered as protected
recursively (and are expected to be encrypted in the PF format).
Linux-SGX/tools directory contains the pf_crypt utility that converts files
to/from the protected format.
Previously, Glibc build produced the following message:
"*** errlist.c count 134 inflated to GLIBC_2.12 count 135 (old
errno.h?)". This message is *not* a Graphene build issue and
may confuse users, so this commit removes it.
Previously, Glibc patches were generated with shortened index hashes.
This commit re-generates all Glibc patches with complete index
hashes using `--full-index` option.
This commit also removes mentions of removed old Glibc 2.19 and the
unused Gold ld patch.
Enabling this macro breaks the build due to two typos, both in just a
single line (sic!; OBJECT_INTERNVAL and VMA_INTERVAL).
git blame points to "The first official release" commit, which means
that no one used it since at least 2014. We can safely get rid of it.
This commit renames manifest option `sgx.print_stats` into
`sgx.enable_stats` and adds enabling TCS.FLAGS.DBGOPTIN for all
enclave threads when this manifest option is set. This allows to
collect performance counters and generally enable debug and profiling
features of enclaves (built in debug SGX mode).
This is the first step in removing this obsolete header.
Additionally, AtomicMath test is removed, as it became obsolete after
these changes (and was relying on undefined behaviors anyway).
Previously, Graphene sent arguments to a child process (spawned via
execve() syscall) in the clear. This was insecure. This commit fixes
it by always spawning a new child process without arguments and then
sending the arguments in the checkpoint (which is securely encrypted
on Linux-SGX PAL). The new logic is the same as with environ.
This test is noped-out with #ifdefs on x86_64. The current code does
not allow to listen on a socket that is not bound, so this test fails
when it actually runs (verified on PPC64).
As part of argv protection, Graphene now requires an explicit
manifest option to pass command-line arguments, either
"loader.argv_src_file" or "loader.insecure__use_cmdline_argv". As
part of that change, most manifests were updated to include these
options, but not all. This commit fixes this for the rest of
manifests.
We don't use it in tests, plus it didn't work on SGX - there was a
warning about autogeneration inserted before the autogenerated shebang.
Also, test_106_manifest_with_shebang didn't actually test the shebang
but ran the binary through the loader, so it was meaningless. We'll need
to fix it and implement again after cleaning up Graphene invocation.
Pointer comparison is legal in C only if both pointers point to the same
array or its end, plus it's UB to decrement a pointer pointing to
array's first element.
Michał Kowalczyk