ELF payload: what goes into MRTD and RTMRs?

[dimakuv]

I have my ELF payload. I link it with TD-Shim firmware like this:

$ cargo run -p td-shim-tools --bin td-shim-ld -- \
  target/x86_64-unknown-none/release/ResetVector.bin target/x86_64-unknown-none/release/td-shim \
  -t executable -p my-payload \
   -o resulting-binary

The resulting binary is 16MB in size:

$ $ ls -lah resulting-binary
-rw-r--r-- 16M Oct 31 01:27 resulting-binary

Then this resulting binary is fed to QEMU to start a TDX VM:

qemu ... -bios resulting-binary

I'm trying to make sense of the MRTD and RTMR measurements that I observe:

• My original payload:

  MRTD    = d0 78 10 95 8e 42 82 14 ...
  RTMR[0] = 2e 8f f9 2e d0 0d ed bc ...
  RTMR[1] = d7 c0 29 9f bf d0 a9 7d ...
  RTMR[2] = 00 00 00 00 00 00 00 00 ...
  RTMR[3] = 00 00 00 00 00 00 00 00 ...

• My slightly modified payload (one byte difference):

  report MRTD    = 52 cb 42 08 f1 15 3a d5 ...
  report RTMR[0] = 2e 8f f9 2e d0 0d ed bc ...
  report RTMR[1] = 3b 1a d8 a8 a7 61 8a c4 ...
  report RTMR[2] = 00 00 00 00 00 00 00 00 ...
  report RTMR[3] = 00 00 00 00 00 00 00 00 ...

I understand why RTMRs 2 and 3 are all-zeros. VMM, TD-Shim, and my payload do not touch these RTMRs.

I think I understand why RTMR[0] is a constant -- it's because I run QEMU with the same parameters (like the list of exposed devices), so RTMR[0] reflects the VMM inputs (the TD Hob generated by VMM and handed over to TD-Shim).

But I'm confused with MRTD and RTMR[1]:

• Apparently, MRTD reflects both the TD-Shim firmware itself and my payload binary.
• RTMR[1] reflects Payload and PayloadParam? But the payload binary was already measured into MRTD; why is it also measured into RTMR[1]? Why is RTMR[1] changed in my experiment?
  • What is PayloadParam exactly? How would it be reflected in my QEMU invocation? I don't pass any parameters to the payload, I don't use -append to add kernel arguments.

Your spec says this:

The payload may or might not be included in the binary and the payload may or might not be measured in MRTD based upon different use cases. If the payload image is not measured in MRTD, then it shall be measured to RTMR[1].

I'm confused by "based upon different use cases". What does it mean exactly? Who and how decides whether the payload is measured into MRTD? Is it decided by the VMM, based on the combination of -bios and -kernel cmdline arguments?

[jyao1]

It seems a bug - https://github.com/confidential-containers/td-shim/blob/main/td-shim/src/bin/td-shim/main.rs#L225 - to unconditionally extend payload to RTMR1.

If payload is already measured by TDMR, then this step should be skipped.

[gaojiaqi7]

PR #618 is submitted to fix the duplicate measurements.

$ cargo run -p td-shim-tools --bin td-shim-ld -- \
  target/x86_64-unknown-none/release/ResetVector.bin target/x86_64-unknown-none/release/td-shim \
  -t executable -p my-payload \
   -o resulting-binary

@dimakuv seems you are using the td-shim-ld tool without exec-payload-section feature, thus the payload binary is included in the BFV section. The reason for using this feature is that current upstream qemu does not support payload section type yet.

So in summary:

• If the exec-payload-section feature is disabled, the payload binary will be extended both into MRTD and RTMR[1]. The PR Measure payload only when EXTENDMR is not set #618 will fix the duplication and it will be measured into MRTD only.
• If the exec-payload-section feature is enabled, the payload binary will be extended into RTMR[1] only because the default attribute of payload section is PAGE.ADD.

You can try to enable the feature by adding --features=exec-payload-section to the command above and check if your qemu support it, thanks.

[jyao1]

@dimakuv , could you please take a look at the patch, to see if it resolved your problem?

[dimakuv]

@jyao1 @gaojiaqi7 I tried the PR #618:

~/td-shim$ git branch
* 1103/measure_payload_conditionally

I do the exact same steps as I described above. Unfortunately, I don't see any improvement:

• Original payload:

  report MRTD = 29 76 33 1d 88 9f 89 48 ...
  report RTMR[0] = 2e 8f f9 2e d0 0d ed bc ...
  report RTMR[1] = 52 c5 32 34 ff 70 82 4d ...
  report RTMR[2] = 00 00 00 00 00 00 00 00 ...
  report RTMR[3] = 00 00 00 00 00 00 00 00 ...

• Modified payload (1 byte modification):

  report MRTD = d9 97 5e 76 1b 0b 53 73 ...
  report RTMR[0] = 2e 8f f9 2e d0 0d ed bc ...
  report RTMR[1] = 77 6d 03 61 28 24 9e d1 ...
  report RTMR[2] = 00 00 00 00 00 00 00 00 ...
  report RTMR[3] = 00 00 00 00 00 00 00 00 ...

As you can notice, both MRTD and RTMR[1] are updated.

P.S. I didn't test --features=exec-payload-section yet. Could you elaborate more on the QEMU's payload argument, with some links?

[gaojiaqi7]

Missed the situation. It should work now. Thanks.

[dimakuv]

The latest commit seems to work fine:

• Original payload:

  report MRTD = a0 ed e1 8c f4 08 ff ab ...
  report RTMR[0] = 2e 8f f9 2e d0 0d ed bc ...
  report RTMR[1] = 51 89 23 b0 f9 55 d0 8d ...
  report RTMR[2] = 00 00 00 00 00 00 00 00 ...
  report RTMR[3] = 00 00 00 00 00 00 00 00 ...

• Modified payload (1 byte modification):

  report MRTD = c3 7b 5d 99 2d 98 b4 d7 ...
  report RTMR[0] = 2e 8f f9 2e d0 0d ed bc ...
  report RTMR[1] = 51 89 23 b0 f9 55 d0 8d ...
  report RTMR[2] = 00 00 00 00 00 00 00 00 ...
  report RTMR[3] = 00 00 00 00 00 00 00 00 ...

Now, MRTD is updated when the payload is modified. But RTMR[1] stays the same.

[jyao1]

@dimakuv , thank you very much to confirm that.