Creation of OS image for Realm and possible alternatives

[atulfj]

Hi,

In the following portion of launch-realm.sh:

./lkvm run \
	--debug \
	--realm \
	--measurement-algo="sha256" \
	--disable-sve \
	--console serial \
	--irqchip=gicv3 \
	--network mode=user \
	-m 256M \
	-c 1 \
	-k linux.realm \
	-i rootfs-realm.cpio.gz \
	-p "earlycon=ttyS0 printk.devkmsg=on" \
	--9p /shared,FMR

Islet currently uses linux.realm as its OS image. Is it a generic linux image, or has it been modified by Arm or Islet developers to support Realms? If yes, is there a source or documentation for the modifications? If not, could you suggest some alternative images that could be used instead? Thanks.

[p-sawicki2]

@atulfj It's a dedicated kernel image that has changes introduced by Arm. You can find its source code here https://gitlab.arm.com/linux-arm/linux-cca/-/commits/cca-guest/rmm-v1.0-eac5/?ref_type=heads (notice, that there are also changes for the Linux kernel running on the host side). As for the documentation, I recommend searching the Linux kernel mailing lists, where the original patches were published.

[atulfj]

Thanks for the comment, @p-sawicki2.

One more query: The versions of standard libraries (such as GLIBC) that are present in the Guest OS (Realm) are older than what is required by libtensorflow.so and libtensorflow_flex.so. Any idea how this could've happened? (Ref: issue#356)

I would also like to know how the libraries are being loaded into the guest - is it via rootfs-realm.cpio.gz? If anyone wanted to update the versions to match the requirements, or create it from scratch, how can it be done? Is there any documentation available to generate artifacts that are present inside assets/rootfs? It would be helpful to know in case we wanted to add support for running other ML frameworks inside the Realm.

[p-sawicki2]

@atulfj

One more query: The versions of standard libraries (such as GLIBC) that are present in the Guest OS (Realm) are older than what is required by libtensorflow.so and libtensorflow_flex.so. Any idea how this could've happened? (Ref: #356)

@bitboom @jinbpark could you help to solve the issue with libraries?

I would also like to know how the libraries are being loaded into the guest - is it via rootfs-realm.cpio.gz?

There is a /shared folder which content, as the name suggests, is shared between the realm, the host and the PC host (the machine where the FVP emulator runs on). So, there is no need to modify rootfs-realm.cpio.gz file. You can just copy your files into the shared folder and they should become available in the realm. You can do it in runtime as well.

This mechanism is basically used to ease experimentation and development, but should not be used in real-world scenarios. It's because custom files copied to a /shared folder are not reflected in the Realm Initial Measurement of the attestation token (except linux.realm, rootfs-realm.cpio.gz and the launching script file).

[atulfj]

@p-sawicki2

In the ARM FVP confidential-ml examples, where do the "prebuilt example binaries" like device.exe come from? If I want to modify the code and create a new executable (device.exe) file to run inside the realm, which device.cc script (or any other files) do I need to change and run?

[p-sawicki2]

@atulfj Regarding the confidential-ml, you need to ask @jinbpark who is the author of that example.

[atulfj]

Okay, @jinbpark kindly take a look at my query.

One more thing - when device application runs inside the Realm, it is not using any of the Islet's attest, verify or other functions. Where are the functions getting used then? Who does Islet provide these API services to?

[jinbpark]

One more query: The versions of standard libraries (such as GLIBC) that are present in the Guest OS (Realm) are older than what is required by libtensorflow.so and libtensorflow_flex.so. Any idea how this could've happened? (Ref: #356)

Hi @atulfj,
there seems to be a discrepancy between the environment in which the tensorflow is built and that of the current Guest OS.
Rebuliding the tensorflow library or the root file system might work. (rebuilding a root file system with the library dependencies used in tensorflow might be easier)
I dont' have enough time to dig into this issue at this moment. I'll look at it next month and provide an updated docker image and instructions accordingly.

it is not using any of the Islet's attest, verify or other functions. Where are the functions getting used then?

device.cpp is bulit on top of the certifier framework where Islet is integrated.
More specifically, what the certifier does is provide a unified APIs (e.g., attest) with an abstraction for different CC platforms (SEV-SNP, SGX, and CCA), meaning that
device.cpp is designed to call certifier's APIs (e.g., certify_me()) which in turn call Islet's APIs internally.
(honestly, the current implementation does not call Islet APIs though. I'll update it next month as well to actually call Islet APIs through the certifier)

Who does Islet provide these API services to?

Applications running on a Realm (VM) can directly use such APIs. As mentioned in the above, it's just that
Islet APIs are abstracted away by the certifier in confidential-ml examples.