From: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
Ross Philipson <ross.philipson@oracle.com>,
trenchboot-devel@googlegroups.com,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions
Date: Sat, 24 May 2025 01:19:17 +0300 [thread overview]
Message-ID: <aDD0ZYM-PtV7NKVc@MjU3Nj> (raw)
In-Reply-To: <4896ab0b-f45e-43e9-bcee-f5496717eb2a@suse.com>
On Wed, May 21, 2025 at 05:45:04PM +0200, Jan Beulich wrote:
> > +/* SPDX-License-Identifier: GPL-2.0 */
>
> GPL-2.0-only is, I think, the one to use for new code.
Right.
> > +/*
> > + * Copyright (c) 2025 Apertus Solutions, LLC
> > + * Copyright (c) 2025 Oracle and/or its affiliates.
> > + * Copyright (c) 2025 3mdeb Sp. z o.o
>
> I'm curious: Considering the (just) 2 S-o-b, where's the 3rd copyright
> line coming from?
I'll add "Daniel P. Smith" (already in CC), not sure why his S-o-B
wasn't there.
> > +#include <xen/types.h>
>
> Looks like xen/stdint.h would suffice?
It would for types, but there is also use of `NULL`.
> > +#define UEFI_SLR_TABLE_GUID \
> > + { 0x877a9b2aU, 0x0385, 0x45d1, { 0xa0, 0x34, 0x9d, 0xac, 0x9c, 0x9e, 0x56, 0x5f } }
>
> I'm not sure this is a good place to put UEFI GUIDs. Considering e.g ...
It's here because the GUID is related more to SLRT than to EFI. I can
move it if there is a more fitting place for table GUIDs.
> > +/* SLR table header values */
> > +#define SLR_TABLE_MAGIC 0x4452544d
> > +#define SLR_TABLE_REVISION 1
> > +
> > +/* Current revisions for the policy and UEFI config */
> > +#define SLR_POLICY_REVISION 1
> > +#define SLR_UEFI_CONFIG_REVISION 1
>
> ... this, is the whole concept perhaps bound to UEFI? In which casethe
> whole header may want to move to the efi/ subdir?
This isn't EFI-specific, legacy boot is supported. Some types of
entries are there to provide EFI-specific information.
> > +/* SLR defined architectures */
> > +#define SLR_INTEL_TXT 1
> > +#define SLR_AMD_SKINIT 2
>
> These are both x86, yet the header is put in the common include dir?
It's x86-specific with the goal to add more architectures in the future.
I don't know, maybe the header should start as arch-specific and be
moved later, your call.
> > +/*
> > + * Primary SLR Table Header
> > + */
> > +struct slr_table
> > +{
> > + uint32_t magic;
> > + uint16_t revision;
> > + uint16_t architecture;
> > + uint32_t size;
> > + uint32_t max_size;
> > + /* entries[] */
> > +} __packed;
>
> If x86-specific, the question on the need for some of the __packed arises
> again.
The table is used to communicate data from pre-DRTM world to DRTM-world
and is produced and consumed by unrelated software components that don't
necessarily pad structures the same way by default.
> > +/*
> > + * Prototype of a function pointed to by slr_entry_dl_info::dl_handler.
> > + */
> > +typedef void (*dl_handler_func)(struct slr_bl_context *bl_context);
>
> It being an internal header, ...
> > + uint64_t dl_handler;
>
> ... why can't this type be used here then? This would presumably avoid a
> typecast later.
It's not an internal header in my understanding of the phrase, Xen
parses what a bootloader has passed to it. In principle, pointers could
be 32-bit here.
> > +static inline void *
> > +slr_end_of_entries(struct slr_table *table)
> > +{
> > + return (uint8_t *)table + table->size;
>
> Considering the function's return type, why not cast to void * (or perhaps
> const void *, if the return type also can be such)?
No particular reason other than that pointer arithmetic on
pointers-to-void typically causes build issues. Can be changed for Xen.
> > +static inline struct slr_entry_hdr *
> > +slr_next_entry(struct slr_table *table, struct slr_entry_hdr *curr)
> > +{
> > + struct slr_entry_hdr *next = (struct slr_entry_hdr *)
> > + ((uint8_t *)curr + curr->size);
> > +
> > + if ( (void *)next >= slr_end_of_entries(table) )
> > + return NULL;
>
> Is this sufficient as a check? With it fulfilled, ...
>
> > + if ( next->tag == SLR_ENTRY_END )
>
> ... this member access may still be out of bounds. IOW the question is what
> level of checking is really adequate here.
SLR_ENTRY_END should really end the table, but it won't hurt to check
for out of bounds. Thanks, will correct the checks.
> > +static inline struct slr_entry_hdr *
> > +slr_next_entry_by_tag (struct slr_table *table,
> > + struct slr_entry_hdr *entry,
> > + uint16_t tag)
> > +{
> > + if ( !entry ) /* Start from the beginning */
> > + entry = (struct slr_entry_hdr *)((uint8_t *)table + sizeof(*table));
>
> Extending from the earlier comment - if the inner cast was to void * here,
> the outer one could be dropped altogether.
>
> Jan
Will update.
Regards
next prev parent reply other threads:[~2025-05-23 22:19 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 [this message]
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
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=aDD0ZYM-PtV7NKVc@MjU3Nj \
--to=sergii.dmytruk@3mdeb.com \
--cc=dpsmith@apertussolutions.com \
--cc=jbeulich@suse.com \
--cc=ross.philipson@oracle.com \
--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.