Log TDX measurements on boot#143
Conversation
alexhulbert
left a comment
There was a problem hiding this comment.
I think we should try to keep as much binary artifact out of shared/as possible. is there any way we could do this cleanly without compiled code?
if it's hard, maybe we should consider adding to devtools instead
We can generate the quote and dump the whole thing as base64 with a script. But if we want to just print the measurement values, im not sure how we would parse the quote to extract them. |
@ameba23 Is this too hacky? 5 lines of perl does the job $b = "\0" x 1088;
sysopen F, "/dev/tdx_guest", 2 or die $!;
ioctl F, 0xc4405401, $b or die $!;
@r = unpack "(H96)4", substr $b, 784, 192;
print "RTMR$_: $r[$_]\n" for 0..3; |
Fine by me, if that counts as not using a binary. Im guessing we would have to add perl to Also on non-TDX hardware this prints: Maybe we can make it print something like 'Measurements not available on this platform'. |
|
lots of core Linux packages depend on Perl (e.g. debconf/dpkg, git, udev, etc) so we def already have it in the image, but adding it as an explicit dependency wouldn't hurt For the error message, this should do the trick: my $errmsg = "Measurements not available on this platform\n";
my $b = "\0" x 1088;
sysopen F, "/dev/tdx_guest", 2 or warn $errmsg and exit 0;
ioctl F, 0xc4405401, $b or die $!;
my @r = unpack "(H96)4", substr $b, 784, 192;
print "RTMR$_: $r[$_]\n" for 0..3; |
|
I have switched to using a perl script, and confirmed working on GCP: One thing worth noting, on Azure this presumably wont print the PCR values. Im not sure if we really care about that though. |
alexhulbert
left a comment
There was a problem hiding this comment.
let's do this with systemd. Systemd expects to be PID1, and this change pushes it to PID2
|
From GCP: |
This logs TDX measurement values on OS boot.
The idea is to make it easy to check that deployments have the expected measurement values without needing remote access to the image in order to generate an attestation.
The problem
On production images remote access via ssh / serial console should be disabled. But this makes it hard to check that the measurements match our released image. mripper requires ssh to do this. When trying to reproduce measurements computed by attest, it was annoying to require remote access.
Testing
Tested on GCP - in the serial logs i see this:
If started on a non-CVM i see:
Notes
As for the actual format of the measurements, we probably want to use JSON or something. But i first wanted to check whether people want this at all.
This is not intended to act as a proof that the measurements are correct, since we don't log the whole attestation with signatures. This is for internal testing of measurement computation only.