Github actions workflow for building CVM image on release

[ameba23]

This builds a confidential virtual machine image containing the entropy-tss binary when a release is made.

Eventually the binary could be built reproducibly from within yocto or guix - see: entropyxyz/meta-entropy-tss#2

But for now, entropy-tss is built in a docker container with our usual release workflow, and the binary bundled into the image.

[ameba23]

Did a test run and there are two problems:

ENTROPY_TSS_BINARY_URI variable is not being set - from this log line:

Parsing recipes...NOTE: /build/srcs/poky/meta-entropy-tss/recipes-core/entropy-tss/entropy-tss.bb: ENTROPY_TSS_BINARY_URI is set to:

upload-artifacts action cannot find the artifacts:

Warning: No files were found with the provided path: ~/work/yocto-build/yocto-build/reproducible-build/artifacts-base/core-image-minimal-tdx-gcp.rootfs.wic.tar.gz. No artifacts will be uploaded.

https://github.com/entropyxyz/entropy-core/actions/runs/13456986651/job/37604133561?pr=1313

[ameba23]

I have not yet tested the binaries from the release pipeline (built in with the entropyxyz/entropy-tss docker image) with our CVM image, but just to note that there are some difference from the known working one i have been using (which was built on ubuntu 24.10 with cargo.

Built with entropyxyz/entropy-tss:

$ ldd entropy-tss_v0.3.0_linux_amd64
	linux-vdso.so.1 (0x0000795a8da88000)
	libssl.so.1.1 => not found
	libcrypto.so.1.1 => not found
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000795a8da54000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x0000795a8c1c8000)
	libm.so.6 => /usr/lib/libm.so.6 (0x0000795a8c0d0000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x0000795a8c0c9000)
	libc.so.6 => /usr/lib/libc.so.6 (0x0000795a8bed7000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x0000795a8da8a000)

Known working configuration:

$ ldd ../src/entropy/meta-entropy-tss/recipes-core/entropy-tss/entropy-tss
	linux-vdso.so.1 (0x00007d2aca3d0000)
	libssl.so.3 => /usr/lib/libssl.so.3 (0x00007d2ac8924000)
	libcrypto.so.3 => /usr/lib/libcrypto.so.3 (0x00007d2ac8400000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007d2ac88f6000)
	libm.so.6 => /usr/lib/libm.so.6 (0x00007d2ac8308000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007d2ac8116000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007d2aca3d2000)   

There are some extra dependencies which maybe we don't (yet) have.

[ameba23]

The issues in my above comment are now fixed.

But there are some on-going issues with this:

• Build and release workflow fails following release of rustup 1.28.0 #1328
• upload-artifact gives us a URL to a zip archive, containing binaries for both x86 and arm. What we expect in the entropy-tss bitbake recipe is the URL of the x86 binary (not in a zip archive). So either we need to update that script to handle unzipping the file and storing it somewhere, or we need a way of uploading the unzipped x86 binary somewhere using something other than upload-artifact.
• To generate non-mock attestations, entropy-tss needs to be compiled with the production feature flag present. Likewise, to verify real PCK certificate chains and not allow mock quotes, entropy also needs to be compiled with the production feature flag present. So we need a way to pass this flag to the docker build setup.

Then the final problem - which i propose to do in a follow-up PR. We need to boot the CVM image, and hit the /version http route in order to get the measurement values which need to be included in the TDX testnet chainspec:

entropy-core/node/cli/src/chain_spec/tdx_testnet.rs

Line 25 in f436763

const ACCEPTED_MEASUREMENT: [u8; 32] = [0; 32];

This means we ideally need to programmatically deploy the CVM to google cloud, boot it and get the measurement. Which would mean setting up a service account for GCP.

We do have some scripts for generating the measurements from CVM images without booting them:

https://github.com/entropyxyz/yocto-build/blob/fd348438306218496e09c6e41159fa3407ea7a3d/Makefile#L26-L36

But i have not yet tested them and so for now i would propose we deploy and boot the image to be sure.