Pylint output was filtered so that many files with existing pylint
violations were allowed to stay broken.
I made sure all files pass pylint, but whitelisted some rules that
we commonly disable:
* missing docstrings: most of the code is tests/internal anyway
* invalid-name: too many violations, and we commonly use one- or
two-character names (like "a, b" or "t1, t2") which is
disallowed by this rule; we could tweak it and then fix
remaining violations such as camel-case or lowercase constants
* fixme: we leave TODOs as a matter of practice, same as in C
* high-level style rules like too-few-* and too-many-*,
no-self-use
Hopefully that will make using pylint less annoying, while also
catching serious issues (such as unused variables or imports).
The manifest syntax stays exactly the same, including 0 and 1
integers to denote boolean values (this is done for ease of porting
and can be fixed in future commits). The only visible change is
surrounding strings in the manifest with quotes (requirement of
TOML). All manifests and Makefiles of our tests and example apps are
ported to the new TOML syntax. Documentation is updated.
On debug builds, the standard output is littered with debug log from
graphene, so this likely never worked properly. This wasn't catched by
jenkins either.
Previously, Graphene assumed that if it was built with the DCAP
SGX driver or in-kernel SGX driver, then it should use DCAP/ECDSA
based attestation. In fact, the SGX driver has nothing to do with
the attestation scheme. This commit allows to use EPID based
attestation even when Graphene is built with the DCAP SGX driver.
Supporting these options complicates the design of Graphene and loading
logic significantly, providing little useful functionality:
- loader.exec:
- the main user of it were our tests
- worked only for the first process spawned inside Graphene, as it
was a unidirectional manifest->binary mapping, so the child
process didn't know about the corresponding manifest.
- sgx.sigfile:
- probably all existing usages of it were completely redundant
- was resolved relatively to CWD instead of the executable location,
which made it mostly useless
From now on, the correct location of the files is:
- either place the manifest and sigfile next to the binary, with a
matching name, or
- create a symlink to the binary in the folder where manifests are
stored and launch it through this symlink
The purpose of this example was to show how to break a cyclic dependency
when spawning processes, using an ugly hack. This hack will stop working
after manifest resolution cleanup, which will be followed by a loader
rework, which finally will make this use-case work out-of-the-box,
without requiring any hacks.
The manifest option "sgx.allow_file_creation" is useless (most
real-world apps will set it to "1" anyway). So this commit simply
removes this option and always allows to create files.
This commit forces OpenVINO to use OpenMP library instead of TBB.
This is due to the currently missing functionality in Graphene to
correctly initialize TBB (missing /sys/devices/ support).
This example shows how to write manifests for multi-process applications
and highlights the trick of breaking an endless loop of SGX trusted
children by using symlinks. This example also stresses the FS
checkpointing system of Graphene.
Our current TensorFlow example is actually TensorFlow Lite (less
functional version of TensorFlow, used only for inference). Rename
it to avoid confusion of new users.
Trusted child enclaves must inherit the provisioned master (wrap) key
for protected files from the parent enclave on fork/clone. This commit
adds this functionality and modifies the RA-TLS secret provisioning
PF client to test this (including in Jenkins).
Kudos to Li Xun for reporting this bug and proposing a solution.
Previously, we introduced `sgx.zero_heap_on_demand` in Linux-SGX as a
knob to trade off runtime degradation on memory allocations for faster
enclave start-up times. This was an incorrect fix because Linux-SGX's
`_DkVirtualMemoryAlloc()` always zeroess the requested memory region,
so there was a double-zero of the heap at runtime. Note that LibOS
layer silently assumes that `_DkVirtualMemoryAlloc()` zeroes out the
memory, and many applications rely on this (Apache, Blender in my
experiments). Thus, this commit keeps the zero-out in
`_DkVirtualMemoryAlloc()` and removes zero-outs on enclave init and in
`get_enclave_pages()`. This renders `sgx.zero_heap_on_demand`
useless, so this manifest option is also removed. Also note that this
commit doesn't introduce any performance degradation (in fact, now
Graphene behaves as if `sgx.zero_heap_on_demand = 1` always).
The commit: [Examples] tensorflow: Fix default `make` target
replaced the target 'default' with 'all'.
However, the targets 'run-graphene', 'run-native' and 'check'
still depend on 'default', so it is not possible to use them.
To fix this, modify these targets to depend on 'all' instead.
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).
The client part of RA-TLS demo only ran outside SGX. This patch optionally
allows the client to run in Graphene SGX as well. This is useful for those
who need to create a secure channel between Graphene SGX processes running
on different machines.
Using Redis 6.0.5 on more recent distros (Fedora 32) avoids linker
issues like the following ones:
/usr/bin/ld: server.o:sds.h:37: multiple definition of `SDS_NOINIT';
quicklist.o:sds.h:37: first defined here
Using the latest busybox 1.32.0 on more recent distros (Fedora 32)
avoids linker issues like the following ones:
/usr/bin/ld: util-linux/lib.a(rdate.o): in function `rdate_main':
rdate.c:(.text.rdate_main+0x150): undefined reference to `stime'
/usr/bin/ld: coreutils/lib.a(date.o): in function `date_main':
date.c:(.text.date_main+0x2a4): undefined reference to `stime'
collect2: error: ld returned 1 exit status
Previously, RA-TLS was recommended to be used with LD_PRELOAD trick.
However, LD_PRELOAD is too hacky and shouldn't be used to preload
libraries to an executable (in contrast to its normal use of
replacing functions from one library with another). This commit
removes any mentions of LD_PRELOAD trick from RA-TLS, and
replaces LD_PRELOAD with `dlopen()` in ra-tls-mbedtls example.
Secret Provisioning provides a simple interface for enclavized
applications to connect to a trusted secret-provisioning service and
securely pass the secrets inside the SGX enclave. The application acts
as a client and the secret-provisioning service as a server. They
establish a TLS session via mutual authentication, where the service
sends a classical X.509 certificate and the application sends an
RA-TLS X.509 certificate. After the service verifies the RA-TLS
certificate and its SGX-related information, it provisions secrets
to the application. The TLS session may continue to be used by the
application and the server after the initial provisioning. Secret
Provisioning feature relies heavily on RA-TLS.
Secret Provisioning is shipped as three libraries:
- secret_prov_attest.so: creates RA-TLS X.509 certificate with SGX
quote embedded and sends it to the secret-provisioning service as
part of mutual attestation of TLS session. Linked into enclavized
applications. Not thread-safe.
- secret_prov_verify_epid.so: establishes a TLS session with mutual
attestation, verifies received RA-TLS certificate, and sends secrets
back to the enclavized application. Linked into secret-provisioning
service. Verifies RA-TLS certificate using EPID-based flows.
Multi-threaded and thread-safe (new thread for each client).
- secret_prov_verify_dcap.so: same as secret_prov_verify_epid.so but
verifies RA-TLS certificate using ECDSA/DCAP-based flows.
Multi-threaded and thread-safe (new thread for each client).
This commit also adds two Secret Provisioning examples, with a minimal
enclavized app, a more complicated enclavized app, and a single
secret-provisioning service. These examples are added to Jenkins.
LMbench was causing a lot of problems in the past and we just noticed
another one (the last one from the list below), which broke the
camel's back :)
Some of the issues:
- Original mirrors are unstable.
- Its source is terrible.
- It's not portable (e.g. needs custom patches to run on Fedora).
- Runs for quite long in CI (a few minutes).
- The last update to the project was 15 years ago (13 on dev branch).
- It uses some features not implemented in Graphene
(getrusage(RUSAGE_SELF, ...)) without checking for errors, which leads
to reporting bogus times.
- Actually, it silently skips failures, because the command is piped to
`tee` and then `tee`'s exit code is checked instead of the original
command's.
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.
Running `make` without arguments (as advertized in the README)
previously resulted in "make: *** No rule to make target 'all'", because
of ".DEFAULT_GOAL := all" in Scripts/Makefile.Host.
RA-TLS integrates Intel SGX remote attestation into the TLS connection
setup. Conceptually, it extends the standard X.509 certificate with
SGX-related information. The additional information allows the receiver
(verifier) of the certificate to verify that it is indeed communicating
with an SGX enclave (attester). RA-TLS is shipped as three libraries:
- ra_tls_attest.so: creates self-signed RA-TLS X.509 certificate with
SGX quote embedded; typically linked into server apps.
- ra_tls_verify_epid.so: verifies RA-TLS certificate by sending SGX
quote to IAS and verifying attestation report from IAS; typically
linked into client apps.
- ra_tls_verify_dcap.so: verifies RA-TLS certificate by providing SGX
quote v3 to the libsgx_dcap_quoteverify library and relying on its
assessment of the quote; typically linked into client apps.
This commit also adds an RA-TLS example using simple mbedTLS server
and client. The server generates the RA-TLS certificate, and the client
connects to the server, verifies this certificate, and performs a
dummy HTTP request. This example is added to Jenkins.
Also, add library paths so that lmbench now also works on Fedora.
This should now work on both Fedora and Ubuntu 18.04 and also when
libtircp is not installed, so we can patch unconditionally.
- This example will be compared with another example for loading
encrypted models and inputs using PFS. Thus, load the model from a file.
- Updated Makefile and README.md
Wojtek Porczyk