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 12:11:59 -0400 [thread overview]
Message-ID: <20160919161158.GC9860@localhost.localdomain> (raw)
In-Reply-To: <57DFC514020000780010FDBF@prv-mh.provo.novell.com>
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;
}
[And update the design]
> can be zero would also be wrong.
>
> > @@ -43,23 +42,36 @@ int arch_livepatch_verify_func(const struct livepatch_func *func)
> >
> > void arch_livepatch_apply_jmp(struct livepatch_func *func)
> > {
> > - int32_t val;
> > uint8_t *old_ptr;
> > -
> > - BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->opaque));
> > - BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof(val)));
> > + uint8_t insn[sizeof(func->opaque)];
> > + unsigned int len;
> >
> > old_ptr = func->old_addr;
> > - memcpy(func->opaque, old_ptr, PATCH_INSN_SIZE);
> > + len = livepatch_insn_len(func);
> > + if ( !len )
> > + return;
> > +
> > + memcpy(func->opaque, old_ptr, len);
> > + if ( func->new_addr )
> > + {
> > + int32_t val;
> > +
> > + BUILD_BUG_ON(ARCH_PATCH_INSN_SIZE != (1 + sizeof(val)));
> > +
> > + insn[0] = 0xe9;
> > + val = func->new_addr - func->old_addr - ARCH_PATCH_INSN_SIZE;
> > +
> > + memcpy(&insn[1], &val, sizeof(val));
> > + }
> > + else
> > + add_nops(&insn, len);
> >
> > - *old_ptr++ = 0xe9; /* Relative jump */
>
> Are you btw intentionally getting rid of this comment? And with the
Not at all. Just missed it.
> 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).
>
> > +static inline size_t livepatch_insn_len(const struct livepatch_func *func)
>
> I think it would be nice to use consistent types: The current sole caller
> stores the result of the function in an unsigned int, and I see no reason
> why the function couldn't also return such.
/me nods.
>
> 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 16:12 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 [this message]
2016-09-19 16:31 ` Jan Beulich
2016-09-19 17:02 ` Konrad Rzeszutek Wilk
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=20160919161158.GC9860@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.