All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Ross Lagerwall <ross.lagerwall@citrix.com>,
	Konrad Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
	Bjoern Doebel <doebel@amazon.de>
Subject: Re: [PATCH v2] livepatch: account for patch offset when applying NOP patch
Date: Wed, 30 Mar 2022 16:19:30 +0200	[thread overview]
Message-ID: <YkRm8oc0vQzRQ7VL@Air-de-Roger> (raw)
In-Reply-To: <772f0afc-64db-6b98-af49-bd970ac78cbb@suse.com>

On Wed, Mar 30, 2022 at 01:05:31PM +0200, Jan Beulich wrote:
> While not triggered by the trivial xen_nop in-tree patch on
> staging/master, that patch exposes a problem on the stable trees, where
> all functions have ENDBR inserted. When NOP-ing out a range, we need to
> account for this. Handle this right in livepatch_insn_len().
> 
> This requires livepatch_insn_len() to be called _after_ ->patch_offset
> was set. Note however that the earlier call cannot be deleted. In fact
> its result should have been used to guard the is_endbr64() /
> is_endbr64_poison() invocations - add the missing check now. While
> making that adjustment, also use the local variable "old_ptr"
> consistently.
> 
> Fixes: 6974c75180f1 ("xen/x86: Livepatch: support patching CET-enhanced functions")

I have to admit I'm confused as to why that commit carries a Tested-by
from Arm.  Did Arm test the commit on x86 hardware?  Because that
commit only touches x86 specific code.

> Signed-off-by: Jan Beulich <jbeulich@suse.com>

FWIW, on the original implementation, I think it would have been
clearer to advance old_ptr and adjust the length?

> ---
> v2: Re-issue livepatch_insn_len(). Fix buffer overrun.
> ---
> Only build tested, as I don't have a live patching environment available.
> 
> For Arm this assumes that the patch_offset field starts out as zero; I
> think we can make such an assumption, yet otoh on x86 explicit
> initialization was added by the cited commit.
> 
> Note that the other use of is_endbr64() / is_endbr64_poison() in
> arch_livepatch_verify_func() would need the extra check only for
> cosmetic reasons, because ARCH_PATCH_INSN_SIZE > ENDBR64_LEN (5 > 4).
> Hence I'm not altering the code there.
> 
> --- a/xen/arch/x86/livepatch.c
> +++ b/xen/arch/x86/livepatch.c
> @@ -157,9 +157,15 @@ void noinline arch_livepatch_apply(struc
>       * loaded hotpatch (to avoid racing against other fixups adding/removing
>       * ENDBR64 or similar instructions).
>       */
> -    if ( is_endbr64(old_ptr) || is_endbr64_poison(func->old_addr) )
> +    if ( len >= ENDBR64_LEN &&
> +         (is_endbr64(old_ptr) || is_endbr64_poison(old_ptr)) )
>          func->patch_offset += ENDBR64_LEN;
>  
> +    /* This call must be re-issued once ->patch_offset has its final value. */
> +    len = livepatch_insn_len(func);
> +    if ( !len )
> +        return;
> +
>      memcpy(func->opaque, old_ptr + func->patch_offset, len);
>      if ( func->new_addr )
>      {
> --- a/xen/include/xen/livepatch.h
> +++ b/xen/include/xen/livepatch.h
> @@ -90,7 +90,7 @@ static inline
>  unsigned int livepatch_insn_len(const struct livepatch_func *func)
>  {
>      if ( !func->new_addr )
> -        return func->new_size;
> +        return func->new_size - func->patch_offset;

Seeing as func->patch_offset is explicitly initialized in
arch_livepatch_apply for x86, do we also need to do the same on Arm
now that the field will be used by common code?

Maybe the initialization done in arch_livepatch_apply for x86 is not
strictly required.

Thanks, Roger.


  reply	other threads:[~2022-03-30 14:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-30 11:05 [PATCH v2] livepatch: account for patch offset when applying NOP patch Jan Beulich
2022-03-30 14:19 ` Roger Pau Monné [this message]
2022-03-30 14:55   ` Jan Beulich
2022-03-30 15:02     ` Roger Pau Monné
2022-03-30 17:04 ` Roger Pau Monné
2022-03-31  6:42   ` Jan Beulich
2022-03-31  8:01     ` Roger Pau Monné
2022-03-31  8:13       ` Jan Beulich
2022-03-31  8:27         ` Roger Pau Monné
2022-03-31  8:36           ` Jan Beulich

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=YkRm8oc0vQzRQ7VL@Air-de-Roger \
    --to=roger.pau@citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=doebel@amazon.de \
    --cc=jbeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --cc=ross.lagerwall@citrix.com \
    --cc=wl@xen.org \
    --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.