Files
Michał Kowalczyk e587869e13 [LibOS+Pal] manifest: Remove support for loader.exec and sgx.sigfile
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
2020-10-23 00:06:46 +02:00
..

Bash example

This directory contains an example for running Bash in Graphene, including the Makefile and a template for generating the manifest. The application is tested on Ubuntu 16.04, with both normal Linux and SGX platforms.

Generating the manifest

Building for Linux

Run make (non-debug) or make DEBUG=1 (debug) in the directory.

Building for SGX

Run make SGX=1 (non-debug) or make SGX=1 DEBUG=1 (debug) in the directory.

Running Bash with Graphene

Here's an example of running Bash scripts under Graphene:

Without SGX:

./pal_loader bash.manifest -c "ls"
./pal_loader bash.manifest -c "cd scripts && bash bash_test.sh 2"

With SGX:

SGX=1 ./pal_loader bash.manifest -c "ls"
SGX=1 ./pal_loader bash.manifest -c "cd scripts && bash bash_test.sh 2"