All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Marek Marczykowski-Górecki" <marmarek@invisiblethingslab.com>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: "Sergii Dmytruk" <sergii.dmytruk@3mdeb.com>,
	xen-devel@lists.xenproject.org,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Nicola Vetrini" <nicola.vetrini@bugseng.com>,
	"Doug Goldstein" <cardoe@cardoe.com>,
	"Daniel P. Smith" <dpsmith@apertussolutions.com>,
	"Ross Philipson" <ross.philipson@oracle.com>,
	trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v2 20/22] x86/slaunch: support EFI boot
Date: Wed, 14 May 2025 18:12:01 +0200	[thread overview]
Message-ID: <aCTA0UNMRbDex-Yi@mail-itl> (raw)
In-Reply-To: <1ba433ce-44b6-4d70-a232-f5f83f1fbaf8@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, May 14, 2025 at 11:58:49AM -0400, Demi Marie Obenour wrote:
> Why is it better for Xen to rely on the bootloader to implement the
> specification, instead of xen.efi itself implementing secure launch?
> That would make secure launch significantly more usable.  For an
> initial implementation it makes sense to rely on the bootloader, but
> in the future it would be better for xen.efi to have its own
> implementation.

That might be true when looking at the very limited use case. But if you
look at the broader ecosystem, having a common part in the bootloader
makes much more sense, as it can be reused for different kernels without
duplicating a lot of work.

- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmgkwNEACgkQ24/THMrX
1yypmggAiBWdTT3yTZKYA/28IVhTXRPemEGGqdDcqyC2mDQt102kgF7m46LwSv5I
eK1xY7Hz6AG3Mp9pRH4Jltx5j7SMZ0zzesYuADEpDTNIEWx6Xh+W6AQ5ttAKco1M
tcUFiYaDujesLwRNHJpjH1D9Ih82d1SbUoNyjBgnn1cmX2hXXntVDyXttz6P+xUy
Vl8eF3NYC90+sdc0g8aaKKWe6GqDzsBRj+heISYtymiWRcePWgFWMVMrIDB4Yqmo
+KnDYWsDTQn4Bddu1O6AVVVhvlnhgzP8sHWb20gjQpZG2jwJd1DQcNwQy2Ae04xS
Fxx8mBC75utOGNqnft/Pv098BnmYqQ==
=AulS
-----END PGP SIGNATURE-----


  reply	other threads:[~2025-05-14 16:12 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13 17:05 [PATCH v2 00/22] x86: Trenchboot Secure Launch DRTM (Xen) Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 01/22] x86/include/asm/intel-txt.h: constants and accessors for TXT registers and heap Sergii Dmytruk
2025-05-14 14:55   ` Andrew Cooper
2025-05-14 20:09     ` Krystian Hebel
2025-05-18 18:35     ` Sergii Dmytruk
2025-05-18 23:31       ` Rich Persaud
2025-05-19 13:43         ` Sergii Dmytruk
2025-05-19 20:55           ` Rich Persaud
2025-05-21 15:05     ` Jan Beulich
2025-05-21 15:19   ` Jan Beulich
2025-05-23 19:51     ` Sergii Dmytruk
2025-06-02  7:17       ` Jan Beulich
2025-06-02 22:00         ` Sergii Dmytruk
2025-06-03  7:06           ` Jan Beulich
2025-06-03  8:50             ` Sergii Dmytruk
2025-06-03  8:52               ` Jan Beulich
2025-06-03 15:20                 ` Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions Sergii Dmytruk
2025-05-21 15:45   ` Jan Beulich
2025-05-21 15:50     ` Andrew Cooper
2025-05-23 22:19     ` Sergii Dmytruk
2025-06-02  7:31       ` Jan Beulich
2025-06-02 22:19         ` Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 03/22] x86/boot: add MLE header and Secure Launch entry point Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 04/22] x86/boot/slaunch-early: implement early initialization Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 05/22] x86/boot/slaunch-early: early TXT checks and boot data retrieval Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 06/22] xen/arch/x86: reserve TXT memory during Slaunch Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 07/22] x86/mtrr: expose functions for pausing caching Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 08/22] x86/slaunch: restore boot MTRRs after Intel TXT DRTM Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 09/22] xen/lib: add implementation of SHA-1 Sergii Dmytruk
2025-05-14 16:58   ` Andrew Cooper
2025-05-17 18:17     ` Sergii Dmytruk
2025-05-18  8:34       ` Jan Beulich
2025-05-18 11:32         ` Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 10/22] x86/tpm.c: code for early hashing and extending PCRs (for TPM1.2) Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 11/22] x86/tpm.c: support extending PCRs of TPM2.0 Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 12/22] x86/hvm: check for VMX in SMX if Slaunch is active Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 13/22] x86/tpm.c: implement event log for TPM2.0 Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 14/22] x86/boot: choose AP stack based on APIC ID Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 15/22] x86/smpboot.c: TXT AP bringup Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 16/22] x86/slaunch: process DRTM policy Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 17/22] x86/acpi: disallow S3 on Secure Launch boot Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 18/22] x86/boot/slaunch-early: find MBI and SLRT on AMD Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 19/22] x86/slaunch: support AMD SKINIT Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 20/22] x86/slaunch: support EFI boot Sergii Dmytruk
2025-05-14  1:25   ` Demi Marie Obenour
2025-05-14 14:24     ` Sergii Dmytruk
2025-05-14 15:58       ` Demi Marie Obenour
2025-05-14 16:12         ` Marek Marczykowski-Górecki [this message]
2025-05-15 14:39         ` Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 21/22] x86/cpu: report SMX, TXT and SKINIT capabilities Sergii Dmytruk
2025-05-13 17:05 ` [PATCH v2 22/22] MAINTAINERS: add a section for TrenchBoot Slaunch Sergii Dmytruk
2025-05-14  6:36   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aCTA0UNMRbDex-Yi@mail-itl \
    --to=marmarek@invisiblethingslab.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=cardoe@cardoe.com \
    --cc=demiobenour@gmail.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=nicola.vetrini@bugseng.com \
    --cc=roger.pau@citrix.com \
    --cc=ross.philipson@oracle.com \
    --cc=sergii.dmytruk@3mdeb.com \
    --cc=sstabellini@kernel.org \
    --cc=trenchboot-devel@googlegroups.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.