App provisioning framework

[L0czek]

App provisioning

This PR adds app provisioning framework to islet project which allows for installing applications inside realm using OCI containers. The framework components handle everything from downloading, verifying, installing and running the applications. It provides encrypted, persistent storage that each application can use to store confidential data. The realm also checks the authenticity of each application by verifying the application signature against a chain of provided certificates that begin at the embedded CA.

The framework consists of several main components:

• The realm image which implements a special realm with application manager which is responsible for installing and running applications.
• The warden daemon which is responsible for creating disks, network interfaces and finally running kvmtool
• The application registry server which is an OCI container repository. It utilizes the RA-TLS protocol to ensure that the realm is trustworthy before it allows the application to be installed.
• The realm metadata tool which is used to create the realm metadata block so that the sealing keys can be based on vendors public keys.
• The RIM measuring tool is a modified kvmtool which is capable of calculating realm's RIM without launching it.
• This PR which adds key derivation and realm metadata block functionality to enable sealing keys for encryption in realms.

Running the demo

The provided demo shows how an example application can be installed in a realm in islet. The detailed instruction goes over:

• setting up islet,
• preparing the special realm image,
• creating an example application image,
• signing the application,
• setting up the application registry,
• running islet and installing the application.

The detailed instruction to reproduce the app provisioning setup can be found here.

What works now

• Installing and running applications
• Applications are preserved across reboots
• Applications are authenticated based on ecdsa signatures
• Sealing keys can be measurements dependent, if the realm metadata block was not provided to allow for running any realms securely.
• In case the metadata block is present, the sealing keys are based on realm vendor public key to allow for easy application update (the encryption keys doesn't change between application and realms versions)

Known issues

RIM calculation related

Unfortunately, due to the design of how the RIM is calculated for realms, specifying a single RIM value for the application provisioning realm is not trivial. It is caused by measuring the Device Tree Blob which changes based on the kvmtool arguments. Basically, the realm RIM is dependent on such things as:

• virtual network card(s),
• virtio block devices,
• other virtual hardware,
• the order of the hardware in the DeviceTree.

This is especially troublesome as currently the warden daemon provides one disk image for each application. As a result, the kvmtool creates a separate virtio block device for each disk, leading to a change in the DTB. This should be investigated in the future to either stabilize the DTB or provide a rim measuring software. An example of such application is the modified kvmtool. Therefore, it will be further investigated in the future.

Something wrong with Islet rmm

While running the provisioning setup, we started encountering a truly random errors from various layers of the stack that could not be reproduced in tf-rmm. In detail, we encountered the following errors:

• TLS decrypt error during application installation,
• application image hash mismatch,
• some "inode already exists" error from the Linux kernel,
• disk image corruption (the file system wasn't preserved across realm reboots),
• TLS handshake error.

Since we couldn't reproduce them while running tf-rmm there might be some memory issue introduced by islet rmm. We first encountered this issue when we tried to test the application installation using a statically linked rust "hello world" application. It weights about 1MB, due to static linking and debug build. Every time we tried to install it while running islet, the installation process would fail with TLS decrypt error. We then switch to tf-rmm to check if the issue still persisted. To our surprise, it did not. In the next step, we created a lighter "hello world" application that weight only 1KB and managed to get it installed under Islet. This let us conclude that Islet introduces some memory instability that leads to arbitrary corruption when large amounts of data are processed. As of now, we weren't able to pinpoint the issue. You can try to reproduce this issue by trying under islet to:

• install the big application (example_app from the instruction)
• install the lighter one (the light_app from the instruction).

Naturally, this issue must be investigated, as this makes running applications under Islet unstable. Apart from that, https://github.com/islet-project/islet/issues/361 also suggest an issue with realm's memory management.