RTMRs depending on guest memory size

[msanft]

TDX RTMRs 0 and 1 currently depend on the memory size of the guest VM. This is due to two things:

• OVMF measuring the Hobs, which are inherently dependent on the memory size due to their nature. While this makes sense as a primitive approach, these values could also be checked for validity instead of being measured in OVMF, such as in this patch.
• Only applies if an initrd is used; QEMU writing memory-size-dependent addresses into the kernel header, which is later measured in OVMF. This too, could be circumvented by a (possibly TDX-specific) patch in QEMU that loads the initrd to e.g. a fixed address, such as in this very primitive patch.

Now, this doesn't play well with general remote attestation use-cases where the guest memory size is not known in advance, such as with Kata containers.

Is this considered a problem, or are things working as intended? Arguing by measuring the initial memory contents, one could advocate for this being the correct behavior, but for real-world use-cases, this poses a problem.

[syncronize-issues-to-jira]

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/PEK-1499.

This message was autogenerated

[mythi]

Is this considered a problem, or are things working as intended? Arguing by measuring the initial memory contents, one could advocate for this being the correct behavior, but for real-world use-cases, this poses a problem.

The measurements come with an eventlog which can be "replayed" to check the log entries take you to the RTMR value in the signed quote. With that, the verifier can check individual log entries for the relevant measurements.

[msanft]

Thanks for the response, @mythi!

The measurements come with an eventlog which can be "replayed" to check the log entries take you to the RTMR value in the signed quote. With that, the verifier can check individual log entries for the relevant measurements.

I know, and while that does help for all other measurements made except the non-deterministic (across memory sizes), we're still unable to measure that one, which, unfortunately, contains all of the kernel. So there doesn't seem to be away to get a deterministic (again, across memory sizes) kernel measurement yet, which would kind of renders the other verifications worthless?

For the use-cases I'm aware of, deterministic and reproducible RTMRs would be the superior solution; But if the memory-dependent measurements should be kept, would it be a possibility to eventually move them into their own measurement event, so that the rest of the kernel (and firmware) could still be verified?

[mythi]

Let me do a bit of research and ask around.

btw, while not exactly the same #270 talks about the same problem space (and mentions the "no kernel measurement")

[mythi]

Let me do a bit of research and ask around.

btw, while not exactly the same #270 talks about the same problem space (and mentions the "no kernel measurement")

Sorry, I meant #263

[mythi]

Now, this doesn't play well with general remote attestation use-cases where the guest memory size is not known in advance, such as with Kata containers.

@msanft are you using the Kata OVMF + efi-stub flow to boot, btw?

[msanft]

@msanft are you using the Kata OVMF + efi-stub flow to boot, btw?

Yes. We're not directly using the upstream components as we build our own versions, but generally we go OVMF -> EFI stub

[mythi]

@msanft are you using the Kata OVMF + efi-stub flow to boot, btw?

Yes. We're not directly using the upstream components as we build our own versions, but generally we go OVMF -> EFI stub

OK, great. EFI CC Measurement protocol was added to 6.9 so Kata does not have it available just yet (we need to get Kata releases moved to 6.12 LTS). I've checked today I can create reference measurements for the cmdline.

Still working on the kernel part. I'm expecting it to follow tdx-virtual-firmware-design-guide-rev-004-20231206-6.pdf sub-section 12.2 but haven't gotten to it just yet.

[msanft]

EFI CC Measurement protocol was added to 6.9 so Kata does not have it available just yet

Yeah, we use a 6.11 kernel because of that.

But do I understand you correctly? Are you trying to implement measurement precalculation, or are you trying to reproduce the problem? We already have a precalculator available here: https://github.com/edgelesssys/contrast/tree/main/tools/tdx-measure

[mythi]

Trying to reproduce the problem but I also didn't have any tools for it. I'll check your tool and see what I get (which can be the same what you are raporting here ;)

[mythi]

The measurements come with an eventlog which can be "replayed" to check the log entries take you to the RTMR value in the signed quote. With that, the verifier can check individual log entries for the relevant measurements.

I know, and while that does help for all other measurements made except the non-deterministic (across memory sizes), we're still unable to measure that one, which, unfortunately, contains all of the kernel. So there doesn't seem to be away to get a deterministic (again, across memory sizes) kernel measurement yet, which would kind of renders the other verifications worthless?

Looking at your tool (which seems to "reproduce" the expected measurement flow for RTMRs), I can see you're not actually leveraging the eventlog. You don't necessarily need reference RTMR values (for all registries at least). The problem statement and why eventlog is a useful thing, is best described in a TCG doc.

With some simple tweaks to your tool, I can get the kernel "reference" hash:
b1f7c69add5a96861ea6d6ed53b6e43afda76010c2d36473022088a7eff818e2a1fb0ff9930f9cafbb5ad0fa7408aaeb

which correctly shows up in the CCEL:

==== TDX Event Log Entry - 12 [0x7D69B462] ====
RTMR              : 1
Type              : 0x80000003 (EV_EFI_BOOT_SERVICES_APPLICATION)
Length            : 140
Algorithms ID     : 12 (TPM_ALG_SHA384)
Digest[0] :
00000000  B1 F7 C6 9A DD 5A 96 86 1E A6 D6 ED 53 B6 E4 3A  .....Z......S..:
00000010  FD A7 60 10 C2 D3 64 73 02 20 88 A7 EF F8 18 E2  ..`...ds. ......
00000020  A1 FB 0F F9 93 0F 9C AF BB 5A D0 FA 74 08 AA EB  .........Z..t...
RAW DATA: ----------------------------------------------
7D69B462  02 00 00 00 03 00 00 80 01 00 00 00 0C 00 B1 F7  ................
7D69B472  C6 9A DD 5A 96 86 1E A6 D6 ED 53 B6 E4 3A FD A7  ...Z......S..:..
7D69B482  60 10 C2 D3 64 73 02 20 88 A7 EF F8 18 E2 A1 FB  `...ds. ........
7D69B492  0F F9 93 0F 9C AF BB 5A D0 FA 74 08 AA EB 4A 00  .......Z..t...J.
7D69B4A2  00 00 18 F0 9C 7A 00 00 00 00 00 72 CD 00 00 00  .....z.....r....
7D69B4B2  00 00 00 00 00 00 00 00 00 00 2A 00 00 00 00 00  ..........*.....
7D69B4C2  00 00 04 03 14 00 72 F7 28 14 4A B6 1E 44 B8 C3  ......r.(.J..D..
7D69B4D2  9E BD D7 F8 93 C7 04 04 12 00 6B 00 65 00 72 00  ..........k.e.r.
7D69B4E2  6E 00 65 00 6C 00 00 00 7F FF 04 00              n.e.l.......
RAW DATA: ----------------------------------------------

It is true that initrd_addr (derived from guest memory size) has an impact to the measurement.

However, in my tests so far I saw only two values for initrd_addr (VM sizes <4G and VM sizes >4G) so this would mean only two kernel reference measurements to compare. I'm still checking if I'm missing some cases.

I guess the remaining question is, is it possible to use the eventlog based verification? Kata/CoCo TDX evidence has CCEL included already. It sounds it's "cheaper" than maintaining OVMF/qemu patches.

[msanft]

However, in my tests so far I saw only two values for initrd_addr (VM sizes <4G and VM sizes >4G) so this would mean only two kernel reference measurements to compare. I'm still checking if I'm missing some cases.

Yeah, QEMU will "fix" the address if more than 4G of memory are used: https://github.com/qemu/qemu/blob/f48c205fb42be48e2e47b7e1cd9a2802e5ca17b0/hw/i386/x86.c#L1044-L1045

Below 4G, it will be loaded to a non-fixed address that depends on memory size. So e.g. 2G and 3G should result in different kernel hashes.

I guess the remaining question is, is it possible to use the eventlog based verification?

It is, even if it's not "as great" as just having the reference values (due to the sheer size of the event log that needs to be sent upon any attestation). But the memory-dependent kernel hashes are still a problem, also in the event log-based case, in my opinion.

[mythi]

But the memory-dependent kernel hashes are still a problem, also in the event log-based case, in my opinion.

Agree, it needs thinking. On my side, I can only see it changing below 2G VM sizes, though. The measurement above that remains the same.