linux-kernel - Re: [PATCH v12 03/19] x86: Secure Launch Resource Table header file

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: <Z8tJZBl2Nh4RJGDS@kernel.org>
Date: Fri, 7 Mar 2025 21:30:44 +0200
From: Jarkko Sakkinen <jarkko@...nel.org>
To: ross.philipson@...cle.com
Cc: 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-foundation.org,
	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,
	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 v12 03/19] x86: Secure Launch Resource Table header file

On Fri, Mar 07, 2025 at 11:22:02AM -0800, ross.philipson@...cle.com wrote:
> On 3/6/25 9:32 PM, Jarkko Sakkinen wrote:
> > On Thu, Dec 19, 2024 at 11:42:00AM -0800, Ross Philipson wrote:
> > > Introduce the Secure Launch Resource Table which forms the formal
> > > interface between the pre and post launch code.
> > > 
> > > Signed-off-by: Ross Philipson <ross.philipson@...cle.com>
> > 
> > Is this interface kernel specific or uarch specific? I'd just
> > explicitly state the context of the formal interface, that's
> > all.
> 
> It is specific to our DRTM solution (i.e. Secure Launch). It is meant to be
> extensible to accommodate future architectures that have DRTM support
> available. Not sure if I am getting at your specific question.

OK so:

1. It's software defined set of data structures with no ties to
   the hardware architecture.
2. It's essentially an API maintining backwards compatibility.

I have nothing against that definition. It is just that speaking about
formal interface between pre and post launch code does not provide
explanation on what are the constraints of the interface.

So what I was not getting was the specific definition (i.e. *the*
specific formalism under discussion).

BR, Jarkko