[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 02/22] include/xen/slr-table.h: Secure Launch Resource Table definitions



On Wed, Jul 02, 2025 at 04:36:27PM +0200, Jan Beulich wrote:
> On 30.05.2025 15:17, Sergii Dmytruk wrote:
> > The file provides constants, structures and several helper functions for
> > parsing SLRT.
> >
> > The data described by the structures is passed to Xen by a bootloader
> > which initiated DRTM.
> >
> > Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
> > Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxx>
> > Signed-off-by: Sergii Dmytruk <sergii.dmytruk@xxxxxxxxx>
> > ---
> >  xen/include/xen/slr-table.h | 276 ++++++++++++++++++++++++++++++++++++
> >  1 file changed, 276 insertions(+)
> >  create mode 100644 xen/include/xen/slr-table.h
>
> Btw, please don't forget to Cc maintainers of code you're changing / adding.

What do you mean?  I'm running add_maintainers.pl on the patches.

> > +/*
> > + * Prototype of a function pointed to by slr_entry_dl_info::dl_handler.
> > + */
> > +typedef void (*dl_handler_func)(struct slr_bl_context *bl_context);
>
> I keep wondering why this ...
>
> > +/*
> > + * DRTM Dynamic Launch Configuration
> > + */
> > +struct slr_entry_dl_info
> > +{
> > +    struct slr_entry_hdr hdr;
> > +    uint64_t dce_size;
> > +    uint64_t dce_base;
> > +    uint64_t dlme_size;
> > +    uint64_t dlme_base;
> > +    uint64_t dlme_entry;
> > +    struct slr_bl_context bl_context;
> > +    uint64_t dl_handler;
>
> ... then isn't used right here, instead requiring a cast somewhere 
> (presumably,
> as code using this isn't visible in this patch).

As was mentioned earlier: because size of a pointer between Xen and a
bootloader doesn't necessarily match.  What you're proposing can break
under certain conditions.

> > +} __packed;
>
> I similarly keep wondering why there are all these packed attributes here, 
> when
> (afaics) all of the structures are defined in a way that any padding is 
> explicit
> anyway.

As before: it won't hurt, it's future-proof, just in case and to let
reader of the code know the structure must have no padding.  If you want
them gone, I can do that, but I think it will make the code harder to
maintain.

> > +static inline const struct slr_entry_hdr *
> > +slr_next_entry(const struct slr_table *table, const struct slr_entry_hdr 
> > *curr)
> > +{
> > +    const struct slr_entry_hdr *next = (void *)curr + curr->size;
> > +
> > +    if ( (void *)next + sizeof(*next) > slr_end_of_entries(table) )
> > +        return NULL;
> > +    if ( next->tag == SLR_ENTRY_END )
> > +        return NULL;
> > +    if ( (void *)next + next->size > slr_end_of_entries(table) )
> > +        return NULL;
> > +
> > +    return next;
> > +}
> > +
> > +static inline const struct slr_entry_hdr *
> > +slr_next_entry_by_tag(const struct slr_table *table,
> > +                      const struct slr_entry_hdr *entry,
> > +                      uint16_t tag)
> > +{
> > +    if ( !entry ) /* Start from the beginning */
> > +        entry = (void *)table + sizeof(*table);
> > +
> > +    for ( ; ; )
> > +    {
> > +        if ( entry->tag == tag )
> > +            return entry;
> > +
> > +        entry = slr_next_entry(table, entry);
> > +        if ( !entry )
> > +            return NULL;
> > +    }
> > +
> > +    return NULL;
> > +}
>
> For both of the functions, again: Please don't cast away const-ness.
>
> Jan

You had commented on v2 after v3 was already sent.

Regards



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.