search

confidential-containers / td-shim

Confidential Containers Shim Firmware
Other
91 stars 51 forks source link

ELF payload: what goes into MRTD and RTMRs? #617

Closed dimakuv closed 11 months ago

dimakuv commented 11 months ago

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:

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]:

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 commented 11 months ago

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 commented 11 months ago

PR https://github.com/confidential-containers/td-shim/pull/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:

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 commented 11 months ago

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

dimakuv commented 11 months ago

@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:

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 commented 11 months ago

Missed the situation. It should work now. Thanks.

dimakuv commented 11 months ago

The latest commit seems to work fine:

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

jyao1 commented 11 months ago

@dimakuv , thank you very much to confirm that.