[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] RFC: how to differentiate livepatched symbol and original symbol in Xen hypervisor



On Mon, Jun 06, 2016 at 06:32:16AM -0700, Dongli Zhang wrote:
> Hi,
> 
> About the livepatch TODO: "Make XENPF_get_symbol also include Live Patch
> symbols" mentioned at http://wiki.xenproject.org/wiki/XSplice, I am wondering
> how the patched function would be dumped.

Thank you for taking a look!

> 
> For instance, if function "gnttab_usage_print_all" is livepatched, it  would
> show as symbol in both Xen hypervisor and applied livepatch. How are we going
> to differentiate the old and new symbols referring to the same symbol name but
> different address? One address is the original and another is the on pointed 
> by
> instruction "e9 xxxxxxxx".
> 
> Here is a sample on my test machine. The following is my own customized xen
> debug message in "xl debug-keys x". I am patching my own function 
> "my_old_func"
> in Xen hypervisor.
> 
> (XEN) name=my_global_domain, value=0xffff82d080409054, size=28, new=1
> (XEN) name=my_old_func, value=0xffff82d080409070, size=89, new=0
> (XEN) name=mg_data, value=0xffff82d08040a000, size=4, new=1
> 
> The following is the current result of XENPF_get_symbol on Dom0:
> 
> root@vm:/soft/img# cat /proc/xen/xensyms | grep my_old_func
> ffff82d0802465a4 T my_old_func
> ffff82d0802465a4 t .text.my_old_func
> 
> In this example, I livepatched "my_old_func" and thus we have two symbols
> referring the same name but different addresses now (ffff82d0802465a4 and
> ffff82d080409070).

/me nods.
> 
> Are we going to use new nm symbol flag , append extra string in symbol name
> (e.g., my_old_func#livepatch) or this even does not matter?


It should not matter. What the /proc/xen/xensyms should return is the new
address.

For that to work the hypercall makes a call to xensyms_read and that needs to
be fixed to also look in the livepatch symbols. It probably needs an iterator
function to walk over each of the 'virtual_region', like this:

diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index 20bbb28..5455a79 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -14,6 +14,9 @@ typedef const char *symbols_lookup_t(unsigned long addr,
                                      unsigned long *offset,
                                      char *namebuf);
 
+typedef int symbols_iterator_t(uint32_t *symnum, char *type,
+                               unsigned long *address, char *name);
+
 /* Lookup an address. */
 const char *symbols_lookup(unsigned long addr,
                            unsigned long *symbolsize,
diff --git a/xen/include/xen/virtual_region.h b/xen/include/xen/virtual_region.h
index e5e58ed..bba0ac7 100644
--- a/xen/include/xen/virtual_region.h
+++ b/xen/include/xen/virtual_region.h
@@ -18,6 +18,10 @@ struct virtual_region
     /* If this is NULL the default lookup mechanism is used. */
     symbols_lookup_t *symbols_lookup;
 
+    /* Walk over all of the symbols this region provides. */
+    symbols_iterator_t *symbol_iterator;
+    unsigned long nr_symbols;
+
     struct {
         const struct bug_frame *bugs; /* The pointer to array of bug frames. */
         size_t n_bugs;          /* The number of them. */


And xensyms_read would hook up to this.. somehow. And the livepatch.c would
hook its symbol iterator to this function as well.

<lots of handwaving>
> 
> Thank you very much!
> 
> Best,
> 
> Dongli Zhang

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.