MigTD hash mismatch with TDX Module

[fengyuleidian0615]

Hi @gaojiaqi7

User has MigTD with head commit 4f366e0 (HEAD -> main, origin/main, origin/HEAD) vsock: split large data into multiple packets to comply with size limits

Then follow steps as below to compute hash used for prebind, however the hash is different with the one reported from TDX Module, looking further, all the ingredients are same except MRTD, any suggestion here?

./target/debug/migtd-hash --manifest config/servtd_info.json --image <migtd.bin>

Thanks!

[fengyuleidian0615]

The root cause looks like as below:

migtd-hash would eventually call td-shim tee_info_hash to calculate MRTD.
The scheme of calculation from user space tool is:

1. Loop each sections
   2. Loop each page in section
   2a. Measure page attribute for non type 4 (TYPE_PERM_MEM)
   2b. Measure page(16x256B) data for section with attribute =1, marked as measurement

While some VMM/Qemu implement the schema otherwise:

1. Loop each sections
   1a. Create GPA:HPA mapping for the section
   1a.x. Loop each page to measure page attribute for non type 4 (TYPE_PERM_MEM)
   1b. Measure the section with attribute =1, marked as measurement
   1b.x Loop each page(16x256B) to measure the data

Summary:
The hash tool uses per page basis to measure page attribute and then page data; while some VMM/Qemu prefers per section granularity, therefore different hash scheme produce non-matched hash values in the end.

We need to align with upstream design of how to populate memory region for TDVF/Migtd.

Snapshot of sections information from migtd.
{DataOffset = 0xf97000, RawDataSize = 0x69000, MemoryAddress = 0xfff97000, MemoryDataSize = 0x69000, Type = 0x0, Attributes = 0x1}, {DataOffset = 0x41000, RawDataSize = 0xf56000, MemoryAddress = 0xff041000, MemoryDataSize = 0xf56000, Type = 0x5, Attributes = 0x1}, {DataOffset = 0x0, RawDataSize = 0x20000, MemoryAddress = 0xff000000, MemoryDataSize = 0x20000, Type = 0x1, Attributes = 0x0}, {DataOffset = 0x0,RawDataSize = 0x0, MemoryAddress = 0xff021000, MemoryDataSize = 0x10000, Type = 0x3, Attributes = 0x0}, {DataOffset = 0x0, RawDataSize = 0x0,MemoryAddress = 0xff031000, MemoryDataSize = 0x10000, Type = 0x3, Attributes = 0x0}, {DataOffset = 0x0, RawDataSize = 0x0, MemoryAddress = 0x0,MemoryDataSize = 0x2000000, Type = 0x4, Attributes = 0x2}, {DataOffset = 0x0, RawDataSize = 0x0, MemoryAddress = 0xff020000,MemoryDataSize = 0x1000, Type = 0x3, Attributes = 0x0}}

[jyao1]

@fengyuleidian0615 , thanks.

Would you please submit PR to td-shim project directly?

[gaojiaqi7]

Hi @fengyuleidian0615 , from the patch fengyuleidian0615/td-shim@e68fed1, I don't see difference of the final calculation result: if the attribute is not PAGE_ADD/EXTENDMR, it won't take any page of the section into account. Could you provide more details/references about the change?

[gaojiaqi7]

The root cause looks like as below:

migtd-hash would eventually call td-shim tee_info_hash to calculate MRTD. The scheme of calculation from user space tool is:

1. Loop each sections
   2. Loop each page in section
   2a. Measure page attribute for non type 4 (TYPE_PERM_MEM)
   2b. Measure page(16x256B) data for section with attribute =1,  marked as measurement

While some VMM/Qemu implement the schema otherwise:

1. Loop each sections
   1a. Create GPA:HPA mapping for the section
   1a.x. Loop each page to measure page attribute for non type 4 (TYPE_PERM_MEM)
   1b. Measure the section  with attribute =1,  marked as measurement
   1b.x  Loop each page(16x256B) to measure the data

Although QEMU loops by sections, KVM finally calls the TDH.MEM.PAGE.ADD in PAGE_SIZE granularity or TDH.MR.EXTEND in 256B granularity in kernel space, so I think the implementations are equivalent. Please correct me if my understanding is wrong.

[fengyuleidian0615]

Hi @gaojiaqi7

A: stands for page range attribute(GPA)
B: stands for actual page data

ADD PAGE seamcall will measure A
Extend seamcall will measure B

So in the end, we come into two types of streams to measure:
ABABAB...
AAAA...BBBB...

That would produce distinct final hash value.

[gaojiaqi7]

Hi @gaojiaqi7

A: stands for page range attribute(GPA) B: stands for actual page data

ADD PAGE seamcall will measure A Extend seamcall will measure B

So in the end, we come into two types of streams to measure: ABABAB... AAAA...BBBB...

That would produce distinct final hash value.

Thanks @fengyuleidian0615 for the explanation, I understand your point now.

I just checked the upstream KVM implementation in https://github.com/torvalds/linux/blob/v6.16/arch/x86/kvm/vmx/tdx.c#L3153-L3288, it appears to measure these pages in the ABABAB pattern. I think we need to keep align with it unless there is a clearly different spec definition.

[fengyuleidian0615]

I just checked the upstream KVM implementation in https://github.com/torvalds/linux/blob/v6.16/arch/x86/kvm/vmx/tdx.c#L3153-L3288, it appears to measure these pages in the ABABAB pattern. I think we need to keep align with it unless there is a clearly different spec definition.

It's the underlying design from TDX module opens such glitches for upper OS to choose different flow, although upstream Linux employs per-page style, there are out-of-tree design/customized optimization/ 3rd OS implementations besides Linux & Windows could possible still use per-section way.

Essentially TDX Module should merge the ADD PAGE seamcall with EXTEND seamcall by ADD_PAGE(...extend_me_flag) to enforce a unified measure pattern once for all. Anyway I'm not pushing per-section fix here, I think it's worthwhile to document per-page measure description in MigTD hash tool readme explicitly.