Re: [PATCH v8 02/11] x86/virt/tdx: Allocate page bitmap for Dynamic PAMT
"Edgecombe, Rick P" <[email protected]> Wed, 29 Jul 2026 22:14:31 +0000
| Newsgroups | dev.linux.lists.sashiko-reviews,org.kernel.vger.kvm |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 2026-07-25 at 00:33 +0000, [email protected] wrote: > [Severity: Medium] > Does assigning val to pamt_page_bitmap_entry_bits result in an unsafe > truncation? > > Since pamt_page_bitmap_entry_bits is declared as a u8 in > struct tdx_sys_info_tdmr, and the metadata field ID 0x9100000100000013 > specifies a 16-bit value according to the TDX ABI (bits 33:32 are '01'), > a value from the hardware might be silently truncated. > > If a future TDX module increases the required bitmap entry size to 256 bits > or more, wouldn't this truncation cause severe memory under-allocation for > the physically contiguous PAMT memory? Impressed that Sashiko is so knowledgeable about TDX. The spec lists pamt_page_bitmap_entry_bits as byte sized so there will be no truncation. But 33:32 could be 00 and still work. The docs say: All metadata read and write interface functions (e.g., TDH.MNG.RD, TDH.MNG.WR, TDH.VP.RD, TDG.SYS.RDALL etc.) ignore this field when used as an input; they use an implicit value. Hmm... Both will work, but 00 for 33:32 would arguably be more correct even if it is ignored. Hate to spin another version for this tiny non-functional thing. Hmm...