Re: [Xen-devel] [PATCH v4 7/9] livepatch: NOP if func->new_[addr] is zero.

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Aug 24, 2016 at 03:13:18AM -0600, Jan Beulich wrote:
> >>> On 24.08.16 at 04:22, <konrad.wilk@xxxxxxxxxx> wrote:
> > The NOP functionality will NOP any of the code at
> > the 'old_addr' or at 'name' if the 'new_addr' is zero.
> > The purpose of this is to NOP out calls, such as:
> > 
> >  e8 <4-bytes-offset>
> > 
> > (5 byte insn), or on ARM a 4 byte insn for branching.
> > But on x86 we could NOP instructions that are much
> > shorter or longer (up to 15 bytes).
> 
> And we could NOP multiple instructions in one go, i.e. the new
> boundary you introduce is still arbitrary.

True.

I am limited by the 'struct livepatch_func' -> opaque[31] size.

I figured an OK limit would be up to a maximum platform instruction size.
That is what the design document mentions too:
" then `new_size` determines how many instruction bytes to NOP (up to
platform limitations)."

But in reality it could be up to 31 bytes - unless I rework the 'opaque'
to have a void pointer to some bigger size structure - but if I do that
then this gets complicated.

Keep in mind that the person writting the payload can have multiple
'struct livepatch_func' - so you could NOP a stream of say 30 bytes
using two 'struct livepatch_func'.

If we allow the NOP to be up to the size of the 'opaque' size, then
you could NOP a stream of instructions up to 62 bytes with two 
'struct livepatch_func'. or such. Thought to keep this from blowing
up on ARM I would say it has to be up to modulo 4.

Do you have a preference on this?

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel