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

Re: [PATCH v2 4/5] livepatch: Load built-in key during boot



On Sun, May 18, 2025 at 1:17 PM Jan Beulich <jbeulich@xxxxxxxx> wrote:
>
> On 15.05.2025 11:38, Ross Lagerwall wrote:
> > @@ -73,6 +75,10 @@ static struct livepatch_work livepatch_work;
> >  static DEFINE_PER_CPU(bool, work_to_do);
> >  static DEFINE_PER_CPU(struct tasklet, livepatch_tasklet);
> >
> > +#ifdef CONFIG_PAYLOAD_VERIFY
> > +static struct rsa_public_key builtin_payload_key;
>
> __read_mostly or even __ro_after_init?
>
> > @@ -2287,6 +2293,31 @@ static void cf_check livepatch_printall(unsigned 
> > char key)
> >      spin_unlock(&payload_lock);
> >  }
> >
> > +static int __init load_builtin_payload_key(void)
> > +{
> > +#ifdef CONFIG_PAYLOAD_VERIFY
> > +    const uint8_t *ptr;
> > +    uint32_t len;
> > +
> > +    rsa_public_key_init(&builtin_payload_key);
> > +
> > +    ptr = xen_livepatch_key_data;
> > +
> > +    memcpy(&len, ptr, sizeof(len));
>
> Doesn't this (and the similar one further down) need to be an endian-
> ness conversion? In fact, seeing how the data is being built, it's
> not really clear to me what endian-ness the field would be written
> in, when build host and target host endianness differ.

Good point. In v3, I've made this and the build-time tool use little
endian which in most cases should be a no-op.

>
> > +    ptr += sizeof(len);
> > +    builtin_payload_key.n = mpi_read_raw_data(ptr, len);
>
> Whether there are endianness concerns here I also don't know.

As a byte sequence, this always uses big endian (much like OpenSSL).
I've added a comment in v3 to clarify this.

Thanks,
Ross



 


Rackspace

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