-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensuring the measurement register value(s) corresponds to an enclave running the entropy-tss binary #6
Comments
Other projects have solved this problem by instead using the fourth runtime measurement register ( |
Here is the TDX event log for one of our CVMs, which should give an idea of how RTMR 0, 1 and 2 are computed:
|
The best description i have found for how the measurements are made is in: https://www.intel.com/content/www/us/en/content-details/783067/whitepaper-linux-stacks-for-intel-trust-domain-extension-1-0.html But i am still not sure how we can get our binary measured without it being part of the kernal or initrd. |
From reading intel's docs, i had understood that initramfs was not included in measurements. But this post from Flashbots says:
If thats true, we need to create an initramfs for our image, and include the entropy-tss binary there. |
The MRTD register holds the build time measurement for an enclave, and is included in a TDX quote report.
We hope to use this value to determine whether validators are running the VM image from our release.
But currently, it seems that when binaries in the VM image
.qcow2
file are modified, the MRTD value given in quotes does not change.In the Whitepaper linux stacks for intel TDX v1.0 section 3.3, and section 4.2.3 it mentions that the secure boot variables are statically measured into the MRTD.
I'm not sure if this means we need to use secure boot (with Open Virtual Machine Firmware), or if there is some other way of ensuring that our binary gets used in the calculation of the MRTD value.
The canonical tutorial gives an example of using secure boot, but only with virsh (and i am currently using qemu). There are examples elsewhere of using secure boot with qemu.
The text was updated successfully, but these errors were encountered: