From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: andrew.cooper3@citrix.com, xen-devel@lists.xenproject.org,
ross.lagerwall@citrix.com
Subject: Re: [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero.
Date: Mon, 19 Sep 2016 13:02:33 -0400 [thread overview]
Message-ID: <20160919170233.GC30790@localhost.localdomain> (raw)
In-Reply-To: <57E02EFB020000780011041A@prv-mh.provo.novell.com>
On Mon, Sep 19, 2016 at 10:31:23AM -0600, Jan Beulich wrote:
> >>> On 19.09.16 at 18:11, <konrad.wilk@oracle.com> wrote:
> > On Mon, Sep 19, 2016 at 02:59:32AM -0600, Jan Beulich wrote:
> >> >>> On 16.09.16 at 17:29, <konrad.wilk@oracle.com> wrote:
> >> > @@ -31,11 +30,11 @@ void arch_livepatch_revive(void)
> >> >
> >> > int arch_livepatch_verify_func(const struct livepatch_func *func)
> >> > {
> >> > - /* No NOP patching yet. */
> >> > - if ( !func->new_size )
> >> > + /* If NOPing only do up to maximum amount we can put in the ->opaque. */
> >> > + if ( !func->new_addr && func->new_size > sizeof(func->opaque) )
> >> > return -EOPNOTSUPP;
> >> >
> >> > - if ( func->old_size < PATCH_INSN_SIZE )
> >> > + if ( func->old_size < ARCH_PATCH_INSN_SIZE )
> >> > return -EINVAL;
> >>
> >> Is that indeed a requirement when NOPing? You can easily NOP out
> >> just a single byte on x86. Or shouldn't in that case old_size == new_size
> >> anyway? In which case the comment further down stating that new_size
> >
> > The original intent behind .old_size was to guard against patching
> > functions that were less than our relative jump.
> >
> > (The tools end up computing the .old_size as the size of the whole function
> > which is fine).
> >
> > But with this NOPing support, you are right - we could have now an
> > function that is say 4 bytes long and we only need to NOP three bytes
> > out of it (the last instruction I assume would be 'ret').
> >
> > So perhaps this check needs just needs an 'else if' , like so:
> >
> > int arch_livepatch_verify_func(const struct livepatch_func *func)
> > {
> > /* If NOPing.. */
> > if ( !func->new_addr )
> > {
> > /* Only do up to maximum amount we can put in the ->opaque. */
> > if ( func->new_size > sizeof(func->opaque) )
> > return -EOPNOTSUPP;
> >
> > /* One instruction for 'ret' and the other to NOP. */
> > if ( func->old_size < 2 )
> > return -EINVAL;
> > }
> > else if ( func->old_size < ARCH_PATCH_INSN_SIZE )
> > return -EINVAL;
> >
> > return 0;
> > }
>
> Except that I wouldn't use 2, to not exclude patching out some
> single byte in the middle of a function, without regard to what the
> function's actual size is.
Uh-uh.
The _new_size_ determines how many bytes to NOP (in the context of
this patch). The old_size (where we check to be at min 2) is a safety
valve to make sure we don't NOP something outside the function.
..snip..
> >> NOP addition here, perhaps worth dropping the _jmp from the
> >> function name (and its revert counterpart)?
> >
> > Ooh, good idea. But I think it maybe better as a seperate patch (as it
> > also touches the ARM code).
>
> That's in the other series, isn't it?
It expands the existing ones. Right now in 'staging' branch we have an
arch/arm/livepatch.c which has these functions in it.
Granted nothing compiles them, so I could break it in this patch.
But I already cobbled up the patch so may as well use it?
From 45abdd6a0c3a6a2ca7180c7340032ac5b2b186a4 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 19 Sep 2016 12:20:27 -0400
Subject: [PATCH] livepatch: Drop _jmp from arch_livepatch_[apply,revert]_jmp
With "livepatch: NOP if func->new_addr is zero." that name
makes no more sense.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
v7: New submission
---
xen/arch/arm/livepatch.c | 4 ++--
xen/arch/x86/livepatch.c | 4 ++--
xen/include/xen/livepatch.h | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/xen/arch/arm/livepatch.c b/xen/arch/arm/livepatch.c
index 755f596..7f067a0 100644
--- a/xen/arch/arm/livepatch.c
+++ b/xen/arch/arm/livepatch.c
@@ -21,11 +21,11 @@ int arch_livepatch_verify_func(const struct livepatch_func *func)
return -ENOSYS;
}
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
{
}
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
{
}
diff --git a/xen/arch/x86/livepatch.c b/xen/arch/x86/livepatch.c
index 118770e..36bbc5f 100644
--- a/xen/arch/x86/livepatch.c
+++ b/xen/arch/x86/livepatch.c
@@ -47,7 +47,7 @@ int arch_livepatch_verify_func(const struct livepatch_func *func)
return 0;
}
-void arch_livepatch_apply_jmp(struct livepatch_func *func)
+void arch_livepatch_apply(struct livepatch_func *func)
{
uint8_t *old_ptr;
uint8_t insn[sizeof(func->opaque)];
@@ -76,7 +76,7 @@ void arch_livepatch_apply_jmp(struct livepatch_func *func)
memcpy(old_ptr, insn, len);
}
-void arch_livepatch_revert_jmp(const struct livepatch_func *func)
+void arch_livepatch_revert(const struct livepatch_func *func)
{
memcpy(func->old_addr, func->opaque, livepatch_insn_len(func));
}
diff --git a/xen/include/xen/livepatch.h b/xen/include/xen/livepatch.h
index 174af06..b7f66d4 100644
--- a/xen/include/xen/livepatch.h
+++ b/xen/include/xen/livepatch.h
@@ -86,8 +86,8 @@ unsigned int livepatch_insn_len(const struct livepatch_func *func)
int arch_livepatch_quiesce(void);
void arch_livepatch_revive(void);
-void arch_livepatch_apply_jmp(struct livepatch_func *func);
-void arch_livepatch_revert_jmp(const struct livepatch_func *func);
+void arch_livepatch_apply(struct livepatch_func *func);
+void arch_livepatch_revert(const struct livepatch_func *func);
void arch_livepatch_post_action(void);
void arch_livepatch_mask(void);
--
2.4.11
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-09-19 17:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-16 15:29 [PATCH v6] Livepatch fixes and general features for Xen4.8 Konrad Rzeszutek Wilk
2016-09-16 15:29 ` [PATCH v6 1/6] livepatch: Disallow applying after an revert Konrad Rzeszutek Wilk
2016-09-19 8:40 ` Jan Beulich
2016-09-21 12:47 ` Ross Lagerwall
2016-09-16 15:29 ` [PATCH v6 2/6] livepatch: Add limit of 2MB to payload .bss sections Konrad Rzeszutek Wilk
2016-09-19 8:43 ` Jan Beulich
2016-09-16 15:29 ` [PATCH v6 3/6] livepatch: NOP if func->new_addr is zero Konrad Rzeszutek Wilk
2016-09-19 8:59 ` Jan Beulich
2016-09-19 16:11 ` Konrad Rzeszutek Wilk
2016-09-19 16:31 ` Jan Beulich
2016-09-19 17:02 ` Konrad Rzeszutek Wilk [this message]
2016-09-19 20:44 ` Konrad Rzeszutek Wilk
2016-09-20 6:58 ` Jan Beulich
2016-09-19 9:21 ` Jan Beulich
2016-09-21 13:21 ` Ross Lagerwall
2016-09-16 15:29 ` [PATCH v6 4/6] livepach: Add .livepatch.hooks functions and test-case Konrad Rzeszutek Wilk
2016-09-16 15:29 ` [PATCH v6 5/6] livepatch/tests: Make .livepatch.depends be read-only Konrad Rzeszutek Wilk
2016-09-21 12:47 ` Ross Lagerwall
2016-09-16 15:29 ` [PATCH v6 6/6] livepatch/tests: Move the .name value to .rodata Konrad Rzeszutek Wilk
2016-09-19 9:06 ` Jan Beulich
2016-09-21 12:49 ` Ross Lagerwall
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=20160919170233.GC30790@localhost.localdomain \
--to=konrad.wilk@oracle.com \
--cc=JBeulich@suse.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.