RFC: Use runc in the first CoCo release about enclave-cc HOT 12 CLOSED

Thanks Mikko. According to previous discussion, we should avoid this kind of usage(using occlum-run). It's still specific libos usage. Enclave-cc's design principles are the almost same UX as a general container
"command": [
"/run/rune/boot_instance/build/bin/occlum-run",
"/bin/hello_world"
],

from enclave-cc.

Thanks, @mythi. great proposal. Starting with a simple runc for the first stage POC is an excellent idea.

I have some questions about this yaml file. In order to keep the same user experience among Confidential Containers, and shield the underlying libos details for users, I think the command, env, and working dir fields are customized in the YAML file, and we can continue to discuss and improve these.

• command field: As @YangLiang3 said, It's specific libos usage. Enclave-cc's design principles are almost the same UX as a general container. Another question, It must be written as an absolute path to work("/bin/hello_world"), how to support relative paths? We need a component to expand relative paths to absolute paths.
• LD_LIBRARY_PATH field. It seems that the setting of LD_LIBRARY_PATH environment variable is required for all applications. I think the setting of LD_LIBRARY_PATH may be performed by a unified component, such as enclave-agent or shim-rune. So that users do not need to pay attention to this LD_LIBRARY_PATH environment variable In yaml filed.
• workingDir field: directly set to "/run/rune/boot_instance/", running a simple hello world can work at present, but if a complex app needs to be set to another workdir, what should users do?
  Thank you very much!

from enclave-cc.

So that users do not need to pay attention to this LD_LIBRARY_PATH environment variable In yaml filed.

setting this was a quick hack. I can build the boot-instance so that the ld cache includes Occlum paths.

I fixed this and it's not needed anymore.

from enclave-cc.

Looks like Occlum prevents this:

failed to boot up LibOS: EINVAL (#22, Invalid argument): program path must be absolute [line = 357, file = src/entry.rs]

Occlum only permits the running command from the "entry_points" defined in Occlum.json which in default it is "/bin".

OK. my command was occlum-run hello_world which is installed in /bin.

By design, Occlum expects occlum run /bin/hello_world in this case, only absolulte path defined in "entry_points" is accepted as save entry.

from enclave-cc.

@confidential-containers/enclave-cc-maintainers

from enclave-cc.

@haosanzi thanks for the feedback. This RFC is currently about the first release as getting rune with its dependencies installed using the operator is problematic. After the first release we should probably revisit this.

I also think updating these settings should not be left to the user but for example the shim could do these (as it's also aware of the libOS being used). As we are so close to the release, I just did not want (or have the time) to update it. These modifications are all specific to the boot-instance. But as for the UX, also rune usage expects libOS specific variables to be set.

It must be written as an absolute path to work("/bin/hello_world"), how to support relative paths?

I've not used Occlum much to say how this can be done.

So that users do not need to pay attention to this LD_LIBRARY_PATH environment variable In yaml filed.

setting this was a quick hack. I can build the boot-instance so that the ld cache includes Occlum paths.

directly set to "/run/rune/boot_instance/"

this is not app specific but something Occlum expects.

from enclave-cc.

It must be written as an absolute path to work("/bin/hello_world"), how to support relative paths?

I've not used Occlum much to say how this can be done.

Looks like Occlum prevents this:

failed to boot up LibOS: EINVAL (#22, Invalid argument): program path must be absolute [line = 357, file = src/entry.rs]

from enclave-cc.

It must be written as an absolute path to work("/bin/hello_world"), how to support relative paths?

I've not used Occlum much to say how this can be done.

Looks like Occlum prevents this:

failed to boot up LibOS: EINVAL (#22, Invalid argument): program path must be absolute [line = 357, file = src/entry.rs]

Occlum only permits the running command from the "entry_points" defined in Occlum.json which in default it is "/bin".

from enclave-cc.

Occlum only permits the running command from the "entry_points" defined in Occlum.json which in default it is "/bin".

Both gramine and occlum need to know the absolute path to run the app. (please correct me if I'm wrong)
Since the enclave-agent module is responsible for pulling the image in the enclave and has the ability to get the content of the application image, I think the enclave-agent can be responsible for expanding the relative path to an absolute path. Then pass this absolute path as enterypoint to occlum Libos (eg via LA proof).

from enclave-cc.

Looks like Occlum prevents this:

failed to boot up LibOS: EINVAL (#22, Invalid argument): program path must be absolute [line = 357, file = src/entry.rs]

Occlum only permits the running command from the "entry_points" defined in Occlum.json which in default it is "/bin".

OK. my command was occlum-run hello_world which is installed in /bin.

from enclave-cc.

It depends on what's the scope of Rune to define.
My understand is that the rune should do whatever everything to protect a vanilla container to run inside a TEE.
Ideally, the rune will hide all details from container app and containerd and expose only a set of optional security relevant APIs.
We may simplify/shortcut the implementation of rune for staged releases, but the boundary of system should be held and not be drifted or losing its core values gradually.

from enclave-cc.

@bigdata-memory the purpose of this thread was to discuss what to include in the initial release (for which the operator based deployment was the main goal).

from enclave-cc.