Re: Livepatch, symbol resolutions between two livepatchs (new_symbol=0)

[Ross Lagerwall <ross.lagerwall@citrix.com>]

On 08/11/2016 02:28 AM, Konrad Rzeszutek Wilk wrote:
> Hey Ross,
>
> I am running in a symbol dependency issue that I am not exactly
> sure how to solve.
>
> I have an payload that introduces a new function (xen_foobar) which
> will patch over xen_extra_version().
>
snip
>
> As livepatch_symbols_lookup_by_name only looks for symbols that
> have the ->new_symbol set. And xen_foobar does not. So the loading is
> aborted.
>
> Which makes sense - we don't want to match the symbols as they haven't
> really been "finally loaded" in.
>
> But what if the xen_foobar is applied. In that case we should
> change the xen_foobar to be new_symbol=1?

I think you're confused about the purpose of new_symbol. The purpose is 
to ensure that you link against the correct symbol from the base 
hypervisor or the live patch that first introduced it. So, new_symbol=0 
is when a symbol overrides an existing symbol. new_symbol=1 is set when 
a symbol is new introduced in a live patch.

Since all the linking happens during load and not apply, it is perfectly 
OK to link against a symbol that hasn't been applied -- the dependencies 
are there to ensure that you can't apply a patch which links against 
unapplied symbols.

The assumption is that when overriding an existing symbol, the symbol in 
the payload has the same name as the one it is overriding. You're having 
issues above because you're breaking this assumption.

>
> This following patch does that, but I am wondering if there is a better
> way?

The patch is misusing new_symbol for something completely different from 
how it was intended so I hope there is a better way :-P

>
> P.S.
> The reason for this is that I am trying to implement NOP patching.
> And to have some regression testing of this I wrote an function
> (xen_foobar) which calls two functions: foo and bar - and their output is what
> the call to XENVER_extra_version will show (b/c we patch over
> xen_extra_version()).
>
> Then there is another payload - which will want to NOP the call to
> the 'bar' function inside xen_foobar. And for that I need to be able to
> lookup the symbol of xen_foobar.

This is quite a different use case from what currently exists. Currently 
we're only ever interested in writing over the start of the function 
pointed to by a symbol from the base hypervisor or first instance of a 
symbol in a live patch (aka new_symbol=1). Now you need to be able to 
lookup and write over an arbitrary symbol -- how do you choose between 
the n different loaded versions of the same symbol?

I must admit to not seeing the point in NOP patching. It just seems to 
be a special case of arbitrary data patching that could be more easily 
achieved using other means.

Let's have a discussion about this and the symbol issues here at the Xen 
Summit in a couple of weeks time.

-- 
Ross Lagerwall

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