The check against the expected Xen build ID should be done ahead of attempting
to apply the alternatives contained in the livepatch.

If the CPUID in the alternatives patching data is out of the scope of the
running Xen featureset the BUG() in _apply_alternatives() will trigger thus
bringing the system down.  Note the layout of struct alt_instr could also
change between versions.  It's also possible for struct exception_table_entry
to have changed format, hence leading to other kind of errors if parsing of the
payload is done ahead of checking if the Xen build-id matches.

Move the Xen build ID check as early as possible.  To do so introduce a new
check_xen_buildid() function that parses and checks the Xen build-id before
moving the payload.  Since the expected Xen build-id is used early to
detect whether the livepatch payload could be loaded, there's no reason to
store it in the payload struct, as a non-matching Xen build-id won't get the
payload populated in the first place.

Note parse_buildid() has to be slightly adjusted to allow fetching the section
data from the 'data' field instead of the 'load_addr' one: with the Xen build
ID moved ahead of move_payload() 'load_addr' is not yet set when the Xen build
ID check is performed.  Also printing the expected Xen build ID has part of
dumping the payload is no longer done, as all loaded payloads would have Xen
build IDs matching the running Xen, otherwise they would have failed to load.

Fixes: 879615f5db1d ('livepatch: Always check hypervisor build ID upon livepatch upload')
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
---
Changes since v1:
 - Do the Xen build-id check even earlier.
---
 xen/common/livepatch.c              | 66 +++++++++++++++++++----------
 xen/include/xen/livepatch_payload.h |  1 -
 2 files changed, 44 insertions(+), 23 deletions(-)

diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
index 8e61083f23a7..895c425cd5ea 100644
--- a/xen/common/livepatch.c
+++ b/xen/common/livepatch.c
@@ -448,24 +448,21 @@ static bool section_ok(const struct livepatch_elf *elf,
     return true;
 }
 
-static int xen_build_id_dep(const struct payload *payload)
+static int xen_build_id_dep(const struct livepatch_build_id *expected)
 {
     const void *id = NULL;
     unsigned int len = 0;
     int rc;
 
-    ASSERT(payload->xen_dep.len);
-    ASSERT(payload->xen_dep.p);
+    ASSERT(expected->len);
+    ASSERT(expected->p);
 
     rc = xen_build_id(&id, &len);
     if ( rc )
         return rc;
 
-    if ( payload->xen_dep.len != len || memcmp(id, payload->xen_dep.p, len) ) {
-        printk(XENLOG_ERR LIVEPATCH "%s: check against hypervisor build-id failed\n",
-               payload->name);
+    if ( expected->len != len || memcmp(id, expected->p, len) )
         return -EINVAL;
-    }
 
     return 0;
 }
@@ -480,7 +477,8 @@ static int parse_buildid(const struct livepatch_elf_sec *sec,
     /* Presence of the sections is ensured by check_special_sections(). */
     ASSERT(sec);
 
-    n = sec->load_addr;
+    /* Possibly use the temporary load buffer if load_addr isn't yet set. */
+    n = sec->load_addr ?: sec->data;
 
     if ( sec->sec->sh_size <= sizeof(*n) )
         return -EINVAL;
@@ -495,11 +493,44 @@ static int parse_buildid(const struct livepatch_elf_sec *sec,
    return 0;
 }
 
+static int check_xen_buildid(const struct livepatch_elf *elf)
+{
+    struct livepatch_build_id id;
+    const struct livepatch_elf_sec *sec =
+        livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_XEN_DEPENDS);
+    int rc;
+
+    if ( !sec )
+    {
+        printk(XENLOG_ERR LIVEPATCH "%s: %s is missing\n",
+               elf->name, ELF_LIVEPATCH_XEN_DEPENDS);
+        return -EINVAL;
+    }
+
+    rc = parse_buildid(sec, &id);
+    if ( rc )
+    {
+        printk(XENLOG_ERR LIVEPATCH "%s: failed to parse build-id at %s: %d\n",
+               elf->name, ELF_LIVEPATCH_XEN_DEPENDS, rc);
+        return -EINVAL;
+    }
+
+    rc = xen_build_id_dep(&id);
+    if ( rc )
+    {
+        printk(XENLOG_ERR LIVEPATCH
+               "%s: check against hypervisor build-id failed: %d\n",
+               elf->name, rc);
+        return -EINVAL;
+    }
+
+    return 0;
+}
+
 static int check_special_sections(const struct livepatch_elf *elf)
 {
     unsigned int i;
     static const char *const names[] = { ELF_LIVEPATCH_DEPENDS,
-                                         ELF_LIVEPATCH_XEN_DEPENDS,
                                          ELF_BUILD_ID_NOTE};
 
     for ( i = 0; i < ARRAY_SIZE(names); i++ )
@@ -755,12 +786,6 @@ static int prepare_payload(struct payload *payload,
     if ( rc )
         return rc;
 
-    rc = parse_buildid(livepatch_elf_sec_by_name(elf,
-                                                 ELF_LIVEPATCH_XEN_DEPENDS),
-                       &payload->xen_dep);
-    if ( rc )
-        return rc;
-
     /* Setup the virtual region with proper data. */
     region = &payload->region;
 
@@ -1069,6 +1094,10 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
     if ( rc )
         goto out;
 
+    rc = check_xen_buildid(&elf);
+    if ( rc )
+       goto out;
+
     rc = move_payload(payload, &elf);
     if ( rc )
         goto out;
@@ -1093,10 +1122,6 @@ static int load_payload_data(struct payload *payload, void *raw, size_t len)
     if ( rc )
         goto out;
 
-    rc = xen_build_id_dep(payload);
-    if ( rc )
-        goto out;
-
     rc = build_symbol_table(payload, &elf);
     if ( rc )
         goto out;
@@ -2199,9 +2224,6 @@ static void cf_check livepatch_printall(unsigned char key)
 
         if ( data->dep.len )
             printk("depend-on=%*phN\n", data->dep.len, data->dep.p);
-
-        if ( data->xen_dep.len )
-            printk("depend-on-xen=%*phN\n", data->xen_dep.len, data->xen_dep.p);
     }
 
     spin_unlock(&payload_lock);
diff --git a/xen/include/xen/livepatch_payload.h b/xen/include/xen/livepatch_payload.h
index 472d6a4a63c1..c6dc7cb5fa21 100644
--- a/xen/include/xen/livepatch_payload.h
+++ b/xen/include/xen/livepatch_payload.h
@@ -62,7 +62,6 @@ struct payload {
     unsigned int nsyms;                  /* Nr of entries in .strtab and symbols. */
     struct livepatch_build_id id;        /* ELFNOTE_DESC(.note.gnu.build-id) of the payload. */
     struct livepatch_build_id dep;       /* ELFNOTE_DESC(.livepatch.depends). */
-    struct livepatch_build_id xen_dep;   /* ELFNOTE_DESC(.livepatch.xen_depends). */
     livepatch_loadcall_t *const *load_funcs;   /* The array of funcs to call after */
     livepatch_unloadcall_t *const *unload_funcs;/* load and unload of the payload. */
     struct livepatch_hooks hooks;        /* Pre and post hooks for apply and revert */
-- 
2.46.0

On 25/09/2024 9:42 am, Roger Pau Monne wrote:
> The check against the expected Xen build ID should be done ahead of attempting
> to apply the alternatives contained in the livepatch.
>
> If the CPUID in the alternatives patching data is out of the scope of the
> running Xen featureset the BUG() in _apply_alternatives() will trigger thus
> bringing the system down.  Note the layout of struct alt_instr could also
> change between versions.  It's also possible for struct exception_table_entry
> to have changed format, hence leading to other kind of errors if parsing of the
> payload is done ahead of checking if the Xen build-id matches.
>
> Move the Xen build ID check as early as possible.  To do so introduce a new
> check_xen_buildid() function that parses and checks the Xen build-id before
> moving the payload.  Since the expected Xen build-id is used early to
> detect whether the livepatch payload could be loaded, there's no reason to
> store it in the payload struct, as a non-matching Xen build-id won't get the
> payload populated in the first place.
>
> Note parse_buildid() has to be slightly adjusted to allow fetching the section
> data from the 'data' field instead of the 'load_addr' one: with the Xen build
> ID moved ahead of move_payload() 'load_addr' is not yet set when the Xen build
> ID check is performed.  Also printing the expected Xen build ID has part of
> dumping the payload is no longer done, as all loaded payloads would have Xen
> build IDs matching the running Xen, otherwise they would have failed to load.
>
> Fixes: 879615f5db1d ('livepatch: Always check hypervisor build ID upon livepatch upload')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

Much nicer.  A couple of suggestions.

> ---
> Changes since v1:
>  - Do the Xen build-id check even earlier.
> ---
>  xen/common/livepatch.c              | 66 +++++++++++++++++++----------
>  xen/include/xen/livepatch_payload.h |  1 -
>  2 files changed, 44 insertions(+), 23 deletions(-)
>
> diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
> index 8e61083f23a7..895c425cd5ea 100644
> --- a/xen/common/livepatch.c
> +++ b/xen/common/livepatch.c
> @@ -448,24 +448,21 @@ static bool section_ok(const struct livepatch_elf *elf,
>      return true;
>  }
>  
> -static int xen_build_id_dep(const struct payload *payload)
> +static int xen_build_id_dep(const struct livepatch_build_id *expected)
>  {
>      const void *id = NULL;
>      unsigned int len = 0;
>      int rc;
>  
> -    ASSERT(payload->xen_dep.len);
> -    ASSERT(payload->xen_dep.p);
> +    ASSERT(expected->len);
> +    ASSERT(expected->p);
>  
>      rc = xen_build_id(&id, &len);
>      if ( rc )
>          return rc;
>  
> -    if ( payload->xen_dep.len != len || memcmp(id, payload->xen_dep.p, len) ) {
> -        printk(XENLOG_ERR LIVEPATCH "%s: check against hypervisor build-id failed\n",
> -               payload->name);
> +    if ( expected->len != len || memcmp(id, expected->p, len) )
>          return -EINVAL;
> -    }

I'd suggest merging this into check_xen_buildid(), which is the single
caller and serves the same singular purpose.

It removes the ASSERT() (expected is now a local variable), and it helps
with some diagnostic improvements.

>  
>      return 0;
>  }
> @@ -495,11 +493,44 @@ static int parse_buildid(const struct livepatch_elf_sec *sec,
>     return 0;
>  }
>  
> +static int check_xen_buildid(const struct livepatch_elf *elf)
> +{
> +    struct livepatch_build_id id;
> +    const struct livepatch_elf_sec *sec =
> +        livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_XEN_DEPENDS);
> +    int rc;
> +
> +    if ( !sec )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "%s: %s is missing\n",

"%s: Section: '%s' missing\n".

(Maybe no single quotes around the section as we know it's non-empty.)

> +               elf->name, ELF_LIVEPATCH_XEN_DEPENDS);
> +        return -EINVAL;
> +    }
> +
> +    rc = parse_buildid(sec, &id);
> +    if ( rc )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH "%s: failed to parse build-id at %s: %d\n",

"%s: Failed to parse section '%s' as build id: %d\n".

> +               elf->name, ELF_LIVEPATCH_XEN_DEPENDS, rc);
> +        return -EINVAL;
> +    }
> +
> +    rc = xen_build_id_dep(&id);
> +    if ( rc )
> +    {
> +        printk(XENLOG_ERR LIVEPATCH
> +               "%s: check against hypervisor build-id failed: %d\n",

"%s: build-id mismatch:\n"
"  livepatch: %*phN\n"
"        xen: %*phN\n"

This needs xen_build_id_dep() inlining in order to have the xen build-id
string, but the end result is much more informative.

I think I'm happy doing all of this on commit, but it might be a better
idea not to.

~Andrew

On Wed, Sep 25, 2024 at 11:21:01AM +0100, Andrew Cooper wrote:
> On 25/09/2024 9:42 am, Roger Pau Monne wrote:
> > The check against the expected Xen build ID should be done ahead of attempting
> > to apply the alternatives contained in the livepatch.
> >
> > If the CPUID in the alternatives patching data is out of the scope of the
> > running Xen featureset the BUG() in _apply_alternatives() will trigger thus
> > bringing the system down.  Note the layout of struct alt_instr could also
> > change between versions.  It's also possible for struct exception_table_entry
> > to have changed format, hence leading to other kind of errors if parsing of the
> > payload is done ahead of checking if the Xen build-id matches.
> >
> > Move the Xen build ID check as early as possible.  To do so introduce a new
> > check_xen_buildid() function that parses and checks the Xen build-id before
> > moving the payload.  Since the expected Xen build-id is used early to
> > detect whether the livepatch payload could be loaded, there's no reason to
> > store it in the payload struct, as a non-matching Xen build-id won't get the
> > payload populated in the first place.
> >
> > Note parse_buildid() has to be slightly adjusted to allow fetching the section
> > data from the 'data' field instead of the 'load_addr' one: with the Xen build
> > ID moved ahead of move_payload() 'load_addr' is not yet set when the Xen build
> > ID check is performed.  Also printing the expected Xen build ID has part of
> > dumping the payload is no longer done, as all loaded payloads would have Xen
> > build IDs matching the running Xen, otherwise they would have failed to load.
> >
> > Fixes: 879615f5db1d ('livepatch: Always check hypervisor build ID upon livepatch upload')
> > Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
> 
> Much nicer.  A couple of suggestions.
> 
> > ---
> > Changes since v1:
> >  - Do the Xen build-id check even earlier.
> > ---
> >  xen/common/livepatch.c              | 66 +++++++++++++++++++----------
> >  xen/include/xen/livepatch_payload.h |  1 -
> >  2 files changed, 44 insertions(+), 23 deletions(-)
> >
> > diff --git a/xen/common/livepatch.c b/xen/common/livepatch.c
> > index 8e61083f23a7..895c425cd5ea 100644
> > --- a/xen/common/livepatch.c
> > +++ b/xen/common/livepatch.c
> > @@ -448,24 +448,21 @@ static bool section_ok(const struct livepatch_elf *elf,
> >      return true;
> >  }
> >  
> > -static int xen_build_id_dep(const struct payload *payload)
> > +static int xen_build_id_dep(const struct livepatch_build_id *expected)
> >  {
> >      const void *id = NULL;
> >      unsigned int len = 0;
> >      int rc;
> >  
> > -    ASSERT(payload->xen_dep.len);
> > -    ASSERT(payload->xen_dep.p);
> > +    ASSERT(expected->len);
> > +    ASSERT(expected->p);
> >  
> >      rc = xen_build_id(&id, &len);
> >      if ( rc )
> >          return rc;
> >  
> > -    if ( payload->xen_dep.len != len || memcmp(id, payload->xen_dep.p, len) ) {
> > -        printk(XENLOG_ERR LIVEPATCH "%s: check against hypervisor build-id failed\n",
> > -               payload->name);
> > +    if ( expected->len != len || memcmp(id, expected->p, len) )
> >          return -EINVAL;
> > -    }
> 
> I'd suggest merging this into check_xen_buildid(), which is the single
> caller and serves the same singular purpose.
> 
> It removes the ASSERT() (expected is now a local variable), and it helps
> with some diagnostic improvements.

Sure.

> >  
> >      return 0;
> >  }
> > @@ -495,11 +493,44 @@ static int parse_buildid(const struct livepatch_elf_sec *sec,
> >     return 0;
> >  }
> >  
> > +static int check_xen_buildid(const struct livepatch_elf *elf)
> > +{
> > +    struct livepatch_build_id id;
> > +    const struct livepatch_elf_sec *sec =
> > +        livepatch_elf_sec_by_name(elf, ELF_LIVEPATCH_XEN_DEPENDS);
> > +    int rc;
> > +
> > +    if ( !sec )
> > +    {
> > +        printk(XENLOG_ERR LIVEPATCH "%s: %s is missing\n",
> 
> "%s: Section: '%s' missing\n".
> 
> (Maybe no single quotes around the section as we know it's non-empty.)
> 
> > +               elf->name, ELF_LIVEPATCH_XEN_DEPENDS);
> > +        return -EINVAL;
> > +    }
> > +
> > +    rc = parse_buildid(sec, &id);
> > +    if ( rc )
> > +    {
> > +        printk(XENLOG_ERR LIVEPATCH "%s: failed to parse build-id at %s: %d\n",
> 
> "%s: Failed to parse section '%s' as build id: %d\n".
> 
> > +               elf->name, ELF_LIVEPATCH_XEN_DEPENDS, rc);
> > +        return -EINVAL;
> > +    }
> > +
> > +    rc = xen_build_id_dep(&id);
> > +    if ( rc )
> > +    {
> > +        printk(XENLOG_ERR LIVEPATCH
> > +               "%s: check against hypervisor build-id failed: %d\n",
> 
> "%s: build-id mismatch:\n"
> "  livepatch: %*phN\n"
> "        xen: %*phN\n"
> 
> This needs xen_build_id_dep() inlining in order to have the xen build-id
> string, but the end result is much more informative.
> 
> I think I'm happy doing all of this on commit, but it might be a better
> idea not to.

No problem, I can send a v3.

Thanks, Roger.