[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |