From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org,
Ross Lagerwall <ross.lagerwall@citrix.com>
Subject: Re: [PATCH v2 4/6] xen/livepatch: do Xen build-id check earlier
Date: Wed, 25 Sep 2024 15:39:28 +0200 [thread overview]
Message-ID: <ZvQSkDv1rrASCsSu@macbook.local> (raw)
In-Reply-To: <eaa4a524-fd12-4716-9d9f-cff25a4c9bbf@citrix.com>
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.
next prev parent reply other threads:[~2024-09-25 13:39 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-25 8:42 [PATCH v2 0/6] xen/livepatch: improvements to loading Roger Pau Monne
2024-09-25 8:42 ` [PATCH v2 1/6] xen/livepatch: remove useless check for duplicated sections Roger Pau Monne
2024-09-25 8:52 ` Jan Beulich
2024-09-25 9:21 ` Roger Pau Monné
2024-09-25 9:29 ` Andrew Cooper
2024-09-25 8:42 ` [PATCH v2 2/6] xen/livepatch: zero pointer to temporary load buffer Roger Pau Monne
2024-09-25 9:33 ` Andrew Cooper
2024-09-25 10:00 ` Roger Pau Monné
2024-09-25 18:28 ` Andrew Cooper
2024-09-26 7:06 ` Roger Pau Monné
2024-09-26 8:22 ` Roger Pau Monné
2024-09-26 8:24 ` Andrew Cooper
2024-09-26 8:36 ` Roger Pau Monné
2024-09-25 8:42 ` [PATCH v2 3/6] xen/livepatch: simplify and unify logic in prepare_payload() Roger Pau Monne
2024-09-25 9:37 ` Andrew Cooper
2024-09-25 10:02 ` Roger Pau Monné
2024-09-25 8:42 ` [PATCH v2 4/6] xen/livepatch: do Xen build-id check earlier Roger Pau Monne
2024-09-25 10:21 ` Andrew Cooper
2024-09-25 13:39 ` Roger Pau Monné [this message]
2024-09-25 8:42 ` [PATCH v2 5/6] x86/alternatives: do not BUG during apply Roger Pau Monne
2024-09-25 9:01 ` Jan Beulich
2024-09-25 9:28 ` Roger Pau Monné
2024-09-25 10:02 ` Jan Beulich
2024-09-25 10:25 ` Andrew Cooper
2024-09-25 10:53 ` Andrew Cooper
2024-09-25 13:55 ` Roger Pau Monné
2024-09-25 8:42 ` [PATCH v2 6/6] x86/alternative: build time check feature is in range Roger Pau Monne
2024-09-25 8:51 ` Andrew Cooper
2024-09-25 9:24 ` Roger Pau Monné
2024-09-25 9:04 ` Jan Beulich
2024-09-25 9:23 ` Roger Pau Monné
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=ZvQSkDv1rrASCsSu@macbook.local \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ross.lagerwall@citrix.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.