Re: [PATCH v15 16/28] x86/txt: Intel Trusted eXecution Technology (TXT) definitions

Dave Hansen
2025-12-18T16:34:39Z

On 12/15/25 15:33, Ross Philipson wrote:
> +static inline void *txt_sinit_mle_data_start(void *heap)
> +{
> + return heap + txt_bios_data_size(heap) +
> + txt_os_mle_data_size(heap) +
> + txt_os_sinit_data_size(heap) + sizeof(u64);
> +}

So each one of these walks through the entire table?

Maybe I'm naive, but wouldn't this all be a lot more sane if it was just
parsed *once* into a table of pointers?

enum {
FIELD1,
FIELD2,
FIELD3,
MAX_NR
};

void *parseit(u8 *heap)
{
void *ptr_array[MAX_NR] = {};
void *place = heap;

for (int i = 0; i < MAX_NR; i++) {
// The buffer starts with the length:
u32 *size_ptr = place;

// Consume the length:
place += sizeof(*size_ptr);

// Point at the data:
ptr_array[i] = place;
// Consume the data:
place += *size_ptr;
}
// along with some sanity checks
}

Then, to access FIELDs you do:

struct field1_struct *f1s = ptr_array[FIELD1];
struct field2_struct *f1s = ptr_array[FIELD2];

Yeah, it means keeping that pointer array around. But <shrug>. It's also
not about performance. That ^ is a billion times easier to understand
because it lays out the "heap" logic in one place. You don't have to
recurse through half a dozen helpers to figure things out.