On 13/06/17 21:51, Andrew Cooper wrote:
> A symndx of STN_UNDEF is special, and means a symbol value of 0.
>
> There is no real symbol data for it, so avoid tripping over a NULL pointer
> with "elf->sym[symndx].sym->st_value".
>
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> ---
> CC: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> CC: Ross Lagerwall <ross.lagerw...@citrix.com>
> CC: Jan Beulich <jbeul...@suse.com>
> CC: Stefano Stabellini <sstabell...@kernel.org>
> CC: Julien Grall <julien.gr...@arm.com>
>
> Functionally tested on x86, but both arm variants look to suffer from the same
> issue.  Compile tested on all architectures.
>
> TODO: Figure out how my livepatch has a STN_UNDEF relocation...

On second thoughts, maybe STN_UNDEF symbols should be a hard failure.

(XEN) livepatch: live: Applying 1 functions
(XEN) ----[ Xen-4.10-unstable  x86_64  debug=y   Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<0000000000000000>] 0000000000000000

In this case, the hook function hasn't been wired up correctly, which
causes apply_payload() to fall over a NULL data->load_funcs[i]();

As for why the STN_UNDEF symbol, it comes from an assembly hook function
missing a .type attribute.  Still, Xen shouldn't crash when it
encounters one.

~Andrew

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

Reply via email to