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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6ddb3366-31a8-4d18-a553-908a035f7cf2@intel.com>
Date: Thu, 18 Dec 2025 08:34:36 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Ross Philipson <ross.philipson@...cle.com>, linux-kernel@...r.kernel.org,
 x86@...nel.org, linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-crypto@...r.kernel.org, kexec@...ts.infradead.org,
 linux-efi@...r.kernel.org, iommu@...ts.linux.dev
Cc: dpsmith@...rtussolutions.com, tglx@...utronix.de, mingo@...hat.com,
 bp@...en8.de, hpa@...or.com, dave.hansen@...ux.intel.com, ardb@...nel.org,
 mjg59@...f.ucam.org, James.Bottomley@...senpartnership.com,
 peterhuewe@....de, jarkko@...nel.org, jgg@...pe.ca, luto@...capital.net,
 nivedita@...m.mit.edu, herbert@...dor.apana.org.au, davem@...emloft.net,
 corbet@....net, ebiederm@...ssion.com, dwmw2@...radead.org,
 baolu.lu@...ux.intel.com, kanth.ghatraju@...cle.com,
 andrew.cooper3@...rix.com, trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v15 16/28] x86/txt: Intel Trusted eXecution Technology
 (TXT) definitions

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.