Skip to content

Frequently Asked Questions

Container Image

Failed Access

When pulling an image from our image registry fails, sometimes it is not clear if the image does not exist or if one does not have access rights to this image. You can check via gitlab.scontain.com if you have access to the image repo and if a certain tag exists. For example, if you want to check if you have access rights to pull images from repo sconecuratedimages/node, you could open page https://gitlab.scontain.com/sconecuratedimages to search for this repo. Alternatively, you could directly go to https://gitlab.scontain.com/sconecuratedimages/node/container_registry to see if you have access to this page and if the tag exists. On how to check if the tag exists, please see the next point.

Finding an image tag

If you want to check if a certain tag exists, you can use the GUI of our registry: https://gitlab.scontain.com/sconecuratedimages to find the repo and then to find the tag. If there exists a large number of tags in a repo, this can be inconvenient. If you like to use the command line, you could search for tags using the CLI.

Attestation

How can I verify the authenticity and integrity of my running running in enclave, if I access it remotely

One approach is to store the encrypted certificate in an encrypted file region and SCONE CAS gives the service access to the file key only after a successful attestation. If the service can authenticate itself with the correct certificate, this means that it passed the attestation.

How do I bind an interpreter (Python, JavaScript, Java) with its scripts/programs in a secure container?

The problem is that the scripts/programs are not measured during the attestation of the enclave, i.e., it is not included in MrEnclave. This code must be protected with the SCONE file shield, i.e., this must be encrypted and/or authenticated. The current state of the file system is checked during attestation and this ensures the integrity of the code (i.e., no modification), the freshness (i.e., no old version is used), and the confidentiality (i.e., an adversary cannot see the code - in case the code is stored an encrypted file region).

In a future version of SCONE, we will by default enable an option in which all files must be encrypted/authenticated, i.e., any access to an unprotected file will fail.

How can one restrict the initial script that the protected interpreter executes?

The arguments of the code executed inside of an enclave must be passed via SCONE CAS. In other words, the initial script is protected by CAS, i.e., by passing the arguments to Python only after attestation via a secure channel directly into the enclave.

In a future version of SCONE, we will by default enable an option in which all files must be encrypted/authenticated, i.e., any access to an unprotected file will fail. This means that only code that is already include in an encrypted / authenticated file region can be executed.

How can I pass secrets to my enclave?

You could pass these secrets as environment variables via CAS or you can store these in encrypted files. SCONE will pass the environment variables and the file encryption key only after a successful attestation to the application via TLS.

Certificate Verification fails

SCONE CAS provides certification authorities (CAs), i.e, it can generate a CA and this CA can generate certificates on behalf of security policies (aka sessions). Sometimes the verification of these generated certificate fails. Often this indicates that the common_name or the dns names (Subject Alternative Name) are not properly set in the policy.

Simulation Mode

Program crashes/stops in simulation mode

Simulation mode assumes a modern CPU with instructions like AESNI and SSE and AVX extensions. If they are not available, your program will exit with an error message.

Attestation of programs in simulation mode

While we permit to run applications in simulation mode, i.e., to run on machines without an SGX-capable CPU, we do not support the attestation of programs in simulation mode. In case you want to use attestation, you need to run on an SGX-capable machine.

My process/enclave is getting killed without any error message

Context: For SGX version 1, we have to preallocate all memory an enclave can use during its startup. This means that the enclave might request so much memory that the Linux Out-Of-Memory-Killer might kill the process in which this enclave runs. Ensure that you have enough free main memory such that your enclave can start.

My machine has lots of main memory but still processes are getting killed

Try to figure out - using tools like top - which processes are using up your memory. Sometimes, you might have too many active docker containers running: check this with docker ps -a. Try to run docker containers with docker run --rm to enforce automatic cleanup after a container exits.

My program does not start up

Context: For SGX version 1, we have to preallocate all memory an enclave can use during its startup. We cannot estimate how much memory your application needs. Hence, for SGX version 1, we provide environment variables SCONE_HEAP and SCONE_STACK.

For Java and GO programs, set SCONE_HEAP to at least 1G. The default heap size is 64MB.

The default stack size is 64KBytes. This is too little for some applications like Python and MariaDB. A good value for applications that use lots of stack seem to be 4MBytes, i.e., set export SCONE_STACK=4M.

My program has a very large VIRT memory footprint

SCONE reserves 64GB of the virtual address space for each enclave using the SGX driver. Hence, when monitoring a process, e.g., with top, VIRT is reported as at least 64g. Note that the important measure is the physical memory used: top reports this in column RES (given in KiB)).

Crash Failures

My program crashes / gets killed

  • SGX version 1: check that your program has a sufficiently large heap by setting environment variable SCONE_HEAP (see above)

  • SGX version 1: check that your program has sufficiently large stacks by setting environment variable SCONE_STACK (see above).

  • SGX version 1: check that you machine has sufficient main memory see above)

  • Run your program with scone-gdb to determine where your program crashes

Running inside of enclaves

How do I know that I run inside of an enclave?

How can I experimentally show that I run inside of an enclave?

Please check out our memory dump tutorial on this.

How can I enforce/verify that a service/program runs inside of an enclave?

You need to attest that your program runs inside of an enclave. SCONE supports transparent attestation with the help of CAS.

On the application level, one often does not want to perform an explicit attestation but an implicit attestation with the help of TLS to reduce/eliminate the amount of reengineering that is needed. The idea is that a service can only provide the correct TLS certificate if it runs inside an enclave. To do so, one would give the enclave an encrypted TLS private key in the file system (can be generate by Scone CAS if this is requested) and the enclave gets only access to the encryption key after a successful attestation. The decryption of the TLS private key is done transparently by SCONE.

Does SCONE support enclaves in production mode?

Note that by default SCONE runs in debug or pre-release mode. For production enclaves, you still need to get an enclave signer key from Intel. This will change when Intel makes flexible launch control available.

Shielding

Does SCONE ensure the security of incoming and outgoing TCP connections to/from a service running in an enclave?

Please use TLS in your service. If your service does not support TLS out of the box, use our TCP shield.

How do I encrypt stdin/stdout/stderr?

Send us an email on how to use the terminal shield

How do I encrypt pipes?

Send us an email regarding the encryption of pipes.

How do I encrypt TCP connections?

Context: Some services do not support TLS out of the box. Since Scone version 5.7.0 we support an network shield to encrypt network traffic.

How do I transparently encrypt/decrypt files?

Enable the file shield.

Are all files in a container encrypted?

No, only those in an encrypted file region.

What do I need to do to protect the files my service needs, e.g. HTTPS encryption key and certificate

You need to encrypt them when you build you container image.

Dynamic Libraries

What are protected dynamic libraries?

The dynamic libraries loaded during start up of program are included in the hash of the enclave, i.e., any modification of any of these libraries will change MrEnclave. In that sense, the dynamic libraries are integrity protected since any modifications will result in a failed attestation.

One can determine the dynamic libraries which are loaded during startup with command ldd for native binaries. Note that depending on how the binary is build (static linking, dynamic linking, for Alpine Linux or for Ubuntu), ldd might only print the dynamic libraries used to start the enclave.

To enable the loading of protected dynamic libraries, i.e., encrypted or authenticated shared libraries, set environment variable SCONE_ALLOW_DLOPEN=1 in your session policy. If you want to disallow this, do not define SCONE_ALLOW_DLOPEN.

What are unprotected dynamic libraries?

An unprotected shared library, i.e., a shared library that is neither encrypted nor authenticated by the filesystem shield). It is loaded after the program has started by the application with a call to function dlopen (or similar). These libraries are not integrity protected by MrEnclave since they are loaded after MrEnclave was computed. To ensure the integrity of these shared library they have to be located in an authenticated or an encrypted file region.

To enable the loading of unprotected dynamic libraries after startup, set environment variable SCONE_ALLOW_DLOPEN=2. This will also enable loading libraries during startup. Never use SCONE_ALLOW_DLOPEN=2 in production mode.

Encrypted Code and Libraries

One can encrypt code by pushing your main code in a shared library that is stored in an encrypted file region. In this way, you can protect the integrity as well as the confidentiality of your code.

Library Path

If you experience undefined symbols like __cxa_init_primary_exception, ensure that your library path (LD_LIBRARY_PATH) is set such that if finds the SCONE libraries. For example, inside our SCONE crosscompiler container, you might set

export LD_LIBRARY_PATH=/opt/scone/cross-compiler/x86_64-linux-musl/lib/

Resource Usage

CPU utilization / number of threads is higher than in native mode

By default, we use multiple threads to serve inside the enclave and to serve system calls outside the enclave. If theses threads have no work to do, they go to sleep.

You can reduce the number of threads / CPU utilization by specifying a SCONE configuration file which uses less threads. For example, you could use one thread inside the enclave and one outside the enclave with this configuration file:

cat > /etc/sgx-musl.conf << EOF
Q 1
e -1 0 0
s -1 0 0
EOF

The CPU utilization is still higher than in native mode

In our experience, then newest version of SCONE needs less than 1-2% CPU utilization when a service is idling.

If the CPU utilization of a service is higher than the native version during idle periods, you could try to tune the the backoff behavior of the queues by setting parameters L and P appropriately. Note that the standard values should in most cases do not need any tuning.

The memory usage is higher than in native mode

The issue is that SGX v1 enclaves must allocate all memory at startup since enclaves are fixed (- this will change with SGXv2). You can reduce memory consumption by setting SCONE_HEAP and SCONE_STACK. In SGX v2 we will allocate memory on demand, i.e., we will be more memory efficient.

Note that in SGX v2, we will be able to dynamically adjust the size of the heap and the stack sizes automatically, i.e., one does not need to allocate all memory in the beginning. This will also reduce the startup times.

High startup times

Since in SGX v1 one needs to allocate all memory at the start of an enclave, startup times can be very large. In SGX v2, we will be able to dynamically scale the size of an enclave during runtime. Since we will allocate less memory during startup time, this will reduce the startup times.

Side-Channel Protection

The newest microcode of new Intel CPUs protects against L1TF side channels when hyperthreading is disabled. Please ensure that your CPU microcode is up-to-date: You can follow the following instruction to update the microcode of your CPU.

Unimplemented Functions

Some function returns ENOSYS

Sometimes it is difficult to diagnose why a function fails. In most cases, the issue is that we do not yet support fork.

You can check which functions might not be supported by running your application with environment variable SCONE_LOG=7.

Driver Issues

No Access to SGX device

Ensure that you installed the Intel SGX driver on your machine and that the SGX driver is accessible in your container.