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

Dave Hansen dave.hansen at intel.com
Thu Dec 18 08:34:36 PST 2025


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.



More information about the kexec mailing list