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: <2c0074fa-4f58-4895-9c2e-e1fca59d3bdb@oracle.com>
Date: Thu, 18 Dec 2025 10:17:11 -0800
From: ross.philipson@...cle.com
To: Dave Hansen <dave.hansen@...el.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/18/25 8:34 AM, Dave Hansen wrote:
> 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.

That is an excellent idea, we will do that. I may be able to use the 
same the index scheme when I do the early remap operations too. That 
walks the heap each time but does not have to. It just wants a pointer 
to what to map.

Thank you,
Ross