Skip to content

Execution environments

Jump to bottom
Joanna Rutkowska edited this page Oct 26, 2018 · 1 revision

Execution environments

Notes from meeting on 2018-10-25

The primary role of execution environment is to provide some kind of service. In most (all?) cases this is about allowing to run some arbitrary programs or VMs.

  1. Execution environments can be anything from VMs to specific applications (e.g. Blender renderer). This is still TBD, see below.

  2. From the security perspective there are two, largely complementary aspects:

  • protect host from payload (VMs)
  • protect payload from host (SGX)

Thus, we might want to combine more than one exec env to achieve both kinds of protection (e.g. SGX and some VM technology).

  1. Execution environments are provided only on provider nodes. At least this is what Golem Core is concerned about. If the app integrator decides that they want to also spawn e.g. a docker or VM on a consumer computer (which might or might not be part of the Golem network), they are free to start it, but it won't be managed by Golem daemon.

Open questions:

  1. Perhaps specific apps/services should not be considered an execution env, but rather be clients of them? E.g. our Blender service would still need to be hosted within some execution environment: docker, VM, or... "host direct" (which in practice means e.g.: POSIX exec env).

  2. Choice of exec env management software. Current candidates:

  • libvirt
  • openstack
  • something else?

Also, how does current Clay code fit into this picture?

Clone this wiki locally