* [PATCH v5] xSplice v1 design and implementation.
@ 2016-03-24 20:00 Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane Konrad Rzeszutek Wilk
` (27 more replies)
0 siblings, 28 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Hey!
Changelog:
v4: http://lists.xen.org/archives/html/xen-devel/2016-03/msg01776.html
- Lots of review. Lots of rework. Some patches checked in.
v3: http://www.gossamer-threads.com/lists/xen/devel/418262
and
http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg04106.html
- Act on all reviews.
- Redo the flow of patches
v2: http://lists.xen.org/archives/html/xen-devel/2016-01/msg01597.html
- Updated code/docs/design with review comments.
- Make xen also have an PT_NOTE
- Added more of Ross's patches
- Combined build-id patchset with this.
(since the RFC and the Seattle Xen presentation)
- Finished off some of the work around the build-id.
- Settled on the preemption mechanism.
- Cleaned the patches a lot up, broke them up to easy
review for maintainers.
v1: http://lists.xenproject.org/archives/html/xen-devel/2015-09/msg02116.html
- Put all the design comments in the code
Prototype: http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02595.html
[Posting by Ross]
- Took all reviews into account.
- Redid the patches
GIT TREE:
------------------------
git://xenbits.xen.org/people/konradwilk/xen.git xsplice.v5
*Tools Maintainers*
------------------------
Two of the patches have been reviewed and have an Ack by toolstack maintainers:
xen-xsplice: Tool to manipulate xsplice payloads
libxc: Implementation of XEN_XSPLICE_op in libxc
The other two need an Ack:
libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id
libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall
[This one has an Ack from George]
*Hypervisor Maintainers*
------------------------
The rest of the patches (24! of them) need Acks and Reviews...
Daniel has Acked the XSM checks in the hypervisor patches.
*What is xSplice?*
------------------------
A mechanism to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.
*What will this patchset do once I've it*
------------------------
Patch the hypervisor.
*Why are you emailing me?*
------------------------
Please please review as many patches as possible.
*OK, what do you have?*
------------------------
They are located at a git tree:
git://xenbits.xen.org/people/konradwilk/xen.git xsplice.v5
(Copying from Ross's email):
Much of the work is implementing a basic version of the Linux kernel module
loader. The code:
* Loading of xSplice ELF payloads.
* Copying allocated sections into a new executable region of memory.
* Resolving symbols.
* Applying relocations.
* Patching of altinstructions.
* Special handling of bug frames and exception tables.
* Unloading of xSplice ELF payloads.
* Compiling a sample xSplice ELF payload
* Resolving symbols
* Using build-id dependencies
* Support for shadow variable framework
* Support for executing ELF payload functions on load/unload.
The other main bit of this work is applying and reverting the patches safely.
As implemented, the code is patched with each CPU waiting in the
return-to-guest path (i.e. with no stack) or on the cpu-idle path
which appears to be the safest way of patching. While it is safe we should
still (in the next wave of patches) to verify to not patch cetain critical
sections (say the code doing the patching)
All of the following should work:
* Applying patches safely.
* Reverting patches safely.
* Replacing patches safely (e.g. reverting any applied patches and applying
a new patch).
* Bug frames as part of modules. This means adding or
changing WARN, ASSERT, BUG, and run_in_exception_handler works correctly.
Line number only changes _are ignored_.
* Exception tables as part of modules. E.g. wrmsr_safe and copy_to_user work
correctly when used in a patch module.
* Stacking of patches on top of each other
* Resolving symbols (even of patches)
*Limitations*
------------------------
The above is enough to fully implement an update system where multiple source
patches are combined (using combinediff) and built into a single binary
which then atomically replaces any existing loaded patches
(this is why Ross added a REPLACE operation). This is the approach used
by kPatch and kGraft.
Multiple completely independent patches can also be loaded but unexpected
interactions may occur.
As it stands, the patches are statically linked which means that independent
patches cannot be linked against one another (e.g. if one introduces a
new symbol). Using the combinediff approach above fixes this.
Backtraces containing functions from a patch module do not show the symbol name.
There is no checking that a patch which is loaded is built for the
correct hypervisor (need to use build-id).
Binary patching works at the function level.
*Testing*
------------------------
You can use the example code included in this patchset:
# xl info | grep extra
xen_extra : -unstable
# xen-xsplice load /usr/lib/debug/xen_hello_world.xsplice
Uploading /usr/lib/debug/xen_hello_world.xsplice (2071 bytes)
Performing check: completed
Performing apply:. completed
# xl info | grep extra
xen_extra : Hello World
# xen-xsplice revert xen_hello_world
Performing revert:. completed
# xen-xsplice unload xen_hello_world
Performing unload: completed
# xl info | grep extra
xen_extra : -unstable
Or you can use git://xenbits.xen.org/people/konradwilk/xsplice-build-tools.git
which generates the ELF payloads.
This link has a nice description of how to use the tool:
http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg02595.html
.gitignore | 5 +
Config.mk | 12 +
MAINTAINERS | 10 +
docs/misc/xsplice.markdown | 1127 ++++++++++++++++++
tools/flask/policy/policy/modules/xen/xen.te | 9 +-
tools/libxc/include/xenctrl.h | 94 +-
tools/libxc/xc_core.c | 35 +-
tools/libxc/xc_dom_boot.c | 12 +-
tools/libxc/xc_domain.c | 3 +-
tools/libxc/xc_misc.c | 337 ++++++
tools/libxc/xc_private.c | 53 +-
tools/libxc/xc_private.h | 7 +-
tools/libxc/xc_resume.c | 3 +-
tools/libxc/xc_sr_save.c | 9 +-
tools/libxc/xg_save_restore.h | 6 +-
tools/libxl/libxl.c | 96 +-
tools/libxl/libxl.h | 6 +
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 1 +
tools/misc/Makefile | 4 +
tools/misc/xen-xsplice.c | 463 ++++++++
tools/ocaml/libs/xc/xenctrl_stubs.c | 39 +-
tools/python/xen/lowlevel/xc/xc.c | 30 +-
tools/xenstat/libxenstat/src/xenstat.c | 12 +-
tools/xentrace/xenctx.c | 3 +-
xen/Makefile | 2 +
xen/arch/arm/Makefile | 7 +-
xen/arch/arm/setup.c | 4 +
xen/arch/arm/traps.c | 40 +-
xen/arch/arm/xen.lds.S | 14 +-
xen/arch/arm/xsplice.c | 75 ++
xen/arch/x86/Makefile | 45 +-
xen/arch/x86/alternative.c | 20 +-
xen/arch/x86/boot/mkelf32.c | 137 ++-
xen/arch/x86/domain.c | 4 +
xen/arch/x86/extable.c | 40 +-
xen/arch/x86/hvm/hvm.c | 1 +
xen/arch/x86/hvm/svm/svm.c | 2 +
xen/arch/x86/hvm/vmx/vmcs.c | 2 +
xen/arch/x86/setup.c | 13 +
xen/arch/x86/test/Makefile | 90 ++
xen/arch/x86/test/xen_bye_world.c | 34 +
xen/arch/x86/test/xen_bye_world_func.c | 25 +
xen/arch/x86/test/xen_hello_world.c | 65 ++
xen/arch/x86/test/xen_hello_world_func.c | 26 +
xen/arch/x86/test/xen_replace_world.c | 35 +
xen/arch/x86/test/xen_replace_world_func.c | 25 +
xen/arch/x86/traps.c | 45 +-
xen/arch/x86/x86_64/compat/entry.S | 2 +
xen/arch/x86/x86_64/entry.S | 2 +
xen/arch/x86/xen.lds.S | 23 +
xen/arch/x86/xsplice.c | 298 +++++
xen/common/Kconfig | 16 +
xen/common/Makefile | 4 +
xen/common/compat/kernel.c | 2 +
xen/common/kernel.c | 217 +++-
xen/common/symbols.c | 44 +-
xen/common/sysctl.c | 7 +
xen/common/version.c | 67 ++
xen/common/virtual_region.c | 160 +++
xen/common/vmap.c | 33 +-
xen/common/vsprintf.c | 15 +-
xen/common/xsplice.c | 1575 ++++++++++++++++++++++++++
xen/common/xsplice_elf.c | 398 +++++++
xen/common/xsplice_shadow.c | 109 ++
xen/include/asm-arm/nmi.h | 13 +
xen/include/asm-x86/alternative.h | 6 +
xen/include/asm-x86/uaccess.h | 5 +
xen/include/asm-x86/x86_64/page.h | 2 +
xen/include/public/arch-arm.h | 2 +
xen/include/public/sysctl.h | 167 +++
xen/include/public/version.h | 73 +-
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 4 +
xen/include/xen/symbols.h | 11 +
xen/include/xen/version.h | 6 +
xen/include/xen/virtual_region.h | 48 +
xen/include/xen/vmap.h | 14 +
xen/include/xen/xsplice.h | 131 +++
xen/include/xen/xsplice_elf.h | 56 +
xen/include/xen/xsplice_patch.h | 95 ++
xen/include/xsm/dummy.h | 21 +
xen/include/xsm/xsm.h | 6 +
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 44 +
xen/xsm/flask/policy/access_vectors | 25 +-
86 files changed, 6547 insertions(+), 284 deletions(-)
Konrad Rzeszutek Wilk (18):
HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall
arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup.
vmap: Add vmalloc_cb and vfree_cb
xsplice: Design document
xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
libxc: Implementation of XEN_XSPLICE_op in libxc
xen-xsplice: Tool to manipulate xsplice payloads
x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.
x86, xsplice: Print payload's symbol name and payload name in backtraces
build_id: Provide ld-embedded build-ids
HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id.
libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id
xsplice: Print build_id in keyhandler and on bootup.
xsplice: Stacking build-id dependency checking.
xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE
xsplice: Print dependency and payloads build_id in the keyhandler.
MAINTAINERS/xsplice: Add myself and Ross as the maintainers.
Ross Lagerwall (10):
xsplice: Add helper elf routines
xsplice: Implement payload loading
xsplice: Implement support for applying/reverting/replacing patches.
xsplice,symbols: Implement symbol name resolution on address.
xsplice: Add .xsplice.hooks functions and test-case
xsplice: Add support for bug frames.
xsplice: Add support for exception tables.
xsplice: Add support for alternatives
xsplice: Prevent duplicate payloads from being loaded.
xsplice: Add support for shadow variables.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-24 20:22 ` Andrew Cooper
2016-03-24 20:00 ` [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall Konrad Rzeszutek Wilk
` (26 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Stefano Stabellini, Konrad Rzeszutek Wilk, Ian Jackson,
Julien Grall, Stefano Stabellini, Jan Beulich, Keir Fraser,
Daniel De Graaf
This hypercall mirrors the XENVER_ in that it has similar functionality.
However it is designed differently:
- No compat layer. The data structures are the same size on 32
as on 64-bit.
- The hypercall accepts three arguments - the command, pointer to
an buffer, and the length of the buffer.
- Each sub-ops can be "probed" for size by returning the size of
buffer that will be needed - if the buffer is NULL.
- Subops can complete even if the buffer is too small - truncated
data will be filled and hypercall will return -ENOBUFS.
- VERSION_commandline, VERSION_changeset are privileged.
- There is no XENVER_compile_info equivalent.
- The hypercall can return -EPERM and toolstack/OSes are expected
to deal with. However there are three subops: XEN_VERSION_version,
XEN_VERSION_platform_parameters and XEN_VERSION_get_features
that will always return an value as guests cannot survive without them.
While we combine some of the common code between XENVER_ and VERSION_
take the liberty of moving pae_extended_cr3 in x86 area.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> [XSM bits]
---
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v1-v3: Was not part of the series.
v4: New posting.
v5: Remove memset and use {}. Tweak copy_to_guest and capabilities_info,
add ASSERT(sz) per Andrew's review. Add cached=1 back in.
Per Jan, s/VERSION_OP/VERSION/, squash size check with do_version_op,
update the comments. Dropped Andrew's Review-by. Ate newlines.
Added initcall to guard against garbage being set in cached data.
Folded code populating cache in __init. s/char/char[]/ in public.h
---
---
tools/flask/policy/policy/modules/xen/xen.te | 7 +-
xen/arch/arm/traps.c | 1 +
xen/arch/x86/hvm/hvm.c | 1 +
xen/arch/x86/x86_64/compat/entry.S | 2 +
xen/arch/x86/x86_64/entry.S | 2 +
xen/common/compat/kernel.c | 2 +
xen/common/kernel.c | 213 ++++++++++++++++++++++-----
xen/include/public/arch-arm.h | 2 +
xen/include/public/version.h | 70 ++++++++-
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 4 +
xen/include/xsm/dummy.h | 21 +++
xen/include/xsm/xsm.h | 6 +
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 35 +++++
xen/xsm/flask/policy/access_vectors | 21 ++-
16 files changed, 346 insertions(+), 43 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e174e48..7e69ce9 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -74,11 +74,12 @@ allow dom0_t xen_t:xen2 {
get_symbol
};
-# Allow dom0 to use all XENVER_ subops that have checks.
+# Allow dom0 to use all XENVER_ subops and VERSION subops that have checks.
# Note that dom0 is part of domain_type so this has duplicates.
allow dom0_t xen_t:version {
xen_extraversion xen_compile_info xen_capabilities
xen_changeset xen_pagesize xen_guest_handle xen_commandline
+ extraversion capabilities changeset pagesize guest_handle commandline
};
allow dom0_t xen_t:mmu memorymap;
@@ -145,10 +146,12 @@ if (guest_writeconsole) {
# pmu_ctrl is for)
allow domain_type xen_t:xen2 pmu_use;
-# For normal guests all possible except XENVER_commandline.
+# For normal guests all possible except XENVER_commandline, VERSION_changeset,
+# and VERSION_commandline
allow domain_type xen_t:version {
xen_extraversion xen_compile_info xen_capabilities
xen_changeset xen_pagesize xen_guest_handle
+ extraversion capabilities pagesize guest_handle
};
###############################################################################
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 83744e8..31d2115 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1235,6 +1235,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
HYPERCALL(multicall, 2),
HYPERCALL(platform_op, 1),
HYPERCALL_ARM(vcpu_op, 3),
+ HYPERCALL(version_op, 3),
};
#ifndef NDEBUG
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 80d59ff..f16b590 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5322,6 +5322,7 @@ static const struct {
COMPAT_CALL(platform_op),
COMPAT_CALL(mmuext_op),
HYPERCALL(xenpmu_op),
+ HYPERCALL(version_op),
HYPERCALL(arch_1)
};
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 33e2c12..fd25e84 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -394,6 +394,7 @@ ENTRY(compat_hypercall_table)
.quad do_tmem_op
.quad do_ni_hypercall /* reserved for XenClient */
.quad do_xenpmu_op /* 40 */
+ .quad do_version_op
.rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
.quad compat_ni_hypercall
.endr
@@ -445,6 +446,7 @@ ENTRY(compat_hypercall_args_table)
.byte 1 /* do_tmem_op */
.byte 0 /* reserved for XenClient */
.byte 2 /* do_xenpmu_op */ /* 40 */
+ .byte 3 /* do_version_op */
.rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
.byte 0 /* compat_ni_hypercall */
.endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 07ef096..b0e7257 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -730,6 +730,7 @@ ENTRY(hypercall_table)
.quad do_tmem_op
.quad do_ni_hypercall /* reserved for XenClient */
.quad do_xenpmu_op /* 40 */
+ .quad do_version_op
.rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
.quad do_ni_hypercall
.endr
@@ -781,6 +782,7 @@ ENTRY(hypercall_args_table)
.byte 1 /* do_tmem_op */
.byte 0 /* reserved for XenClient */
.byte 2 /* do_xenpmu_op */ /* 40 */
+ .byte 3 /* do_version_op */
.rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
.byte 0 /* do_ni_hypercall */
.endr
diff --git a/xen/common/compat/kernel.c b/xen/common/compat/kernel.c
index df93fdd..7a7ca53 100644
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -39,6 +39,8 @@ CHECK_TYPE(capabilities_info);
CHECK_TYPE(domain_handle);
+CHECK_TYPE(version_op_val);
+
#define xennmi_callback compat_nmi_callback
#define xennmi_callback_t compat_nmi_callback_t
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index a4a3c36..5616c06 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -221,6 +221,47 @@ void __init do_initcalls(void)
#endif
+static int get_features(struct domain *d, xen_feature_info_t *fi)
+{
+ switch ( fi->submap_idx )
+ {
+ case 0:
+ fi->submap = (1U << XENFEAT_memory_op_vnode_supported);
+ if ( paging_mode_translate(d) )
+ fi->submap |=
+ (1U << XENFEAT_writable_page_tables) |
+ (1U << XENFEAT_auto_translated_physmap);
+ if ( is_hardware_domain(d) )
+ fi->submap |= 1U << XENFEAT_dom0;
+#ifdef CONFIG_X86
+ if ( VM_ASSIST(d, pae_extended_cr3) )
+ fi->submap |= (1U << XENFEAT_pae_pgdir_above_4gb);
+ switch ( d->guest_type )
+ {
+ case guest_type_pv:
+ fi->submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
+ (1U << XENFEAT_highmem_assist) |
+ (1U << XENFEAT_gnttab_map_avail_bits);
+ break;
+ case guest_type_pvh:
+ fi->submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+ (1U << XENFEAT_supervisor_mode_kernel) |
+ (1U << XENFEAT_hvm_callback_vector);
+ break;
+ case guest_type_hvm:
+ fi->submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+ (1U << XENFEAT_hvm_callback_vector) |
+ (1U << XENFEAT_hvm_pirqs);
+ break;
+ }
+#endif
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
/*
* Simple hypercalls.
*/
@@ -298,47 +339,14 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_get_features:
{
xen_feature_info_t fi;
- struct domain *d = current->domain;
+ int rc;
if ( copy_from_guest(&fi, arg, 1) )
return -EFAULT;
- switch ( fi.submap_idx )
- {
- case 0:
- fi.submap = (1U << XENFEAT_memory_op_vnode_supported);
- if ( VM_ASSIST(d, pae_extended_cr3) )
- fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb);
- if ( paging_mode_translate(d) )
- fi.submap |=
- (1U << XENFEAT_writable_page_tables) |
- (1U << XENFEAT_auto_translated_physmap);
- if ( is_hardware_domain(d) )
- fi.submap |= 1U << XENFEAT_dom0;
-#ifdef CONFIG_X86
- switch ( d->guest_type )
- {
- case guest_type_pv:
- fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
- (1U << XENFEAT_highmem_assist) |
- (1U << XENFEAT_gnttab_map_avail_bits);
- break;
- case guest_type_pvh:
- fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
- (1U << XENFEAT_supervisor_mode_kernel) |
- (1U << XENFEAT_hvm_callback_vector);
- break;
- case guest_type_hvm:
- fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
- (1U << XENFEAT_hvm_callback_vector) |
- (1U << XENFEAT_hvm_pirqs);
- break;
- }
-#endif
- break;
- default:
- return -EINVAL;
- }
+ rc = get_features(current->domain, &fi);
+ if ( rc )
+ return rc;
if ( __copy_to_guest(arg, &fi, 1) )
return -EFAULT;
@@ -381,6 +389,123 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
return -ENOSYS;
}
+/* Computed by kernel_cache_init. */
+static xen_capabilities_info_t __read_mostly cached_cap;
+static unsigned int __read_mostly cached_cap_len;
+
+/*
+ * Similar to HYPERVISOR_xen_version but with a sane interface
+ * (has a length, one can probe for the length) and with one less sub-ops:
+ * missing XENVER_compile_info.
+ */
+DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
+ unsigned int len)
+{
+ union {
+ xen_version_op_val_t val;
+ xen_feature_info_t fi;
+ } u = {};
+ unsigned int sz = 0;
+ const void *ptr = NULL;
+ int rc = xsm_version_op(XSM_OTHER, cmd);
+
+ /* We can safely return -EPERM! */
+ if ( rc )
+ return rc;
+
+ /*
+ * The HYPERVISOR_xen_version differs in that some return the value,
+ * and some copy it on back on argument. We follow the same rule for all
+ * sub-ops: return 0 on success, positive value of bytes returned, and
+ * always copy the result in arg. Yeey sanity!
+ */
+ switch ( cmd )
+ {
+ case XEN_VERSION_version:
+ sz = sizeof(xen_version_op_val_t);
+ u.val = (xen_major_version() << 16) | xen_minor_version();
+ break;
+
+ case XEN_VERSION_extraversion:
+ sz = strlen(xen_extra_version()) + 1;
+ ptr = xen_extra_version();
+ break;
+
+ case XEN_VERSION_capabilities:
+ sz = cached_cap_len;
+ ptr = cached_cap;
+ break;
+
+ case XEN_VERSION_changeset:
+ sz = strlen(xen_changeset()) + 1;
+ ptr = xen_changeset();
+ break;
+
+ case XEN_VERSION_platform_parameters:
+ sz = sizeof(xen_version_op_val_t);
+ u.val = HYPERVISOR_VIRT_START;
+ break;
+
+ case XEN_VERSION_get_features:
+ sz = sizeof(xen_feature_info_t);
+
+ if ( guest_handle_is_null(arg) )
+ break;
+
+ if ( copy_from_guest(&u.fi, arg, 1) )
+ {
+ rc = -EFAULT;
+ break;
+ }
+ rc = get_features(current->domain, &u.fi);
+ break;
+
+ case XEN_VERSION_pagesize:
+ sz = sizeof(xen_version_op_val_t);
+ u.val = PAGE_SIZE;
+ break;
+
+ case XEN_VERSION_guest_handle:
+ sz = ARRAY_SIZE(current->domain->handle);
+ ptr = current->domain->handle;
+ break;
+
+ case XEN_VERSION_commandline:
+ sz = strlen(saved_cmdline) + 1;
+ ptr = saved_cmdline;
+ break;
+
+ default:
+ rc = -ENOSYS;
+ }
+
+ if ( rc )
+ return rc;
+
+ /*
+ * This hypercall also allows the client to probe. If it provides
+ * a NULL arg we will return the size of the space it has to
+ * allocate for the specific sub-op.
+ */
+ ASSERT(sz);
+ if ( guest_handle_is_null(arg) )
+ return sz;
+
+ if ( !rc )
+ {
+ unsigned int bytes = min(sz, len);
+
+ if ( copy_to_guest(arg, ptr ? : &u, bytes) )
+ rc = -EFAULT;
+
+ /* We return len (truncate) worth of data even if we fail. */
+ if ( !rc && sz > len )
+ rc = -ENOBUFS;
+ }
+
+ return rc == 0 ? sz : rc;
+}
+
DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
{
struct xennmi_callback cb;
@@ -418,6 +543,20 @@ DO(ni_hypercall)(void)
return -ENOSYS;
}
+static int __init kernel_cache_init(void)
+{
+ /*
+ * Pre-allocate the cache so we do not have to worry about
+ * simultaneous invocations on safe_strcat by guests and the cache
+ * data becoming garbage.
+ */
+ arch_get_xen_caps(&cached_cap);
+ cached_cap_len = strlen(cached_cap) + 1;
+
+ return 0;
+}
+__initcall(kernel_cache_init);
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 870bc3b..5f90718 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -128,6 +128,8 @@
* * VCPUOP_register_vcpu_info
* * VCPUOP_register_runstate_memory_area
*
+ * HYPERVISOR_version_op
+ * All generic sub-operations
*
* Other notes on the ARM ABI:
*
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index 24a582f..d71ec5b 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -30,7 +30,14 @@
#include "xen.h"
-/* NB. All ops return zero on success, except XENVER_{version,pagesize} */
+/*
+ * There are two hypercalls mentioned in here. The XENVER_ are for
+ * HYPERCALL_xen_version (17), while VERSION_ are for the
+ * HYPERCALL_version_op (41).
+ *
+ * The subops are very similar except that the later hypercall has a
+ * sane interface.
+ */
/* arg == NULL; returns major:minor (16:16). */
#define XENVER_version 0
@@ -87,6 +94,67 @@ typedef struct xen_feature_info xen_feature_info_t;
#define XENVER_commandline 9
typedef char xen_commandline_t[1024];
+/*
+ * The HYPERCALL_version_op has a set of sub-ops which mirror the
+ * sub-ops of HYPERCALL_xen_version. However this hypercall differs
+ * radically from the former:
+ * - It returns the amount of bytes returned.
+ * - It will return -XEN_EPERM if the guest is not permitted
+ * (Albeit XEN_VERSION_version, XEN_VERSION_platform_parameters, and
+ * XEN_VERSION_get_features will always return an value as guest cannot
+ * survive without this information).
+ * - It will return the requested data in arg.
+ * - It requires an third argument (len) for the length of the
+ * arg. Naturally the arg has to fit the requested data otherwise
+ * -XEN_ENOBUFS is returned.
+ *
+ * It also offers an mechanism to probe for the amount of bytes an
+ * sub-op will require. Having the arg have an NULL handle will
+ * return the number of bytes requested for the operation. Or an
+ * negative value if an error is encountered.
+ */
+
+typedef uint64_t xen_version_op_val_t;
+DEFINE_XEN_GUEST_HANDLE(xen_version_op_val_t);
+
+/*
+ * arg == xen_version_op_val_t. Encoded as major:minor (31..16:15..0), while
+ * 63..32 are zero.
+ */
+#define XEN_VERSION_version 0
+
+/* arg == char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_extraversion 1
+
+/* arg == char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_capabilities 3
+
+/* arg == char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_changeset 4
+
+/* arg == xen_version_op_val_t. */
+#define XEN_VERSION_platform_parameters 5
+
+/*
+ * arg = xen_feature_info_t - shares the same structure
+ * as the XENVER_get_features.
+ */
+#define XEN_VERSION_get_features 6
+
+/* arg == xen_version_op_val_t. */
+#define XEN_VERSION_pagesize 7
+
+/*
+ * arg == void.
+ *
+ * The toolstack fills it out for guest consumption. It is intended to hold
+ * the UUID of the guest.
+ */
+#define XEN_VERSION_guest_handle 8
+
+/* arg = char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_commandline 9
+
#endif /* __XEN_PUBLIC_VERSION_H__ */
/*
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 64ba7ab..1a99929 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -115,6 +115,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
#define __HYPERVISOR_tmem_op 38
#define __HYPERVISOR_xc_reserved_op 39 /* reserved for XenClient */
#define __HYPERVISOR_xenpmu_op 40
+#define __HYPERVISOR_version_op 41 /* supersedes xen_version (17) */
/* Architecture-specific hypercall definitions. */
#define __HYPERVISOR_arch_0 48
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 0c8ae0e..e8d2b81 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -147,6 +147,10 @@ do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
extern long
do_xenpmu_op(unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg);
+extern long
+do_version_op(unsigned int cmd,
+ XEN_GUEST_HANDLE_PARAM(void) arg, unsigned int len);
+
#ifdef CONFIG_COMPAT
extern int
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index abbe282..e5dad35 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -751,3 +751,24 @@ static XSM_INLINE int xsm_xen_version (XSM_DEFAULT_ARG uint32_t op)
return xsm_default_action(XSM_PRIV, current->domain, NULL);
}
}
+
+static XSM_INLINE int xsm_version_op (XSM_DEFAULT_ARG uint32_t op)
+{
+ XSM_ASSERT_ACTION(XSM_OTHER);
+ switch ( op )
+ {
+ case XEN_VERSION_version:
+ case XEN_VERSION_platform_parameters:
+ case XEN_VERSION_get_features:
+ /* These MUST always be accessible to any guest by default. */
+ return 0;
+ case XEN_VERSION_extraversion:
+ case XEN_VERSION_capabilities:
+ case XEN_VERSION_pagesize:
+ case XEN_VERSION_guest_handle:
+ /* These can be accessible to a guest. */
+ return xsm_default_action(XSM_HOOK, current->domain, NULL);
+ default:
+ return xsm_default_action(XSM_PRIV, current->domain, NULL);
+ }
+}
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 5ecbee0..ac80472 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -194,6 +194,7 @@ struct xsm_operations {
int (*pmu_op) (struct domain *d, unsigned int op);
#endif
int (*xen_version) (uint32_t cmd);
+ int (*version_op) (uint32_t cmd);
};
#ifdef CONFIG_XSM
@@ -737,6 +738,11 @@ static inline int xsm_xen_version (xsm_default_t def, uint32_t op)
return xsm_ops->xen_version(op);
}
+static inline int xsm_version_op (xsm_default_t def, uint32_t op)
+{
+ return xsm_ops->version_op(op);
+}
+
#endif /* XSM_NO_WRAPPERS */
#ifdef CONFIG_MULTIBOOT
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 9791ad4..776dd09 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -163,4 +163,5 @@ void xsm_fixup_ops (struct xsm_operations *ops)
set_to_dummy_if_null(ops, pmu_op);
#endif
set_to_dummy_if_null(ops, xen_version);
+ set_to_dummy_if_null(ops, version_op);
}
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2069cb3..1eaec58 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1658,6 +1658,40 @@ static int flask_xen_version (uint32_t op)
}
}
+static int flask_version_op (uint32_t op)
+{
+ u32 dsid = domain_sid(current->domain);
+
+ switch ( op )
+ {
+ case XEN_VERSION_version:
+ case XEN_VERSION_platform_parameters:
+ case XEN_VERSION_get_features:
+ /* These MUST always be accessible to any guest by default. */
+ return 0;
+ case XEN_VERSION_extraversion:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__EXTRAVERSION, NULL);
+ case XEN_VERSION_capabilities:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__CAPABILITIES, NULL);
+ case XEN_VERSION_changeset:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__CHANGESET, NULL);
+ case XEN_VERSION_pagesize:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__PAGESIZE, NULL);
+ case XEN_VERSION_guest_handle:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__GUEST_HANDLE, NULL);
+ case XEN_VERSION_commandline:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__COMMANDLINE, NULL);
+ default:
+ return -EPERM;
+ }
+}
+
long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
int compat_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
@@ -1797,6 +1831,7 @@ static struct xsm_operations flask_ops = {
.pmu_op = flask_pmu_op,
#endif
.xen_version = flask_xen_version,
+ .version_op = flask_version_op,
};
static __init void flask_init(void)
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index badcf1c..56600bb 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -496,12 +496,14 @@ class security
del_ocontext
}
-# Class version is used to describe the XENVER_ hypercall.
+# Class version is used to describe the XENVER_ and VERSION hypercall.
# Almost all sub-ops are described here - in the default case all of them should
-# be allowed except the XENVER_commandline.
+# be allowed except the XENVER_commandline, VERSION_commandline, and
+# VERSION_changeset.
#
# The ones that are omitted are XENVER_version, XENVER_platform_parameters,
-# and XENVER_get_features - as they MUST always be returned to a guest.
+# XENVER_get_features, XEN_VERSION_version, XEN_VERSION_platform_parameters,
+# and XEN_VERSION_get_features - as they MUST always be returned to a guest.
#
class version
{
@@ -519,4 +521,17 @@ class version
xen_guest_handle
# Xen command line.
xen_commandline
+# --- VERSION hypercall ---
+# Extra informations (-unstable).
+ extraversion
+# Such as "xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64".
+ capabilities
+# Source code changeset.
+ changeset
+# Page size the hypervisor uses.
+ pagesize
+# An value that the control stack can choose.
+ guest_handle
+# Xen command line.
+ commandline
}
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-24 21:24 ` Wei Liu
2016-03-24 20:00 ` [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup Konrad Rzeszutek Wilk
` (25 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Stefano Stabellini, George Dunlap,
Konrad Rzeszutek Wilk, Ian Jackson, Julien Grall, David Scott
We change the xen_version libxc code to use the new hypercall.
Which of course means every user in the code base has to
be changed over.
It is important to note that the xc_version_op has a different
return semantic than the previous one. It returns negative
values on error (like the old one), but it also returns
an positive value on success (unlike the old one). The positive
value is the number of bytes copied in.
Note that both Ocaml and xenstat use tabs instead of four
spaces so they look quite odd.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Tested-by: Andrew Cooper <andrew.cooper3@citrix.com> [for the Ocaml stubs]
Acked-by: George Dunlap <george.dunlap@eu.citrix.com> [xenctx bits]
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: David Scott <dave@recoil.org>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
v4: New patch.
- Use xc_version_op_val_t instead of uint32 or such
- Make sure to check ret < 0 instead of ret (as it returns the size) -
in Ocaml code. Found by Andrew.
- Update comment for xc_version to mention the return the size
v5: Wei's review, s/VERSION_OP/VERSION/
---
tools/libxc/include/xenctrl.h | 32 +++++++++++++-
tools/libxc/xc_core.c | 35 +++++++--------
tools/libxc/xc_dom_boot.c | 12 +++++-
tools/libxc/xc_domain.c | 3 +-
tools/libxc/xc_private.c | 53 ++++-------------------
tools/libxc/xc_private.h | 7 +--
tools/libxc/xc_resume.c | 3 +-
tools/libxc/xc_sr_save.c | 9 ++--
tools/libxc/xg_save_restore.h | 6 ++-
tools/libxl/libxl.c | 79 ++++++++++++++++++++++------------
tools/ocaml/libs/xc/xenctrl_stubs.c | 39 +++++++----------
tools/python/xen/lowlevel/xc/xc.c | 30 +++++++------
tools/xenstat/libxenstat/src/xenstat.c | 12 +++---
tools/xentrace/xenctx.c | 3 +-
14 files changed, 177 insertions(+), 146 deletions(-)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 150d727..a9e4dc1 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -1477,7 +1477,37 @@ int xc_tbuf_set_evt_mask(xc_interface *xch, uint32_t mask);
int xc_domctl(xc_interface *xch, struct xen_domctl *domctl);
int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl);
-int xc_version(xc_interface *xch, int cmd, void *arg);
+/**
+ * This function returns the size of buffer to be allocated for
+ * the cmd. The cmd are XEN_VERSION_*.
+ */
+ssize_t xc_version_len(xc_interface *xch, unsigned int cmd);
+
+/**
+ * This function retrieves the information from the version_op hypercall.
+ * The len is the size of the arg buffer. If arg is NULL, will not
+ * perform hypercall - instead will just return the size of arg
+ * buffer that is needed.
+ *
+ * Note that prior to Xen 4.7 this would return 0 for success and
+ * negative value (-1) for error (with the error in errno). In Xen 4.7
+ * and later for success it will return an positive value which is the
+ * number of bytes copied in arg.
+ *
+ * It can also return -1 with various errno values:
+ * - EPERM - not permitted.
+ * - ENOBUFS - the len was to short, output in arg truncated.
+ * - ENOSYS - not implemented.
+ *
+ * @parm xch a handle to an open hypervisor interface
+ * @parm cmd XEN_VERSION_* value
+ * @param arg Pointer to xen_version_op_buf_t or xen_version_op_val_t
+ * @param len Size of arg
+ * @return size of bytes copied in arg on success, -1 on failure (and
+ * errno will contain the error)
+ *
+ */
+int xc_version(xc_interface *xch, unsigned int cmd, void *arg, size_t len);
int xc_flask_op(xc_interface *xch, xen_flask_op_t *op);
diff --git a/tools/libxc/xc_core.c b/tools/libxc/xc_core.c
index d792566..cfeba6b 100644
--- a/tools/libxc/xc_core.c
+++ b/tools/libxc/xc_core.c
@@ -270,42 +270,43 @@ elfnote_fill_xen_version(xc_interface *xch,
*xen_version)
{
int rc;
+ xen_version_op_val_t val = 0;
memset(xen_version, 0, sizeof(*xen_version));
- rc = xc_version(xch, XENVER_version, NULL);
+ rc = xc_version(xch, XEN_VERSION_version, &val, sizeof(val));
if ( rc < 0 )
return rc;
- xen_version->major_version = rc >> 16;
- xen_version->minor_version = rc & ((1 << 16) - 1);
+ xen_version->major_version = val >> 16;
+ xen_version->minor_version = val & ((1 << 16) - 1);
- rc = xc_version(xch, XENVER_extraversion,
- &xen_version->extra_version);
+ rc = xc_version(xch, XEN_VERSION_extraversion,
+ xen_version->extra_version,
+ sizeof(xen_version->extra_version));
if ( rc < 0 )
return rc;
- rc = xc_version(xch, XENVER_compile_info,
- &xen_version->compile_info);
+ rc = xc_version(xch, XEN_VERSION_capabilities,
+ xen_version->capabilities,
+ sizeof(xen_version->capabilities));
if ( rc < 0 )
return rc;
- rc = xc_version(xch,
- XENVER_capabilities, &xen_version->capabilities);
+ rc = xc_version(xch, XEN_VERSION_changeset, xen_version->changeset,
+ sizeof(xen_version->changeset));
if ( rc < 0 )
return rc;
- rc = xc_version(xch, XENVER_changeset, &xen_version->changeset);
+ rc = xc_version(xch, XEN_VERSION_platform_parameters,
+ &xen_version->platform_parameters,
+ sizeof(xen_version->platform_parameters));
if ( rc < 0 )
return rc;
- rc = xc_version(xch, XENVER_platform_parameters,
- &xen_version->platform_parameters);
+ val = 0;
+ rc = xc_version(xch, XEN_VERSION_pagesize, &val, sizeof(val));
if ( rc < 0 )
return rc;
-
- rc = xc_version(xch, XENVER_pagesize, NULL);
- if ( rc < 0 )
- return rc;
- xen_version->pagesize = rc;
+ xen_version->pagesize = val;
return 0;
}
diff --git a/tools/libxc/xc_dom_boot.c b/tools/libxc/xc_dom_boot.c
index 791041b..bbff72e 100644
--- a/tools/libxc/xc_dom_boot.c
+++ b/tools/libxc/xc_dom_boot.c
@@ -112,11 +112,19 @@ int xc_dom_compat_check(struct xc_dom_image *dom)
int xc_dom_boot_xen_init(struct xc_dom_image *dom, xc_interface *xch, domid_t domid)
{
+ xen_version_op_val_t val = 0;
+
+ if ( xc_version(xch, XEN_VERSION_version, &val, sizeof(val)) < 0 )
+ {
+ xc_dom_panic(xch, XC_INTERNAL_ERROR, "can't get Xen version!");
+ return -1;
+ }
+ dom->xen_version = val;
dom->xch = xch;
dom->guest_domid = domid;
- dom->xen_version = xc_version(xch, XENVER_version, NULL);
- if ( xc_version(xch, XENVER_capabilities, &dom->xen_caps) < 0 )
+ if ( xc_version(xch, XEN_VERSION_capabilities, dom->xen_caps,
+ sizeof(dom->xen_caps)) < 0 )
{
xc_dom_panic(xch, XC_INTERNAL_ERROR, "can't get xen capabilities");
return -1;
diff --git a/tools/libxc/xc_domain.c b/tools/libxc/xc_domain.c
index 050216e..9ebd1d6 100644
--- a/tools/libxc/xc_domain.c
+++ b/tools/libxc/xc_domain.c
@@ -2084,7 +2084,8 @@ int xc_map_domain_meminfo(xc_interface *xch, int domid,
_di.guest_width = minfo->guest_width;
/* Get page table levels (see get_platform_info() in xg_save_restore.h */
- if ( xc_version(xch, XENVER_capabilities, &xen_caps) )
+ if ( xc_version(xch, XEN_VERSION_capabilities, xen_caps,
+ sizeof(xen_caps)) < 0 )
{
PERROR("Could not get Xen capabilities (for page table levels)");
return -1;
diff --git a/tools/libxc/xc_private.c b/tools/libxc/xc_private.c
index c41e433..631ad91 100644
--- a/tools/libxc/xc_private.c
+++ b/tools/libxc/xc_private.c
@@ -457,58 +457,23 @@ int xc_sysctl(xc_interface *xch, struct xen_sysctl *sysctl)
return do_sysctl(xch, sysctl);
}
-int xc_version(xc_interface *xch, int cmd, void *arg)
+ssize_t xc_version_len(xc_interface *xch, unsigned int cmd)
{
- DECLARE_HYPERCALL_BOUNCE(arg, 0, XC_HYPERCALL_BUFFER_BOUNCE_OUT); /* Size unknown until cmd decoded */
- size_t sz;
- int rc;
-
- switch ( cmd )
- {
- case XENVER_version:
- sz = 0;
- break;
- case XENVER_extraversion:
- sz = sizeof(xen_extraversion_t);
- break;
- case XENVER_compile_info:
- sz = sizeof(xen_compile_info_t);
- break;
- case XENVER_capabilities:
- sz = sizeof(xen_capabilities_info_t);
- break;
- case XENVER_changeset:
- sz = sizeof(xen_changeset_info_t);
- break;
- case XENVER_platform_parameters:
- sz = sizeof(xen_platform_parameters_t);
- break;
- case XENVER_get_features:
- sz = sizeof(xen_feature_info_t);
- break;
- case XENVER_pagesize:
- sz = 0;
- break;
- case XENVER_guest_handle:
- sz = sizeof(xen_domain_handle_t);
- break;
- case XENVER_commandline:
- sz = sizeof(xen_commandline_t);
- break;
- default:
- ERROR("xc_version: unknown command %d\n", cmd);
- return -EINVAL;
- }
+ return do_version_op(xch, cmd, NULL, 0);
+}
- HYPERCALL_BOUNCE_SET_SIZE(arg, sz);
+int xc_version(xc_interface *xch, unsigned int cmd, void *arg, size_t sz)
+{
+ DECLARE_HYPERCALL_BOUNCE(arg, sz, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+ int rc;
- if ( (sz != 0) && xc_hypercall_bounce_pre(xch, arg) )
+ if ( xc_hypercall_bounce_pre(xch, arg) )
{
PERROR("Could not bounce buffer for version hypercall");
return -ENOMEM;
}
- rc = do_xen_version(xch, cmd, HYPERCALL_BUFFER(arg));
+ rc = do_version_op(xch, cmd, HYPERCALL_BUFFER(arg), sz);
if ( sz != 0 )
xc_hypercall_bounce_post(xch, arg);
diff --git a/tools/libxc/xc_private.h b/tools/libxc/xc_private.h
index aa8daf1..5be8fdd 100644
--- a/tools/libxc/xc_private.h
+++ b/tools/libxc/xc_private.h
@@ -214,11 +214,12 @@ void xc__hypercall_buffer_cache_release(xc_interface *xch);
* Hypercall interfaces.
*/
-static inline int do_xen_version(xc_interface *xch, int cmd, xc_hypercall_buffer_t *dest)
+static inline long do_version_op(xc_interface *xch, int cmd,
+ xc_hypercall_buffer_t *dest, ssize_t len)
{
DECLARE_HYPERCALL_BUFFER_ARGUMENT(dest);
- return xencall2(xch->xcall, __HYPERVISOR_xen_version,
- cmd, HYPERCALL_BUFFER_AS_ARG(dest));
+ return xencall3(xch->xcall, __HYPERVISOR_version_op,
+ cmd, HYPERCALL_BUFFER_AS_ARG(dest), len);
}
static inline int do_physdev_op(xc_interface *xch, int cmd, void *op, size_t len)
diff --git a/tools/libxc/xc_resume.c b/tools/libxc/xc_resume.c
index e692b81..5bf4cf0 100644
--- a/tools/libxc/xc_resume.c
+++ b/tools/libxc/xc_resume.c
@@ -56,7 +56,8 @@ static int modify_returncode(xc_interface *xch, uint32_t domid)
return 0;
/* HVM guests have host address width. */
- if ( xc_version(xch, XENVER_capabilities, &caps) != 0 )
+ if ( xc_version(xch, XEN_VERSION_capabilities, caps,
+ sizeof(caps)) < 0 )
{
PERROR("Could not get Xen capabilities");
return -1;
diff --git a/tools/libxc/xc_sr_save.c b/tools/libxc/xc_sr_save.c
index 388ae7f..7f1818c 100644
--- a/tools/libxc/xc_sr_save.c
+++ b/tools/libxc/xc_sr_save.c
@@ -9,7 +9,7 @@
static int write_headers(struct xc_sr_context *ctx, uint16_t guest_type)
{
xc_interface *xch = ctx->xch;
- int32_t xen_version = xc_version(xch, XENVER_version, NULL);
+ xen_version_op_val_t xen_version;
struct xc_sr_ihdr ihdr =
{
.marker = IHDR_MARKER,
@@ -21,15 +21,16 @@ static int write_headers(struct xc_sr_context *ctx, uint16_t guest_type)
{
.type = guest_type,
.page_shift = XC_PAGE_SHIFT,
- .xen_major = (xen_version >> 16) & 0xffff,
- .xen_minor = (xen_version) & 0xffff,
};
- if ( xen_version < 0 )
+ if ( xc_version(xch, XEN_VERSION_version, &xen_version,
+ sizeof(xen_version)) < 0 )
{
PERROR("Unable to obtain Xen Version");
return -1;
}
+ dhdr.xen_major = (xen_version >> 16) & 0xffff;
+ dhdr.xen_minor = (xen_version) & 0xffff;
if ( write_exact(ctx->fd, &ihdr, sizeof(ihdr)) )
{
diff --git a/tools/libxc/xg_save_restore.h b/tools/libxc/xg_save_restore.h
index 303081d..007875f 100644
--- a/tools/libxc/xg_save_restore.h
+++ b/tools/libxc/xg_save_restore.h
@@ -57,10 +57,12 @@ static inline int get_platform_info(xc_interface *xch, uint32_t dom,
xen_capabilities_info_t xen_caps = "";
xen_platform_parameters_t xen_params;
- if (xc_version(xch, XENVER_platform_parameters, &xen_params) != 0)
+ if (xc_version(xch, XEN_VERSION_platform_parameters, &xen_params,
+ sizeof(xen_params)) < 0)
return 0;
- if (xc_version(xch, XENVER_capabilities, &xen_caps) != 0)
+ if (xc_version(xch, XEN_VERSION_capabilities, xen_caps,
+ sizeof(xen_caps)) < 0)
return 0;
if (xc_maximum_ram_page(xch, max_mfn))
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 3471c4c..6c3ec40 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5212,50 +5212,73 @@ libxl_numainfo *libxl_get_numainfo(libxl_ctx *ctx, int *nr)
return ret;
}
+
+static int libxl__xc_version_wrapper(libxl__gc *gc, unsigned int cmd, char *buf, ssize_t len, char **dst)
+{
+ int r;
+
+ r = xc_version(CTX->xch, cmd, buf, len);
+ if ( r == -EPERM )
+ {
+ buf[0] = '\0';
+ }
+ else if ( r < 0 )
+ {
+ return r;
+ }
+ *dst = libxl__strdup(NOGC, buf);
+ return 0;
+}
+
const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
{
GC_INIT(ctx);
- union {
- xen_extraversion_t xen_extra;
- xen_compile_info_t xen_cc;
- xen_changeset_info_t xen_chgset;
- xen_capabilities_info_t xen_caps;
- xen_platform_parameters_t p_parms;
- xen_commandline_t xen_commandline;
- } u;
- long xen_version;
+ char *buf;
+ xen_version_op_val_t val = 0;
libxl_version_info *info = &ctx->version_info;
if (info->xen_version_extra != NULL)
goto out;
- xen_version = xc_version(ctx->xch, XENVER_version, NULL);
- info->xen_version_major = xen_version >> 16;
- info->xen_version_minor = xen_version & 0xFF;
+ if (xc_version(CTX->xch, XEN_VERSION_pagesize, &val, sizeof(val)) < 0)
+ goto out;
+
+ info->pagesize = val;
+ /* 4K buffer. */
+ buf = libxl__zalloc(gc, info->pagesize);
- xc_version(ctx->xch, XENVER_extraversion, &u.xen_extra);
- info->xen_version_extra = libxl__strdup(NOGC, u.xen_extra);
+ val = 0;
+ if (xc_version(CTX->xch, XEN_VERSION_version, &val, sizeof(val)) < 0)
+ goto out;
+ info->xen_version_major = val >> 16;
+ info->xen_version_minor = val & 0xFF;
- xc_version(ctx->xch, XENVER_compile_info, &u.xen_cc);
- info->compiler = libxl__strdup(NOGC, u.xen_cc.compiler);
- info->compile_by = libxl__strdup(NOGC, u.xen_cc.compile_by);
- info->compile_domain = libxl__strdup(NOGC, u.xen_cc.compile_domain);
- info->compile_date = libxl__strdup(NOGC, u.xen_cc.compile_date);
+ if (libxl__xc_version_wrapper(gc, XEN_VERSION_extraversion, buf,
+ info->pagesize, &info->xen_version_extra) < 0)
+ goto out;
- xc_version(ctx->xch, XENVER_capabilities, &u.xen_caps);
- info->capabilities = libxl__strdup(NOGC, u.xen_caps);
+ info->compiler = libxl__strdup(NOGC, "");
+ info->compile_by = libxl__strdup(NOGC, "");
+ info->compile_domain = libxl__strdup(NOGC, "");
+ info->compile_date = libxl__strdup(NOGC, "");
- xc_version(ctx->xch, XENVER_changeset, &u.xen_chgset);
- info->changeset = libxl__strdup(NOGC, u.xen_chgset);
+ if (libxl__xc_version_wrapper(gc, XEN_VERSION_capabilities, buf,
+ info->pagesize, &info->capabilities) < 0)
+ goto out;
- xc_version(ctx->xch, XENVER_platform_parameters, &u.p_parms);
- info->virt_start = u.p_parms.virt_start;
+ if (libxl__xc_version_wrapper(gc, XEN_VERSION_changeset, buf,
+ info->pagesize, &info->changeset) < 0)
+ goto out;
- info->pagesize = xc_version(ctx->xch, XENVER_pagesize, NULL);
+ val = 0;
+ if (xc_version(CTX->xch, XEN_VERSION_platform_parameters, &val,
+ sizeof(val)) < 0)
+ goto out;
- xc_version(ctx->xch, XENVER_commandline, &u.xen_commandline);
- info->commandline = libxl__strdup(NOGC, u.xen_commandline);
+ info->virt_start = val;
+ (void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
+ info->pagesize, &info->commandline);
out:
GC_FREE;
return info;
diff --git a/tools/ocaml/libs/xc/xenctrl_stubs.c b/tools/ocaml/libs/xc/xenctrl_stubs.c
index 74928e9..4ac5dce 100644
--- a/tools/ocaml/libs/xc/xenctrl_stubs.c
+++ b/tools/ocaml/libs/xc/xenctrl_stubs.c
@@ -853,21 +853,21 @@ CAMLprim value stub_xc_version_version(value xch)
CAMLparam1(xch);
CAMLlocal1(result);
xen_extraversion_t extra;
- long packed;
+ xen_version_op_val_t packed;
int retval;
caml_enter_blocking_section();
- packed = xc_version(_H(xch), XENVER_version, NULL);
+ retval = xc_version(_H(xch), XEN_VERSION_version, &packed, sizeof(packed));
caml_leave_blocking_section();
- if (packed < 0)
+ if (retval < 0)
failwith_xc(_H(xch));
caml_enter_blocking_section();
- retval = xc_version(_H(xch), XENVER_extraversion, &extra);
+ retval = xc_version(_H(xch), XEN_VERSION_extraversion, &extra, sizeof(extra));
caml_leave_blocking_section();
- if (retval)
+ if (retval < 0)
failwith_xc(_H(xch));
result = caml_alloc_tuple(3);
@@ -884,37 +884,28 @@ CAMLprim value stub_xc_version_compile_info(value xch)
{
CAMLparam1(xch);
CAMLlocal1(result);
- xen_compile_info_t ci;
- int retval;
-
- caml_enter_blocking_section();
- retval = xc_version(_H(xch), XENVER_compile_info, &ci);
- caml_leave_blocking_section();
-
- if (retval)
- failwith_xc(_H(xch));
result = caml_alloc_tuple(4);
- Store_field(result, 0, caml_copy_string(ci.compiler));
- Store_field(result, 1, caml_copy_string(ci.compile_by));
- Store_field(result, 2, caml_copy_string(ci.compile_domain));
- Store_field(result, 3, caml_copy_string(ci.compile_date));
+ Store_field(result, 0, caml_copy_string(""));
+ Store_field(result, 1, caml_copy_string(""));
+ Store_field(result, 2, caml_copy_string(""));
+ Store_field(result, 3, caml_copy_string(""));
CAMLreturn(result);
}
-static value xc_version_single_string(value xch, int code, void *info)
+static value xc_version_single_string(value xch, int code, void *info, ssize_t len)
{
CAMLparam1(xch);
int retval;
caml_enter_blocking_section();
- retval = xc_version(_H(xch), code, info);
+ retval = xc_version(_H(xch), code, info, len);
caml_leave_blocking_section();
- if (retval)
+ if (retval < 0)
failwith_xc(_H(xch));
CAMLreturn(caml_copy_string((char *)info));
@@ -925,7 +916,8 @@ CAMLprim value stub_xc_version_changeset(value xch)
{
xen_changeset_info_t ci;
- return xc_version_single_string(xch, XENVER_changeset, &ci);
+ return xc_version_single_string(xch, XEN_VERSION_changeset,
+ &ci, sizeof(ci));
}
@@ -933,7 +925,8 @@ CAMLprim value stub_xc_version_capabilities(value xch)
{
xen_capabilities_info_t ci;
- return xc_version_single_string(xch, XENVER_capabilities, &ci);
+ return xc_version_single_string(xch, XEN_VERSION_capabilities,
+ &ci, sizeof(ci));
}
diff --git a/tools/python/xen/lowlevel/xc/xc.c b/tools/python/xen/lowlevel/xc/xc.c
index c40a4e9..5854ddc 100644
--- a/tools/python/xen/lowlevel/xc/xc.c
+++ b/tools/python/xen/lowlevel/xc/xc.c
@@ -1204,34 +1204,40 @@ static PyObject *pyxc_xeninfo(XcObject *self)
xen_capabilities_info_t xen_caps;
xen_platform_parameters_t p_parms;
xen_commandline_t xen_commandline;
- long xen_version;
- long xen_pagesize;
+ xen_version_op_val_t xen_version;
+ xen_version_op_val_t xen_pagesize;
char str[128];
- xen_version = xc_version(self->xc_handle, XENVER_version, NULL);
-
- if ( xc_version(self->xc_handle, XENVER_extraversion, &xen_extra) != 0 )
+ if ( xc_version(self->xc_handle, XEN_VERSION_version, &xen_version,
+ sizeof(xen_version)) < 0 )
return pyxc_error_to_exception(self->xc_handle);
- if ( xc_version(self->xc_handle, XENVER_compile_info, &xen_cc) != 0 )
+ if ( xc_version(self->xc_handle, XEN_VERSION_extraversion, &xen_extra,
+ sizeof(xen_extra)) < 0 )
return pyxc_error_to_exception(self->xc_handle);
- if ( xc_version(self->xc_handle, XENVER_changeset, &xen_chgset) != 0 )
+ memset(&xen_cc, 0, sizeof(xen_cc));
+
+ if ( xc_version(self->xc_handle, XEN_VERSION_changeset, &xen_chgset,
+ sizeof(xen_chgset)) < 0 )
return pyxc_error_to_exception(self->xc_handle);
- if ( xc_version(self->xc_handle, XENVER_capabilities, &xen_caps) != 0 )
+ if ( xc_version(self->xc_handle, XEN_VERSION_capabilities, &xen_caps,
+ sizeof(xen_caps)) < 0 )
return pyxc_error_to_exception(self->xc_handle);
- if ( xc_version(self->xc_handle, XENVER_platform_parameters, &p_parms) != 0 )
+ if ( xc_version(self->xc_handle, XEN_VERSION_platform_parameters,
+ &p_parms, sizeof(p_parms)) < 0 )
return pyxc_error_to_exception(self->xc_handle);
- if ( xc_version(self->xc_handle, XENVER_commandline, &xen_commandline) != 0 )
+ if ( xc_version(self->xc_handle, XEN_VERSION_commandline,
+ &xen_commandline, sizeof(xen_commandline)) < 0 )
return pyxc_error_to_exception(self->xc_handle);
snprintf(str, sizeof(str), "virt_start=0x%"PRI_xen_ulong, p_parms.virt_start);
- xen_pagesize = xc_version(self->xc_handle, XENVER_pagesize, NULL);
- if (xen_pagesize < 0 )
+ if ( xc_version(self->xc_handle, XEN_VERSION_pagesize, &xen_pagesize,
+ sizeof(xen_pagesize)) < 0 )
return pyxc_error_to_exception(self->xc_handle);
return Py_BuildValue("{s:i,s:i,s:s,s:s,s:i,s:s,s:s,s:s,s:s,s:s,s:s,s:s}",
diff --git a/tools/xenstat/libxenstat/src/xenstat.c b/tools/xenstat/libxenstat/src/xenstat.c
index 3495f3f..efb68b5 100644
--- a/tools/xenstat/libxenstat/src/xenstat.c
+++ b/tools/xenstat/libxenstat/src/xenstat.c
@@ -621,20 +621,18 @@ unsigned long long xenstat_network_tdrop(xenstat_network * network)
/* Collect Xen version information */
static int xenstat_collect_xen_version(xenstat_node * node)
{
- long vnum = 0;
+ xen_version_op_val_t vnum = 0;
xen_extraversion_t version;
/* Collect Xen version information if not already collected */
if (node->handle->xen_version[0] == '\0') {
/* Get the Xen version number and extraversion string */
- vnum = xc_version(node->handle->xc_handle,
- XENVER_version, NULL);
-
- if (vnum < 0)
+ if (xc_version(node->handle->xc_handle,
+ XEN_VERSION_version, &vnum, sizeof(vnum)) < 0)
return 0;
- if (xc_version(node->handle->xc_handle, XENVER_extraversion,
- &version) < 0)
+ if (xc_version(node->handle->xc_handle, XEN_VERSION_extraversion,
+ &version, sizeof(version)) < 0)
return 0;
/* Format the version information as a string and store it */
snprintf(node->handle->xen_version, VERSION_SIZE, "%ld.%ld%s",
diff --git a/tools/xentrace/xenctx.c b/tools/xentrace/xenctx.c
index e647179..cd280fc 100644
--- a/tools/xentrace/xenctx.c
+++ b/tools/xentrace/xenctx.c
@@ -1000,7 +1000,8 @@ static void dump_ctx(int vcpu)
guest_word_size = (cpuctx.msr_efer & 0x400) ? 8 :
guest_protected_mode ? 4 : 2;
/* HVM guest context records are always host-sized */
- if (xc_version(xenctx.xc_handle, XENVER_capabilities, &xen_caps) != 0) {
+ if (xc_version(xenctx.xc_handle, XEN_VERSION_capabilities,
+ &xen_caps, sizeof(xen_caps)) < 0) {
perror("xc_version");
return;
}
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-30 16:09 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb Konrad Rzeszutek Wilk
` (24 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Julien Grall, Stefano Stabellini, Jan Beulich,
Konrad Rzeszutek Wilk
During execution of the hypervisor we have two regions of
executable code - stext -> _etext, and _sinittext -> _einitext.
The later is not needed after bootup.
We also have various built-in macros and functions to search
in between those two swaths depending on the state of the system.
That is either for bug_frames, exceptions (x86) or symbol
names for the instruction.
With xSplice in the picture - we need a mechansim for new payloads
to searched as well for all of this.
Originally we had extra 'if (xsplice)...' but that gets
a bit tiring and does not hook up nicely.
This 'struct virtual_region' and virtual_region_list provide a
mechanism to search for the bug_frames, exception table,
and symbol names entries without having various calls in
other sub-components in the system.
Code which wishes to participate in bug_frames and exception table
entries search has to only use two public APIs:
- register_virtual_region
- unregister_virtual_region
to let the core code know.
If the ->lookup_symbol is not then the default internal symbol lookup
mechanism is used.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v4: New patch.
v5:
- Rename to virtual_region.
- Ditch the 'skip' function.
- Remove the _stext.
- Use RCU lists.
- Add a search function.
- Remove extern, add rcu_read_lock. remove __ from name.
---
---
xen/arch/arm/setup.c | 4 +
xen/arch/arm/traps.c | 39 ++++++----
xen/arch/x86/extable.c | 12 ++-
xen/arch/x86/setup.c | 6 ++
xen/arch/x86/traps.c | 40 ++++++----
xen/common/Makefile | 1 +
xen/common/symbols.c | 11 ++-
xen/common/virtual_region.c | 160 +++++++++++++++++++++++++++++++++++++++
xen/include/xen/symbols.h | 9 +++
xen/include/xen/virtual_region.h | 48 ++++++++++++
10 files changed, 293 insertions(+), 37 deletions(-)
create mode 100644 xen/common/virtual_region.c
create mode 100644 xen/include/xen/virtual_region.h
diff --git a/xen/arch/arm/setup.c b/xen/arch/arm/setup.c
index 6d205a9..09ff1ea 100644
--- a/xen/arch/arm/setup.c
+++ b/xen/arch/arm/setup.c
@@ -34,6 +34,7 @@
#include <xen/keyhandler.h>
#include <xen/cpu.h>
#include <xen/pfn.h>
+#include <xen/virtual_region.h>
#include <xen/vmap.h>
#include <xen/libfdt/libfdt.h>
#include <xen/acpi.h>
@@ -860,6 +861,9 @@ void __init start_xen(unsigned long boot_phys_offset,
system_state = SYS_STATE_active;
+ /* Must be done past setting system_state. */
+ unregister_init_virtual_region();
+
domain_unpause_by_systemcontroller(dom0);
/* Switch on to the dynamically allocated stack for the idle vcpu
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 31d2115..2097f69 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -31,6 +31,7 @@
#include <xen/softirq.h>
#include <xen/domain_page.h>
#include <xen/perfc.h>
+#include <xen/virtual_region.h>
#include <public/sched.h>
#include <public/xen.h>
#include <asm/debugger.h>
@@ -101,6 +102,8 @@ integer_param("debug_stack_lines", debug_stack_lines);
void init_traps(void)
{
+ setup_virtual_regions();
+
/* Setup Hyp vector base */
WRITE_SYSREG((vaddr_t)hyp_traps_vector, VBAR_EL2);
@@ -1077,27 +1080,33 @@ void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
int do_bug_frame(struct cpu_user_regs *regs, vaddr_t pc)
{
- const struct bug_frame *bug;
+ const struct bug_frame *bug = NULL;
const char *prefix = "", *filename, *predicate;
unsigned long fixup;
- int id, lineno;
- static const struct bug_frame *const stop_frames[] = {
- __stop_bug_frames_0,
- __stop_bug_frames_1,
- __stop_bug_frames_2,
- NULL
- };
+ int id = -1, lineno;
+ struct virtual_region *region;
- for ( bug = __start_bug_frames, id = 0; stop_frames[id]; ++bug )
+ region = search_for_text(pc);
+ if ( region )
{
- while ( unlikely(bug == stop_frames[id]) )
- ++id;
+ for ( id = 0; id < BUGFRAME_NR; id++ )
+ {
+ const struct bug_frame *b;
+ unsigned int i;
- if ( ((vaddr_t)bug_loc(bug)) == pc )
- break;
+ for ( i = 0, b = region->frame[id].bugs;
+ i < region->frame[id].n_bugs; b++, i++ )
+ {
+ if ( ((vaddr_t)bug_loc(b)) == pc )
+ {
+ bug = b;
+ goto found;
+ }
+ }
+ }
}
-
- if ( !stop_frames[id] )
+ found:
+ if ( !bug )
return -ENOENT;
/* WARN, BUG or ASSERT: decode the filename pointer and line number. */
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index 89b5bcb..c6c367a 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -1,10 +1,12 @@
-#include <xen/config.h>
#include <xen/init.h>
+#include <xen/list.h>
#include <xen/perfc.h>
+#include <xen/rcupdate.h>
#include <xen/sort.h>
#include <xen/spinlock.h>
#include <asm/uaccess.h>
+#include <xen/virtual_region.h>
#define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field)
@@ -80,8 +82,12 @@ search_one_table(const struct exception_table_entry *first,
unsigned long
search_exception_table(unsigned long addr)
{
- return search_one_table(
- __start___ex_table, __stop___ex_table-1, addr);
+ struct virtual_region *region = search_for_text(addr);
+
+ if ( region && region->ex )
+ return search_one_table(region->ex, region->ex_end-1, addr);
+
+ return 0;
}
unsigned long
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index ee65f55..c8a5adb 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -26,6 +26,7 @@
#include <xen/pfn.h>
#include <xen/nodemask.h>
#include <xen/tmem_xen.h>
+#include <xen/virtual_region.h>
#include <xen/watchdog.h>
#include <public/version.h>
#include <compat/platform.h>
@@ -514,6 +515,9 @@ static void noinline init_done(void)
system_state = SYS_STATE_active;
+ /* MUST be done prior to removing .init data. */
+ unregister_init_virtual_region();
+
domain_unpause_by_systemcontroller(hardware_domain);
/* Zero the .init code and data. */
@@ -616,6 +620,8 @@ void __init noreturn __start_xen(unsigned long mbi_p)
smp_prepare_boot_cpu();
sort_exception_tables();
+ setup_virtual_regions();
+
/* Full exception support from here on in. */
loader = (mbi->flags & MBI_LOADERNAME)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 6fbb1cf..6c73198 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -48,6 +48,7 @@
#include <xen/kexec.h>
#include <xen/trace.h>
#include <xen/paging.h>
+#include <xen/virtual_region.h>
#include <xen/watchdog.h>
#include <asm/system.h>
#include <asm/io.h>
@@ -1132,18 +1133,12 @@ static int emulate_forced_invalid_op(struct cpu_user_regs *regs)
void do_invalid_op(struct cpu_user_regs *regs)
{
- const struct bug_frame *bug;
+ const struct bug_frame *bug = NULL;
u8 bug_insn[2];
const char *prefix = "", *filename, *predicate, *eip = (char *)regs->eip;
unsigned long fixup;
- int id, lineno;
- static const struct bug_frame *const stop_frames[] = {
- __stop_bug_frames_0,
- __stop_bug_frames_1,
- __stop_bug_frames_2,
- __stop_bug_frames_3,
- NULL
- };
+ int id = -1, lineno;
+ struct virtual_region *region;
DEBUGGER_trap_entry(TRAP_invalid_op, regs);
@@ -1160,16 +1155,29 @@ void do_invalid_op(struct cpu_user_regs *regs)
memcmp(bug_insn, "\xf\xb", sizeof(bug_insn)) )
goto die;
- for ( bug = __start_bug_frames, id = 0; stop_frames[id]; ++bug )
+ region = search_for_text(regs->eip);
+ if ( region )
{
- while ( unlikely(bug == stop_frames[id]) )
- ++id;
- if ( bug_loc(bug) == eip )
- break;
+ for ( id = 0; id < BUGFRAME_NR; id++ )
+ {
+ const struct bug_frame *b;
+ unsigned int i;
+
+ for ( i = 0, b = region->frame[id].bugs;
+ i < region->frame[id].n_bugs; b++, i++ )
+ {
+ if ( bug_loc(b) == eip )
+ {
+ bug = b;
+ goto found;
+ }
+ }
+ }
}
- if ( !stop_frames[id] )
- goto die;
+ found:
+ if ( !bug )
+ goto die;
eip += sizeof(bug_insn);
if ( id == BUGFRAME_run_fn )
{
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 77de27e..e43ec49 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -51,6 +51,7 @@ obj-y += time.o
obj-y += timer.o
obj-y += trace.o
obj-y += version.o
+obj-y += virtual_region.o
obj-y += vm_event.o
obj-y += vmap.o
obj-y += vsprintf.o
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index a59c59d..92fb0ee 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -17,6 +17,7 @@
#include <xen/lib.h>
#include <xen/string.h>
#include <xen/spinlock.h>
+#include <xen/virtual_region.h>
#include <public/platform.h>
#include <xen/guest_access.h>
@@ -97,8 +98,7 @@ static unsigned int get_symbol_offset(unsigned long pos)
bool_t is_active_kernel_text(unsigned long addr)
{
- return (is_kernel_text(addr) ||
- (system_state < SYS_STATE_active && is_kernel_inittext(addr)));
+ return !!search_for_text(addr);
}
const char *symbols_lookup(unsigned long addr,
@@ -108,13 +108,18 @@ const char *symbols_lookup(unsigned long addr,
{
unsigned long i, low, high, mid;
unsigned long symbol_end = 0;
+ struct virtual_region *region;
namebuf[KSYM_NAME_LEN] = 0;
namebuf[0] = 0;
- if (!is_active_kernel_text(addr))
+ region = search_for_text(addr);
+ if (!region)
return NULL;
+ if (region->symbols_lookup)
+ return region->symbols_lookup(addr, symbolsize, offset, namebuf);
+
/* do a binary search on the sorted symbols_addresses array */
low = 0;
high = symbols_num_syms;
diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
new file mode 100644
index 0000000..a560fe0
--- /dev/null
+++ b/xen/common/virtual_region.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/init.h>
+#include <xen/kernel.h>
+#include <xen/rcupdate.h>
+#include <xen/spinlock.h>
+#include <xen/virtual_region.h>
+
+#ifdef CONFIG_X86
+#include <asm/uaccess.h>
+#endif
+
+static struct virtual_region core = {
+ .list = LIST_HEAD_INIT(core.list),
+ .start = (unsigned long)_stext,
+ .end = (unsigned long)_etext,
+#ifdef CONFIG_X86
+ .ex = (struct exception_table_entry *)__start___ex_table,
+ .ex_end = (struct exception_table_entry *)__stop___ex_table,
+#endif
+};
+
+/* Becomes irrelevant when __init sections are cleared. */
+static struct virtual_region core_init __initdata = {
+ .list = LIST_HEAD_INIT(core_init.list),
+ .start = (unsigned long)_sinittext,
+ .end = (unsigned long)_einittext,
+#ifdef CONFIG_X86
+ /* Even if they are __init their exception entry still gets stuck here. */
+ .ex = (struct exception_table_entry *)__start___ex_table,
+ .ex_end = (struct exception_table_entry *)__stop___ex_table,
+#endif
+};
+
+/*
+ * RCU locking. Additions are done either at startup (when there is only
+ * one CPU) or when all CPUs are running without IRQs.
+ *
+ * Deletions are big tricky. We do it when xSplicing (all CPUs running
+ * without IRQs) or during bootup (when clearing the init).
+ *
+ * Hence we use list_del_rcu (which sports an memory fence) and a spinlock
+ * on deletion.
+ *
+ * All readers of virtual_region_list MUST use list list_for_each_entry_rcu.
+ *
+ */
+static LIST_HEAD(virtual_region_list);
+static DEFINE_SPINLOCK(virtual_region_lock);
+static DEFINE_RCU_READ_LOCK(rcu_virtual_region_lock);
+
+struct virtual_region* search_for_text(unsigned long addr)
+{
+ struct virtual_region *region;
+
+ rcu_read_lock(&rcu_virtual_region_lock);
+
+ list_for_each_entry_rcu( region, &virtual_region_list, list )
+ {
+ if ( addr >= region->start && addr < region->end )
+ {
+ rcu_read_unlock(&rcu_virtual_region_lock);
+ return region;
+ }
+ }
+
+ rcu_read_unlock(&rcu_virtual_region_lock);
+ return NULL;
+}
+
+int register_virtual_region(struct virtual_region *r)
+{
+ ASSERT(!local_irq_is_enabled());
+
+ list_add_tail_rcu(&r->list, &virtual_region_list);
+
+ return 0;
+}
+
+static void remove_virtual_region(struct virtual_region *r)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&virtual_region_lock, flags);
+ list_del_rcu(&r->list);
+ spin_unlock_irqrestore(&virtual_region_lock, flags);
+ /*
+ * We do not need to invoke call_rcu.
+ *
+ * This is due to the fact that on the deletion we have made sure
+ * to use spinlocks (to guard against somebody else calling
+ * unregister_virtual_region) and list_deletion spiced with
+ * memory barrier.
+ *
+ * That protects us from corrupting the list as the readers all
+ * use list_for_each_entry_rcu which is safe against concurrent
+ * deletions.
+ */
+}
+
+void unregister_virtual_region(struct virtual_region *r)
+{
+ /* Expected to be called from xSplice - which has IRQs disabled. */
+ ASSERT(!local_irq_is_enabled());
+
+ remove_virtual_region(r);
+}
+
+void unregister_init_virtual_region(void)
+{
+ BUG_ON(system_state != SYS_STATE_active);
+
+ remove_virtual_region(&core_init);
+}
+
+void __init setup_virtual_regions(void)
+{
+ ssize_t sz;
+ unsigned int i;
+ static const struct bug_frame *const __initconstrel bug_frames[] = {
+ __start_bug_frames,
+ __stop_bug_frames_0,
+ __stop_bug_frames_1,
+ __stop_bug_frames_2,
+#ifdef CONFIG_X86
+ __stop_bug_frames_3,
+#endif
+ NULL
+ };
+
+ for ( i = 1; bug_frames[i]; i++ )
+ {
+ const struct bug_frame *s;
+
+ s = bug_frames[i - 1];
+ sz = bug_frames[i] - s;
+
+ core.frame[i - 1].n_bugs = sz;
+ core.frame[i - 1].bugs = s;
+
+ core_init.frame[i - 1].n_bugs = sz;
+ core_init.frame[i - 1].bugs = s;
+ }
+
+ register_virtual_region(&core_init);
+ register_virtual_region(&core);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index 1fa0537..f58e611 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -5,6 +5,15 @@
#define KSYM_NAME_LEN 127
+/*
+ * Typedef for the callback functions that symbols_lookup
+ * can call if virtual_region_list has an callback for it.
+ */
+typedef const char *symbols_lookup_t(unsigned long addr,
+ unsigned long *symbolsize,
+ unsigned long *offset,
+ char *namebuf);
+
/* 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
new file mode 100644
index 0000000..b1d5eb4
--- /dev/null
+++ b/xen/include/xen/virtual_region.h
@@ -0,0 +1,48 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#ifndef __XEN_VIRTUAL_REGION_LIST__
+#define __XEN_VIRTUAL_REGION_LIST__
+
+#include <xen/list.h>
+#include <xen/symbols.h>
+
+struct virtual_region
+{
+ struct list_head list;
+ unsigned long start; /* Virtual address start. */
+ unsigned long end; /* Virtual address start. */
+
+ /*
+ * If this is NULL the default lookup mechanism is used.
+ */
+ symbols_lookup_t *symbols_lookup;
+
+ struct {
+ const struct bug_frame *bugs; /* The pointer to array of bug frames. */
+ ssize_t n_bugs; /* The number of them. */
+ } frame[BUGFRAME_NR];
+
+ struct exception_table_entry *ex;
+ struct exception_table_entry *ex_end;
+};
+
+struct virtual_region *search_for_text(unsigned long addr);
+void setup_virtual_regions(void);
+void unregister_init_virtual_region(void);
+int register_virtual_region(struct virtual_region *r);
+void unregister_virtual_region(struct virtual_region *r);
+
+#endif /* __XEN_VIRTUAL_REGION_LIST__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (2 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-30 16:24 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 05/28] xsplice: Design document Konrad Rzeszutek Wilk
` (23 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
For those users who want to supply their own vmap callback.
To be called _after_ the pages have been allocated and
the vmap API is ready to hand out virtual addresses.
Instead of using the vmap ones it can call the callback
which will be responsible for generating the virtual
address.
This allows users (such as xSplice) to provide their own
mechanism to set the page flags.
The users (such as patch titled "xsplice: Implement payload
loading") can wrap the calls to __vmap to accomplish this.
We also provide a mechanism for the calleer to squirrel
the MFN array in case they want to modify the virtual
addresses easily.
We also provide the free-ing code path - to use the vunmap_cb
to take care of tearing down the virtual addresses.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v4: New patch.
v5: Update per Jan's comments.
---
---
xen/common/vmap.c | 33 ++++++++++++++++++++++++++-------
xen/include/xen/vmap.h | 14 ++++++++++++++
2 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 134eda0..08e7859 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -216,7 +216,7 @@ void vunmap(const void *va)
vm_free(va);
}
-void *vmalloc(size_t size)
+void *vmalloc_cb(size_t size, vmap_cb_t *vmap_cb, mfn_t **mfn_array)
{
mfn_t *mfn;
size_t pages, i;
@@ -238,11 +238,15 @@ void *vmalloc(size_t size)
mfn[i] = _mfn(page_to_mfn(pg));
}
- va = vmap(mfn, pages);
+ va = vmap_cb ? vmap_cb(mfn, pages) : vmap(mfn, pages);
if ( va == NULL )
goto error;
- xfree(mfn);
+ if ( mfn_array )
+ *mfn_array = mfn;
+ else
+ xfree(mfn);
+
return va;
error:
@@ -252,6 +256,11 @@ void *vmalloc(size_t size)
return NULL;
}
+void *vmalloc(size_t size)
+{
+ return vmalloc_cb(size, NULL, NULL);
+}
+
void *vzalloc(size_t size)
{
void *p = vmalloc(size);
@@ -266,16 +275,15 @@ void *vzalloc(size_t size)
return p;
}
-void vfree(void *va)
+void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc)
{
- unsigned int i, pages;
+ unsigned int i;
struct page_info *pg;
PAGE_LIST_HEAD(pg_list);
if ( !va )
return;
- pages = vm_size(va);
ASSERT(pages);
for ( i = 0; i < pages; i++ )
@@ -285,9 +293,20 @@ void vfree(void *va)
ASSERT(page);
page_list_add(page, &pg_list);
}
- vunmap(va);
+ if ( !vfree_cb_fnc )
+ vunmap(va);
+ else
+ vfree_cb_fnc(va, pages);
while ( (pg = page_list_remove_head(&pg_list)) != NULL )
free_domheap_page(pg);
}
+
+void vfree(void *va)
+{
+ if ( !va )
+ return;
+
+ vfree_cb(va, vm_size(va), NULL);
+}
#endif
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 5671ac8..02cadb3 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -12,9 +12,23 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
void *vmap(const mfn_t *mfn, unsigned int nr);
void vunmap(const void *);
void *vmalloc(size_t size);
+
+/*
+ * Callback for vmalloc_cb to use when vmap-ing.
+ */
+typedef void *(vmap_cb_t)(const mfn_t *mfn, unsigned int pages);
+void *vmalloc_cb(size_t size, vmap_cb_t *vmap_cb, mfn_t **);
+
void *vzalloc(size_t size);
void vfree(void *va);
+/*
+ * Callback for vfree to use an equivalent of vmap_cb_t
+ * when tearing down.
+ */
+typedef void (vfree_cb_t)(void *va, unsigned int pages);
+void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc);
+
void __iomem *ioremap(paddr_t, size_t);
static inline void iounmap(void __iomem *va)
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 05/28] xsplice: Design document
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (3 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-29 9:36 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 06/28] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
` (22 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
A mechanism is required to binarily patch the running hypervisor with new
opcodes that have come about due to primarily security updates.
This document describes the design of the API that would allow us to
upload to the hypervisor binary patches.
This document has been shaped by the input from:
Martin Pohlack <mpohlack@amazon.de>
Jan Beulich <jbeulich@suse.com>
Thank you!
Input-from: Martin Pohlack <mpohlack@amazon.de>
Input-from: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v1-2: review
v3: Split document in v1 and v2 (todo) to simplify implementation goals.
- Add const on some structures. Truncate size to uint16_t where it makes sense.
- Convert 'id' to 'name', Add Ross's comments about what is implemented.
- Wei's and Ross's reviews.
- Jan's review comments.
- Jan's review comments.
s/int32_t state/uint32_t state/ now that return code is in seperate
field (rc). Add various other types, such as R_X86_64_PC64 in the list.
Mention the need for compiler check.
v4:
- Drop the LOADED->CHECKED state and go directly to CHECKED state. Drop
LOADED.
v5: Julien mentioned ARM 32-bit would not use ELF64, so make the .xsplice.func
use uintXX_t types instead of ELF ones. Remove the OUT on idx subfield.
Mention that 'nr' being zero can be used for probing the number of payloads.
Update what 'idx' means.
---
docs/misc/xsplice.markdown | 1039 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 1039 insertions(+)
create mode 100644 docs/misc/xsplice.markdown
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
new file mode 100644
index 0000000..a5303f0
--- /dev/null
+++ b/docs/misc/xsplice.markdown
@@ -0,0 +1,1039 @@
+# xSplice Design v1
+
+## Rationale
+
+A mechanism is required to binarily patch the running hypervisor with new
+opcodes that have come about due to primarily security updates.
+
+This document describes the design of the API that would allow us to
+upload to the hypervisor binary patches.
+
+The document is split in four sections:
+
+ * Detailed descriptions of the problem statement.
+ * Design of the data structures.
+ * Design of the hypercalls.
+ * Implementation notes that should be taken into consideration.
+
+
+## Glossary
+
+ * splice - patch in the binary code with new opcodes
+ * trampoline - a jump to a new instruction.
+ * payload - telemetries of the old code along with binary blob of the new
+ function (if needed).
+ * reloc - telemetries contained in the payload to construct proper trampoline.
+
+## History
+
+The document has gone under various reviews and only covers v1 design.
+
+The end of the document has a section titled `Not Yet Done` which
+outlines ideas and design for the future version of this work.
+
+## Multiple ways to patch
+
+The mechanism needs to be flexible to patch the hypervisor in multiple ways
+and be as simple as possible. The compiled code is contiguous in memory with
+no gaps - so we have no luxury of 'moving' existing code and must either
+insert a trampoline to the new code to be executed - or only modify in-place
+the code if there is sufficient space. The placement of new code has to be done
+by hypervisor and the virtual address for the new code is allocated dynamically.
+
+This implies that the hypervisor must compute the new offsets when splicing
+in the new trampoline code. Where the trampoline is added (inside
+the function we are patching or just the callers?) is also important.
+
+To lessen the amount of code in hypervisor, the consumer of the API
+is responsible for identifying which mechanism to employ and how many locations
+to patch. Combinations of modifying in-place code, adding trampoline, etc
+has to be supported. The API should allow read/write any memory within
+the hypervisor virtual address space.
+
+We must also have a mechanism to query what has been applied and a mechanism
+to revert it if needed.
+
+## Workflow
+
+The expected workflows of higher-level tools that manage multiple patches
+on production machines would be:
+
+ * The first obvious task is loading all available / suggested
+ hotpatches when they are available.
+ * Whenever new hotpatches are installed, they should be loaded too.
+ * One wants to query which modules have been loaded at runtime.
+ * If unloading is deemed safe (see unloading below), one may want to
+ support a workflow where a specific hotpatch is marked as bad and
+ unloaded.
+
+## Patching code
+
+The first mechanism to patch that comes in mind is in-place replacement.
+That is replace the affected code with new code. Unfortunately the x86
+ISA is variable size which places limits on how much space we have available
+to replace the instructions. That is not a problem if the change is smaller
+than the original opcode and we can fill it with nops. Problems will
+appear if the replacement code is longer.
+
+The second mechanism is by ti replace the call or jump to the
+old function with the address of the new function.
+
+A third mechanism is to add a jump to the new function at the
+start of the old function. N.B. The Xen hypervisor implements the third
+mechanism. See `Trampoline (e9 opcode)` section for more details.
+
+### Example of trampoline and in-place splicing
+
+As example we will assume the hypervisor does not have XSA-132 (see
+*domctl/sysctl: don't leak hypervisor stack to toolstacks*
+4ff3449f0e9d175ceb9551d3f2aecb59273f639d) and we would like to binary patch
+the hypervisor with it. The original code looks as so:
+
+<pre>
+ 48 89 e0 mov %rsp,%rax
+ 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
+</pre>
+
+while the new patched hypervisor would be:
+
+<pre>
+ 48 c7 45 b8 00 00 00 00 movq $0x0,-0x48(%rbp)
+ 48 c7 45 c0 00 00 00 00 movq $0x0,-0x40(%rbp)
+ 48 c7 45 c8 00 00 00 00 movq $0x0,-0x38(%rbp)
+ 48 89 e0 mov %rsp,%rax
+ 48 25 00 80 ff ff and $0xffffffffffff8000,%rax
+</pre>
+
+This is inside the arch_do_domctl. This new change adds 21 extra
+bytes of code which alters all the offsets inside the function. To alter
+these offsets and add the extra 21 bytes of code we might not have enough
+space in .text to squeeze this in.
+
+As such we could simplify this problem by only patching the site
+which calls arch_do_domctl:
+
+<pre>
+do_domctl:
+ e8 4b b1 05 00 callq ffff82d08015fbb9 <arch_do_domctl>
+</pre>
+
+with a new address for where the new `arch_do_domctl` would be (this
+area would be allocated dynamically).
+
+Astute readers will wonder what we need to do if we were to patch `do_domctl`
+- which is not called directly by hypervisor but on behalf of the guests via
+the `compat_hypercall_table` and `hypercall_table`.
+Patching the offset in `hypercall_table` for `do_domctl:
+(ffff82d080103079 <do_domctl>:)
+
+<pre>
+
+ ffff82d08024d490: 79 30
+ ffff82d08024d492: 10 80 d0 82 ff ff
+
+</pre>
+
+with the new address where the new `do_domctl` is possible. The other
+place where it is used is in `hvm_hypercall64_table` which would need
+to be patched in a similar way. This would require an in-place splicing
+of the new virtual address of `arch_do_domctl`.
+
+In summary this example patched the callee of the affected function by
+ * allocating memory for the new code to live in,
+ * changing the virtual address in all the functions which called the old
+ code (computing the new offset, patching the callq with a new callq).
+ * changing the function pointer tables with the new virtual address of
+ the function (splicing in the new virtual address). Since this table
+ resides in the .rodata section we would need to temporarily change the
+ page table permissions during this part.
+
+However it has drawbacks - the safety checks which have to make sure
+the function is not on the stack - must also check every caller. For some
+patches this could mean - if there were an sufficient large amount of
+callers - that we would never be able to apply the update.
+
+Having the patching done at predetermined instances where the stacks
+are not deep mostly solves this problem.
+
+### Example of different trampoline patching.
+
+An alternative mechanism exists where we can insert a trampoline in the
+existing function to be patched to jump directly to the new code. This
+lessens the locations to be patched to one but it puts pressure on the
+CPU branching logic (I-cache, but it is just one unconditional jump).
+
+For this example we will assume that the hypervisor has not been compiled
+with fe2e079f642effb3d24a6e1a7096ef26e691d93e (XSA-125: *pre-fill structures
+for certain HYPERVISOR_xen_version sub-ops*) which mem-sets an structure
+in `xen_version` hypercall. This function is not called **anywhere** in
+the hypervisor (it is called by the guest) but referenced in the
+`compat_hypercall_table` and `hypercall_table` (and indirectly called
+from that). Patching the offset in `hypercall_table` for the old
+`do_xen_version` (ffff82d080112f9e <do_xen_version>)
+
+</pre>
+ ffff82d08024b270 <hypercall_table>:
+ ...
+ ffff82d08024b2f8: 9e 2f 11 80 d0 82 ff ff
+
+</pre>
+
+with the new address where the new `do_xen_version` is possible. The other
+place where it is used is in `hvm_hypercall64_table` which would need
+to be patched in a similar way. This would require an in-place splicing
+of the new virtual address of `do_xen_version`.
+
+An alternative solution would be to patch insert a trampoline in the
+old `do_xen_version' function to directly jump to the new `do_xen_version`.
+
+<pre>
+ ffff82d080112f9e do_xen_version:
+ ffff82d080112f9e: 48 c7 c0 da ff ff ff mov $0xffffffffffffffda,%rax
+ ffff82d080112fa5: 83 ff 09 cmp $0x9,%edi
+ ffff82d080112fa8: 0f 87 24 05 00 00 ja ffff82d0801134d2 ; do_xen_version+0x534
+</pre>
+
+with:
+
+<pre>
+ ffff82d080112f9e do_xen_version:
+ ffff82d080112f9e: e9 XX YY ZZ QQ jmpq [new do_xen_version]
+</pre>
+
+which would lessen the amount of patching to just one location.
+
+In summary this example patched the affected function to jump to the
+new replacement function which required:
+ * allocating memory for the new code to live in,
+ * inserting trampoline with new offset in the old function to point to the
+ new function.
+ * Optionally we can insert in the old function a trampoline jump to an function
+ providing an BUG_ON to catch errant code.
+
+The disadvantage of this are that the unconditional jump will consume a small
+I-cache penalty. However the simplicity of the patching and higher chance
+of passing safety checks make this a worthwhile option.
+
+This patching has a similar drawback as inline patching - the safety
+checks have to make sure the function is not on the stack. However
+since we are replacing at a higher level (a full function as opposed
+to various offsets within functions) the checks are simpler.
+
+Having the patching done at predetermined instances where the stacks
+are not deep mostly solves this problem as well.
+
+### Security
+
+With this method we can re-write the hypervisor - and as such we **MUST** be
+diligent in only allowing certain guests to perform this operation.
+
+Furthermore with SecureBoot or tboot, we **MUST** also verify the signature
+of the payload to be certain it came from a trusted source and integrity
+was intact.
+
+As such the hypercall **MUST** support an XSM policy to limit what the guest
+is allowed to invoke. If the system is booted with signature checking the
+signature checking will be enforced.
+
+## Design of payload format
+
+The payload **MUST** contain enough data to allow us to apply the update
+and also safely reverse it. As such we **MUST** know:
+
+ * The locations in memory to be patched. This can be determined dynamically
+ via symbols or via virtual addresses.
+ * The new code that will be patched in.
+
+This binary format can be constructed using an custom binary format but
+there are severe disadvantages of it:
+
+ * The format might need to be changed and we need an mechanism to accommodate
+ that.
+ * It has to be platform agnostic.
+ * Easily constructed using existing tools.
+
+As such having the payload in an ELF file is the sensible way. We would be
+carrying the various sets of structures (and data) in the ELF sections under
+different names and with definitions.
+
+Note that every structure has padding. This is added so that the hypervisor
+can re-use those fields as it sees fit.
+
+Earlier design attempted to ineptly explain the relations of the ELF sections
+to each other without using proper ELF mechanism (sh_info, sh_link, data
+structures using Elf types, etc). This design will explain the structures
+and how they are used together and not dig in the ELF format - except mention
+that the section names should match the structure names.
+
+The xSplice payload is a relocatable ELF binary. A typical binary would have:
+
+ * One or more .text sections.
+ * Zero or more read-only data sections.
+ * Zero or more data sections.
+ * Relocations for each of these sections.
+
+It may also have some architecture-specific sections. For example:
+
+ * Alternatives instructions.
+ * Bug frames.
+ * Exception tables.
+ * Relocations for each of these sections.
+
+The xSplice core code loads the payload as a standard ELF binary, relocates it
+and handles the architecture-specifc sections as needed. This process is much
+like what the Linux kernel module loader does.
+
+The payload contains a section (xsplice_patch_func) with an array of structures
+describing the functions to be patched:
+
+<pre>
+struct xsplice_patch_func {
+ const char *name;
+ uint64_t new_addr;
+ uint64_t old_addr;
+ uint32_t new_size;
+ uint32_t old_size;
+ uint8_t pad[32];
+};
+</pre>
+
+The size of the structure is 64 bytes.
+
+* `name` is the symbol name of the old function. Only used if `old_addr` is
+ zero, otherwise will be used during dynamic linking (when hypervisor loads
+ the payload).
+
+* `old_addr` is the address of the function to be patched and is filled in at
+ payload generation time if hypervisor function address is known. If unknown,
+ the value *MUST* be zero and the hypervisor will attempt to resolve the address.
+
+* `new_addr` is the address of the function that is replacing the old
+ function. The address is filled in during relocation. The value **MUST** be
+ the address of the new function in the file.
+
+* `old_size` and `new_size` contain the sizes of the respective functions in bytes.
+ The value of `old_size` **MUST** not be zero.
+
+* `pad` **MUST** be zero.
+
+The size of the `xsplice_patch_func` array is determined from the ELF section
+size.
+
+When applying the patch the hypervisor iterates over each `xsplice_patch_func`
+structure and the core code inserts a trampoline at `old_addr` to `new_addr`.
+
+When reverting a patch, the hypervisor iterates over each `xsplice_patch_func`
+and the core code copies the data from the undo buffer (private internal copy)
+to `old_addr`.
+
+## Hypercalls
+
+We will employ the sub operations of the system management hypercall (sysctl).
+There are to be four sub-operations:
+
+ * upload the payloads.
+ * listing of payloads summary uploaded and their state.
+ * getting an particular payload summary and its state.
+ * command to apply, delete, or revert the payload.
+
+Most of the actions are asynchronous therefore the caller is responsible
+to verify that it has been applied properly by retrieving the summary of it
+and verifying that there are no error codes associated with the payload.
+
+We **MUST** make some of them asynchronous due to the nature of patching
+it requires every physical CPU to be lock-step with each other.
+The patching mechanism while an implementation detail, is not an short
+operation and as such the design **MUST** assume it will be an long-running
+operation.
+
+The sub-operations will spell out how preemption is to be handled (if at all).
+
+Furthermore it is possible to have multiple different payloads for the same
+function. As such an unique name per payload has to be visible to allow proper manipulation.
+
+The hypercall is part of the `xen_sysctl`. The top level structure contains
+one uint32_t to determine the sub-operations and one padding field which
+*MUST* always be zero.
+
+<pre>
+struct xen_sysctl_xsplice_op {
+ uint32_t cmd; /* IN: XEN_SYSCTL_XSPLICE_*. */
+ uint32_t pad; /* IN: Always zero. */
+ union {
+ ... see below ...
+ } u;
+};
+
+</pre>
+while the rest of hypercall specific structures are part of the this structure.
+
+### Basic type: struct xen_xsplice_name
+
+Most of the hypercalls employ an shared structure called `struct xen_xsplice_name`
+which contains:
+
+ * `name` - pointer where the string for the name is located.
+ * `size` - the size of the string
+ * `pad` - padding - to be zero.
+
+The structure is as follow:
+
+<pre>
+/*
+ * Uniquely identifies the payload. Should be human readable.
+ * Includes the NUL terminator
+ */
+#define XEN_XSPLICE_NAME_SIZE 128
+struct xen_xsplice_name {
+ XEN_GUEST_HANDLE_64(char) name; /* IN, pointer to name. */
+ uint16_t size; /* IN, size of name. May be upto
+ XEN_XSPLICE_NAME_SIZE. */
+ uint16_t pad[3]; /* IN: MUST be zero. */
+};
+</pre>
+
+### XEN_SYSCTL_XSPLICE_UPLOAD (0)
+
+Upload a payload to the hypervisor. The payload is verified
+against basic checks and if there are any issues the proper return code
+will be returned. The payload is not applied at this time - that is
+controlled by *XEN_SYSCTL_XSPLICE_ACTION*.
+
+The caller provides:
+
+ * A `struct xen_xsplice_name` called `name` which has the unique name.
+ * `size` the size of the ELF payload (in bytes).
+ * `payload` the virtual address of where the ELF payload is.
+
+The `name` could be an UUID that stays fixed forever for a given
+payload. It can be embedded into the ELF payload at creation time
+and extracted by tools.
+
+The return value is zero if the payload was succesfully uploaded.
+Otherwise an -XEN_EXX return value is provided. Duplicate `name` are not supported.
+
+The `payload` is the ELF payload as mentioned in the `Payload format` section.
+
+The structure is as follow:
+
+<pre>
+struct xen_sysctl_xsplice_upload {
+ xen_xsplice_name_t name; /* IN, name of the patch. */
+ uint64_t size; /* IN, size of the ELF file. */
+ XEN_GUEST_HANDLE_64(uint8) payload; /* IN: ELF file. */
+};
+</pre>
+
+### XEN_SYSCTL_XSPLICE_GET (1)
+
+Retrieve an status of an specific payload. This caller provides:
+
+ * A `struct xen_xsplice_name` called `name` which has the unique name.
+ * A `struct xen_xsplice_status` structure. The member values will
+ be over-written upon completion.
+
+Upon completion the `struct xen_xsplice_status` is updated.
+
+ * `status` - indicates the current status of the payload:
+ * *XSPLICE_STATUS_CHECKED* (1) loaded and the ELF payload safety checks passed.
+ * *XSPLICE_STATUS_APPLIED* (2) loaded, checked, and applied.
+ * No other value is possible.
+ * `rc` - -XEN_EXX type errors encountered while performing the last
+ XSPLICE_ACTION_* operation. The normal values can be zero or -XEN_EAGAIN which
+ respectively mean: success or operation in progress. Other values
+ imply an error occurred. If there is an error in `rc`, `status` will **NOT**
+ have changed.
+
+The return value of the hypercall is zero on success and -XEN_EXX on failure.
+(Note that the `rc`` value can be different from the return value, as in
+rc=-XEN_EAGAIN and return value can be 0).
+
+For example, supposing there is an payload:
+
+<pre>
+ status: XSPLICE_STATUS_CHECKED
+ rc: 0
+</pre>
+
+We apply an action - XSPLICE_ACTION_REVERT - to revert it (which won't work
+as we have not even applied it. Afterwards we will have:
+
+<pre>
+ status: XSPLICE_STATUS_CHECKED
+ rc: -XEN_EINVAL
+</pre>
+
+It has failed but it remains loaded.
+
+This operation is synchronous and does not require preemption.
+
+The structure is as follow:
+
+<pre>
+struct xen_xsplice_status {
+#define XSPLICE_STATUS_CHECKED 1
+#define XSPLICE_STATUS_APPLIED 2
+ uint32_t state; /* OUT: XSPLICE_STATE_*. */
+ int32_t rc; /* OUT: 0 if no error, otherwise -XEN_EXX. */
+};
+
+struct xen_sysctl_xsplice_get {
+ xen_xsplice_name_t name; /* IN, the name of the payload. */
+ xen_xsplice_status_t status; /* IN/OUT: status of the payload. */
+};
+</pre>
+
+### XEN_SYSCTL_XSPLICE_LIST (2)
+
+Retrieve an array of abbreviated status and names of payloads that are loaded in the
+hypervisor.
+
+The caller provides:
+
+ * `version`. Version of the payload. Caller should re-use the field provided by
+ the hypervisor. If the value differs the data is stale.
+ * `idx` index iterator. The index into the hypervisor's payload count. It is
+ recommended that on first invocation zero be used so that `nr` (which the
+ hypervisor will update with the remaining payload count) be provided.
+ Also the hypervisor will provide `version` with the most current value.
+ * `nr` the max number of entries to populate. Can be zero which will result
+ in the hypercall being a probing one and return the number of payloads
+ (and update the `version`).
+ * `pad` - *MUST* be zero.
+ * `status` virtual address of where to write `struct xen_xsplice_status`
+ structures. Caller *MUST* allocate up to `nr` of them.
+ * `name` - virtual address of where to write the unique name of the payload.
+ Caller *MUST* allocate up to `nr` of them. Each *MUST* be of
+ **XEN_XSPLICE_NAME_SIZE** size. Note that **XEN_XSPLICE_NAME_SIZE** includes
+ the NUL terminator.
+ * `len` - virtual address of where to write the length of each unique name
+ of the payload. Caller *MUST* allocate up to `nr` of them. Each *MUST* be
+ of sizeof(uint32_t) (4 bytes).
+
+If the hypercall returns an positive number, it is the number (upto `nr`
+provided to the hypercall) of the payloads returned, along with `nr` updated
+with the number of remaining payloads, `version` updated (it may be the same
+across hypercalls - if it varies the data is stale and further calls could
+fail). The `status`, `name`, and `len`' are updated at their designed index
+value (`idx`) with the returned value of data.
+
+If the hypercall returns -XEN_E2BIG the `nr` is too big and should be
+lowered.
+
+If the hypercall returns an zero value there are no more payloads.
+
+Note that due to the asynchronous nature of hypercalls the control domain might
+have added or removed a number of payloads making this information stale. It is
+the responsibility of the toolstack to use the `version` field to check
+between each invocation. if the version differs it should discard the stale
+data and start from scratch. It is OK for the toolstack to use the new
+`version` field.
+
+The `struct xen_xsplice_status` structure contains an status of payload which includes:
+
+ * `status` - indicates the current status of the payload:
+ * *XSPLICE_STATUS_CHECKED* (1) loaded and the ELF payload safety checks passed.
+ * *XSPLICE_STATUS_APPLIED* (2) loaded, checked, and applied.
+ * No other value is possible.
+ * `rc` - -XEN_EXX type errors encountered while performing the last
+ XSPLICE_ACTION_* operation. The normal values can be zero or -XEN_EAGAIN which
+ respectively mean: success or operation in progress. Other values
+ imply an error occurred. If there is an error in `rc`, `status` will **NOT**
+ have changed.
+
+The structure is as follow:
+
+<pre>
+struct xen_sysctl_xsplice_list {
+ uint32_t version; /* OUT: Hypervisor stamps value.
+ If varies between calls, we are
+ getting stale data. */
+ uint32_t idx; /* IN: Index into hypervisor array.
+ Should be between [0, nr). */
+ uint32_t nr; /* IN: How many status, names, and len
+ should be filled out. Can be zero to get
+ amount of payloads and version.
+ OUT: How many payloads left. */
+ uint32_t pad; /* IN: Must be zero. */
+ XEN_GUEST_HANDLE_64(xen_xsplice_status_t) status; /* OUT. Must have enough
+ space allocate for nr of them. */
+ XEN_GUEST_HANDLE_64(char) id; /* OUT: Array of names. Each member
+ MUST XEN_XSPLICE_NAME_SIZE in size.
+ Must have nr of them. */
+ XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of name's.
+ Must have nr of them. */
+};
+</pre>
+
+### XEN_SYSCTL_XSPLICE_ACTION (3)
+
+Perform an operation on the payload structure referenced by the `name` field.
+The operation request is asynchronous and the status should be retrieved
+by using either **XEN_SYSCTL_XSPLICE_GET** or **XEN_SYSCTL_XSPLICE_LIST** hypercall.
+
+The caller provides:
+
+ * A 'struct xen_xsplice_name` `name` containing the unique name.
+ * `cmd` the command requested:
+ * *XSPLICE_ACTION_CHECK* (1) check that the payload will apply properly.
+ This also verfies the payload - which may require SecureBoot firmware
+ calls. This is the initial state an payload is in.
+ * *XSPLICE_ACTION_UNLOAD* (2) unload the payload.
+ Any further hypercalls against the `name` will result in failure unless
+ **XEN_SYSCTL_XSPLICE_UPLOAD** hypercall is perfomed with same `name`.
+ * *XSPLICE_ACTION_REVERT* (3) revert the payload. If the operation takes
+ more time than the upper bound of time the `rc` in `xen_xsplice_status'
+ retrieved via **XEN_SYSCTL_XSPLICE_GET** will be -XEN_EBUSY.
+ * *XSPLICE_ACTION_APPLY* (4) apply the payload. If the operation takes
+ more time than the upper bound of time the `rc` in `xen_xsplice_status'
+ retrieved via **XEN_SYSCTL_XSPLICE_GET** will be -XEN_EBUSY.
+ * *XSPLICE_ACTION_REPLACE* (5) revert all applied payloads and apply this
+ payload. If the operation takes more time than the upper bound of time
+ the `rc` in `xen_xsplice_status' retrieved via **XEN_SYSCTL_XSPLICE_GET**
+ will be -XEN_EBUSY.
+ * `time` the upper bound of time (ms) the cmd should take. Zero means infinite.
+ If within the time the operation does not succeed the operation would go in
+ error state.
+ * `pad` - *MUST* be zero.
+
+The return value will be zero unless the provided fields are incorrect.
+
+The structure is as follow:
+
+<pre>
+#define XSPLICE_ACTION_CHECK 1
+#define XSPLICE_ACTION_UNLOAD 2
+#define XSPLICE_ACTION_REVERT 3
+#define XSPLICE_ACTION_APPLY 4
+#define XSPLICE_ACTION_REPLACE 5
+struct xen_sysctl_xsplice_action {
+ xen_xsplice_name_t name; /* IN, name of the patch. */
+ uint32_t cmd; /* IN: XSPLICE_ACTION_* */
+ uint32_t time; /* IN: Zero if no timeout. */
+ /* Or upper bound of time (ms) */
+ /* for operation to take. */
+};
+
+</pre>
+
+## State diagrams of XSPLICE_ACTION commands.
+
+There is a strict ordering state of what the commands can be.
+The XSPLICE_ACTION prefix has been dropped to easy reading and
+does not include the XSPLICE_STATES:
+
+<pre>
+ /->\
+ \ /
+ UNLOAD <--- CHECK ---> REPLACE|APPLY --> REVERT --\
+ \ |
+ \-------------------<-------------/
+
+</pre>
+## State transition table of XSPLICE_ACTION commands and XSPLICE_STATUS.
+
+Note that:
+
+ - The CHECKED state is the starting one achieved with *XEN_SYSCTL_XSPLICE_UPLOAD* hypercall.
+ - The REVERT operation on success will automatically move to the CHECKED state.
+ - There are two STATES: CHECKED and APPLIED.
+ - There are five actions (aka commands): CHECK, APPLY, REPLACE, REVERT, and UNLOAD.
+
+The state transition table of valid states and action states:
+
+<pre>
+
++---------+---------+--------------------------------+-------+--------+
+| ACTION | Current | Result | Next STATE: |
+| ACTION | STATE | |CHECKED|APPLIED |
++---------+----------+-------------------------------+-------+--------+
+| CHECK | CHECKED | Check payload (once more, no) | x | |
+| | | errors) | | |
++---------+---------+--------------------------------+-------+--------+
+| CHECK | CHECKED | Check payload (once more, with | | |
+| | | errors) | | |
++---------+---------+--------------------------------+-------+--------+
+| UNLOAD | CHECKED | Unload payload. Always works. | | |
+| | | No next states. | | |
++---------+---------+--------------------------------+-------+--------+
+| APPLY | CHECKED | Apply payload (success). | | x |
++---------+---------+--------------------------------+-------+--------+
+| APPLY | CHECKED | Apply payload (error|timeout) | x | |
++---------+---------+--------------------------------+-------+--------+
+| REPLACE | CHECKED | Revert payloads and apply new | | x |
+| | | payload with success. | | |
++---------+---------+--------------------------------+-------+--------+
+| REPLACE | CHECKED | Revert payloads and apply new | x | |
+| | | payload with error. | | |
++---------+---------+--------------------------------+-------+--------+
+| REVERT | APPLIED | Revert payload (success). | x | |
++---------+---------+--------------------------------+-------+--------+
+| REVERT | APPLIED | Revert payload (error|timeout) | | x |
++---------+---------+--------------------------------+-------+--------+
+</pre>
+
+All the other state transitions are invalid.
+
+## Sequence of events.
+
+The normal sequence of events is to:
+
+ 1. *XEN_SYSCTL_XSPLICE_UPLOAD* to upload the payload. If there are errors *STOP* here.
+ 2. *XEN_SYSCTL_XSPLICE_GET* to check the `->rc`. If *-XEN_EAGAIN* spin. If zero go to next step.
+ 3. *XEN_SYSCTL_XSPLICE_ACTION* with *XSPLICE_ACTION_APPLY* to apply the patch.
+ 4. *XEN_SYSCTL_XSPLICE_GET* to check the `->rc`. If in *-XEN_EAGAIN* spin. If zero exit with success.
+
+
+## Addendum
+
+Implementation quirks should not be discussed in a design document.
+
+However these observations can provide aid when developing against this
+document.
+
+
+### Alternative assembler
+
+Alternative assembler is a mechanism to use different instructions depending
+on what the CPU supports. This is done by providing multiple streams of code
+that can be patched in - or if the CPU does not support it - padded with
+`nop` operations. The alternative assembler macros cause the compiler to
+expand the code to place a most generic code in place - emit a special
+ELF .section header to tag this location. During run-time the hypervisor
+can leave the areas alone or patch them with an better suited opcodes.
+
+Note that patching functions that copy to or from guest memory requires
+to support alternative support. For example this can be due to SMAP
+(specifically *stac* and *clac* operations) which is enabled on Broadwell
+and later architectures. It may be related to other alternative instructions.
+
+### When to patch
+
+During the discussion on the design two candidates bubbled where
+the call stack for each CPU would be deterministic. This would
+minimize the chance of the patch not being applied due to safety
+checks failing. Safety checks such as not patching code which
+is on the stack - which can lead to corruption.
+
+#### Rendezvous code instead of stop_machine for patching
+
+The hypervisor's time rendezvous code runs synchronously across all CPUs
+every second. Using the stop_machine to patch can stall the time rendezvous
+code and result in NMI. As such having the patching be done at the tail
+of rendezvous code should avoid this problem.
+
+However the entrance point for that code is
+do_softirq->timer_softirq_action->time_calibration
+which ends up calling on_selected_cpus on remote CPUs.
+
+The remote CPUs receive CALL_FUNCTION_VECTOR IPI and execute the
+desired function.
+
+#### Before entering the guest code.
+
+Before we call VMXResume we check whether any soft IRQs need to be executed.
+This is a good spot because all Xen stacks are effectively empty at
+that point.
+
+To randezvous all the CPUs an barrier with an maximum timeout (which
+could be adjusted), combined with forcing all other CPUs through the
+hypervisor with IPIs, can be utilized to execute lockstep instructions
+on all CPUs.
+
+The approach is similar in concept to stop_machine and the time rendezvous
+but is time-bound. However the local CPU stack is much shorter and
+a lot more deterministic.
+
+This is implemented in the Xen Project hypervisor.
+
+### Compiling the hypervisor code
+
+Hotpatch generation often requires support for compiling the target
+with -ffunction-sections / -fdata-sections. Changes would have to
+be done to the linker scripts to support this.
+
+### Generation of xSplice ELF payloads
+
+The design of that is not discussed in this design.
+
+This is implemented in a seperate tool which lives in a seperate
+GIT repo.
+
+Currently it resides at https://github.com/rosslagerwall/xsplice-build
+
+### Exception tables and symbol tables growth
+
+We may need support for adapting or augmenting exception tables if
+patching such code. Hotpatches may need to bring their own small
+exception tables (similar to how Linux modules support this).
+
+If supporting hotpatches that introduce additional exception-locations
+is not important, one could also change the exception table in-place
+and reorder it afterwards.
+
+As found almost every patch (XSA) to a non-trivial function requires
+additional entries in the exception table and/or the bug frames.
+
+This is implemented in the Xen Project hypervisor.
+
+### .rodata sections
+
+The patching might require strings to be updated as well. As such we must be
+also able to patch the strings as needed. This sounds simple - but the compiler
+has a habit of coalescing strings that are the same - which means if we in-place
+alter the strings - other users will be inadvertently affected as well.
+
+This is also where pointers to functions live - and we may need to patch this
+as well. And switch-style jump tables.
+
+To guard against that we must be prepared to do patching similar to
+trampoline patching or in-line depending on the flavour. If we can
+do in-line patching we would need to:
+
+ * alter `.rodata` to be writeable.
+ * inline patch.
+ * alter `.rodata` to be read-only.
+
+If are doing trampoline patching we would need to:
+
+ * allocate a new memory location for the string.
+ * all locations which use this string will have to be updated to use the
+ offset to the string.
+ * mark the region RO when we are done.
+
+The trampoline patching is implemented in the Xen Project hypervisor.
+
+### .bss and .data sections.
+
+In place patching writable data is not suitable as it is unclear what should be done
+depending on the current state of data. As such it should not be attempted.
+
+However, functions which are being patched can bring in changes to strings
+(.data or .rodata section changes), or even to .bss sections.
+
+As such the ELF payload can introduce new .rodata, .bss, and .data sections.
+Patching in the new function will end up also patching in the new .rodata
+section and the new function will reference the new string in the new
+.rodata section.
+
+This is implemented in the Xen Project hypervisor.
+
+### Security
+
+Only the privileged domain should be allowed to do this operation.
+
+
+# Not Yet Done
+
+This is for further development of xSplice.
+
+## Goals
+
+The implementation must also have a mechanism for:
+
+ * An dependency mechanism for the payloads. To use that information to load:
+ - The appropiate payload. To verify that payload is built against the
+ hypervisor. This can be done via the `build-id`
+ or via providing an copy of the old code - so that the hypervisor can
+ verify it against the code in memory.
+ - To construct an appropiate order of payloads to load in case they
+ depend on each other.
+ * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
+ * Be able to patch .rodata, .bss, and .data sections.
+ * Further safety checks (blacklist of which functions cannot be patched, check
+ the stack, make sure the payload is built with same compiler as hypervisor).
+ * NOP out the code sequence if `new_size` is zero.
+ * Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64] in payload file.
+
+### xSplice interdependencies
+
+xSplice patches interdependencies are tricky.
+
+There are the ways this can be addressed:
+ * A single large patch that subsumes and replaces all previous ones.
+ Over the life-time of patching the hypervisor this large patch
+ grows to accumulate all the code changes.
+ * Hotpatch stack - where an mechanism exists that loads the hotpatches
+ in the same order they were built in. We would need an build-id
+ of the hypevisor to make sure the hot-patches are build against the
+ correct build.
+ * Payload containing the old code to check against that. That allows
+ the hotpatches to be loaded indepedently (if they don't overlap) - or
+ if the old code also containst previously patched code - even if they
+ overlap.
+
+The disadvantage of the first large patch is that it can grow over
+time and not provide an bisection mechanism to identify faulty patches.
+
+The hot-patch stack puts stricts requirements on the order of the patches
+being loaded and requires an hypervisor build-id to match against.
+
+The old code allows much more flexibility and an additional guard,
+but is more complex to implement.
+
+### Handle inlined __LINE__
+
+This problem is related to hotpatch construction
+and potentially has influence on the design of the hotpatching
+infrastructure in Xen.
+
+For example:
+
+We have file1.c with functions f1 and f2 (in that order). f2 contains a
+BUG() (or WARN()) macro and at that point embeds the source line number
+into the generated code for f2.
+
+Now we want to hotpatch f1 and the hotpatch source-code patch adds 2
+lines to f1 and as a consequence shifts out f2 by two lines. The newly
+constructed file1.o will now contain differences in both binary
+functions f1 (because we actually changed it with the applied patch) and
+f2 (because the contained BUG macro embeds the new line number).
+
+Without additional information, an algorithm comparing file1.o before
+and after hotpatch application will determine both functions to be
+changed and will have to include both into the binary hotpatch.
+
+Options:
+
+1. Transform source code patches for hotpatches to be line-neutral for
+ each chunk. This can be done in almost all cases with either
+ reformatting of the source code or by introducing artificial
+ preprocessor "#line n" directives to adjust for the introduced
+ differences.
+
+ This approach is low-tech and simple. Potentially generated
+ backtraces and existing debug information refers to the original
+ build and does not reflect hotpatching state except for actually
+ hotpatched functions but should be mostly correct.
+
+2. Ignoring the problem and living with artificially large hotpatches
+ that unnecessarily patch many functions.
+
+ This approach might lead to some very large hotpatches depending on
+ content of specific source file. It may also trigger pulling in
+ functions into the hotpatch that cannot reasonable be hotpatched due
+ to limitations of a hotpatching framework (init-sections, parts of
+ the hotpatching framework itself, ...) and may thereby prevent us
+ from patching a specific problem.
+
+ The decision between 1. and 2. can be made on a patch--by-patch
+ basis.
+
+3. Introducing an indirection table for storing line numbers and
+ treating that specially for binary diffing. Linux may follow
+ this approach.
+
+ We might either use this indirection table for runtime use and patch
+ that with each hotpatch (similarly to exception tables) or we might
+ purely use it when building hotpatches to ignore functions that only
+ differ at exactly the location where a line-number is embedded.
+
+For BUG(), WARN(), etc., the line number is embedded into the bug frame, not
+the function itself.
+
+Similar considerations are true to a lesser extent for __FILE__, but it
+could be argued that file renaming should be done outside of hotpatches.
+
+## Signature checking requirements.
+
+The signature checking requires that the layout of the data in memory
+**MUST** be same for signature to be verified. This means that the payload
+data layout in ELF format **MUST** match what the hypervisor would be
+expecting such that it can properly do signature verification.
+
+The signature is based on the all of the payloads continuously laid out
+in memory. The signature is to be appended at the end of the ELF payload
+prefixed with the string '~Module signature appended~\n', followed by
+an signature header then followed by the signature, key identifier, and signers
+name.
+
+Specifically the signature header would be:
+
+<pre>
+#define PKEY_ALGO_DSA 0
+#define PKEY_ALGO_RSA 1
+
+#define PKEY_ID_PGP 0 /* OpenPGP generated key ID */
+#define PKEY_ID_X509 1 /* X.509 arbitrary subjectKeyIdentifier */
+
+#define HASH_ALGO_MD4 0
+#define HASH_ALGO_MD5 1
+#define HASH_ALGO_SHA1 2
+#define HASH_ALGO_RIPE_MD_160 3
+#define HASH_ALGO_SHA256 4
+#define HASH_ALGO_SHA384 5
+#define HASH_ALGO_SHA512 6
+#define HASH_ALGO_SHA224 7
+#define HASH_ALGO_RIPE_MD_128 8
+#define HASH_ALGO_RIPE_MD_256 9
+#define HASH_ALGO_RIPE_MD_320 10
+#define HASH_ALGO_WP_256 11
+#define HASH_ALGO_WP_384 12
+#define HASH_ALGO_WP_512 13
+#define HASH_ALGO_TGR_128 14
+#define HASH_ALGO_TGR_160 15
+#define HASH_ALGO_TGR_192 16
+
+
+struct elf_payload_signature {
+ u8 algo; /* Public-key crypto algorithm PKEY_ALGO_*. */
+ u8 hash; /* Digest algorithm: HASH_ALGO_*. */
+ u8 id_type; /* Key identifier type PKEY_ID*. */
+ u8 signer_len; /* Length of signer's name */
+ u8 key_id_len; /* Length of key identifier */
+ u8 __pad[3];
+ __be32 sig_len; /* Length of signature data */
+};
+
+</pre>
+(Note that this has been borrowed from Linux module signature code.).
+
+
+### .bss and .data sections.
+
+In place patching writable data is not suitable as it is unclear what should be done
+depending on the current state of data. As such it should not be attempted.
+
+That said we should provide hook functions so that the existing data
+can be changed during payload application.
+
+
+### Inline patching
+
+The hypervisor should verify that the in-place patching would fit within
+the code or data.
+
+### Trampoline (e9 opcode)
+
+The e9 opcode used for jmpq uses a 32-bit signed displacement. That means
+we are limited to up to 2GB of virtual address to place the new code
+from the old code. That should not be a problem since Xen hypervisor has
+a very small footprint.
+
+However if we need - we can always add two trampolines. One at the 2GB
+limit that calls the next trampoline.
+
+Please note there is a small limitation for trampolines in
+function entries: The target function (+ trailing padding) must be able
+to accomodate the trampoline. On x86 with +-2 GB relative jumps,
+this means 5 bytes are required.
+
+Depending on compiler settings, there are several functions in Xen that
+are smaller (without inter-function padding).
+
+<pre>
+readelf -sW xen-syms | grep " FUNC " | \
+ awk '{ if ($3 < 5) print $3, $4, $5, $8 }'
+
+...
+3 FUNC LOCAL wbinvd_ipi
+3 FUNC LOCAL shadow_l1_index
+...
+</pre>
+A compile-time check for, e.g., a minimum alignment of functions or a
+runtime check that verifies symbol size (+ padding to next symbols) for
+that in the hypervisor is advised.
+
+The tool for generating payloads currently does perform a compile-time
+check to ensure that the function to be replaced is large enough.
+
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 06/28] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (4 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 05/28] xsplice: Design document Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-31 9:45 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 07/28] libxc: Implementation of XEN_XSPLICE_op in libxc Konrad Rzeszutek Wilk
` (21 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Daniel De Graaf, Stefano Stabellini, Ian Jackson,
Konrad Rzeszutek Wilk
The implementation does not actually do any patching.
It just adds the framework for doing the hypercalls,
keeping track of ELF payloads, and the basic operations:
- query which payloads exist,
- query for specific payloads,
- check*1, apply*1, replace*1, and unload payloads.
*1: Which of course in this patch are nops.
The functionality is disabled on ARM until all arch
components are implemented.
Also by default it is disabled until the implementation
is in place.
We also use recursive spinlocks to so that the find_payload
function does not need to have a 'lock' and 'non-lock' variant.
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
v2: Rebased on keyhandler: rework keyhandler infrastructure
v3: Fixed XSM.
- Removed REVERTED state.
Split status and error code.
Add REPLACE action.
Separate payload data from the payload structure.
s/XSPLICE_ID_../XSPLICE_NAME_../
- Add xsplice and CONFIG_XSPLICE build toption.
Fix code per Jan's review.
Update the sysctl.h (change bits to enum like)
- Rebase on Kconfig changes.
- Add missing pad checks. Re-order keyhandler.h to build on ARM.
- Rebase on build: hook the schedulers into Kconfig
- s/id/name/; s/payload_list_lock/payload_lock/
- Put #ifdef CONFIG_XSPLICE in header file per Doug review.
- Andrew review:
- use recursive spinlocks, change name to xsplice_op,
sprinkle new-lines, add local variable block, include
state diagram, squash two goto labels, use vzalloc instead of
alloc_xenheap_pages.
- change 'state' from int32 to uint32_t
- remove the err label out of xsplice_upload
- use void* instaed of uint8_t
- move code around to make it easier to read.
- Add vmap.h to compiler under ARM.
- Add missing Copyright in header file
- Dropped LOADED state, make the payload go in CHECKED.
v4: Made it only work on x86 per Julien's (ARM) maintainer request.
v5: Dropped the load->check state example in sysctl.h
Made the ->nr=0 call work. Remove rc=0 in lots of cases. Update
header from design doc.
---
tools/flask/policy/policy/modules/xen/xen.te | 1 +
xen/common/Kconfig | 12 +
xen/common/Makefile | 1 +
xen/common/sysctl.c | 7 +
xen/common/xsplice.c | 406 +++++++++++++++++++++++++++
xen/include/public/sysctl.h | 167 +++++++++++
xen/include/xen/xsplice.h | 35 +++
xen/xsm/flask/hooks.c | 6 +
xen/xsm/flask/policy/access_vectors | 2 +
9 files changed, 637 insertions(+)
create mode 100644 xen/common/xsplice.c
create mode 100644 xen/include/xen/xsplice.h
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 7e69ce9..68ef6de 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -72,6 +72,7 @@ allow dom0_t xen_t:xen2 {
allow dom0_t xen_t:xen2 {
pmu_ctrl
get_symbol
+ xsplice_op
};
# Allow dom0 to use all XENVER_ subops and VERSION subops that have checks.
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index 3522ecb..d80dddb 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -182,4 +182,16 @@ config SCHED_DEFAULT
endmenu
+# Enable/Disable xsplice support
+config XSPLICE
+ bool "xSplice live patching support"
+ default n
+ depends on X86
+ ---help---
+ Allows a running Xen hypervisor to be dynamically patched using
+ binary patches without rebooting. This is primarily used to binarily
+ patch in the field an hypervisor with XSA fixes.
+
+ If unsure, say Y.
+
endmenu
diff --git a/xen/common/Makefile b/xen/common/Makefile
index e43ec49..1e4bc70 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -58,6 +58,7 @@ obj-y += vsprintf.o
obj-y += wait.o
obj-$(CONFIG_XENOPROF) += xenoprof.o
obj-y += xmalloc_tlsf.o
+obj-$(CONFIG_XSPLICE) += xsplice.o
obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
diff --git a/xen/common/sysctl.c b/xen/common/sysctl.c
index 253b7c8..0fac940 100644
--- a/xen/common/sysctl.c
+++ b/xen/common/sysctl.c
@@ -28,6 +28,7 @@
#include <xsm/xsm.h>
#include <xen/pmstat.h>
#include <xen/gcov.h>
+#include <xen/xsplice.h>
long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
{
@@ -460,6 +461,12 @@ long do_sysctl(XEN_GUEST_HANDLE_PARAM(xen_sysctl_t) u_sysctl)
ret = tmem_control(&op->u.tmem_op);
break;
+ case XEN_SYSCTL_xsplice_op:
+ ret = xsplice_op(&op->u.xsplice);
+ if ( ret != -EOPNOTSUPP )
+ copyback = 1;
+ break;
+
default:
ret = arch_do_sysctl(op, u_sysctl);
copyback = 0;
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
new file mode 100644
index 0000000..0047032
--- /dev/null
+++ b/xen/common/xsplice.c
@@ -0,0 +1,406 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/err.h>
+#include <xen/guest_access.h>
+#include <xen/keyhandler.h>
+#include <xen/lib.h>
+#include <xen/list.h>
+#include <xen/mm.h>
+#include <xen/sched.h>
+#include <xen/smp.h>
+#include <xen/spinlock.h>
+#include <xen/vmap.h>
+#include <xen/xsplice.h>
+
+#include <asm/event.h>
+#include <public/sysctl.h>
+
+static DEFINE_SPINLOCK(payload_lock);
+static LIST_HEAD(payload_list);
+
+static unsigned int payload_cnt;
+static unsigned int payload_version = 1;
+
+struct payload {
+ uint32_t state; /* One of the XSPLICE_STATE_*. */
+ int32_t rc; /* 0 or -XEN_EXX. */
+ struct list_head list; /* Linked to 'payload_list'. */
+ char name[XEN_XSPLICE_NAME_SIZE]; /* Name of it. */
+};
+
+static int verify_name(const xen_xsplice_name_t *name)
+{
+ if ( !name->size || name->size > XEN_XSPLICE_NAME_SIZE )
+ return -EINVAL;
+
+ if ( name->pad[0] || name->pad[1] || name->pad[2] )
+ return -EINVAL;
+
+ if ( !guest_handle_okay(name->name, name->size) )
+ return -EINVAL;
+
+ return 0;
+}
+
+static int verify_payload(const xen_sysctl_xsplice_upload_t *upload)
+{
+ if ( verify_name(&upload->name) )
+ return -EINVAL;
+
+ if ( !upload->size )
+ return -EINVAL;
+
+ if ( upload->size > MB(2) )
+ return -EINVAL;
+
+ if ( !guest_handle_okay(upload->payload, upload->size) )
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * We may be holding the payload_lock or not. Hence we need
+ * the recursive spinlock. Or we can judiciously use an
+ * lock argument to differenciate - but it is simpler with recursive locks.
+ */
+static struct payload *find_payload(const xen_xsplice_name_t *name)
+{
+ struct payload *data, *found = NULL;
+ char n[XEN_XSPLICE_NAME_SIZE];
+ int rc;
+
+ rc = verify_name(name);
+ if ( rc )
+ return ERR_PTR(rc);
+
+ if ( __copy_from_guest(n, name->name, name->size) )
+ return ERR_PTR(-EFAULT);
+
+ if ( n[name->size - 1] )
+ return ERR_PTR(-EINVAL);
+
+ spin_lock_recursive(&payload_lock);
+
+ list_for_each_entry ( data, &payload_list, list )
+ {
+ if ( !strcmp(data->name, n) )
+ {
+ found = data;
+ break;
+ }
+ }
+
+ spin_unlock_recursive(&payload_lock);
+
+ return found;
+}
+
+/* We MUST be holding the payload_lock spinlock. */
+static void free_payload(struct payload *data)
+{
+ ASSERT(spin_is_locked(&payload_lock));
+ list_del(&data->list);
+ payload_cnt--;
+ payload_version++;
+ xfree(data);
+}
+
+static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
+{
+ struct payload *data;
+ int rc;
+
+ rc = verify_payload(upload);
+ if ( rc )
+ return rc;
+
+ data = find_payload(&upload->name);
+ if ( data && !IS_ERR(data) /* Found. */ )
+ return -EEXIST;
+
+ if ( IS_ERR(data) )
+ return PTR_ERR(data);
+
+ data = xzalloc(struct payload);
+ if ( !data )
+ return -ENOMEM;
+
+ rc = -EFAULT;
+ if ( __copy_from_guest(data->name, upload->name.name, upload->name.size) )
+ goto out;
+
+ rc = -EINVAL;
+ if ( data->name[upload->name.size - 1] )
+ goto out;
+
+ rc = 0;
+ data->state = XSPLICE_STATE_CHECKED;
+ INIT_LIST_HEAD(&data->list);
+
+ spin_lock_recursive(&payload_lock);
+ list_add_tail(&data->list, &payload_list);
+ payload_cnt++;
+ payload_version++;
+ spin_unlock_recursive(&payload_lock);
+
+ out:
+ if ( rc )
+ xfree(data);
+
+ return rc;
+}
+
+static int xsplice_get(xen_sysctl_xsplice_get_t *get)
+{
+ struct payload *data;
+ int rc;
+
+ rc = verify_name(&get->name);
+ if ( rc )
+ return rc;
+
+ spin_lock_recursive(&payload_lock);
+
+ data = find_payload(&get->name);
+ if ( IS_ERR_OR_NULL(data) )
+ {
+ spin_unlock_recursive(&payload_lock);
+ if ( !data )
+ return -ENOENT;
+
+ return PTR_ERR(data);
+ }
+
+ get->status.state = data->state;
+ get->status.rc = data->rc;
+
+ spin_unlock_recursive(&payload_lock);
+
+ return 0;
+}
+
+static int xsplice_list(xen_sysctl_xsplice_list_t *list)
+{
+ xen_xsplice_status_t status;
+ struct payload *data;
+ unsigned int idx = 0, i = 0;
+ int rc = 0;
+
+ if ( list->nr > 1024 )
+ return -E2BIG;
+
+ if ( list->pad )
+ return -EINVAL;
+
+ if ( list->nr &&
+ (!guest_handle_okay(list->status, list->nr) ||
+ !guest_handle_okay(list->name, XEN_XSPLICE_NAME_SIZE * list->nr) ||
+ !guest_handle_okay(list->len, list->nr)) )
+ return -EINVAL;
+
+ spin_lock_recursive(&payload_lock);
+ if ( list->idx > payload_cnt )
+ {
+ spin_unlock_recursive(&payload_lock);
+ return -EINVAL;
+ }
+
+ if ( list->nr )
+ {
+ list_for_each_entry( data, &payload_list, list )
+ {
+ uint32_t len;
+
+ if ( list->idx > i++ )
+ continue;
+
+ status.state = data->state;
+ status.rc = data->rc;
+ len = strlen(data->name) + 1;
+
+ /* N.B. 'idx' != 'i'. */
+ if ( __copy_to_guest_offset(list->name, idx * XEN_XSPLICE_NAME_SIZE,
+ data->name, len) ||
+ __copy_to_guest_offset(list->len, idx, &len, 1) ||
+ __copy_to_guest_offset(list->status, idx, &status, 1) )
+ {
+ rc = -EFAULT;
+ break;
+ }
+
+ idx++;
+
+ if ( (idx >= list->nr) || hypercall_preempt_check() )
+ break;
+ }
+ }
+ list->nr = payload_cnt - i; /* Remaining amount. */
+ list->version = payload_version;
+ spin_unlock_recursive(&payload_lock);
+
+ /* And how many we have processed. */
+ return rc ? : idx;
+}
+
+static int xsplice_action(xen_sysctl_xsplice_action_t *action)
+{
+ struct payload *data;
+ int rc;
+
+ rc = verify_name(&action->name);
+ if ( rc )
+ return rc;
+
+ spin_lock_recursive(&payload_lock);
+ data = find_payload(&action->name);
+ if ( IS_ERR_OR_NULL(data) )
+ {
+ spin_unlock_recursive(&payload_lock);
+ if ( !data )
+ return -ENOENT;
+
+ return PTR_ERR(data);
+ }
+
+ switch ( action->cmd )
+ {
+ case XSPLICE_ACTION_CHECK:
+ if ( data->state == XSPLICE_STATE_CHECKED )
+ {
+ /* No implementation yet. */
+ data->state = XSPLICE_STATE_CHECKED;
+ data->rc = 0;
+ }
+ break;
+
+ case XSPLICE_ACTION_UNLOAD:
+ if ( data->state == XSPLICE_STATE_CHECKED )
+ {
+ free_payload(data);
+ /* No touching 'data' from here on! */
+ data = NULL;
+ }
+ break;
+
+ case XSPLICE_ACTION_REVERT:
+ if ( data->state == XSPLICE_STATE_APPLIED )
+ {
+ /* No implementation yet. */
+ data->state = XSPLICE_STATE_CHECKED;
+ data->rc = 0;
+ }
+ break;
+
+ case XSPLICE_ACTION_APPLY:
+ if ( data->state == XSPLICE_STATE_CHECKED )
+ {
+ /* No implementation yet. */
+ data->state = XSPLICE_STATE_APPLIED;
+ data->rc = 0;
+ }
+ break;
+
+ case XSPLICE_ACTION_REPLACE:
+ if ( data->state == XSPLICE_STATE_CHECKED )
+ {
+ /* No implementation yet. */
+ data->state = XSPLICE_STATE_CHECKED;
+ data->rc = 0;
+ }
+ break;
+
+ default:
+ rc = -EOPNOTSUPP;
+ break;
+ }
+
+ spin_unlock_recursive(&payload_lock);
+
+ return rc;
+}
+
+int xsplice_op(xen_sysctl_xsplice_op_t *xsplice)
+{
+ int rc;
+
+ if ( xsplice->pad )
+ return -EINVAL;
+
+ switch ( xsplice->cmd )
+ {
+ case XEN_SYSCTL_XSPLICE_UPLOAD:
+ rc = xsplice_upload(&xsplice->u.upload);
+ break;
+
+ case XEN_SYSCTL_XSPLICE_GET:
+ rc = xsplice_get(&xsplice->u.get);
+ break;
+
+ case XEN_SYSCTL_XSPLICE_LIST:
+ rc = xsplice_list(&xsplice->u.list);
+ break;
+
+ case XEN_SYSCTL_XSPLICE_ACTION:
+ rc = xsplice_action(&xsplice->u.action);
+ break;
+
+ default:
+ rc = -EOPNOTSUPP;
+ break;
+ }
+
+ return rc;
+}
+
+static const char *state2str(uint32_t state)
+{
+#define STATE(x) [XSPLICE_STATE_##x] = #x
+ static const char *const names[] = {
+ STATE(CHECKED),
+ STATE(APPLIED),
+ };
+#undef STATE
+
+ if (state >= ARRAY_SIZE(names) || !names[state])
+ return "unknown";
+
+ return names[state];
+}
+
+static void xsplice_printall(unsigned char key)
+{
+ struct payload *data;
+
+ if ( !spin_trylock_recursive(&payload_lock) )
+ {
+ printk("Lock held. Try again.\n");
+ return;
+ }
+
+ list_for_each_entry ( data, &payload_list, list )
+ printk(" name=%s state=%s(%d)\n", data->name,
+ state2str(data->state), data->state);
+
+ spin_unlock_recursive(&payload_lock);
+}
+
+static int __init xsplice_init(void)
+{
+ register_keyhandler('x', xsplice_printall, "print xsplicing info", 1);
+ return 0;
+}
+__initcall(xsplice_init);
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/public/sysctl.h b/xen/include/public/sysctl.h
index 96680eb..269612e 100644
--- a/xen/include/public/sysctl.h
+++ b/xen/include/public/sysctl.h
@@ -766,6 +766,171 @@ struct xen_sysctl_tmem_op {
typedef struct xen_sysctl_tmem_op xen_sysctl_tmem_op_t;
DEFINE_XEN_GUEST_HANDLE(xen_sysctl_tmem_op_t);
+/*
+ * XEN_SYSCTL_XSPLICE_op
+ *
+ * Refer to the docs/unstable/misc/xsplice.markdown
+ * for the design details of this hypercall.
+ *
+ * There are four sub-ops:
+ * XEN_SYSCTL_XSPLICE_UPLOAD (0)
+ * XEN_SYSCTL_XSPLICE_GET (1)
+ * XEN_SYSCTL_XSPLICE_LIST (2)
+ * XEN_SYSCTL_XSPLICE_ACTION (3)
+ *
+ * The normal sequence of sub-ops is to:
+ * 1) XEN_SYSCTL_XSPLICE_UPLOAD to upload the payload. If errors STOP.
+ * 2) XEN_SYSCTL_XSPLICE_GET to check the `->rc`. If -XEN_EAGAIN spin.
+ * If zero go to next step.
+ * 3) XEN_SYSCTL_XSPLICE_ACTION with XSPLICE_ACTION_APPLY to apply the patch.
+ * 4) XEN_SYSCTL_XSPLICE_GET to check the `->rc`. If in -XEN_EAGAIN spin.
+ * If zero exit with success.
+ */
+
+/*
+ * Structure describing an ELF payload. Uniquely identifies the
+ * payload. Should be human readable.
+ * Recommended length is upto XEN_XSPLICE_NAME_SIZE.
+ * Includes the NUL terminator.
+ */
+#define XEN_XSPLICE_NAME_SIZE 128
+struct xen_xsplice_name {
+ XEN_GUEST_HANDLE_64(char) name; /* IN: pointer to name. */
+ uint16_t size; /* IN: size of name. May be upto
+ XEN_XSPLICE_NAME_SIZE. */
+ uint16_t pad[3]; /* IN: MUST be zero. */
+};
+typedef struct xen_xsplice_name xen_xsplice_name_t;
+DEFINE_XEN_GUEST_HANDLE(xen_xsplice_name_t);
+
+/*
+ * Upload a payload to the hypervisor. The payload is verified
+ * against basic checks and if there are any issues the proper return code
+ * will be returned. The payload is not applied at this time - that is
+ * controlled by XEN_SYSCTL_XSPLICE_ACTION.
+ *
+ * The return value is zero if the payload was succesfully uploaded.
+ * Otherwise an EXX return value is provided. Duplicate `name` are not
+ * supported.
+ *
+ * The payload at this point is verified against basic checks.
+ *
+ * The `payload` is the ELF payload as mentioned in the `Payload format`
+ * section in the xSplice design document.
+ */
+#define XEN_SYSCTL_XSPLICE_UPLOAD 0
+struct xen_sysctl_xsplice_upload {
+ xen_xsplice_name_t name; /* IN, name of the patch. */
+ uint64_t size; /* IN, size of the ELF file. */
+ XEN_GUEST_HANDLE_64(uint8) payload; /* IN, the ELF file. */
+};
+typedef struct xen_sysctl_xsplice_upload xen_sysctl_xsplice_upload_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_upload_t);
+
+/*
+ * Retrieve an status of an specific payload.
+ *
+ * Upon completion the `struct xen_xsplice_status` is updated.
+ *
+ * The return value is zero on success and XEN_EXX on failure. This operation
+ * is synchronous and does not require preemption.
+ */
+#define XEN_SYSCTL_XSPLICE_GET 1
+
+struct xen_xsplice_status {
+#define XSPLICE_STATE_CHECKED 1
+#define XSPLICE_STATE_APPLIED 2
+ uint32_t state; /* OUT: XSPLICE_STATE_*. */
+ int32_t rc; /* OUT: 0 if no error, otherwise -XEN_EXX. */
+};
+typedef struct xen_xsplice_status xen_xsplice_status_t;
+DEFINE_XEN_GUEST_HANDLE(xen_xsplice_status_t);
+
+struct xen_sysctl_xsplice_get {
+ xen_xsplice_name_t name; /* IN, name of the payload. */
+ xen_xsplice_status_t status; /* IN/OUT, state of it. */
+};
+typedef struct xen_sysctl_xsplice_get xen_sysctl_xsplice_get_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_get_t);
+
+/*
+ * Retrieve an array of abbreviated status and names of payloads that are
+ * loaded in the hypervisor.
+ *
+ * If the hypercall returns an positive number, it is the number (up to `nr`)
+ * of the payloads returned, along with `nr` updated with the number of remaining
+ * payloads, `version` updated (it may be the same across hypercalls. If it
+ * varies the data is stale and further calls could fail). The `status`,
+ * `name`, and `len`' are updated at their designed index value (`idx`) with
+ * the returned value of data.
+ *
+ * If the hypercall returns E2BIG the `nr` is too big and should be
+ * lowered. The upper limit of `nr` is left to the implemention.
+ *
+ * Note that due to the asynchronous nature of hypercalls the domain might have
+ * added or removed the number of payloads making this information stale. It is
+ * the responsibility of the toolstack to use the `version` field to check
+ * between each invocation. if the version differs it should discard the stale
+ * data and start from scratch. It is OK for the toolstack to use the new
+ * `version` field.
+ */
+#define XEN_SYSCTL_XSPLICE_LIST 2
+struct xen_sysctl_xsplice_list {
+ uint32_t version; /* OUT: Hypervisor stamps value.
+ If varies between calls, we are
+ * getting stale data. */
+ uint32_t idx; /* IN: Index into hypervisor array.
+ Should be between [0, nr). */
+ uint32_t nr; /* IN: How many status, name, and len
+ should fill out. Can be zero to get
+ amount of payloads and version.
+ OUT: How many payloads left. */
+ uint32_t pad; /* IN: Must be zero. */
+ XEN_GUEST_HANDLE_64(xen_xsplice_status_t) status; /* OUT. Must have enough
+ space allocate for nr of them. */
+ XEN_GUEST_HANDLE_64(char) name; /* OUT: Array of names. Each member
+ MUST XEN_XSPLICE_NAME_SIZE in size.
+ Must have nr of them. */
+ XEN_GUEST_HANDLE_64(uint32) len; /* OUT: Array of lengths of name's.
+ Must have nr of them. */
+};
+typedef struct xen_sysctl_xsplice_list xen_sysctl_xsplice_list_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_list_t);
+
+/*
+ * Perform an operation on the payload structure referenced by the `name` field.
+ * The operation request is asynchronous and the status should be retrieved
+ * by using either XEN_SYSCTL_XSPLICE_GET or XEN_SYSCTL_XSPLICE_LIST hypercall.
+ */
+#define XEN_SYSCTL_XSPLICE_ACTION 3
+struct xen_sysctl_xsplice_action {
+ xen_xsplice_name_t name; /* IN, name of the patch. */
+#define XSPLICE_ACTION_CHECK 1
+#define XSPLICE_ACTION_UNLOAD 2
+#define XSPLICE_ACTION_REVERT 3
+#define XSPLICE_ACTION_APPLY 4
+#define XSPLICE_ACTION_REPLACE 5
+ uint32_t cmd; /* IN: XSPLICE_ACTION_*. */
+ uint32_t timeout; /* IN: Zero if no timeout. */
+ /* Or upper bound of time (ms) */
+ /* for operation to take. */
+};
+typedef struct xen_sysctl_xsplice_action xen_sysctl_xsplice_action_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_action_t);
+
+struct xen_sysctl_xsplice_op {
+ uint32_t cmd; /* IN: XEN_SYSCTL_XSPLICE_*. */
+ uint32_t pad; /* IN: Always zero. */
+ union {
+ xen_sysctl_xsplice_upload_t upload;
+ xen_sysctl_xsplice_list_t list;
+ xen_sysctl_xsplice_get_t get;
+ xen_sysctl_xsplice_action_t action;
+ } u;
+};
+typedef struct xen_sysctl_xsplice_op xen_sysctl_xsplice_op_t;
+DEFINE_XEN_GUEST_HANDLE(xen_sysctl_xsplice_op_t);
+
struct xen_sysctl {
uint32_t cmd;
#define XEN_SYSCTL_readconsole 1
@@ -791,6 +956,7 @@ struct xen_sysctl {
#define XEN_SYSCTL_pcitopoinfo 22
#define XEN_SYSCTL_psr_cat_op 23
#define XEN_SYSCTL_tmem_op 24
+#define XEN_SYSCTL_xsplice_op 25
uint32_t interface_version; /* XEN_SYSCTL_INTERFACE_VERSION */
union {
struct xen_sysctl_readconsole readconsole;
@@ -816,6 +982,7 @@ struct xen_sysctl {
struct xen_sysctl_psr_cmt_op psr_cmt_op;
struct xen_sysctl_psr_cat_op psr_cat_op;
struct xen_sysctl_tmem_op tmem_op;
+ struct xen_sysctl_xsplice_op xsplice;
uint8_t pad[128];
} u;
};
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
new file mode 100644
index 0000000..5c84851
--- /dev/null
+++ b/xen/include/xen/xsplice.h
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#ifndef __XEN_XSPLICE_H__
+#define __XEN_XSPLICE_H__
+
+struct xen_sysctl_xsplice_op;
+
+#ifdef CONFIG_XSPLICE
+
+int xsplice_op(struct xen_sysctl_xsplice_op *);
+
+#else
+
+#include <xen/errno.h> /* For -EOPNOTSUPP */
+static inline int xsplice_op(struct xen_sysctl_xsplice_op *op)
+{
+ return -EOPNOTSUPP;
+}
+
+#endif /* CONFIG_XSPLICE */
+
+#endif /* __XEN_XSPLICE_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 1eaec58..3ef0441 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -808,6 +808,12 @@ static int flask_sysctl(int cmd)
case XEN_SYSCTL_tmem_op:
return domain_has_xen(current->domain, XEN__TMEM_CONTROL);
+#ifdef CONFIG_XSPLICE
+ case XEN_SYSCTL_xsplice_op:
+ return avc_current_has_perm(SECINITSID_XEN, SECCLASS_XEN2,
+ XEN2__XSPLICE_OP, NULL);
+#endif
+
default:
printk("flask_sysctl: Unknown op %d\n", cmd);
return -EPERM;
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 56600bb..1c59b58 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -93,6 +93,8 @@ class xen2
pmu_ctrl
# PMU use (domains, including unprivileged ones, will be using this operation)
pmu_use
+# XEN_SYSCTL_xsplice_op
+ xsplice_op
}
# Classes domain and domain2 consist of operations that a domain performs on
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 07/28] libxc: Implementation of XEN_XSPLICE_op in libxc
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (5 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 06/28] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 08/28] xen-xsplice: Tool to manipulate xsplice payloads Konrad Rzeszutek Wilk
` (20 subsequent siblings)
27 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Stefano Stabellini, Ian Jackson, Konrad Rzeszutek Wilk
The underlaying toolstack code to do the basic
operations when using the XEN_XSPLICE_op syscalls:
- upload the payload,
- get status of an payload,
- list all the payloads,
- apply, check, replace, and revert the payload.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
v2: Actually set zero for the _pad entries.
v3: Split status into state and error code.
Add REPLACE action.
- Use timeout and utilize pads.
- Update per Wei's review.
- Extra space slipped in, remove it
v4: Add Wei's review, update comment and Ack.
---
tools/libxc/include/xenctrl.h | 62 ++++++++
tools/libxc/xc_misc.c | 337 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 399 insertions(+)
diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index a9e4dc1..65b4758 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2561,6 +2561,68 @@ int xc_psr_cat_get_l3_info(xc_interface *xch, uint32_t socket,
bool *cdp_enabled);
#endif
+int xc_xsplice_upload(xc_interface *xch,
+ char *name, unsigned char *payload, uint32_t size);
+
+int xc_xsplice_get(xc_interface *xch,
+ char *name,
+ xen_xsplice_status_t *status);
+
+/*
+ * The heart of this function is to get an array of xen_xsplice_status_t.
+ *
+ * However it is complex because it has to deal with the hypervisor
+ * returning some of the requested data or data being stale
+ * (another hypercall might alter the list).
+ *
+ * The parameters that the function expects to contain data from
+ * the hypervisor are: 'info', 'name', and 'len'. The 'done' and
+ * 'left' are also updated with the number of entries filled out
+ * and respectively the number of entries left to get from hypervisor.
+ *
+ * It is expected that the caller of this function will take the
+ * 'left' and use the value for 'start'. This way we have an
+ * cursor in the array. Note that the 'info','name', and 'len' will
+ * be updated at the subsequent calls.
+ *
+ * The 'max' is to be provided by the caller with the maximum
+ * number of entries that 'info', 'name', and 'len' arrays can
+ * be filled up with.
+ *
+ * Each entry in the 'name' array is expected to be of XEN_XSPLICE_NAME_SIZE
+ * length.
+ *
+ * Each entry in the 'info' array is expected to be of xen_xsplice_status_t
+ * structure size.
+ *
+ * Each entry in the 'len' array is expected to be of uint32_t size.
+ *
+ * The return value is zero if the hypercall completed successfully.
+ * Note that the return value is _not_ the amount of entries filled
+ * out - that is saved in 'done'.
+ *
+ * If there was an error performing the operation, the return value
+ * will contain an negative -EXX type value. The 'done' and 'left'
+ * will contain the number of entries that had been succesfully
+ * retrieved (if any).
+ */
+int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
+ xen_xsplice_status_t *info, char *name,
+ uint32_t *len, unsigned int *done,
+ unsigned int *left);
+
+/*
+ * The operations are asynchronous and the hypervisor may take a while
+ * to complete them. The `timeout` offers an option to expire the
+ * operation if it could not be completed within the specified time
+ * (in ms). Value of 0 means let hypervisor decide the best timeout.
+ */
+int xc_xsplice_apply(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_revert(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_unload(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_check(xc_interface *xch, char *name, uint32_t timeout);
+int xc_xsplice_replace(xc_interface *xch, char *name, uint32_t timeout);
+
/* Compat shims */
#include "xenctrl_compat.h"
diff --git a/tools/libxc/xc_misc.c b/tools/libxc/xc_misc.c
index 124537b..e09ac90 100644
--- a/tools/libxc/xc_misc.c
+++ b/tools/libxc/xc_misc.c
@@ -693,6 +693,343 @@ int xc_hvm_inject_trap(
return rc;
}
+int xc_xsplice_upload(xc_interface *xch,
+ char *name,
+ unsigned char *payload,
+ uint32_t size)
+{
+ int rc;
+ DECLARE_SYSCTL;
+ DECLARE_HYPERCALL_BUFFER(char, local);
+ DECLARE_HYPERCALL_BOUNCE(name, 0 /* later */, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+ xen_xsplice_name_t def_name = { .pad = { 0, 0, 0 } };
+
+ if ( !name || !payload )
+ return -1;
+
+ def_name.size = strlen(name) + 1;
+ if ( def_name.size > XEN_XSPLICE_NAME_SIZE )
+ return -1;
+
+ HYPERCALL_BOUNCE_SET_SIZE(name, def_name.size);
+
+ if ( xc_hypercall_bounce_pre(xch, name) )
+ return -1;
+
+ local = xc_hypercall_buffer_alloc(xch, local, size);
+ if ( !local )
+ {
+ xc_hypercall_bounce_post(xch, name);
+ return -1;
+ }
+ memcpy(local, payload, size);
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_UPLOAD;
+ sysctl.u.xsplice.pad = 0;
+ sysctl.u.xsplice.u.upload.size = size;
+ set_xen_guest_handle(sysctl.u.xsplice.u.upload.payload, local);
+
+ sysctl.u.xsplice.u.upload.name = def_name;
+ set_xen_guest_handle(sysctl.u.xsplice.u.upload.name.name, name);
+
+ rc = do_sysctl(xch, &sysctl);
+
+ xc_hypercall_buffer_free(xch, local);
+ xc_hypercall_bounce_post(xch, name);
+
+ return rc;
+}
+
+int xc_xsplice_get(xc_interface *xch,
+ char *name,
+ xen_xsplice_status_t *status)
+{
+ int rc;
+ DECLARE_SYSCTL;
+ DECLARE_HYPERCALL_BOUNCE(name, 0 /*adjust later */, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+ xen_xsplice_name_t def_name = { .pad = { 0, 0, 0 } };
+
+ if ( !name )
+ return -1;
+
+ def_name.size = strlen(name) + 1;
+ if ( def_name.size > XEN_XSPLICE_NAME_SIZE )
+ return -1;
+
+ HYPERCALL_BOUNCE_SET_SIZE(name, def_name.size);
+
+ if ( xc_hypercall_bounce_pre(xch, name) )
+ return -1;
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_GET;
+ sysctl.u.xsplice.pad = 0;
+
+ sysctl.u.xsplice.u.get.status.state = 0;
+ sysctl.u.xsplice.u.get.status.rc = 0;
+
+ sysctl.u.xsplice.u.get.name = def_name;
+ set_xen_guest_handle(sysctl.u.xsplice.u.get.name.name, name);
+
+ rc = do_sysctl(xch, &sysctl);
+
+ xc_hypercall_bounce_post(xch, name);
+
+ memcpy(status, &sysctl.u.xsplice.u.get.status, sizeof(*status));
+
+ return rc;
+}
+
+/*
+ * The heart of this function is to get an array of xen_xsplice_status_t.
+ *
+ * However it is complex because it has to deal with the hypervisor
+ * returning some of the requested data or data being stale
+ * (another hypercall might alter the list).
+ *
+ * The parameters that the function expects to contain data from
+ * the hypervisor are: 'info', 'name', and 'len'. The 'done' and
+ * 'left' are also updated with the number of entries filled out
+ * and respectively the number of entries left to get from hypervisor.
+ *
+ * It is expected that the caller of this function will take the
+ * 'left' and use the value for 'start'. This way we have an
+ * cursor in the array. Note that the 'info','name', and 'len' will
+ * be updated at the subsequent calls.
+ *
+ * The 'max' is to be provided by the caller with the maximum
+ * number of entries that 'info', 'name', and 'len' arrays can
+ * be filled up with.
+ *
+ * Each entry in the 'name' array is expected to be of XEN_XSPLICE_NAME_SIZE
+ * length.
+ *
+ * Each entry in the 'info' array is expected to be of xen_xsplice_status_t
+ * structure size.
+ *
+ * Each entry in the 'len' array is expected to be of uint32_t size.
+ *
+ * The return value is zero if the hypercall completed successfully.
+ * Note that the return value is _not_ the amount of entries filled
+ * out - that is saved in 'done'.
+ *
+ * If there was an error performing the operation, the return value
+ * will contain an negative -EXX type value. The 'done' and 'left'
+ * will contain the number of entries that had been succesfully
+ * retrieved (if any).
+ */
+int xc_xsplice_list(xc_interface *xch, unsigned int max, unsigned int start,
+ xen_xsplice_status_t *info,
+ char *name, uint32_t *len,
+ unsigned int *done,
+ unsigned int *left)
+{
+ int rc;
+ DECLARE_SYSCTL;
+ /* The sizes are adjusted later - hence zero. */
+ DECLARE_HYPERCALL_BOUNCE(info, 0, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+ DECLARE_HYPERCALL_BOUNCE(name, 0, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+ DECLARE_HYPERCALL_BOUNCE(len, 0, XC_HYPERCALL_BUFFER_BOUNCE_OUT);
+ uint32_t max_batch_sz, nr;
+ uint32_t version = 0, retries = 0;
+ uint32_t adjust = 0;
+ ssize_t sz;
+
+ if ( !max || !info || !name || !len )
+ return -1;
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_LIST;
+ sysctl.u.xsplice.pad = 0;
+ sysctl.u.xsplice.u.list.version = 0;
+ sysctl.u.xsplice.u.list.idx = start;
+ sysctl.u.xsplice.u.list.pad = 0;
+
+ max_batch_sz = max;
+ /* Convience value. */
+ sz = sizeof(*name) * XEN_XSPLICE_NAME_SIZE;
+ *done = 0;
+ *left = 0;
+ do {
+ /*
+ * The first time we go in this loop our 'max' may be bigger
+ * than what the hypervisor is comfortable with - hence the first
+ * couple of loops may adjust the number of entries we will
+ * want filled (tracked by 'nr').
+ *
+ * N.B. This is a do { } while loop and the right hand side of
+ * the conditional when adjusting will evaluate to false (as
+ * *left is set to zero before the loop. Hence we need this
+ * adjust - even if we reset it at the start of the loop.
+ */
+ if ( adjust )
+ adjust = 0; /* Used when adjusting the 'max_batch_sz' or 'retries'. */
+
+ nr = min(max - *done, max_batch_sz);
+
+ sysctl.u.xsplice.u.list.nr = nr;
+ /* Fix the size (may vary between hypercalls). */
+ HYPERCALL_BOUNCE_SET_SIZE(info, nr * sizeof(*info));
+ HYPERCALL_BOUNCE_SET_SIZE(name, nr * nr);
+ HYPERCALL_BOUNCE_SET_SIZE(len, nr * sizeof(*len));
+ /* Move the pointer to proper offset into 'info'. */
+ (HYPERCALL_BUFFER(info))->ubuf = info + *done;
+ (HYPERCALL_BUFFER(name))->ubuf = name + (sz * *done);
+ (HYPERCALL_BUFFER(len))->ubuf = len + *done;
+ /* Allocate memory. */
+ rc = xc_hypercall_bounce_pre(xch, info);
+ if ( rc )
+ break;
+
+ rc = xc_hypercall_bounce_pre(xch, name);
+ if ( rc )
+ break;
+
+ rc = xc_hypercall_bounce_pre(xch, len);
+ if ( rc )
+ break;
+
+ set_xen_guest_handle(sysctl.u.xsplice.u.list.status, info);
+ set_xen_guest_handle(sysctl.u.xsplice.u.list.name, name);
+ set_xen_guest_handle(sysctl.u.xsplice.u.list.len, len);
+
+ rc = do_sysctl(xch, &sysctl);
+ /*
+ * From here on we MUST call xc_hypercall_bounce. If rc < 0 we
+ * end up doing it (outside the loop), so using a break is OK.
+ */
+ if ( rc < 0 && errno == E2BIG )
+ {
+ if ( max_batch_sz <= 1 )
+ break;
+ max_batch_sz >>= 1;
+ adjust = 1; /* For the loop conditional to let us loop again. */
+ /* No memory leaks! */
+ xc_hypercall_bounce_post(xch, info);
+ xc_hypercall_bounce_post(xch, name);
+ xc_hypercall_bounce_post(xch, len);
+ continue;
+ }
+ else if ( rc < 0 ) /* For all other errors we bail out. */
+ break;
+
+ if ( !version )
+ version = sysctl.u.xsplice.u.list.version;
+
+ if ( sysctl.u.xsplice.u.list.version != version )
+ {
+ /* We could make this configurable as parameter? */
+ if ( retries++ > 3 )
+ {
+ rc = -1;
+ errno = EBUSY;
+ break;
+ }
+ *done = 0; /* Retry from scratch. */
+ version = sysctl.u.xsplice.u.list.version;
+ adjust = 1; /* And make sure we continue in the loop. */
+ /* No memory leaks. */
+ xc_hypercall_bounce_post(xch, info);
+ xc_hypercall_bounce_post(xch, name);
+ xc_hypercall_bounce_post(xch, len);
+ continue;
+ }
+
+ /* We should never hit this, but just in case. */
+ if ( rc > nr )
+ {
+ errno = EOVERFLOW; /* Overflow! */
+ rc = -1;
+ break;
+ }
+ *left = sysctl.u.xsplice.u.list.nr; /* Total remaining count. */
+ /* Copy only up 'rc' of data' - we could add 'min(rc,nr) if desired. */
+ HYPERCALL_BOUNCE_SET_SIZE(info, (rc * sizeof(*info)));
+ HYPERCALL_BOUNCE_SET_SIZE(name, (rc * sz));
+ HYPERCALL_BOUNCE_SET_SIZE(len, (rc * sizeof(*len)));
+ /* Bounce the data and free the bounce buffer. */
+ xc_hypercall_bounce_post(xch, info);
+ xc_hypercall_bounce_post(xch, name);
+ xc_hypercall_bounce_post(xch, len);
+ /* And update how many elements of info we have copied into. */
+ *done += rc;
+ /* Update idx. */
+ sysctl.u.xsplice.u.list.idx = *done;
+ } while ( adjust || (*done < max && *left != 0) );
+
+ if ( rc < 0 )
+ {
+ xc_hypercall_bounce_post(xch, len);
+ xc_hypercall_bounce_post(xch, name);
+ xc_hypercall_bounce_post(xch, info);
+ }
+
+ return rc > 0 ? 0 : rc;
+}
+
+static int _xc_xsplice_action(xc_interface *xch,
+ char *name,
+ unsigned int action,
+ uint32_t timeout)
+{
+ int rc;
+ DECLARE_SYSCTL;
+ /* The size is figured out when we strlen(name) */
+ DECLARE_HYPERCALL_BOUNCE(name, 0, XC_HYPERCALL_BUFFER_BOUNCE_IN);
+ xen_xsplice_name_t def_name = { .pad = { 0, 0, 0 } };
+
+ def_name.size = strlen(name) + 1;
+
+ if ( def_name.size > XEN_XSPLICE_NAME_SIZE )
+ return -1;
+
+ HYPERCALL_BOUNCE_SET_SIZE(name, def_name.size);
+
+ if ( xc_hypercall_bounce_pre(xch, name) )
+ return -1;
+
+ sysctl.cmd = XEN_SYSCTL_xsplice_op;
+ sysctl.u.xsplice.cmd = XEN_SYSCTL_XSPLICE_ACTION;
+ sysctl.u.xsplice.pad = 0;
+ sysctl.u.xsplice.u.action.cmd = action;
+ sysctl.u.xsplice.u.action.timeout = timeout;
+
+ sysctl.u.xsplice.u.action.name = def_name;
+ set_xen_guest_handle(sysctl.u.xsplice.u.action.name.name, name);
+
+ rc = do_sysctl(xch, &sysctl);
+
+ xc_hypercall_bounce_post(xch, name);
+
+ return rc;
+}
+
+int xc_xsplice_apply(xc_interface *xch, char *name, uint32_t timeout)
+{
+ return _xc_xsplice_action(xch, name, XSPLICE_ACTION_APPLY, timeout);
+}
+
+int xc_xsplice_revert(xc_interface *xch, char *name, uint32_t timeout)
+{
+ return _xc_xsplice_action(xch, name, XSPLICE_ACTION_REVERT, timeout);
+}
+
+int xc_xsplice_unload(xc_interface *xch, char *name, uint32_t timeout)
+{
+ return _xc_xsplice_action(xch, name, XSPLICE_ACTION_UNLOAD, timeout);
+}
+
+int xc_xsplice_check(xc_interface *xch, char *name, uint32_t timeout)
+{
+ return _xc_xsplice_action(xch, name, XSPLICE_ACTION_CHECK, timeout);
+}
+
+int xc_xsplice_replace(xc_interface *xch, char *name, uint32_t timeout)
+{
+ return _xc_xsplice_action(xch, name, XSPLICE_ACTION_REPLACE, timeout);
+}
+
/*
* Local variables:
* mode: C
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 08/28] xen-xsplice: Tool to manipulate xsplice payloads
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (6 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 07/28] libxc: Implementation of XEN_XSPLICE_op in libxc Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 09/28] xsplice: Add helper elf routines Konrad Rzeszutek Wilk
` (19 subsequent siblings)
27 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Stefano Stabellini, Ian Jackson, Konrad Rzeszutek Wilk
A simple tool that allows an system admin to perform
basic xsplice operations:
- Upload a xsplice file (with an unique name)
- List all the xsplice payloads loaded.
- Apply, revert, replace, or unload the payload using the
unique name.
- Do all two - upload, and apply the payload in one go (load).
Also will use the name of the file as the <name>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
v2:
- Removed REVERTED state.
- Fixed bugs handling XSPLICE_STATUS_PROGRESS.
- Split status into state and error.
Add REPLACE action.
v3:
- Utilize the timeout and use the default one (let the hypervisor
pick it).
- Change the s/all/load and infer the <id> from name of file.
- s/id/name/
- Don't use hypercall buffer in upload_func, instead do it in libxc
- Remove the debug printk.
- Remove goto's (per Wei's review)
- Use fprintf(stderr in error paths.
- Add local variable block.
- Syntax, expand comment, and don't overwrite rc if xc_xsplice_upload failed.
v4:
- Remove LOADED state. Only have CHECKED state.
---
.gitignore | 1 +
tools/misc/Makefile | 4 +
tools/misc/xen-xsplice.c | 463 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 468 insertions(+)
create mode 100644 tools/misc/xen-xsplice.c
diff --git a/.gitignore b/.gitignore
index b40453e..b9c9550 100644
--- a/.gitignore
+++ b/.gitignore
@@ -181,6 +181,7 @@ tools/misc/xc_shadow
tools/misc/xen_cpuperf
tools/misc/xen-detect
tools/misc/xen-tmem-list-parse
+tools/misc/xen-xsplice
tools/misc/xenperf
tools/misc/xenpm
tools/misc/xen-hvmctx
diff --git a/tools/misc/Makefile b/tools/misc/Makefile
index a2ef0ec..e1956f6 100644
--- a/tools/misc/Makefile
+++ b/tools/misc/Makefile
@@ -31,6 +31,7 @@ INSTALL_SBIN += xenlockprof
INSTALL_SBIN += xenperf
INSTALL_SBIN += xenpm
INSTALL_SBIN += xenwatchdogd
+INSTALL_SBIN += xen-xsplice
INSTALL_SBIN += $(INSTALL_SBIN-y)
# Everything to be installed in a private bin/
@@ -99,6 +100,9 @@ xen-mfndump: xen-mfndump.o
xenwatchdogd: xenwatchdogd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+xen-xsplice: xen-xsplice.o
+ $(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenctrl) $(APPEND_LDFLAGS)
+
xen-lowmemd: xen-lowmemd.o
$(CC) $(LDFLAGS) -o $@ $< $(LDLIBS_libxenevtchn) $(LDLIBS_libxenctrl) $(LDLIBS_libxenstore) $(APPEND_LDFLAGS)
diff --git a/tools/misc/xen-xsplice.c b/tools/misc/xen-xsplice.c
new file mode 100644
index 0000000..fb9228e
--- /dev/null
+++ b/tools/misc/xen-xsplice.c
@@ -0,0 +1,463 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ */
+
+#include <fcntl.h>
+#include <libgen.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <unistd.h>
+#include <xenctrl.h>
+#include <xenstore.h>
+
+static xc_interface *xch;
+
+void show_help(void)
+{
+ fprintf(stderr,
+ "xen-xsplice: Xsplice test tool\n"
+ "Usage: xen-xsplice <command> [args]\n"
+ " <name> An unique name of payload. Up to %d characters.\n"
+ "Commands:\n"
+ " help display this help\n"
+ " upload <name> <file> upload file <file> with <name> name\n"
+ " list list payloads uploaded.\n"
+ " apply <name> apply <name> patch.\n"
+ " revert <name> revert name <name> patch.\n"
+ " replace <name> apply <name> patch and revert all others.\n"
+ " unload <name> unload name <name> patch.\n"
+ " load <file> upload, check and apply <file>.\n"
+ " name is the <file> name\n",
+ XEN_XSPLICE_NAME_SIZE);
+}
+
+/* wrapper function */
+static int help_func(int argc, char *argv[])
+{
+ show_help();
+ return 0;
+}
+
+#define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0]))
+
+static const char *state2str(unsigned int state)
+{
+#define STATE(x) [XSPLICE_STATE_##x] = #x
+ static const char *const names[] = {
+ STATE(CHECKED),
+ STATE(APPLIED),
+ };
+#undef STATE
+ if (state >= ARRAY_SIZE(names) || !names[state])
+ return "unknown";
+
+ return names[state];
+}
+
+/* This value was choosen adhoc. It could be 42 too. */
+#define MAX_LEN 11
+static int list_func(int argc, char *argv[])
+{
+ unsigned int idx, done, left, i;
+ xen_xsplice_status_t *info = NULL;
+ char *name = NULL;
+ uint32_t *len = NULL;
+ int rc = ENOMEM;
+
+ if ( argc )
+ {
+ show_help();
+ return -1;
+ }
+ idx = left = 0;
+ info = malloc(sizeof(*info) * MAX_LEN);
+ if ( !info )
+ return rc;
+ name = malloc(sizeof(*name) * XEN_XSPLICE_NAME_SIZE * MAX_LEN);
+ if ( !name )
+ {
+ free(info);
+ return rc;
+ }
+ len = malloc(sizeof(*len) * MAX_LEN);
+ if ( !len ) {
+ free(name);
+ free(info);
+ return rc;
+ }
+
+ fprintf(stdout," ID | status\n"
+ "----------------------------------------+------------\n");
+ do {
+ done = 0;
+ /* The memset is done to catch errors. */
+ memset(info, 'A', sizeof(*info) * MAX_LEN);
+ memset(name, 'B', sizeof(*name * MAX_LEN * XEN_XSPLICE_NAME_SIZE));
+ memset(len, 'C', sizeof(*len) * MAX_LEN);
+ rc = xc_xsplice_list(xch, MAX_LEN, idx, info, name, len, &done, &left);
+ if ( rc )
+ {
+ fprintf(stderr, "Failed to list %d/%d: %d(%s)!\n",
+ idx, left, errno, strerror(errno));
+ break;
+ }
+ for ( i = 0; i < done; i++ )
+ {
+ unsigned int j;
+ uint32_t sz;
+ char *str;
+
+ sz = len[i];
+ str = name + (i * XEN_XSPLICE_NAME_SIZE);
+ for ( j = sz; j < XEN_XSPLICE_NAME_SIZE; j++ )
+ str[j] = '\0';
+
+ printf("%-40s| %s", str, state2str(info[i].state));
+ if ( info[i].rc )
+ printf(" (%d, %s)\n", -info[i].rc, strerror(-info[i].rc));
+ else
+ puts("");
+ }
+ idx += done;
+ } while ( left );
+
+ free(name);
+ free(info);
+ free(len);
+ return rc;
+}
+#undef MAX_LEN
+
+static int get_name(int argc, char *argv[], char *name)
+{
+ ssize_t len = strlen(argv[0]);
+ if ( len > XEN_XSPLICE_NAME_SIZE )
+ {
+ fprintf(stderr, "ID MUST be %d characters!\n", XEN_XSPLICE_NAME_SIZE);
+ errno = EINVAL;
+ return errno;
+ }
+ /* Don't want any funny strings from the stack. */
+ memset(name, 0, XEN_XSPLICE_NAME_SIZE);
+ strncpy(name, argv[0], len);
+ return 0;
+}
+
+static int upload_func(int argc, char *argv[])
+{
+ char *filename;
+ char name[XEN_XSPLICE_NAME_SIZE];
+ int fd = 0, rc;
+ struct stat buf;
+ unsigned char *fbuf;
+ ssize_t len;
+
+ if ( argc != 2 )
+ {
+ show_help();
+ return -1;
+ }
+
+ if ( get_name(argc, argv, name) )
+ return EINVAL;
+
+ filename = argv[1];
+ fd = open(filename, O_RDONLY);
+ if ( fd < 0 )
+ {
+ fprintf(stderr, "Could not open %s, error: %d(%s)\n",
+ filename, errno, strerror(errno));
+ return errno;
+ }
+ if ( stat(filename, &buf) != 0 )
+ {
+ fprintf(stderr, "Could not get right size %s, error: %d(%s)\n",
+ filename, errno, strerror(errno));
+ close(fd);
+ return errno;
+ }
+
+ len = buf.st_size;
+ fbuf = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, 0);
+ if ( fbuf == MAP_FAILED )
+ {
+ fprintf(stderr,"Could not map: %s, error: %d(%s)\n",
+ filename, errno, strerror(errno));
+ close (fd);
+ return errno;
+ }
+ printf("Uploading %s (%zu bytes)\n", filename, len);
+ rc = xc_xsplice_upload(xch, name, fbuf, len);
+ if ( rc )
+ fprintf(stderr, "Upload failed: %s, error: %d(%s)!\n",
+ filename, errno, strerror(errno));
+
+ if ( munmap( fbuf, len) )
+ {
+ fprintf(stderr, "Could not unmap!? error: %d(%s)!\n",
+ errno, strerror(errno));
+ if ( !rc )
+ rc = errno;
+ }
+ close(fd);
+
+ return rc;
+}
+
+/* These MUST match to the 'action_options[]' array slots. */
+enum {
+ ACTION_APPLY = 0,
+ ACTION_REVERT = 1,
+ ACTION_UNLOAD = 2,
+ ACTION_REPLACE = 3,
+};
+
+struct {
+ int allow; /* State it must be in to call function. */
+ int expected; /* The state to be in after the function. */
+ const char *name;
+ int (*function)(xc_interface *xch, char *name, uint32_t timeout);
+ unsigned int executed; /* Has the function been called?. */
+} action_options[] = {
+ { .allow = XSPLICE_STATE_CHECKED,
+ .expected = XSPLICE_STATE_APPLIED,
+ .name = "apply",
+ .function = xc_xsplice_apply,
+ },
+ { .allow = XSPLICE_STATE_APPLIED,
+ .expected = XSPLICE_STATE_CHECKED,
+ .name = "revert",
+ .function = xc_xsplice_revert,
+ },
+ { .allow = XSPLICE_STATE_CHECKED,
+ .expected = -ENOENT,
+ .name = "unload",
+ .function = xc_xsplice_unload,
+ },
+ { .allow = XSPLICE_STATE_CHECKED,
+ .expected = XSPLICE_STATE_APPLIED,
+ .name = "replace",
+ .function = xc_xsplice_replace,
+ },
+};
+
+/* Go around 300 * 0.1 seconds = 30 seconds. */
+#define RETRIES 300
+/* aka 0.1 second */
+#define DELAY 100000
+
+int action_func(int argc, char *argv[], unsigned int idx)
+{
+ char name[XEN_XSPLICE_NAME_SIZE];
+ int rc, original_state;
+ xen_xsplice_status_t status;
+ unsigned int retry = 0;
+
+ if ( argc != 1 )
+ {
+ show_help();
+ return -1;
+ }
+
+ if ( idx >= ARRAY_SIZE(action_options) )
+ return -1;
+
+ if ( get_name(argc, argv, name) )
+ return EINVAL;
+
+ /* Check initial status. */
+ rc = xc_xsplice_get(xch, name, &status);
+ if ( rc )
+ {
+ fprintf(stderr, "%s failed to get status (rc=%d, %s)!\n",
+ name, -rc, strerror(-rc));
+ return -1;
+ }
+ if ( status.rc == -EAGAIN )
+ {
+ fprintf(stderr, "%s failed. Operation already in progress\n", name);
+ return -1;
+ }
+
+ if ( status.state == action_options[idx].expected )
+ {
+ printf("No action needed\n");
+ return 0;
+ }
+
+ /* Perform action. */
+ if ( action_options[idx].allow & status.state )
+ {
+ printf("Performing %s:", action_options[idx].name);
+ rc = action_options[idx].function(xch, name, 0);
+ if ( rc )
+ {
+ fprintf(stderr, "%s failed with %d(%s)\n", name, -rc, strerror(-rc));
+ return -1;
+ }
+ }
+ else
+ {
+ printf("%s: in wrong state (%s), expected (%s)\n",
+ name, state2str(status.state),
+ state2str(action_options[idx].expected));
+ return -1;
+ }
+
+ original_state = status.state;
+ do {
+ rc = xc_xsplice_get(xch, name, &status);
+ if ( rc )
+ {
+ rc = -errno;
+ break;
+ }
+
+ if ( status.state != original_state )
+ break;
+ if ( status.rc && status.rc != -EAGAIN )
+ {
+ rc = status.rc;
+ break;
+ }
+
+ printf(".");
+ fflush(stdout);
+ usleep(DELAY);
+ } while ( ++retry < RETRIES );
+
+ if ( retry >= RETRIES )
+ {
+ fprintf(stderr, "%s: Operation didn't complete after 30 seconds.\n", name);
+ return -1;
+ }
+ else
+ {
+ if ( rc == 0 )
+ rc = status.state;
+
+ if ( action_options[idx].expected == rc )
+ printf(" completed\n");
+ else if ( rc < 0 )
+ {
+ fprintf(stderr, "%s failed with %d(%s)\n", name, -rc, strerror(-rc));
+ return -1;
+ }
+ else
+ {
+ fprintf(stderr, "%s: in wrong state (%s), expected (%s)\n",
+ name, state2str(rc),
+ state2str(action_options[idx].expected));
+ return -1;
+ }
+ }
+
+ return 0;
+}
+
+static int load_func(int argc, char *argv[])
+{
+ int rc;
+ char *new_argv[2];
+ char *path, *name, *lastdot;
+
+ if ( argc != 1 )
+ {
+ show_help();
+ return -1;
+ }
+ /* <file> */
+ new_argv[1] = argv[0];
+
+ /* Synthesize the <id> */
+ path = strdup(argv[0]);
+
+ name = basename(path);
+ lastdot = strrchr(name, '.');
+ if ( lastdot != NULL )
+ *lastdot = '\0';
+ new_argv[0] = name;
+
+ rc = upload_func(2 /* <id> <file> */, new_argv);
+ if ( rc )
+ return rc;
+
+ rc = action_func(1 /* only <id> */, new_argv, ACTION_APPLY);
+ if ( rc )
+ action_func(1, new_argv, ACTION_UNLOAD);
+
+ free(path);
+ return rc;
+}
+
+/*
+ * These are also functions in action_options that are called in case
+ * none of the ones in main_options match.
+ */
+struct {
+ const char *name;
+ int (*function)(int argc, char *argv[]);
+} main_options[] = {
+ { "help", help_func },
+ { "list", list_func },
+ { "upload", upload_func },
+ { "load", load_func },
+};
+
+int main(int argc, char *argv[])
+{
+ int i, j, ret;
+
+ if ( argc <= 1 )
+ {
+ show_help();
+ return 0;
+ }
+ for ( i = 0; i < ARRAY_SIZE(main_options); i++ )
+ if (!strncmp(main_options[i].name, argv[1], strlen(argv[1])))
+ break;
+
+ if ( i == ARRAY_SIZE(main_options) )
+ {
+ for ( j = 0; j < ARRAY_SIZE(action_options); j++ )
+ if (!strncmp(action_options[j].name, argv[1], strlen(argv[1])))
+ break;
+
+ if ( j == ARRAY_SIZE(action_options) )
+ {
+ fprintf(stderr, "Unrecognised command '%s' -- try "
+ "'xen-xsplice help'\n", argv[1]);
+ return 1;
+ }
+ } else
+ j = ARRAY_SIZE(action_options);
+
+ xch = xc_interface_open(0,0,0);
+ if ( !xch )
+ {
+ fprintf(stderr, "failed to get the handler\n");
+ return 0;
+ }
+
+ if ( i == ARRAY_SIZE(main_options) )
+ ret = action_func(argc -2, argv + 2, j);
+ else
+ ret = main_options[i].function(argc -2, argv + 2);
+
+ xc_interface_close(xch);
+
+ return !!ret;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 09/28] xsplice: Add helper elf routines
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (7 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 08/28] xen-xsplice: Tool to manipulate xsplice payloads Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-31 12:03 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 10/28] xsplice: Implement payload loading Konrad Rzeszutek Wilk
` (18 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Add Elf routines and data structures in preparation for loading an
xSplice payload.
We make an assumption that the max number of sections an ELF payload
can have is 64. We can in future make this be dependent on the
names of the sections and verifying against a list, but for right now
this suffices.
Also we a whole lot of checks to make sure that the ELF payload
file is not corrupted nor that the offsets point past the file.
For most of the checks we print an message if the hypervisor is built
with debug enabled.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v2: - With the #define ELFSIZE in the ARM file we can use the common
#defines instead of using #ifdef CONFIG_ARM_32. Moved to another
patch.
- Add checks for ELF file.
- Add name to be printed.
- Add len for easier ELF checks.
- Expand on the checks. Add macro.
v3: Remove the return_ macro
- Add return_ macro back but make it depend on debug=y
- Per Andrew review: add local variable. Fix memory leak in
elf_resolve_sections, Remove macro and use dprintk. Fix alignment.
Use void* instead of uint8_t to handle raw payload.
v4 - Fix memory leak in elf_get_sym
- Add XSPLICE to printk/dprintk
v5: Sprinkle newlines.
---
xen/common/Makefile | 1 +
xen/common/xsplice_elf.c | 294 ++++++++++++++++++++++++++++++++++++++++++
xen/include/xen/xsplice.h | 3 +
xen/include/xen/xsplice_elf.h | 51 ++++++++
4 files changed, 349 insertions(+)
create mode 100644 xen/common/xsplice_elf.c
create mode 100644 xen/include/xen/xsplice_elf.h
diff --git a/xen/common/Makefile b/xen/common/Makefile
index 1e4bc70..afd84b6 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -59,6 +59,7 @@ obj-y += wait.o
obj-$(CONFIG_XENOPROF) += xenoprof.o
obj-y += xmalloc_tlsf.o
obj-$(CONFIG_XSPLICE) += xsplice.o
+obj-$(CONFIG_XSPLICE) += xsplice_elf.o
obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
new file mode 100644
index 0000000..f22cede
--- /dev/null
+++ b/xen/common/xsplice_elf.c
@@ -0,0 +1,294 @@
+/*
+ * Copyright (C) 2016 Citrix Systems R&D Ltd.
+ */
+
+#include <xen/errno.h>
+#include <xen/lib.h>
+#include <xen/xsplice_elf.h>
+#include <xen/xsplice.h>
+
+struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf *elf,
+ const char *name)
+{
+ unsigned int i;
+
+ for ( i = 0; i < elf->hdr->e_shnum; i++ )
+ {
+ if ( !strcmp(name, elf->sec[i].name) )
+ return &elf->sec[i];
+ }
+
+ return NULL;
+}
+
+static int elf_resolve_sections(struct xsplice_elf *elf, const void *data)
+{
+ struct xsplice_elf_sec *sec;
+ unsigned int i;
+
+ /* xsplice_elf_load sanity checked e_shnum checked. */
+ sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
+ if ( !sec )
+ {
+ printk(XENLOG_ERR "%s%s: Could not allocate memory for section table!\n",
+ XSPLICE, elf->name);
+ return -ENOMEM;
+ }
+
+ elf->sec = sec;
+
+ /* N.B. We also will ingest SHN_UNDEF sections. */
+ for ( i = 0; i < elf->hdr->e_shnum; i++ )
+ {
+ ssize_t delta = elf->hdr->e_shoff + i * elf->hdr->e_shentsize;
+
+ if ( delta + sizeof(Elf_Shdr) > elf->len )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Section header [%d] is past end of payload!\n",
+ XSPLICE, elf->name, i);
+ return -EINVAL;
+ }
+
+ sec[i].sec = (Elf_Shdr *)(data + delta);
+ delta = sec[i].sec->sh_offset;
+
+ if ( delta > elf->len )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Section [%d] data is past end of payload!\n",
+ XSPLICE, elf->name, i);
+ return -EINVAL;
+ }
+
+ sec[i].data = data + delta;
+ /* Name is populated in xsplice_elf_sections_name. */
+ sec[i].name = NULL;
+
+ if ( sec[i].sec->sh_type == SHT_SYMTAB )
+ {
+ if ( elf->symtab )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Multiple symbol tables!\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ elf->symtab = &sec[i];
+
+ /*
+ * elf->symtab->sec->sh_link would point to the right section
+ * but we hadn't finished parsing all the sections.
+ */
+ if ( elf->symtab->sec->sh_link > elf->hdr->e_shnum )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Symbol table idx (%d) to strtab past end (%d)\n",
+ XSPLICE, elf->name, elf->symtab->sec->sh_link,
+ elf->hdr->e_shnum);
+ return -EINVAL;
+ }
+ }
+ }
+
+ if ( !elf->symtab )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: No symbol table found!\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ /* There can be multiple SHT_STRTAB so pick the right one. */
+ elf->strtab = &sec[elf->symtab->sec->sh_link];
+
+ if ( !elf->symtab->sec->sh_size || !elf->symtab->sec->sh_entsize ||
+ elf->symtab->sec->sh_entsize != sizeof(Elf_Sym) )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Symbol table header is corrupted!\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int elf_resolve_section_names(struct xsplice_elf *elf, const void *data)
+{
+ const char *shstrtab;
+ unsigned int i;
+ unsigned int offset, delta;
+
+ /*
+ * The elf->sec[0 -> e_shnum] structures have been verified by
+ * elf_resolve_sections. Find file offset for section string table.
+ */
+ offset = elf->sec[elf->hdr->e_shstrndx].sec->sh_offset;
+
+ if ( offset > elf->len )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: shstrtab section offset (%u) past end of payload!\n",
+ XSPLICE, elf->name, elf->hdr->e_shstrndx);
+ return -EINVAL;
+ }
+
+ shstrtab = (data + offset);
+
+ /* We could ignore the first as it is reserved.. */
+ for ( i = 0; i < elf->hdr->e_shnum; i++ )
+ {
+ delta = elf->sec[i].sec->sh_name;
+
+ if ( offset + delta > elf->len )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: shstrtab [%d] data is past end of payload!\n",
+ XSPLICE, elf->name, i);
+ return -EINVAL;
+ }
+
+ elf->sec[i].name = shstrtab + delta;
+ }
+
+ return 0;
+}
+
+static int elf_get_sym(struct xsplice_elf *elf, const void *data)
+{
+ struct xsplice_elf_sec *symtab_sec, *strtab_sec;
+ struct xsplice_elf_sym *sym;
+ unsigned int i, delta, offset, nsym;
+
+ symtab_sec = elf->symtab;
+ strtab_sec = elf->strtab;
+
+ /* Pointers arithmetic to get file offset. */
+ offset = strtab_sec->data - data;
+
+ ASSERT(offset == strtab_sec->sec->sh_offset);
+
+ /* symtab_sec->data was computed in elf_resolve_sections. */
+ ASSERT((symtab_sec->sec->sh_offset + data) == symtab_sec->data);
+
+ /* No need to check values as elf_resolve_sections did it. */
+ nsym = symtab_sec->sec->sh_size / symtab_sec->sec->sh_entsize;
+
+ sym = xmalloc_array(struct xsplice_elf_sym, nsym);
+ if ( !sym )
+ {
+ printk(XENLOG_ERR "%s%s: Could not allocate memory for symbols\n",
+ XSPLICE, elf->name);
+ return -ENOMEM;
+ }
+
+ /* So we don't leak memory. */
+ elf->sym = sym;
+ for ( i = 0; i < nsym; i++ )
+ {
+ Elf_Sym *s;
+
+ if ( i * sizeof(Elf_Sym) > elf->len )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Symbol header [%d] is past end of payload!\n",
+ XSPLICE, elf->name, i);
+ return -EINVAL;
+ }
+
+ s = &((Elf_Sym *)symtab_sec->data)[i];
+
+ /* If st->name is STN_UNDEF is zero, the check will always be true. */
+ delta = s->st_name;
+
+ /* Offset has been computed earlier. */
+ if ( offset + delta > elf->len )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Symbol [%u] data is past end of payload!\n",
+ XSPLICE, elf->name, i);
+ return -EINVAL;
+ }
+
+ sym[i].sym = s;
+ if ( s->st_name == STN_UNDEF )
+ sym[i].name = NULL;
+ else
+ sym[i].name = data + ( delta + offset );
+ }
+ elf->nsym = nsym;
+
+ return 0;
+}
+
+static int xsplice_header_check(const struct xsplice_elf *elf)
+{
+ if ( sizeof(*elf->hdr) >= elf->len )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Section header is bigger than payload!\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ if ( elf->hdr->e_shstrndx == SHN_UNDEF )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Section name idx is undefined!?\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ /* Check that section name index is within the sections. */
+ if ( elf->hdr->e_shstrndx > elf->hdr->e_shnum )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Section name idx (%d) is past end of sections (%d)!\n",
+ XSPLICE, elf->name, elf->hdr->e_shstrndx, elf->hdr->e_shnum);
+ return -EINVAL;
+ }
+
+ if ( elf->hdr->e_shnum > 64 )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Too many (%d) sections!\n",
+ XSPLICE, elf->name, elf->hdr->e_shnum);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+int xsplice_elf_load(struct xsplice_elf *elf, void *data)
+{
+ int rc;
+
+ elf->hdr = data;
+
+ rc = xsplice_header_check(elf);
+ if ( rc )
+ return rc;
+
+ rc = elf_resolve_sections(elf, data);
+ if ( rc )
+ return rc;
+
+ rc = elf_resolve_section_names(elf, data);
+ if ( rc )
+ return rc;
+
+ rc = elf_get_sym(elf, data);
+ if ( rc )
+ return rc;
+
+ return 0;
+}
+
+void xsplice_elf_free(struct xsplice_elf *elf)
+{
+ xfree(elf->sec);
+ elf->sec = NULL;
+ xfree(elf->sym);
+ elf->sym = NULL;
+ elf->nsym = 0;
+ elf->name = NULL;
+ elf->len = 0;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
index 5c84851..00482d0 100644
--- a/xen/include/xen/xsplice.h
+++ b/xen/include/xen/xsplice.h
@@ -10,6 +10,9 @@ struct xen_sysctl_xsplice_op;
#ifdef CONFIG_XSPLICE
+/* Convenience define for printk. */
+#define XSPLICE "xsplice: "
+
int xsplice_op(struct xen_sysctl_xsplice_op *);
#else
diff --git a/xen/include/xen/xsplice_elf.h b/xen/include/xen/xsplice_elf.h
new file mode 100644
index 0000000..e2dea18
--- /dev/null
+++ b/xen/include/xen/xsplice_elf.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2016 Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_XSPLICE_ELF_H__
+#define __XEN_XSPLICE_ELF_H__
+
+#include <xen/types.h>
+#include <xen/elfstructs.h>
+
+/* The following describes an Elf file as consumed by xSplice. */
+struct xsplice_elf_sec {
+ Elf_Shdr *sec; /* Hooked up in elf_resolve_sections. */
+ const char *name; /* Human readable name hooked in
+ elf_resolve_section_names. */
+ const void *data; /* Pointer to the section (done by
+ elf_resolve_sections). */
+};
+
+struct xsplice_elf_sym {
+ Elf_Sym *sym;
+ const char *name;
+};
+
+struct xsplice_elf {
+ const char *name; /* Pointer to payload->name. */
+ ssize_t len; /* Length of the ELF file. */
+ Elf_Ehdr *hdr; /* ELF file. */
+ struct xsplice_elf_sec *sec; /* Array of sections, allocated by us. */
+ struct xsplice_elf_sym *sym; /* Array of symbols , allocated by us. */
+ unsigned int nsym;
+ struct xsplice_elf_sec *symtab;/* Pointer to .symtab section - aka to sec[x]. */
+ struct xsplice_elf_sec *strtab;/* Pointer to .strtab section - aka to sec[y]. */
+};
+
+struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf *elf,
+ const char *name);
+int xsplice_elf_load(struct xsplice_elf *elf, void *data);
+void xsplice_elf_free(struct xsplice_elf *elf);
+
+#endif /* __XEN_XSPLICE_ELF_H__ */
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 10/28] xsplice: Implement payload loading
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (8 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 09/28] xsplice: Add helper elf routines Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-31 13:45 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches Konrad Rzeszutek Wilk
` (17 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Julien Grall, Stefano Stabellini, Jan Beulich,
Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Add support for loading xsplice payloads. This is somewhat similar to
the Linux kernel module loader, implementing the following steps:
- Verify the elf file.
- Parse the elf file.
- Allocate a region of memory mapped within a free area of
[xen_virt_end, XEN_VIRT_END].
- Copy allocated sections into the new region. Split them in three
regions - .text, .data, and .rodata. MUST have at least .text.
- Resolve section symbols. All other symbols must be absolute addresses.
(Note that patch titled "xsplice,symbols: Implement symbol name resolution
on address" implements that)
- Perform relocations.
- Secure the the regions (.text,.data,.rodata) with proper permissions.
We capitalize on the vmalloc callback API (see patch titled:
"vmap: Add vmalloc_cb and vfree_cb") to allocate a region
of memory within the [xen_virt_end, XEN_VIRT_END] for the code.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v2: - Change the 'xsplice_patch_func' structure layout/size.
- Add more error checking. Fix memory leak.
- Move elf_resolve and elf_perform relocs in elf file.
- Print the payload address and pages in keyhandler.
v3:
- Make it build under ARM
- Build it without using the return_ macro.
- Add fixes from Ross.
- Add the _return macro back - but only use it during debug builds.
- Remove the macro, prefix arch_ on arch specific calls.
v4:
- Move alloc_payload to arch specific file.
- Use void* instead of uint8_t, use const
- Add copyrights
- Unroll the vmap code to add ASSERT. Change while to not incur
potential long error loop
- Use vmalloc/vfree cb APIs
- Secure .text pages to be RX instead of RWX.
v5:
- Fix allocation of virtual addresses only allowing one page to be allocated.
- Create .text, .data, and .rodata regions with different permissions.
- Make the find_space_t not a typedef to pointer to a function.
- Allocate memory in here.
---
---
xen/arch/arm/Makefile | 1 +
xen/arch/arm/xsplice.c | 55 ++++++++
xen/arch/x86/Makefile | 1 +
xen/arch/x86/setup.c | 7 +
xen/arch/x86/xsplice.c | 258 +++++++++++++++++++++++++++++++++++++
xen/common/xsplice.c | 262 +++++++++++++++++++++++++++++++++++++-
xen/common/xsplice_elf.c | 91 +++++++++++++
xen/include/asm-x86/x86_64/page.h | 2 +
xen/include/xen/xsplice.h | 46 +++++++
xen/include/xen/xsplice_elf.h | 5 +
10 files changed, 725 insertions(+), 3 deletions(-)
create mode 100644 xen/arch/arm/xsplice.c
create mode 100644 xen/arch/x86/xsplice.c
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 0328b50..eae5cb3 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -40,6 +40,7 @@ obj-y += device.o
obj-y += decode.o
obj-y += processor.o
obj-y += smc.o
+obj-$(CONFIG_XSPLICE) += xsplice.o
#obj-bin-y += ....o
diff --git a/xen/arch/arm/xsplice.c b/xen/arch/arm/xsplice.c
new file mode 100644
index 0000000..e9c49ab
--- /dev/null
+++ b/xen/arch/arm/xsplice.c
@@ -0,0 +1,55 @@
+/*
+ * Copyright (C) 2016 Citrix Systems R&D Ltd.
+ */
+#include <xen/lib.h>
+#include <xen/errno.h>
+#include <xen/xsplice_elf.h>
+#include <xen/xsplice.h>
+
+int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data)
+{
+ return -ENOSYS;
+}
+
+int arch_xsplice_perform_rel(struct xsplice_elf *elf,
+ const struct xsplice_elf_sec *base,
+ const struct xsplice_elf_sec *rela)
+{
+ return -ENOSYS;
+}
+
+int arch_xsplice_perform_rela(struct xsplice_elf *elf,
+ const struct xsplice_elf_sec *base,
+ const struct xsplice_elf_sec *rela)
+{
+ return -ENOSYS;
+}
+
+void *arch_xsplice_alloc_payload(unsigned int pages, mfn_t **mfn)
+{
+ return NULL;
+}
+
+int arch_xsplice_secure(void *va, unsigned int pages, enum va_type type,
+ const mfn_t *mfn)
+{
+ return -ENOSYS;
+}
+
+void arch_xsplice_register_find_space(find_space_t *cb)
+{
+}
+
+void arch_xsplice_free_payload(void *va, unsigned int pages)
+{
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 729065b..8a6a7d5 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -64,6 +64,7 @@ obj-y += vm_event.o
obj-y += xstate.o
obj-$(crash_debug) += gdbstub.o
+obj-$(CONFIG_XSPLICE) += xsplice.o
x86_emulate.o: x86_emulate/x86_emulate.c x86_emulate/x86_emulate.h
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index c8a5adb..b306da8 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -100,6 +100,9 @@ unsigned long __read_mostly xen_phys_start;
unsigned long __read_mostly xen_virt_end;
+unsigned long __read_mostly avail_virt_start;
+unsigned long __read_mostly avail_virt_end;
+
DEFINE_PER_CPU(struct tss_struct, init_tss);
char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE];
@@ -1211,6 +1214,10 @@ void __init noreturn __start_xen(unsigned long mbi_p)
~((1UL << L2_PAGETABLE_SHIFT) - 1);
destroy_xen_mappings(xen_virt_end, XEN_VIRT_START + BOOTSTRAP_MAP_BASE);
+ avail_virt_start = xen_virt_end;
+ avail_virt_end = XEN_VIRT_END - NR_CPUS * PAGE_SIZE;
+ BUG_ON(avail_virt_end <= avail_virt_start);
+
/*
* If not using 2M mappings to gain suitable pagetable permissions
* directly from the relocation above, remap the code/data
diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
new file mode 100644
index 0000000..7149540
--- /dev/null
+++ b/xen/arch/x86/xsplice.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright (C) 2016 Citrix Systems R&D Ltd.
+ */
+
+#include <xen/errno.h>
+#include <xen/lib.h>
+#include <xen/mm.h>
+#include <xen/pfn.h>
+#include <xen/vmap.h>
+#include <xen/xsplice_elf.h>
+#include <xen/xsplice.h>
+
+int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data)
+{
+
+ Elf_Ehdr *hdr = data;
+
+ if ( !IS_ELF(*hdr) )
+ {
+ printk(XENLOG_ERR "%s%s: Not an ELF payload!\n", XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ if ( elf->len < (sizeof *hdr) ||
+ !IS_ELF(*hdr) ||
+ hdr->e_ident[EI_CLASS] != ELFCLASS64 ||
+ hdr->e_ident[EI_DATA] != ELFDATA2LSB ||
+ hdr->e_ident[EI_OSABI] != ELFOSABI_SYSV ||
+ hdr->e_machine != EM_X86_64 ||
+ hdr->e_type != ET_REL ||
+ hdr->e_phnum != 0 )
+ {
+ printk(XENLOG_ERR "%s%s: Invalid ELF payload!\n", XSPLICE, elf->name);
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+int arch_xsplice_perform_rel(struct xsplice_elf *elf,
+ const struct xsplice_elf_sec *base,
+ const struct xsplice_elf_sec *rela)
+{
+ dprintk(XENLOG_ERR, "%s%s: SHR_REL relocation unsupported\n",
+ XSPLICE, elf->name);
+ return -ENOSYS;
+}
+
+int arch_xsplice_perform_rela(struct xsplice_elf *elf,
+ const struct xsplice_elf_sec *base,
+ const struct xsplice_elf_sec *rela)
+{
+ Elf_RelA *r;
+ unsigned int symndx, i;
+ uint64_t val;
+ uint8_t *dest;
+
+ if ( !rela->sec->sh_entsize || !rela->sec->sh_size ||
+ rela->sec->sh_entsize != sizeof(Elf_RelA) )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Section relative header is corrupted!\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ for ( i = 0; i < (rela->sec->sh_size / rela->sec->sh_entsize); i++ )
+ {
+ r = (Elf_RelA *)(rela->data + i * rela->sec->sh_entsize);
+ if ( (unsigned long)r > (unsigned long)(elf->hdr + elf->len) )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Relative entry %u in %s is past end!\n",
+ XSPLICE, elf->name, i, rela->name);
+ return -EINVAL;
+ }
+
+ symndx = ELF64_R_SYM(r->r_info);
+ if ( symndx > elf->nsym )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Relative symbol wants symbol@%u which is past end!\n",
+ XSPLICE, elf->name, symndx);
+ return -EINVAL;
+ }
+
+ dest = base->load_addr + r->r_offset;
+ val = r->r_addend + elf->sym[symndx].sym->st_value;
+
+ switch ( ELF64_R_TYPE(r->r_info) )
+ {
+ case R_X86_64_NONE:
+ break;
+
+ case R_X86_64_64:
+ *(uint64_t *)dest = val;
+ break;
+
+ case R_X86_64_PLT32:
+ /*
+ * Xen uses -fpic which normally uses PLT relocations
+ * except that it sets visibility to hidden which means
+ * that they are not used. However, when gcc cannot
+ * inline memcpy it emits memcpy with default visibility
+ * which then creates a PLT relocation. It can just be
+ * treated the same as R_X86_64_PC32.
+ */
+ /* Fall through */
+
+ case R_X86_64_PC32:
+ *(uint32_t *)dest = val - (uint64_t)dest;
+ break;
+
+ default:
+ printk(XENLOG_ERR "%s%s: Unhandled relocation %lu\n",
+ XSPLICE, elf->name, ELF64_R_TYPE(r->r_info));
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+static find_space_t *find_space_fnc = NULL;
+
+void arch_xsplice_register_find_space(find_space_t *cb)
+{
+ ASSERT(!find_space_fnc);
+
+ find_space_fnc = cb;
+}
+
+static void* xsplice_map_rwx(const mfn_t *mfn, unsigned int pages)
+{
+ unsigned long cur;
+ unsigned long start, end;
+
+ start = (unsigned long)avail_virt_start;
+ end = start + pages * PAGE_SIZE;
+
+ ASSERT(find_space_fnc);
+
+ if ( find_space_fnc(pages, &start, &end) )
+ return NULL;
+
+ if ( end >= avail_virt_end )
+ return NULL;
+
+ for ( cur = start; pages--; ++mfn, cur += PAGE_SIZE )
+ {
+ /*
+ * We would like to to RX, but we need to copy data in it first.
+ * See arch_xsplice_secure for how we lockdown.
+ */
+ if ( map_pages_to_xen(cur, mfn_x(*mfn), 1, PAGE_HYPERVISOR_RWX) )
+ {
+ if ( cur != start )
+ destroy_xen_mappings(start, cur);
+ return NULL;
+ }
+ }
+
+ return (void*)start;
+}
+
+/*
+ * The function prepares an xSplice payload by allocating space which
+ * then can be used for loading the allocated sections, resolving symbols,
+ * performing relocations, etc.
+ */
+void *arch_xsplice_alloc_payload(unsigned int pages, mfn_t **mfn)
+{
+ unsigned int i;
+ void *p;
+
+ ASSERT(pages);
+ ASSERT(mfn && !*mfn);
+
+ *mfn = NULL;
+ /*
+ * We let the vmalloc allocate the pages we need, and use
+ * our callback. The callback must set the pages W otherwise we can't
+ * put anything in them.
+ */
+ p = vmalloc_cb(pages * PAGE_SIZE, xsplice_map_rwx, mfn);
+ WARN_ON(!p);
+ if ( !p )
+ return NULL;
+
+ for ( i = 0; i < pages; i++ )
+ clear_page(p + (i * PAGE_SIZE) );
+
+ /* Note that we do not free mfn. The caller is responsible for that. */
+ return p;
+}
+
+static void arch_xsplice_vfree_cb(void *va, unsigned int pages)
+{
+ unsigned long addr = (unsigned long)va;
+
+ destroy_xen_mappings(addr, addr + pages * PAGE_SIZE);
+}
+
+/*
+ * Once the resolving symbols, performing relocations, etc is complete
+ * we secure the memory by putting in the proper page table attributes
+ * for the desired type.
+ */
+int arch_xsplice_secure(void *va, unsigned int pages, enum va_type type,
+ const mfn_t *mfn)
+{
+ unsigned long cur;
+ unsigned long start = (unsigned long)va;
+ int flag;
+
+ ASSERT(va);
+ ASSERT(pages);
+
+ if ( type == XSPLICE_VA_RX )
+ flag = PAGE_HYPERVISOR_RX;
+ else if ( type == XSPLICE_VA_RW )
+ flag = PAGE_HYPERVISOR_RW;
+ else
+ flag = PAGE_HYPERVISOR_RO;
+
+ /*
+ * We could walk the pagetable and do the pagetable manipulations
+ * (strip the _PAGE_RW), which would mean also not needing the mfn
+ * array, but there are no generic code for this yet (TODO).
+ *
+ * For right now tear down the pagetables and recreate them.
+ */
+ arch_xsplice_vfree_cb(va, pages);
+
+ for ( cur = start; pages--; ++mfn, cur += PAGE_SIZE )
+ {
+ if ( map_pages_to_xen(cur, mfn_x(*mfn), 1, flag) )
+ {
+ if ( cur != start )
+ destroy_xen_mappings(start, cur);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
+void arch_xsplice_free_payload(void *va, unsigned int pages)
+{
+ vfree_cb(va, pages, arch_xsplice_vfree_cb);
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 0047032..4d24898 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -13,6 +13,7 @@
#include <xen/smp.h>
#include <xen/spinlock.h>
#include <xen/vmap.h>
+#include <xen/xsplice_elf.h>
#include <xen/xsplice.h>
#include <asm/event.h>
@@ -28,6 +29,15 @@ struct payload {
uint32_t state; /* One of the XSPLICE_STATE_*. */
int32_t rc; /* 0 or -XEN_EXX. */
struct list_head list; /* Linked to 'payload_list'. */
+ void *text_addr; /* Virtual address of .text. */
+ size_t text_size; /* .. and its size. */
+ void *rw_addr; /* Virtual address of .data. */
+ size_t rw_size; /* .. and its size (if any). */
+ void *ro_addr; /* Virtual address of .rodata. */
+ size_t ro_size; /* .. and its size (if any). */
+ size_t payload_pages; /* Nr of the pages for the text_addr;
+ rw_addr, and ro_addr (if any) */
+ mfn_t *mfn; /* Array of MFNs of the pages. */
char name[XEN_XSPLICE_NAME_SIZE]; /* Name of it. */
};
@@ -99,6 +109,193 @@ static struct payload *find_payload(const xen_xsplice_name_t *name)
return found;
}
+/*
+ * Functions related to XEN_SYSCTL_XSPLICE_UPLOAD (see xsplice_upload), and
+ * freeing payload (XEN_SYSCTL_XSPLICE_ACTION:XSPLICE_ACTION_UNLOAD).
+ */
+
+static void free_payload_data(struct payload *payload)
+{
+ /* Set to zero until "move_payload". */
+ if ( !payload->text_addr )
+ return;
+
+ xfree(payload->mfn);
+ payload->mfn = NULL;
+
+ arch_xsplice_free_payload(payload->text_addr,
+ payload->payload_pages);
+
+ payload->text_addr = NULL;
+ payload->ro_addr = NULL;
+ payload->rw_addr = NULL;
+ payload->payload_pages = 0;
+}
+
+/*
+* calc_section computes the size (taking into account section alignment).
+*
+* It also modifies sh_entsize with the offset of from the start of
+* virtual address space. This is used in move_payload to figure out the
+* destination location.
+*/
+static void calc_section(struct xsplice_elf_sec *sec, size_t *size)
+{
+ size_t align_size = ROUNDUP(*size, sec->sec->sh_addralign);
+
+ sec->sec->sh_entsize = align_size;
+ *size = sec->sec->sh_size + align_size;
+}
+
+static int find_hole(size_t pages, unsigned long *hole_start,
+ unsigned long *hole_end)
+{
+ struct payload *data, *data2;
+
+ spin_lock_recursive(&payload_lock);
+ list_for_each_entry ( data, &payload_list, list )
+ {
+ list_for_each_entry ( data2, &payload_list, list )
+ {
+ unsigned long start, end;
+
+ start = (unsigned long)data2->text_addr;
+ end = start + data2->payload_pages * PAGE_SIZE;
+ if ( *hole_end > start && *hole_start < end )
+ {
+ *hole_start = end;
+ *hole_end = end + pages * PAGE_SIZE;
+ break;
+ }
+ }
+ if ( &data2->list == &payload_list )
+ break;
+ }
+ spin_unlock_recursive(&payload_lock);
+
+ return 0;
+}
+
+static int move_payload(struct payload *payload, struct xsplice_elf *elf)
+{
+ uint8_t *buf;
+ unsigned int i;
+ size_t size = 0;
+
+ /* Compute text regions. */
+ for ( i = 0; i < elf->hdr->e_shnum; i++ )
+ {
+ if ( (elf->sec[i].sec->sh_flags & (SHF_ALLOC|SHF_EXECINSTR)) ==
+ (SHF_ALLOC|SHF_EXECINSTR) )
+ calc_section(&elf->sec[i], &payload->text_size);
+ }
+
+ /* Compute rw data. */
+ for ( i = 0; i < elf->hdr->e_shnum; i++ )
+ {
+ if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
+ !(elf->sec[i].sec->sh_flags & SHF_EXECINSTR) &&
+ (elf->sec[i].sec->sh_flags & SHF_WRITE) )
+ calc_section(&elf->sec[i], &payload->rw_size);
+ }
+
+ /* Compute ro data. */
+ for ( i = 0; i < elf->hdr->e_shnum; i++ )
+ {
+ if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
+ !(elf->sec[i].sec->sh_flags & SHF_EXECINSTR) &&
+ !(elf->sec[i].sec->sh_flags & SHF_WRITE) )
+ calc_section(&elf->sec[i], &payload->ro_size);
+ }
+
+ /*
+ * Total of all three regions - RX, RW, and RO. We have to have
+ * keep them in seperate pages so we PAGE_ALIGN the RX and RW to have
+ * them on seperate pages. The last one will by default fall on its
+ * own page.
+ */
+ size = PAGE_ALIGN(payload->text_size) + PAGE_ALIGN(payload->rw_size) +
+ payload->ro_size;
+
+ size = PFN_UP(size);
+ buf = arch_xsplice_alloc_payload(size, &payload->mfn);
+ if ( !buf ) {
+ printk(XENLOG_ERR "%s%s: Could not allocate memory for payload!\n",
+ XSPLICE, elf->name);
+ return -ENOMEM;
+ }
+
+ payload->payload_pages = size;
+ payload->text_addr = buf;
+ payload->rw_addr = payload->text_addr + PAGE_ALIGN(payload->text_size);
+ payload->ro_addr = payload->rw_addr + PAGE_ALIGN(payload->rw_size);
+
+ for ( i = 0; i < elf->hdr->e_shnum; i++ )
+ {
+ if ( elf->sec[i].sec->sh_flags & SHF_ALLOC )
+ {
+ if ( (elf->sec[i].sec->sh_flags & SHF_EXECINSTR) )
+ buf = payload->text_addr;
+ else if ( (elf->sec[i].sec->sh_flags & SHF_WRITE) )
+ buf = payload->rw_addr;
+ else
+ buf = payload->ro_addr;
+
+ elf->sec[i].load_addr = buf + elf->sec[i].sec->sh_entsize;
+
+ /* Don't copy NOBITS - such as BSS. */
+ if ( elf->sec[i].sec->sh_type != SHT_NOBITS )
+ {
+ memcpy(elf->sec[i].load_addr, elf->sec[i].data,
+ elf->sec[i].sec->sh_size);
+ dprintk(XENLOG_DEBUG, "%s%s: Loaded %s at 0x%p\n", XSPLICE,
+ elf->name, elf->sec[i].name, elf->sec[i].load_addr);
+ }
+ }
+ }
+
+ return 0;
+}
+
+static int secure_payload(struct payload *payload, struct xsplice_elf *elf)
+{
+ int rc;
+ unsigned int text_pages, rw_pages, ro_pages;
+
+ ASSERT(payload->mfn);
+
+ text_pages = PFN_UP(payload->text_size);
+ ASSERT(text_pages);
+
+ rc = arch_xsplice_secure(payload->text_addr, text_pages, XSPLICE_VA_RX,
+ payload->mfn);
+ if ( rc )
+ return rc;
+
+ rw_pages = PFN_UP(payload->rw_size);
+ if ( rw_pages )
+ {
+ rc = arch_xsplice_secure(payload->rw_addr, rw_pages, XSPLICE_VA_RW,
+ payload->mfn + text_pages);
+ if ( rc )
+ return rc;
+ }
+
+ ro_pages = PFN_UP(payload->ro_size);
+ if ( ro_pages )
+ {
+ rc = arch_xsplice_secure(payload->ro_addr, ro_pages, XSPLICE_VA_RO,
+ payload->mfn + text_pages + rw_pages);
+ }
+
+ ASSERT(ro_pages + rw_pages + text_pages == payload->payload_pages);
+
+ xfree(payload->mfn);
+ payload->mfn = NULL;
+
+ return rc;
+}
+
/* We MUST be holding the payload_lock spinlock. */
static void free_payload(struct payload *data)
{
@@ -106,12 +303,55 @@ static void free_payload(struct payload *data)
list_del(&data->list);
payload_cnt--;
payload_version++;
+ free_payload_data(data);
xfree(data);
}
+static int load_payload_data(struct payload *payload, void *raw, ssize_t len)
+{
+ struct xsplice_elf elf;
+ int rc = 0;
+
+ memset(&elf, 0, sizeof(elf));
+ elf.name = payload->name;
+ elf.len = len;
+
+ rc = arch_xsplice_verify_elf(&elf, raw);
+ if ( rc )
+ return rc;
+
+ rc = xsplice_elf_load(&elf, raw);
+ if ( rc )
+ goto out;
+
+ rc = move_payload(payload, &elf);
+ if ( rc )
+ goto out;
+
+ rc = xsplice_elf_resolve_symbols(&elf);
+ if ( rc )
+ goto out;
+
+ rc = xsplice_elf_perform_relocs(&elf);
+ if ( rc )
+ goto out;
+
+ rc = secure_payload(payload, &elf);
+
+ out:
+ if ( rc )
+ free_payload_data(payload);
+
+ /* Free our temporary data structure. */
+ xsplice_elf_free(&elf);
+
+ return rc;
+}
+
static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
{
struct payload *data;
+ void *raw_data = NULL;
int rc;
rc = verify_payload(upload);
@@ -137,7 +377,19 @@ static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
if ( data->name[upload->name.size - 1] )
goto out;
- rc = 0;
+ rc = -ENOMEM;
+ raw_data = vmalloc(upload->size);
+ if ( !raw_data )
+ goto out;
+
+ rc = -EFAULT;
+ if ( __copy_from_guest(raw_data, upload->payload, upload->size) )
+ goto out;
+
+ rc = load_payload_data(data, raw_data, upload->size);
+ if ( rc )
+ goto out;
+
data->state = XSPLICE_STATE_CHECKED;
INIT_LIST_HEAD(&data->list);
@@ -148,6 +400,7 @@ static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
spin_unlock_recursive(&payload_lock);
out:
+ vfree(raw_data);
if ( rc )
xfree(data);
@@ -382,8 +635,9 @@ static void xsplice_printall(unsigned char key)
}
list_for_each_entry ( data, &payload_list, list )
- printk(" name=%s state=%s(%d)\n", data->name,
- state2str(data->state), data->state);
+ printk(" name=%s state=%s(%d) %p (.data=%p, .rodata=%p) using %zu pages.\n",
+ data->name, state2str(data->state), data->state, data->text_addr,
+ data->rw_addr, data->ro_addr, data->payload_pages);
spin_unlock_recursive(&payload_lock);
}
@@ -391,6 +645,8 @@ static void xsplice_printall(unsigned char key)
static int __init xsplice_init(void)
{
register_keyhandler('x', xsplice_printall, "print xsplicing info", 1);
+
+ arch_xsplice_register_find_space(&find_hole);
return 0;
}
__initcall(xsplice_init);
diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
index f22cede..e5c0b12 100644
--- a/xen/common/xsplice_elf.c
+++ b/xen/common/xsplice_elf.c
@@ -213,6 +213,97 @@ static int elf_get_sym(struct xsplice_elf *elf, const void *data)
return 0;
}
+int xsplice_elf_resolve_symbols(struct xsplice_elf *elf)
+{
+ unsigned int i;
+
+ /*
+ * The first entry of an ELF symbol table is the "undefined symbol index".
+ * aka reserved so we skip it.
+ */
+ ASSERT( elf->sym );
+ for ( i = 1; i < elf->nsym; i++ )
+ {
+ uint16_t idx = elf->sym[i].sym->st_shndx;
+
+ switch ( idx )
+ {
+ case SHN_COMMON:
+ printk(XENLOG_ERR "%s%s: Unexpected common symbol: %s\n",
+ XSPLICE, elf->name, elf->sym[i].name);
+ return -EINVAL;
+ break;
+
+ case SHN_UNDEF:
+ printk(XENLOG_ERR "%s%s: Unknown symbol: %s\n",
+ XSPLICE, elf->name, elf->sym[i].name);
+ return -ENOENT;
+ break;
+
+ case SHN_ABS:
+ dprintk(XENLOG_DEBUG, "%s%s: Absolute symbol: %s => 0x%"PRIx64"\n",
+ XSPLICE, elf->name, elf->sym[i].name,
+ elf->sym[i].sym->st_value);
+ break;
+
+ default:
+ if ( elf->sec[idx].sec->sh_flags & SHF_ALLOC )
+ {
+ elf->sym[i].sym->st_value +=
+ (unsigned long)elf->sec[idx].load_addr;
+ if ( elf->sym[i].name )
+ printk(XENLOG_DEBUG "%s%s: Symbol resolved: %s => 0x%"PRIx64"(%s)\n",
+ XSPLICE, elf->name, elf->sym[i].name,
+ (uint64_t)elf->sym[i].sym->st_value,
+ elf->sec[idx].name);
+ }
+ }
+ }
+
+ return 0;
+}
+
+int xsplice_elf_perform_relocs(struct xsplice_elf *elf)
+{
+ struct xsplice_elf_sec *rela, *base;
+ unsigned int i;
+ int rc;
+
+ /*
+ * The first entry of an ELF symbol table is the "undefined symbol index".
+ * aka reserved so we skip it.
+ */
+ ASSERT( elf->sym );
+ for ( i = 1; i < elf->hdr->e_shnum; i++ )
+ {
+ rela = &elf->sec[i];
+
+ if ( (rela->sec->sh_type != SHT_RELA ) &&
+ (rela->sec->sh_type != SHT_REL ) )
+ continue;
+
+ /* Is it a valid relocation section? */
+ if ( rela->sec->sh_info >= elf->hdr->e_shnum )
+ continue;
+
+ base = &elf->sec[rela->sec->sh_info];
+
+ /* Don't relocate non-allocated sections. */
+ if ( !(base->sec->sh_flags & SHF_ALLOC) )
+ continue;
+
+ if ( elf->sec[i].sec->sh_type == SHT_RELA )
+ rc = arch_xsplice_perform_rela(elf, base, rela);
+ else /* SHT_REL */
+ rc = arch_xsplice_perform_rel(elf, base, rela);
+
+ if ( rc )
+ return rc;
+ }
+
+ return 0;
+}
+
static int xsplice_header_check(const struct xsplice_elf *elf)
{
if ( sizeof(*elf->hdr) >= elf->len )
diff --git a/xen/include/asm-x86/x86_64/page.h b/xen/include/asm-x86/x86_64/page.h
index 86abb94..a854e05 100644
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -38,6 +38,8 @@
#include <xen/pdx.h>
extern unsigned long xen_virt_end;
+extern unsigned long avail_virt_start;
+extern unsigned long avail_virt_end;
#define spage_to_pdx(spg) (((spg) - spage_table)<<(SUPERPAGE_SHIFT-PAGE_SHIFT))
#define pdx_to_spage(pdx) (spage_table + ((pdx)>>(SUPERPAGE_SHIFT-PAGE_SHIFT)))
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
index 00482d0..74850ea 100644
--- a/xen/include/xen/xsplice.h
+++ b/xen/include/xen/xsplice.h
@@ -6,6 +6,9 @@
#ifndef __XEN_XSPLICE_H__
#define __XEN_XSPLICE_H__
+struct xsplice_elf;
+struct xsplice_elf_sec;
+struct xsplice_elf_sym;
struct xen_sysctl_xsplice_op;
#ifdef CONFIG_XSPLICE
@@ -15,6 +18,49 @@ struct xen_sysctl_xsplice_op;
int xsplice_op(struct xen_sysctl_xsplice_op *);
+/* Arch hooks. */
+int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data);
+int arch_xsplice_perform_rel(struct xsplice_elf *elf,
+ const struct xsplice_elf_sec *base,
+ const struct xsplice_elf_sec *rela);
+int arch_xsplice_perform_rela(struct xsplice_elf *elf,
+ const struct xsplice_elf_sec *base,
+ const struct xsplice_elf_sec *rela);
+enum va_type {
+ XSPLICE_VA_RX, /* .text */
+ XSPLICE_VA_RW, /* .data */
+ XSPLICE_VA_RO, /* .rodata */
+};
+
+#include <xen/mm.h>
+void *arch_xsplice_alloc_payload(unsigned int pages, mfn_t **mfn);
+
+/*
+ * Function to secure the allocate pages (from arch_xsplice_alloc_payload)
+ * with the right page permissions.
+ */
+int arch_xsplice_secure(void *va, unsigned int pages, enum va_type types,
+ const mfn_t *mfn);
+
+void arch_xsplice_free_payload(void *va, unsigned int pages);
+
+/*
+ * Callback to find available virtual address space in which the
+ * payload could be put in.
+ *
+ * The arguments are:
+ * - The size of the payload in bytes.
+ * - The starting virtual address to search. To be updated by
+ * callback if space found.
+ * - The ending virtual address to search. To be updated by
+ * callback if space found.
+ *
+ * The return value is zero if search was done. -EXX values
+ * if errors were encountered.
+ */
+typedef int (find_space_t)(size_t, unsigned long *, unsigned long *);
+void arch_xsplice_register_find_space(find_space_t *cb);
+
#else
#include <xen/errno.h> /* For -EOPNOTSUPP */
diff --git a/xen/include/xen/xsplice_elf.h b/xen/include/xen/xsplice_elf.h
index e2dea18..f6ffcbe 100644
--- a/xen/include/xen/xsplice_elf.h
+++ b/xen/include/xen/xsplice_elf.h
@@ -15,6 +15,8 @@ struct xsplice_elf_sec {
elf_resolve_section_names. */
const void *data; /* Pointer to the section (done by
elf_resolve_sections). */
+ uint8_t *load_addr; /* A pointer to the allocated destination.
+ Done by load_payload_data. */
};
struct xsplice_elf_sym {
@@ -38,6 +40,9 @@ struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf *elf,
int xsplice_elf_load(struct xsplice_elf *elf, void *data);
void xsplice_elf_free(struct xsplice_elf *elf);
+int xsplice_elf_resolve_symbols(struct xsplice_elf *elf);
+int xsplice_elf_perform_relocs(struct xsplice_elf *elf);
+
#endif /* __XEN_XSPLICE_ELF_H__ */
/*
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (9 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 10/28] xsplice: Implement payload loading Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 13:28 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version' Konrad Rzeszutek Wilk
` (16 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Kevin Tian, Keir Fraser, Suravee Suthikulpanit,
Konrad Rzeszutek Wilk, Jun Nakajima, Julien Grall,
Stefano Stabellini, Jan Beulich, Boris Ostrovsky
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Implement support for the apply, revert and replace actions.
To perform and action on a payload, the hypercall sets up a data
structure to schedule the work. A hook is added in all the
return-to-guest paths to check for work to do and execute it if needed.
In this way, patches can be applied with all CPUs idle and without
stacks. The first CPU to do_xsplice() becomes the master and triggers a
reschedule softirq to trigger all the other CPUs to enter do_xsplice()
with no stack. Once all CPUs have rendezvoused, all CPUs disable IRQs
and NMIs are ignored. The system is then quiscient and the master
performs the action. After this, all CPUs enable IRQs and NMIs are
re-enabled.
Note that it is unsafe to patch do_nmi and the xSplice internal functions.
Patching functions on NMI/MCE path is liable to end in disaster.
The action to perform is one of:
- APPLY: For each function in the module, store the first 5 bytes of the
old function and replace it with a jump to the new function.
- REVERT: Copy the previously stored bytes into the first 5 bytes of the
old function.
- REPLACE: Revert each applied module and then apply the new module.
To prevent a deadlock with any other barrier in the system, the master
will wait for up to 30ms before timing out.
Measurements found that the patch application to take about 100 μs on a
72 CPU system, whether idle or fully loaded.
We also add an BUILD_ON to make sure that the size of the structure
of the payload is not inadvertly changed.
Lastly we unroll the 'vmap_to_page' on x86 as inside the macro there
is a posibility of a NULL pointer. Hence we unroll it with extra
ASSERTS. Note that asserts on non-debug builds are compiled out hence
the extra checks that will just return (and leak memory).
We also add BUILD_BUG for the structure - and to make sure that the
offsets are correct on both 32 and 64-bit hypervisors (ARM32 and ARM64).
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
--
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Cc: Jun Nakajima <jun.nakajima@intel.com>
Cc: Kevin Tian <kevin.tian@intel.com>
v2: - Pluck the 'struct xsplice_patch_func' in this patch.
- Modify code per review comments.
- Add more data in the keyboard handler.
- Redo the patching code, split it in functions.
v3: - Add return_ macro for debug builds.
- Move s/payload_list_lock/payload_list/ to earlier patch
- Remove const and use ELF types for xsplice_patch_func
- Add check routine to do simple sanity checks for various
sections.
- s/%p/PRIx64/ as ARM builds complain.
- Move code around. Add more dprintk. Add XSPLICE in front of all
printks/dprintk.
Put the NMIs back if we fail patching.
Add per-cpu to lessen contention for global structure.
Extract from xsplice_do_single patching code into xsplice_do_action
Squash xsplice_do_single and check_for_xsplice_work together to
have all rendezvous in one place.
Made XSPLICE_ACTION_REPLACE work again (wrong list iterator)
s/find_special_sections/prepare_payload/
Use list_del_init and INIT_LIST_HEAD for applied_list
v4:
- Add comment, adjust spacing for "Timed out on CPU semaphore"
- Added CR0.WP manipulations when altering the .text of hypervisor.
- Added fix from Andrew for CR0.WP manipulation.
v5: - Made xsplice_patch_func use uintXX_t instead of ELF_ types to easy
making it work under ARM (32bit). Add more BUILD-BUG-ON checks.
- Add more BUILD_ON checks. Sprinkle newlines. Sprinkle newlines. Sprinkle newlines. Sprinkle newlines.
---
---
docs/misc/xsplice.markdown | 3 +-
xen/arch/arm/xsplice.c | 20 ++
xen/arch/x86/domain.c | 4 +
xen/arch/x86/hvm/svm/svm.c | 2 +
xen/arch/x86/hvm/vmx/vmcs.c | 2 +
xen/arch/x86/xsplice.c | 40 ++++
xen/common/xsplice.c | 461 +++++++++++++++++++++++++++++++++++++++++++-
xen/include/asm-arm/nmi.h | 13 ++
xen/include/xen/xsplice.h | 31 ++-
9 files changed, 565 insertions(+), 11 deletions(-)
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index a5303f0..28140dd 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -841,7 +841,8 @@ The implementation must also have a mechanism for:
* Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
* Be able to patch .rodata, .bss, and .data sections.
* Further safety checks (blacklist of which functions cannot be patched, check
- the stack, make sure the payload is built with same compiler as hypervisor).
+ the stack, make sure the payload is built with same compiler as hypervisor,
+ and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
* NOP out the code sequence if `new_size` is zero.
* Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64] in payload file.
diff --git a/xen/arch/arm/xsplice.c b/xen/arch/arm/xsplice.c
index e9c49ab..4fb19b3 100644
--- a/xen/arch/arm/xsplice.c
+++ b/xen/arch/arm/xsplice.c
@@ -6,6 +6,26 @@
#include <xen/xsplice_elf.h>
#include <xen/xsplice.h>
+void arch_xsplice_patching_enter(void)
+{
+}
+
+void arch_xsplice_patching_leave(void)
+{
+}
+
+void arch_xsplice_apply_jmp(struct xsplice_patch_func *func)
+{
+}
+
+void arch_xsplice_revert_jmp(struct xsplice_patch_func *func)
+{
+}
+
+void arch_xsplice_post_action(void)
+{
+}
+
int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data)
{
return -ENOSYS;
diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
index 6ec7554..c63ee21 100644
--- a/xen/arch/x86/domain.c
+++ b/xen/arch/x86/domain.c
@@ -36,6 +36,7 @@
#include <xen/cpu.h>
#include <xen/wait.h>
#include <xen/guest_access.h>
+#include <xen/xsplice.h>
#include <public/sysctl.h>
#include <public/hvm/hvm_vcpu.h>
#include <asm/regs.h>
@@ -120,6 +121,7 @@ static void idle_loop(void)
(*pm_idle)();
do_tasklet();
do_softirq();
+ check_for_xsplice_work(); /* Must be last. */
}
}
@@ -136,6 +138,7 @@ void startup_cpu_idle_loop(void)
static void noreturn continue_idle_domain(struct vcpu *v)
{
+ check_for_xsplice_work();
reset_stack_and_jump(idle_loop);
}
@@ -143,6 +146,7 @@ static void noreturn continue_nonidle_domain(struct vcpu *v)
{
check_wakeup_from_wait();
mark_regs_dirty(guest_cpu_user_regs());
+ check_for_xsplice_work();
reset_stack_and_jump(ret_from_intr);
}
diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c
index 7634c3f..bbb0a73 100644
--- a/xen/arch/x86/hvm/svm/svm.c
+++ b/xen/arch/x86/hvm/svm/svm.c
@@ -26,6 +26,7 @@
#include <xen/hypercall.h>
#include <xen/domain_page.h>
#include <xen/xenoprof.h>
+#include <xen/xsplice.h>
#include <asm/current.h>
#include <asm/io.h>
#include <asm/paging.h>
@@ -1096,6 +1097,7 @@ static void noreturn svm_do_resume(struct vcpu *v)
hvm_do_resume(v);
+ check_for_xsplice_work();
reset_stack_and_jump(svm_asm_do_resume);
}
diff --git a/xen/arch/x86/hvm/vmx/vmcs.c b/xen/arch/x86/hvm/vmx/vmcs.c
index 8284281..ec454dd 100644
--- a/xen/arch/x86/hvm/vmx/vmcs.c
+++ b/xen/arch/x86/hvm/vmx/vmcs.c
@@ -25,6 +25,7 @@
#include <xen/kernel.h>
#include <xen/keyhandler.h>
#include <xen/vm_event.h>
+#include <xen/xsplice.h>
#include <asm/current.h>
#include <asm/cpufeature.h>
#include <asm/processor.h>
@@ -1722,6 +1723,7 @@ void vmx_do_resume(struct vcpu *v)
}
hvm_do_resume(v);
+ check_for_xsplice_work();
reset_stack_and_jump(vmx_asm_do_vmentry);
}
diff --git a/xen/arch/x86/xsplice.c b/xen/arch/x86/xsplice.c
index 7149540..1f77bd8 100644
--- a/xen/arch/x86/xsplice.c
+++ b/xen/arch/x86/xsplice.c
@@ -10,6 +10,46 @@
#include <xen/xsplice_elf.h>
#include <xen/xsplice.h>
+#define PATCH_INSN_SIZE 5
+
+void arch_xsplice_patching_enter(void)
+{
+ /* Disable WP to allow changes to read-only pages. */
+ write_cr0(read_cr0() & ~X86_CR0_WP);
+}
+
+void arch_xsplice_patching_leave(void)
+{
+ /* Reinstate WP. */
+ write_cr0(read_cr0() | X86_CR0_WP);
+}
+
+void arch_xsplice_apply_jmp(struct xsplice_patch_func *func)
+{
+ uint32_t val;
+ uint8_t *old_ptr;
+
+ BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
+ BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
+
+ old_ptr = (uint8_t *)func->old_addr;
+ memcpy(func->undo, old_ptr, PATCH_INSN_SIZE);
+
+ *old_ptr++ = 0xe9; /* Relative jump */
+ val = func->new_addr - func->old_addr - PATCH_INSN_SIZE;
+ memcpy(old_ptr, &val, sizeof val);
+}
+
+void arch_xsplice_revert_jmp(struct xsplice_patch_func *func)
+{
+ memcpy((void *)func->old_addr, func->undo, PATCH_INSN_SIZE);
+}
+
+void arch_xsplice_post_action(void)
+{
+ cpuid_eax(0);
+}
+
int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data)
{
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 4d24898..a0d7fe0 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -3,6 +3,7 @@
*
*/
+#include <xen/cpu.h>
#include <xen/err.h>
#include <xen/guest_access.h>
#include <xen/keyhandler.h>
@@ -11,17 +12,29 @@
#include <xen/mm.h>
#include <xen/sched.h>
#include <xen/smp.h>
+#include <xen/softirq.h>
#include <xen/spinlock.h>
#include <xen/vmap.h>
+#include <xen/wait.h>
#include <xen/xsplice_elf.h>
#include <xen/xsplice.h>
#include <asm/event.h>
+#include <asm/nmi.h>
#include <public/sysctl.h>
+/*
+ * Protects against payload_list operations and also allows only one
+ * caller in schedule_work.
+ */
static DEFINE_SPINLOCK(payload_lock);
static LIST_HEAD(payload_list);
+/*
+ * Patches which have been applied.
+ */
+static LIST_HEAD(applied_list);
+
static unsigned int payload_cnt;
static unsigned int payload_version = 1;
@@ -38,9 +51,31 @@ struct payload {
size_t payload_pages; /* Nr of the pages for the text_addr;
rw_addr, and ro_addr (if any) */
mfn_t *mfn; /* Array of MFNs of the pages. */
+ struct list_head applied_list; /* Linked to 'applied_list'. */
+ struct xsplice_patch_func *funcs; /* The array of functions to patch. */
+ unsigned int nfuncs; /* Nr of functions to patch. */
char name[XEN_XSPLICE_NAME_SIZE]; /* Name of it. */
};
+/* Defines an outstanding patching action. */
+struct xsplice_work
+{
+ atomic_t semaphore; /* Used for rendezvous. First to grab it will
+ do the patching. */
+ atomic_t irq_semaphore; /* Used to signal all IRQs disabled. */
+ uint32_t timeout; /* Timeout to do the operation. */
+ struct payload *data; /* The payload on which to act. */
+ volatile bool_t do_work; /* Signals work to do. */
+ volatile bool_t ready; /* Signals all CPUs synchronized. */
+ uint32_t cmd; /* Action request: XSPLICE_ACTION_* */
+};
+
+/* There can be only one outstanding patching action. */
+static struct xsplice_work xsplice_work;
+
+/* Indicate whether the CPU needs to consult xsplice_work structure. */
+static DEFINE_PER_CPU(bool_t, work_to_do);
+
static int verify_name(const xen_xsplice_name_t *name)
{
if ( !name->size || name->size > XEN_XSPLICE_NAME_SIZE )
@@ -296,6 +331,77 @@ static int secure_payload(struct payload *payload, struct xsplice_elf *elf)
return rc;
}
+static int check_special_sections(struct payload *payload,
+ struct xsplice_elf *elf)
+{
+ unsigned int i;
+ static const char *const names[] = { ".xsplice.funcs" };
+
+ for ( i = 0; i < ARRAY_SIZE(names); i++ )
+ {
+ struct xsplice_elf_sec *sec;
+
+ sec = xsplice_elf_sec_by_name(elf, names[i]);
+ if ( !sec )
+ {
+ printk(XENLOG_ERR "%s%s: %s is missing!\n",
+ XSPLICE, elf->name, names[i]);
+ return -EINVAL;
+ }
+
+ if ( !sec->sec->sh_size )
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static int prepare_payload(struct payload *payload,
+ struct xsplice_elf *elf)
+{
+ struct xsplice_elf_sec *sec;
+ unsigned int i;
+ struct xsplice_patch_func *f;
+
+ sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs");
+ if ( sec )
+ {
+ if ( sec->sec->sh_size % sizeof *payload->funcs )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .xsplice.funcs!\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ payload->funcs = (struct xsplice_patch_func *)sec->load_addr;
+ payload->nfuncs = sec->sec->sh_size / (sizeof *payload->funcs);
+ }
+
+ for ( i = 0; i < payload->nfuncs; i++ )
+ {
+ unsigned int j;
+
+ f = &(payload->funcs[i]);
+
+ if ( !f->new_addr || !f->old_addr || !f->old_size || !f->new_size )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Address or size fields are zero!\n",
+ XSPLICE, elf->name);
+ return -EINVAL;
+ }
+
+ for ( j = 0; j < 8; j++ )
+ if ( f->undo[j] )
+ return -EINVAL;
+
+ for ( j = 0; j < 24; j++ )
+ if ( f->pad[j] )
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/* We MUST be holding the payload_lock spinlock. */
static void free_payload(struct payload *data)
{
@@ -336,6 +442,14 @@ static int load_payload_data(struct payload *payload, void *raw, ssize_t len)
if ( rc )
goto out;
+ rc = check_special_sections(payload, &elf);
+ if ( rc )
+ goto out;
+
+ rc = prepare_payload(payload, &elf);
+ if ( rc )
+ goto out;
+
rc = secure_payload(payload, &elf);
out:
@@ -392,6 +506,7 @@ static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
data->state = XSPLICE_STATE_CHECKED;
INIT_LIST_HEAD(&data->list);
+ INIT_LIST_HEAD(&data->applied_list);
spin_lock_recursive(&payload_lock);
list_add_tail(&data->list, &payload_list);
@@ -499,6 +614,321 @@ static int xsplice_list(xen_sysctl_xsplice_list_t *list)
return rc ? : idx;
}
+/*
+ * The following functions get the CPUs into an appropriate state and
+ * apply (or revert) each of the payload's functions. This is needed
+ * for XEN_SYSCTL_XSPLICE_ACTION operation (see xsplice_action).
+ */
+
+static int apply_payload(struct payload *data)
+{
+ unsigned int i;
+
+ dprintk(XENLOG_DEBUG, "%s%s: Applying %u functions.\n", XSPLICE,
+ data->name, data->nfuncs);
+
+ arch_xsplice_patching_enter();
+
+ for ( i = 0; i < data->nfuncs; i++ )
+ arch_xsplice_apply_jmp(&data->funcs[i]);
+
+ arch_xsplice_patching_leave();
+
+ list_add_tail(&data->applied_list, &applied_list);
+
+ return 0;
+}
+
+/*
+ * This function is executed having all other CPUs with no stack (we may
+ * have cpu_idle on it) and IRQs disabled.
+ */
+static int revert_payload(struct payload *data)
+{
+ unsigned int i;
+
+ dprintk(XENLOG_DEBUG, "%s%s: Reverting.\n", XSPLICE, data->name);
+
+ arch_xsplice_patching_enter();
+
+ for ( i = 0; i < data->nfuncs; i++ )
+ arch_xsplice_revert_jmp(&data->funcs[i]);
+
+ arch_xsplice_patching_leave();
+
+ list_del_init(&data->applied_list);
+
+ return 0;
+}
+
+/*
+ * This function is executed having all other CPUs with no stack (we may
+ * have cpu_idle on it) and IRQs disabled. We guard against NMI by temporarily
+ * installing our NOP NMI handler.
+ */
+static void xsplice_do_action(void)
+{
+ int rc;
+ struct payload *data, *other, *tmp;
+
+ data = xsplice_work.data;
+ /* Now this function should be the only one on any stack.
+ * No need to lock the payload list or applied list. */
+ switch ( xsplice_work.cmd )
+ {
+ case XSPLICE_ACTION_APPLY:
+ rc = apply_payload(data);
+ if ( rc == 0 )
+ data->state = XSPLICE_STATE_APPLIED;
+ break;
+
+ case XSPLICE_ACTION_REVERT:
+ rc = revert_payload(data);
+ if ( rc == 0 )
+ data->state = XSPLICE_STATE_CHECKED;
+ break;
+
+ case XSPLICE_ACTION_REPLACE:
+ rc = 0;
+ /* N.B: Use 'applied_list' member, not 'list'. */
+ list_for_each_entry_safe_reverse ( other, tmp, &applied_list, applied_list )
+ {
+ other->rc = revert_payload(other);
+ if ( other->rc == 0 )
+ other->state = XSPLICE_STATE_CHECKED;
+ else
+ {
+ rc = -EINVAL;
+ break;
+ }
+ }
+
+ if ( rc != -EINVAL )
+ {
+ rc = apply_payload(data);
+ if ( rc == 0 )
+ data->state = XSPLICE_STATE_APPLIED;
+ }
+ break;
+
+ default:
+ rc = -EINVAL;
+ break;
+ }
+
+ data->rc = rc;
+}
+
+/*
+ * MUST be holding the payload_lock.
+ */
+static int schedule_work(struct payload *data, uint32_t cmd, uint32_t timeout)
+{
+ unsigned int cpu;
+
+ ASSERT(spin_is_locked(&payload_lock));
+
+ /* Fail if an operation is already scheduled. */
+ if ( xsplice_work.do_work )
+ return -EBUSY;
+
+ if ( !get_cpu_maps() )
+ {
+ printk(XENLOG_ERR "%s%s: unable to get cpu_maps lock!\n",
+ XSPLICE, data->name);
+ return -EBUSY;
+ }
+
+ xsplice_work.cmd = cmd;
+ xsplice_work.data = data;
+ xsplice_work.timeout = timeout ?: MILLISECS(30);
+
+ dprintk(XENLOG_DEBUG, "%s%s: timeout is %"PRI_stime"ms\n",
+ XSPLICE, data->name, xsplice_work.timeout / MILLISECS(1));
+
+ /*
+ * Once the patching has been completed, the semaphore value will
+ * be num_online_cpus()-1.
+ */
+ atomic_set(&xsplice_work.semaphore, -1);
+ atomic_set(&xsplice_work.irq_semaphore, -1);
+
+ xsplice_work.ready = 0;
+ smp_wmb();
+ xsplice_work.do_work = 1;
+ smp_wmb();
+ /*
+ * Above smp_wmb() gives us an compiler barrier, as we MUST do this
+ * after setting the global structure.
+ */
+ for_each_online_cpu ( cpu )
+ per_cpu(work_to_do, cpu) = 1;
+
+ put_cpu_maps();
+
+ return 0;
+}
+
+/*
+ * Note that because of this NOP code the do_nmi is not safely patchable.
+ * Also if we do receive 'real' NMIs we have lost them. Ditto for MCE.
+ */
+static int mask_nmi_callback(const struct cpu_user_regs *regs, int cpu)
+{
+ /* TODO: Handle missing NMI/MCE.*/
+ return 1;
+}
+
+static void reschedule_fn(void *unused)
+{
+ smp_mb(); /* Synchronize with setting do_work */
+ raise_softirq(SCHEDULE_SOFTIRQ);
+}
+
+static int xsplice_do_wait(atomic_t *counter, s_time_t timeout,
+ unsigned int total_cpus, const char *s)
+{
+ int rc = 0;
+
+ while ( atomic_read(counter) != total_cpus && NOW() < timeout )
+ cpu_relax();
+
+ /* Log & abort. */
+ if ( atomic_read(counter) != total_cpus )
+ {
+ printk(XENLOG_ERR "%s%s: %s %u/%u\n", XSPLICE,
+ xsplice_work.data->name, s, atomic_read(counter), total_cpus);
+ rc = -EBUSY;
+ xsplice_work.data->rc = rc;
+ xsplice_work.do_work = 0;
+ smp_wmb();
+ }
+
+ return rc;
+}
+
+/*
+ * The main function which manages the work of quiescing the system and
+ * patching code.
+ */
+void check_for_xsplice_work(void)
+{
+ unsigned int cpu = smp_processor_id();
+ nmi_callback_t saved_nmi_callback;
+ s_time_t timeout;
+ unsigned long flags;
+
+ /* Fast path: no work to do. */
+ if ( !per_cpu(work_to_do, cpu ) )
+ return;
+
+ /* In case we aborted, other CPUs can skip right away. */
+ if ( (!xsplice_work.do_work) )
+ {
+ per_cpu(work_to_do, cpu) = 0;
+ return;
+ }
+
+ ASSERT(local_irq_is_enabled());
+
+ /* Set at -1, so will go up to num_online_cpus - 1. */
+ if ( atomic_inc_and_test(&xsplice_work.semaphore) )
+ {
+ struct payload *p;
+ unsigned int total_cpus;
+
+ p = xsplice_work.data;
+ if ( !get_cpu_maps() )
+ {
+ printk(XENLOG_ERR "%s%s: CPU%u - unable to get cpu_maps lock!\n",
+ XSPLICE, p->name, cpu);
+ per_cpu(work_to_do, cpu) = 0;
+ xsplice_work.data->rc = -EBUSY;
+ xsplice_work.do_work = 0;
+ /*
+ * Do NOT decrement semaphore down - as that may cause the other
+ * CPU (which may be at this exact moment checking the ASSERT)
+ * to assume the role of master and then needlessly time out
+ * out (as do_work is zero).
+ */
+ return;
+ }
+
+ barrier(); /* MUST do it after get_cpu_maps. */
+ total_cpus = num_online_cpus() - 1;
+
+ if ( total_cpus )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: CPU%u - IPIing the %u CPUs\n",
+ XSPLICE, p->name, cpu, total_cpus);
+ smp_call_function(reschedule_fn, NULL, 0);
+ }
+
+ timeout = xsplice_work.timeout + NOW();
+ if ( xsplice_do_wait(&xsplice_work.semaphore, timeout, total_cpus,
+ "Timed out on CPU semaphore") )
+ goto abort;
+
+ /* "Mask" NMIs. */
+ saved_nmi_callback = set_nmi_callback(mask_nmi_callback);
+
+ /* All CPUs are waiting, now signal to disable IRQs. */
+ xsplice_work.ready = 1;
+ smp_wmb();
+
+ atomic_inc(&xsplice_work.irq_semaphore);
+ if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout, total_cpus,
+ "Timed out on IRQ semaphore") )
+ {
+ local_irq_save(flags);
+ /* Do the patching. */
+ xsplice_do_action();
+ /* To flush out pipeline. */
+ arch_xsplice_post_action();
+ local_irq_restore(flags);
+ }
+ set_nmi_callback(saved_nmi_callback);
+
+ abort:
+ per_cpu(work_to_do, cpu) = 0;
+ xsplice_work.do_work = 0;
+
+ smp_wmb(); /* Synchronize with waiting CPUs. */
+ ASSERT(local_irq_is_enabled());
+
+ put_cpu_maps();
+
+ printk(XENLOG_INFO "%s%s finished with rc=%d\n", XSPLICE,
+ p->name, p->rc);
+ }
+ else
+ {
+ /* Wait for all CPUs to rendezvous. */
+ while ( xsplice_work.do_work && !xsplice_work.ready )
+ {
+ cpu_relax();
+ smp_rmb();
+ }
+
+ /* Disable IRQs and signal. */
+ local_irq_save(flags);
+ atomic_inc(&xsplice_work.irq_semaphore);
+
+ /* Wait for patching to complete. */
+ while ( xsplice_work.do_work )
+ {
+ cpu_relax();
+ smp_rmb();
+ }
+
+ /* To flush out pipeline. */
+ arch_xsplice_post_action();
+ local_irq_restore(flags);
+
+ per_cpu(work_to_do, cpu) = 0;
+ }
+}
+
static int xsplice_action(xen_sysctl_xsplice_action_t *action)
{
struct payload *data;
@@ -542,27 +972,24 @@ static int xsplice_action(xen_sysctl_xsplice_action_t *action)
case XSPLICE_ACTION_REVERT:
if ( data->state == XSPLICE_STATE_APPLIED )
{
- /* No implementation yet. */
- data->state = XSPLICE_STATE_CHECKED;
- data->rc = 0;
+ data->rc = -EAGAIN;
+ rc = schedule_work(data, action->cmd, action->timeout);
}
break;
case XSPLICE_ACTION_APPLY:
if ( data->state == XSPLICE_STATE_CHECKED )
{
- /* No implementation yet. */
- data->state = XSPLICE_STATE_APPLIED;
- data->rc = 0;
+ data->rc = -EAGAIN;
+ rc = schedule_work(data, action->cmd, action->timeout);
}
break;
case XSPLICE_ACTION_REPLACE:
if ( data->state == XSPLICE_STATE_CHECKED )
{
- /* No implementation yet. */
- data->state = XSPLICE_STATE_CHECKED;
- data->rc = 0;
+ data->rc = -EAGAIN;
+ rc = schedule_work(data, action->cmd, action->timeout);
}
break;
@@ -627,6 +1054,7 @@ static const char *state2str(uint32_t state)
static void xsplice_printall(unsigned char key)
{
struct payload *data;
+ unsigned int i;
if ( !spin_trylock_recursive(&payload_lock) )
{
@@ -635,15 +1063,30 @@ static void xsplice_printall(unsigned char key)
}
list_for_each_entry ( data, &payload_list, list )
+ {
printk(" name=%s state=%s(%d) %p (.data=%p, .rodata=%p) using %zu pages.\n",
data->name, state2str(data->state), data->state, data->text_addr,
data->rw_addr, data->ro_addr, data->payload_pages);
+ for ( i = 0; i < data->nfuncs; i++ )
+ {
+ struct xsplice_patch_func *f = &(data->funcs[i]);
+ printk(" %s patch 0x%"PRIx64"(%u) with 0x%"PRIx64"(%u)\n",
+ f->name, f->old_addr, f->old_size, f->new_addr, f->new_size);
+ if ( !(i % 100) )
+ process_pending_softirqs();
+ }
+ }
+
spin_unlock_recursive(&payload_lock);
}
static int __init xsplice_init(void)
{
+ BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
+ BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
+ BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
+
register_keyhandler('x', xsplice_printall, "print xsplicing info", 1);
arch_xsplice_register_find_space(&find_hole);
diff --git a/xen/include/asm-arm/nmi.h b/xen/include/asm-arm/nmi.h
index a60587e..82aff35 100644
--- a/xen/include/asm-arm/nmi.h
+++ b/xen/include/asm-arm/nmi.h
@@ -4,6 +4,19 @@
#define register_guest_nmi_callback(a) (-ENOSYS)
#define unregister_guest_nmi_callback() (-ENOSYS)
+typedef int (*nmi_callback_t)(const struct cpu_user_regs *regs, int cpu);
+
+/**
+ * set_nmi_callback
+ *
+ * Set a handler for an NMI. Only one handler may be
+ * set. Return the old nmi callback handler.
+ */
+static inline nmi_callback_t set_nmi_callback(nmi_callback_t callback)
+{
+ return NULL;
+}
+
#endif /* ASM_NMI_H */
/*
* Local variables:
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
index 74850ea..00b3cb2 100644
--- a/xen/include/xen/xsplice.h
+++ b/xen/include/xen/xsplice.h
@@ -11,12 +11,30 @@ struct xsplice_elf_sec;
struct xsplice_elf_sym;
struct xen_sysctl_xsplice_op;
+#include <xen/elfstructs.h>
+/*
+ * The structure which defines the patching. This is what the hypervisor
+ * expects in the '.xsplice.func' section of the ELF file.
+ *
+ * This MUST be in sync with what the tools generate.
+ */
+struct xsplice_patch_func {
+ const char *name;
+ uint64_t new_addr;
+ uint64_t old_addr;
+ uint32_t new_size;
+ uint32_t old_size;
+ uint8_t undo[8];
+ uint8_t pad[24];
+};
+
#ifdef CONFIG_XSPLICE
/* Convenience define for printk. */
#define XSPLICE "xsplice: "
int xsplice_op(struct xen_sysctl_xsplice_op *);
+void check_for_xsplice_work(void);
/* Arch hooks. */
int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data);
@@ -61,6 +79,17 @@ void arch_xsplice_free_payload(void *va, unsigned int pages);
typedef int (find_space_t)(size_t, unsigned long *, unsigned long *);
void arch_xsplice_register_find_space(find_space_t *cb);
+/*
+ * These functions are called around the critical region patching live code,
+ * for an architecture to take make appropratie global state adjustments.
+ */
+void arch_xsplice_patching_enter(void);
+void arch_xsplice_patching_leave(void);
+
+void arch_xsplice_apply_jmp(struct xsplice_patch_func *func);
+void arch_xsplice_revert_jmp(struct xsplice_patch_func *func);
+void arch_xsplice_post_action(void);
+
#else
#include <xen/errno.h> /* For -EOPNOTSUPP */
@@ -68,7 +97,7 @@ static inline int xsplice_op(struct xen_sysctl_xsplice_op *op)
{
return -EOPNOTSUPP;
}
-
+static inline void check_for_xsplice_work(void) { };
#endif /* CONFIG_XSPLICE */
#endif /* __XEN_XSPLICE_H__ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (10 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 13:33 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address Konrad Rzeszutek Wilk
` (15 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Julien Grall, Stefano Stabellini, Jan Beulich,
Konrad Rzeszutek Wilk
This change demonstrates how to generate an xSplice ELF payload.
The idea here is that we want to patch in the hypervisor
the 'xen_version_extra' function with an function that will
return 'Hello World'. The 'xl info | grep extraversion'
will reflect the new value after the patching.
To generate this ELF payload file we need:
- C code of the new code (xen_hello_world_func.c).
- C code generating the .xsplice.funcs structure
(xen_hello_world.c)
- The address of the old code (xen_extra_version). We
retrieve it by using 'nm --defined' on xen-syms.
- The size of the new and old code for which we use
nm --defined -S on our code and xen-syms respectively.
There are two C files and one header files generated
during build. One could make this one C file if the
size of the newly patched function size was known in
advance (or an random value was choosen).
There is also a strict order of compiling:
1) xen_hello_world_func.c
2) config.h - extract the size of the new function,
the old function and the old function address.
3) xen_hello_world.c - which contains the .xsplice.funcs
structure.
4) Link the object files in an xen_hello_world.xsplice file.
The use-case is simple:
$xen-xsplice load /usr/lib/debug/xen_hello_world.xsplice
$xen-xsplice list
ID | status
----------------------------------------+------------
xen_hello_world APPLIED
$xl info | grep extra
xen_extra : Hello World
$xen-xsplice revert xen_hello_world
Performing revert: completed
$xen-xsplice unload xen_hello_world
Performing unload: completed
$xl info | grep extra
xen_extra : -unstable
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v2: Do it using hypervisor Makefiles
v3: Remove the stale linker file.
Add Copyright and local definition block
s/name/xen_hello_world_name/
---
.gitignore | 2 ++
docs/misc/xsplice.markdown | 36 ++++++++++++++++++++++
xen/Makefile | 2 ++
xen/arch/arm/Makefile | 4 +++
xen/arch/x86/Makefile | 6 ++++
xen/arch/x86/test/Makefile | 53 ++++++++++++++++++++++++++++++++
xen/arch/x86/test/xen_hello_world.c | 30 ++++++++++++++++++
xen/arch/x86/test/xen_hello_world_func.c | 23 ++++++++++++++
8 files changed, 156 insertions(+)
create mode 100644 xen/arch/x86/test/Makefile
create mode 100644 xen/arch/x86/test/xen_hello_world.c
create mode 100644 xen/arch/x86/test/xen_hello_world_func.c
diff --git a/.gitignore b/.gitignore
index b9c9550..8dc76b5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -245,6 +245,8 @@ xen/arch/x86/efi.lds
xen/arch/x86/efi/check.efi
xen/arch/x86/efi/disabled
xen/arch/x86/efi/mkreloc
+xen/arch/x86/test/config.h
+xen/arch/x86/test/xen_hello_world.xsplice
xen/arch/*/efi/boot.c
xen/arch/*/efi/compat.c
xen/arch/*/efi/efi.h
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index 28140dd..a498a61 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -321,11 +321,47 @@ size.
When applying the patch the hypervisor iterates over each `xsplice_patch_func`
structure and the core code inserts a trampoline at `old_addr` to `new_addr`.
+The `new_addr` is altered when the ELF payload is loaded.
When reverting a patch, the hypervisor iterates over each `xsplice_patch_func`
and the core code copies the data from the undo buffer (private internal copy)
to `old_addr`.
+### Example
+
+A simple example of what a payload file can be:
+
+<pre>
+/* MUST be in sync with hypervisor. */
+struct xsplice_patch_func {
+ const char *name;
+ uint64_t new_addr;
+ uint64_t old_addr;
+ uint32_t new_size;
+ uint32_t old_size;
+ uint8_t pad[32];
+};
+
+/* Our replacement function for xen_extra_version. */
+const char *xen_hello_world(void)
+{
+ return "Hello World";
+}
+
+static unsigned char name[] = "xen_hello_world";
+
+struct xsplice_patch_func xsplice_hello_world = {
+ .name = name,
+ .new_addr = (unsigned long)(xen_hello_world),
+ .old_addr = 0xffff82d08013963c, /* Extracted from xen-syms. */
+ .new_size = 13, /* To be be computed by scripts. */
+ .old_size = 13, /* -----------""--------------- */
+} __attribute__((__section__(".xsplice.funcs")));
+
+</pre>
+
+Code must be compiled with -fPIC.
+
## Hypercalls
We will employ the sub operations of the system management hypercall (sysctl).
diff --git a/xen/Makefile b/xen/Makefile
index c908544..2be7deb 100644
--- a/xen/Makefile
+++ b/xen/Makefile
@@ -75,6 +75,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
fi; \
fi
+ $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) install
.PHONY: _uninstall
_uninstall: D=$(DESTDIR)
@@ -92,6 +93,7 @@ _uninstall:
rm -f $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi
rm -f $(D)$(EFI_DIR)/$(T).efi
rm -f $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi
+ $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) uninstall
.PHONY: _debug
_debug:
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index eae5cb3..17e9e3a 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -57,6 +57,10 @@ ifeq ($(CONFIG_ARM_64),y)
ln -sf $(notdir $@) ../../$(notdir $@).efi
endif
+install:
+
+uninstall:
+
$(TARGET).axf: $(TARGET)-syms
# XXX: VE model loads by VMA so instead of
# making a proper ELF we link with LMA == VMA and adjust crudely
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 8a6a7d5..d9416d1 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -75,7 +75,12 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
`$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+ $(MAKE) -f $(BASEDIR)/Rules.mk -C test
+install:
+ $(MAKE) -f $(BASEDIR)/Rules.mk -C test install
+uninstall:
+ $(MAKE) -f $(BASEDIR)/Rules.mk -C test uninstall
ALL_OBJS := $(BASEDIR)/arch/x86/boot/built_in.o $(BASEDIR)/arch/x86/efi/built_in.o $(ALL_OBJS)
@@ -179,3 +184,4 @@ clean::
rm -f $(BASEDIR)/.xen-syms.[0-9]* boot/.*.d
rm -f $(BASEDIR)/.xen.efi.[0-9]* efi/*.o efi/.*.d efi/*.efi efi/disabled efi/mkreloc
rm -f boot/reloc.S boot/reloc.lnk boot/reloc.bin
+ $(MAKE) -f $(BASEDIR)/Rules.mk -C test clean
diff --git a/xen/arch/x86/test/Makefile b/xen/arch/x86/test/Makefile
new file mode 100644
index 0000000..7a364c1
--- /dev/null
+++ b/xen/arch/x86/test/Makefile
@@ -0,0 +1,53 @@
+include $(XEN_ROOT)/Config.mk
+
+CODE_ADDR=$(shell nm --defined $(1) | grep $(2) | awk '{print "0x"$$1}')
+CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
+
+.PHONY: default
+ifdef CONFIG_XSPLICE
+
+XSPLICE := xen_hello_world.xsplice
+
+default: xsplice
+
+install: xsplice
+ $(INSTALL_DATA) $(XSPLICE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
+uninstall:
+ rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
+
+else
+
+default:
+install:
+uninstall:
+
+endif
+
+.PHONY: clean
+clean::
+ rm -f *.o .*.o.d $(XSPLICE) config.h
+
+#
+# To compute these values we need the binary files: xen-syms
+# and xen_hello_world_func.o to be already compiled.
+#
+# We can be assured that xen-syms is already built as we are
+# the last entry in the build target.
+#
+.PHONY: config.h
+config.h: OLD_CODE=$(call CODE_ADDR,$(BASEDIR)/xen-syms,xen_extra_version)
+config.h: OLD_CODE_SZ=$(call CODE_SZ,$(BASEDIR)/xen-syms,xen_extra_version)
+config.h: NEW_CODE_SZ=$(call CODE_SZ,$<,xen_hello_world)
+config.h: xen_hello_world_func.o
+ (set -e; \
+ echo "#define NEW_CODE_SZ $(NEW_CODE_SZ)"; \
+ echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)"; \
+ echo "#define OLD_CODE $(OLD_CODE)") > $@
+
+.PHONY: xsplice
+xsplice: config.h
+ # Need to have these done in sequential order
+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world_func.o
+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world.o
+ $(LD) $(LDFLAGS) -r -o $(XSPLICE) xen_hello_world_func.o \
+ xen_hello_world.o
diff --git a/xen/arch/x86/test/xen_hello_world.c b/xen/arch/x86/test/xen_hello_world.c
new file mode 100644
index 0000000..f6ac098
--- /dev/null
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/xsplice.h>
+#include "config.h"
+
+static char xen_hello_world_name[] = "xen_hello_world";
+extern const char *xen_hello_world(void);
+
+struct xsplice_patch_func __section(".xsplice.funcs") xsplice_xen_hello_world = {
+ .name = xen_hello_world_name,
+ .new_addr = (unsigned long)(xen_hello_world),
+ .old_addr = OLD_CODE,
+ .new_size = NEW_CODE_SZ,
+ .old_size = OLD_CODE_SZ,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/test/xen_hello_world_func.c b/xen/arch/x86/test/xen_hello_world_func.c
new file mode 100644
index 0000000..81380a6
--- /dev/null
+++ b/xen/arch/x86/test/xen_hello_world_func.c
@@ -0,0 +1,23 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+
+/* Our replacement function for xen_extra_version. */
+const char *xen_hello_world(void)
+{
+ return "Hello World";
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (11 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version' Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 15:11 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces Konrad Rzeszutek Wilk
` (14 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Jan Beulich, Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
If in the payload we do not have the old_addr we can resolve
the virtual address based on the UNDEFined symbols.
We also use an boolean flag: new_symbol to track symbols. The usual
case this is used is by:
* A payload may introduce a new symbol
* A payload may override an existing symbol (introduced in Xen or another
payload)
* Overriding symbols must exist in the symtab for backtraces.
* A payload must always link against the object which defines the new symbol.
Considering that payloads may be loaded in any order it would be incorrect to
link against a payload which simply overrides a symbol because you could end
up with a chain of jumps which is inefficient and may result in the expected
function not being executed.
Also we include a local definition block in the symbols.c file.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v1: Ross original version.
v2: Include test-case and document update.
v2: s/size_t/ssize_t/
Include core_text_size, core_text calculation
v4: Cast on dprintk to uint64_t to make ELF 32bit build.
---
xen/arch/x86/Makefile | 6 +-
xen/arch/x86/test/Makefile | 4 +-
xen/arch/x86/test/xen_hello_world.c | 5 +-
xen/common/symbols.c | 33 ++++++++
xen/common/xsplice.c | 160 ++++++++++++++++++++++++++++++++++++
xen/common/xsplice_elf.c | 21 ++++-
xen/include/xen/symbols.h | 2 +
xen/include/xen/xsplice.h | 8 ++
8 files changed, 229 insertions(+), 10 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d9416d1..a1ef24b 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
- | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
+ | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
+ >$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
- | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
+ | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
+ >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
$(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
$(@D)/.$(@F).1.o -o $@
diff --git a/xen/arch/x86/test/Makefile b/xen/arch/x86/test/Makefile
index 7a364c1..22fcb14 100644
--- a/xen/arch/x86/test/Makefile
+++ b/xen/arch/x86/test/Makefile
@@ -35,14 +35,12 @@ clean::
# the last entry in the build target.
#
.PHONY: config.h
-config.h: OLD_CODE=$(call CODE_ADDR,$(BASEDIR)/xen-syms,xen_extra_version)
config.h: OLD_CODE_SZ=$(call CODE_SZ,$(BASEDIR)/xen-syms,xen_extra_version)
config.h: NEW_CODE_SZ=$(call CODE_SZ,$<,xen_hello_world)
config.h: xen_hello_world_func.o
(set -e; \
echo "#define NEW_CODE_SZ $(NEW_CODE_SZ)"; \
- echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)"; \
- echo "#define OLD_CODE $(OLD_CODE)") > $@
+ echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
.PHONY: xsplice
xsplice: config.h
diff --git a/xen/arch/x86/test/xen_hello_world.c b/xen/arch/x86/test/xen_hello_world.c
index f6ac098..243eb3f 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -11,10 +11,13 @@
static char xen_hello_world_name[] = "xen_hello_world";
extern const char *xen_hello_world(void);
+/* External symbol. */
+extern const char *xen_extra_version(void);
+
struct xsplice_patch_func __section(".xsplice.funcs") xsplice_xen_hello_world = {
.name = xen_hello_world_name,
.new_addr = (unsigned long)(xen_hello_world),
- .old_addr = OLD_CODE,
+ .old_addr = (unsigned long)(xen_extra_version),
.new_size = NEW_CODE_SZ,
.old_size = OLD_CODE_SZ,
};
diff --git a/xen/common/symbols.c b/xen/common/symbols.c
index 92fb0ee..329eba2 100644
--- a/xen/common/symbols.c
+++ b/xen/common/symbols.c
@@ -207,3 +207,36 @@ int xensyms_read(uint32_t *symnum, char *type,
return 0;
}
+
+uint64_t symbols_lookup_by_name(const char *symname)
+{
+ uint32_t symnum = 0;
+ uint64_t addr = 0, outaddr = 0;
+ int rc;
+ char type;
+ char name[KSYM_NAME_LEN + 1] = {0};
+
+ do {
+ rc = xensyms_read(&symnum, &type, &addr, name);
+ if ( rc )
+ break;
+
+ if ( !strcmp(name, symname) )
+ {
+ outaddr = addr;
+ break;
+ }
+ } while ( name[0] != '\0' );
+
+ return outaddr;
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index a0d7fe0..24100e7 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -14,6 +14,7 @@
#include <xen/smp.h>
#include <xen/softirq.h>
#include <xen/spinlock.h>
+#include <xen/symbols.h>
#include <xen/vmap.h>
#include <xen/wait.h>
#include <xen/xsplice_elf.h>
@@ -54,6 +55,9 @@ struct payload {
struct list_head applied_list; /* Linked to 'applied_list'. */
struct xsplice_patch_func *funcs; /* The array of functions to patch. */
unsigned int nfuncs; /* Nr of functions to patch. */
+ struct xsplice_symbol *symtab; /* All symbols. */
+ char *strtab; /* Pointer to .strtab. */
+ unsigned int nsyms; /* Nr of entries in .strtab and symbols. */
char name[XEN_XSPLICE_NAME_SIZE]; /* Name of it. */
};
@@ -107,6 +111,34 @@ static int verify_payload(const xen_sysctl_xsplice_upload_t *upload)
return 0;
}
+uint64_t xsplice_symbols_lookup_by_name(const char *symname)
+{
+ struct payload *data;
+ unsigned int i;
+ uint64_t value = 0;
+
+ spin_lock_recursive(&payload_lock);
+
+ list_for_each_entry ( data, &payload_list, list )
+ {
+ for ( i = 0; i < data->nsyms; i++ )
+ {
+ if ( !data->symtab[i].new_symbol )
+ continue;
+
+ if ( !strcmp(data->symtab[i].name, symname) )
+ {
+ value = data->symtab[i].value;
+ goto out;
+ }
+ }
+ }
+
+out:
+ spin_unlock_recursive(&payload_lock);
+ return value;
+}
+
/*
* We may be holding the payload_lock or not. Hence we need
* the recursive spinlock. Or we can judiciously use an
@@ -397,8 +429,126 @@ static int prepare_payload(struct payload *payload,
for ( j = 0; j < 24; j++ )
if ( f->pad[j] )
return -EINVAL;
+
+ /* Lookup function's old address if not already resolved. */
+ if ( !f->old_addr )
+ {
+ f->old_addr = symbols_lookup_by_name(f->name);
+ if ( !f->old_addr )
+ {
+ f->old_addr = xsplice_symbols_lookup_by_name(f->name);
+ if ( !f->old_addr )
+ {
+ printk(XENLOG_ERR "%s%s: Could not resolve old address of %s\n",
+ XSPLICE, elf->name, f->name);
+ return -ENOENT;
+ }
+ }
+ dprintk(XENLOG_DEBUG, "%s%s: Resolved old address %s => 0x%"PRIx64"\n",
+ XSPLICE, elf->name, f->name, f->old_addr);
+ }
+ }
+
+ return 0;
+}
+
+static bool_t is_core_symbol(const struct xsplice_elf *elf,
+ const struct xsplice_elf_sym *sym)
+{
+ if ( sym->sym->st_shndx == SHN_UNDEF ||
+ sym->sym->st_shndx >= elf->hdr->e_shnum )
+ return 0;
+
+ return !!( (elf->sec[sym->sym->st_shndx].sec->sh_flags & SHF_ALLOC) &&
+ (ELF64_ST_TYPE(sym->sym->st_info) == STT_OBJECT ||
+ ELF64_ST_TYPE(sym->sym->st_info) == STT_FUNC) );
+}
+
+static int build_symbol_table(struct payload *payload,
+ const struct xsplice_elf *elf)
+{
+ unsigned int i, j, nsyms = 0;
+ size_t strtab_len = 0;
+ struct xsplice_symbol *symtab;
+ char *strtab;
+
+ ASSERT(payload->nfuncs);
+
+ /* Recall that section @0 is always NULL. */
+ for ( i = 1; i < elf->nsym; i++ )
+ {
+ if ( is_core_symbol(elf, elf->sym + i) )
+ {
+ nsyms++;
+ strtab_len += strlen(elf->sym[i].name) + 1;
+ }
+ }
+
+ symtab = xmalloc_array(struct xsplice_symbol, nsyms);
+ if ( !symtab )
+ return -ENOMEM;
+
+ strtab = xmalloc_bytes(strtab_len);
+ if ( !strtab )
+ {
+ xfree(symtab);
+ return -ENOMEM;
+ }
+
+ nsyms = 0;
+ strtab_len = 0;
+ for ( i = 1; i < elf->nsym; i++ )
+ {
+ if ( is_core_symbol(elf, elf->sym + i) )
+ {
+ symtab[nsyms].name = strtab + strtab_len;
+ symtab[nsyms].size = elf->sym[i].sym->st_size;
+ symtab[nsyms].value = elf->sym[i].sym->st_value;
+ symtab[nsyms].new_symbol = 0; /* To be checked below. */
+ strtab_len += strlcpy(strtab + strtab_len, elf->sym[i].name,
+ KSYM_NAME_LEN) + 1;
+ nsyms++;
+ }
+ }
+
+ for ( i = 0; i < nsyms; i++ )
+ {
+ bool_t found = 0;
+
+ for ( j = 0; j < payload->nfuncs; j++ )
+ {
+ if ( symtab[i].value == payload->funcs[j].new_addr )
+ {
+ found = 1;
+ break;
+ }
+ }
+
+ if ( !found )
+ {
+ if ( xsplice_symbols_lookup_by_name(symtab[i].name) )
+ {
+ printk(XENLOG_ERR "%s%s: duplicate new symbol: %s\n",
+ XSPLICE, elf->name, symtab[i].name);
+ xfree(symtab);
+ xfree(strtab);
+ return -EEXIST;
+ }
+ symtab[i].new_symbol = 1;
+ dprintk(XENLOG_DEBUG, "%s%s: new symbol %s\n",
+ XSPLICE, elf->name, symtab[i].name);
+ }
+ else
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: overriding symbol %s\n",
+ XSPLICE, elf->name, symtab[i].name);
+ }
}
+ payload->symtab = symtab;
+ payload->strtab = strtab;
+ payload->nsyms = nsyms;
+
return 0;
}
@@ -410,6 +560,8 @@ static void free_payload(struct payload *data)
payload_cnt--;
payload_version++;
free_payload_data(data);
+ xfree(data->symtab);
+ xfree(data->strtab);
xfree(data);
}
@@ -450,6 +602,10 @@ static int load_payload_data(struct payload *payload, void *raw, ssize_t len)
if ( rc )
goto out;
+ rc = build_symbol_table(payload, &elf);
+ if ( rc )
+ goto out;
+
rc = secure_payload(payload, &elf);
out:
@@ -517,7 +673,11 @@ static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
out:
vfree(raw_data);
if ( rc )
+ {
+ xfree(data->symtab);
+ xfree(data->strtab);
xfree(data);
+ }
return rc;
}
diff --git a/xen/common/xsplice_elf.c b/xen/common/xsplice_elf.c
index e5c0b12..248e3f3 100644
--- a/xen/common/xsplice_elf.c
+++ b/xen/common/xsplice_elf.c
@@ -4,6 +4,7 @@
#include <xen/errno.h>
#include <xen/lib.h>
+#include <xen/symbols.h>
#include <xen/xsplice_elf.h>
#include <xen/xsplice.h>
@@ -235,15 +236,27 @@ int xsplice_elf_resolve_symbols(struct xsplice_elf *elf)
break;
case SHN_UNDEF:
- printk(XENLOG_ERR "%s%s: Unknown symbol: %s\n",
- XSPLICE, elf->name, elf->sym[i].name);
- return -ENOENT;
+ elf->sym[i].sym->st_value = symbols_lookup_by_name(elf->sym[i].name);
+ if ( !elf->sym[i].sym->st_value )
+ {
+ elf->sym[i].sym->st_value =
+ xsplice_symbols_lookup_by_name(elf->sym[i].name);
+ if ( !elf->sym[i].sym->st_value )
+ {
+ printk(XENLOG_ERR "%s%s: Unknown symbol: %s\n",
+ XSPLICE, elf->name, elf->sym[i].name);
+ return -ENOENT;
+ }
+ }
+ dprintk(XENLOG_DEBUG, "%s%s: Undefined symbol resolved: %s => 0x%"PRIx64"\n",
+ XSPLICE, elf->name, elf->sym[i].name,
+ (uint64_t)elf->sym[i].sym->st_value);
break;
case SHN_ABS:
dprintk(XENLOG_DEBUG, "%s%s: Absolute symbol: %s => 0x%"PRIx64"\n",
XSPLICE, elf->name, elf->sym[i].name,
- elf->sym[i].sym->st_value);
+ (uint64_t)elf->sym[i].sym->st_value);
break;
default:
diff --git a/xen/include/xen/symbols.h b/xen/include/xen/symbols.h
index f58e611..d679aa9 100644
--- a/xen/include/xen/symbols.h
+++ b/xen/include/xen/symbols.h
@@ -23,4 +23,6 @@ const char *symbols_lookup(unsigned long addr,
int xensyms_read(uint32_t *symnum, char *type,
uint64_t *address, char *name);
+uint64_t symbols_lookup_by_name(const char *symname);
+
#endif /*_XEN_SYMBOLS_H*/
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
index 00b3cb2..8bc55f3 100644
--- a/xen/include/xen/xsplice.h
+++ b/xen/include/xen/xsplice.h
@@ -33,8 +33,16 @@ struct xsplice_patch_func {
/* Convenience define for printk. */
#define XSPLICE "xsplice: "
+struct xsplice_symbol {
+ const char *name;
+ uint64_t value;
+ ssize_t size;
+ bool_t new_symbol;
+};
+
int xsplice_op(struct xen_sysctl_xsplice_op *);
void check_for_xsplice_work(void);
+uint64_t xsplice_symbols_lookup_by_name(const char *symname);
/* Arch hooks. */
int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (12 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 15:23 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case Konrad Rzeszutek Wilk
` (13 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
Naturally the backtrace is presented when an instruction
hits an bug_frame or %p is used.
The payloads do not support bug_frames yet - however the functions
the payloads call could hit an BUG() or WARN().
The traps.c has logic to scan for it this - and eventually it will
find the correct bug_frame and the walk the stack using %p to print
the backtrace. For %p and symbols to print a string - the
'is_active_kernel_text' is consulted which uses an 'struct virtual_region'.
Therefore we register our start->end addresses so that
'is_active_kernel_text' will include our payload address.
We also register our symbol lookup table function so that it can
scan the list of payloads and retrieve the correct name.
Lastly we change vsprintf to take into account s and namebuf.
For core code they are the same, but for payloads they are different.
This gets us:
Xen call trace:
[<ffff82d080a00041>] revert_hook+0x31/0x35 [xen_hello_world]
[<ffff82d0801431bd>] xsplice.c#revert_payload+0x86/0xc6
[<ffff82d080143502>] check_for_xsplice_work+0x233/0x3cd
[<ffff82d08017a0b2>] domain.c#continue_idle_domain+0x9/0x1f
Which is great if payloads have similar or same symbol names.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v2: Add missing full stop.
v3: s/module/payload/
v4: Expand comment and include registration of 'virtual_region'
Redo the vsprintf handling of payload name.
Drop the ->skip function
---
xen/common/vsprintf.c | 15 ++++++++++---
xen/common/xsplice.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/xen/common/vsprintf.c b/xen/common/vsprintf.c
index 18d2634..f0b743f 100644
--- a/xen/common/vsprintf.c
+++ b/xen/common/vsprintf.c
@@ -20,6 +20,7 @@
#include <xen/symbols.h>
#include <xen/lib.h>
#include <xen/sched.h>
+#include <xen/xsplice.h>
#include <asm/div64.h>
#include <asm/page.h>
@@ -331,16 +332,17 @@ static char *pointer(char *str, char *end, const char **fmt_ptr,
{
unsigned long sym_size, sym_offset;
char namebuf[KSYM_NAME_LEN+1];
+ bool_t payload = 0;
/* Advance parents fmt string, as we have consumed 's' or 'S' */
++*fmt_ptr;
s = symbols_lookup((unsigned long)arg, &sym_size, &sym_offset, namebuf);
-
- /* If the symbol is not found, fall back to printing the address */
+ /* If the symbol is not found, fall back to printing the address. */
if ( !s )
break;
-
+ if ( strncmp(namebuf, s, KSYM_NAME_LEN) )
+ payload = 1;
/* Print symbol name */
str = string(str, end, s, -1, -1, 0);
@@ -354,6 +356,13 @@ static char *pointer(char *str, char *end, const char **fmt_ptr,
str = number(str, end, sym_size, 16, -1, -1, SPECIAL);
}
+ if ( payload )
+ {
+ str = string(str, end, " [", -1, -1, 0);
+ str = string(str, end, namebuf, -1, -1, 0);
+ str = string(str, end, "]", -1, -1, 0);
+ }
+
return str;
}
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 24100e7..5e77360 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -14,7 +14,9 @@
#include <xen/smp.h>
#include <xen/softirq.h>
#include <xen/spinlock.h>
+#include <xen/string.h>
#include <xen/symbols.h>
+#include <xen/virtual_region.h>
#include <xen/vmap.h>
#include <xen/wait.h>
#include <xen/xsplice_elf.h>
@@ -55,6 +57,8 @@ struct payload {
struct list_head applied_list; /* Linked to 'applied_list'. */
struct xsplice_patch_func *funcs; /* The array of functions to patch. */
unsigned int nfuncs; /* Nr of functions to patch. */
+ struct virtual_region region; /* symbol, bug.frame patching and
+ exception table (x86). */
struct xsplice_symbol *symtab; /* All symbols. */
char *strtab; /* Pointer to .strtab. */
unsigned int nsyms; /* Nr of entries in .strtab and symbols. */
@@ -139,6 +143,51 @@ out:
return value;
}
+static const char *xsplice_symbols_lookup(unsigned long addr,
+ unsigned long *symbolsize,
+ unsigned long *offset,
+ char *namebuf)
+{
+ struct payload *data;
+ unsigned int i;
+ int best;
+
+ /*
+ * No locking since this list is only ever changed during apply or revert
+ * context.
+ */
+ list_for_each_entry ( data, &applied_list, applied_list )
+ {
+ if ( !((void *)addr >= data->text_addr &&
+ (void *)addr < (data->text_addr + data->text_size)) )
+ continue;
+
+ best = -1;
+
+ for ( i = 0; i < data->nsyms; i++ )
+ {
+ if ( data->symtab[i].value <= addr &&
+ ( best == -1 ||
+ data->symtab[best].value < data->symtab[i].value) )
+ best = i;
+ }
+
+ if ( best == -1 )
+ return NULL;
+
+ if ( symbolsize )
+ *symbolsize = data->symtab[best].size;
+ if ( offset )
+ *offset = addr - data->symtab[best].value;
+ if ( namebuf )
+ strlcpy(namebuf, data->name, KSYM_NAME_LEN);
+
+ return data->symtab[best].name;
+ }
+
+ return NULL;
+}
+
/*
* We may be holding the payload_lock or not. Hence we need
* the recursive spinlock. Or we can judiciously use an
@@ -394,6 +443,7 @@ static int prepare_payload(struct payload *payload,
struct xsplice_elf_sec *sec;
unsigned int i;
struct xsplice_patch_func *f;
+ struct virtual_region *region;
sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs");
if ( sec )
@@ -449,6 +499,13 @@ static int prepare_payload(struct payload *payload,
}
}
+ /* Setup the virtual region with proper data. */
+ region = &payload->region;
+
+ region->symbols_lookup = xsplice_symbols_lookup;
+ region->start = (unsigned long)payload->text_addr;
+ region->end = (unsigned long)(payload->text_addr + payload->text_size);
+
return 0;
}
@@ -795,6 +852,7 @@ static int apply_payload(struct payload *data)
arch_xsplice_patching_leave();
list_add_tail(&data->applied_list, &applied_list);
+ register_virtual_region(&data->region);
return 0;
}
@@ -817,6 +875,7 @@ static int revert_payload(struct payload *data)
arch_xsplice_patching_leave();
list_del_init(&data->applied_list);
+ unregister_virtual_region(&data->region);
return 0;
}
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (13 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 15:50 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 16/28] xsplice: Add support for bug frames Konrad Rzeszutek Wilk
` (12 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Jan Beulich, Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Add hook functions which run during patch apply and patch revert.
Hook functions are used by xsplice payloads to manipulate data structures
during patching, etc.
Also add macros to be used by payloads for excluding functions or
sections from being included in a patch.
Furthermore include a test-case for it.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v2: Style guide changes
v3: Include the test-case - and also re-order this patch
---
docs/misc/xsplice.markdown | 21 +++++++++++++
xen/arch/x86/test/xen_hello_world.c | 15 ++++++++++
xen/common/xsplice.c | 37 +++++++++++++++++++++++
xen/include/xen/xsplice_patch.h | 59 +++++++++++++++++++++++++++++++++++++
4 files changed, 132 insertions(+)
create mode 100644 xen/include/xen/xsplice_patch.h
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index a498a61..be9cd71 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -285,6 +285,12 @@ like what the Linux kernel module loader does.
The payload contains a section (xsplice_patch_func) with an array of structures
describing the functions to be patched:
+It optionally may contain the address of functions to be called right before
+being applied and after being reverted:
+
+ * `.xsplice.hooks.load` - an array of function pointers.
+ * `.xsplice.hooks.unload` - an array of function pointers.
+
<pre>
struct xsplice_patch_func {
@@ -362,6 +368,21 @@ struct xsplice_patch_func xsplice_hello_world = {
Code must be compiled with -fPIC.
+
+### .xsplice.hooks.load and .xsplice.hooks.unload
+
+This section contains an array of function pointers to be executed
+before payload is being applied (.xsplice.funcs) or after reverting
+the payload.
+
+Each entry in this array is eight bytes.
+
+The type definition of the function are as follow:
+
+<pre>
+typedef void (*xsplice_loadcall_t)(void);
+typedef void (*xsplice_unloadcall_t)(void);
+</pre>
## Hypercalls
We will employ the sub operations of the system management hypercall (sysctl).
diff --git a/xen/arch/x86/test/xen_hello_world.c b/xen/arch/x86/test/xen_hello_world.c
index 243eb3f..d2b3cc2 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -5,8 +5,10 @@
#include <xen/config.h>
#include <xen/types.h>
+#include <xen/xsplice_patch.h>
#include <xen/xsplice.h>
#include "config.h"
+#include <xen/lib.h>
static char xen_hello_world_name[] = "xen_hello_world";
extern const char *xen_hello_world(void);
@@ -14,6 +16,19 @@ extern const char *xen_hello_world(void);
/* External symbol. */
extern const char *xen_extra_version(void);
+void apply_hook(void)
+{
+ printk(KERN_DEBUG "Hook executing.\n");
+}
+
+void revert_hook(void)
+{
+ printk(KERN_DEBUG "Hook unloaded.\n");
+}
+
+XSPLICE_LOAD_HOOK(apply_hook);
+XSPLICE_UNLOAD_HOOK(revert_hook);
+
struct xsplice_patch_func __section(".xsplice.funcs") xsplice_xen_hello_world = {
.name = xen_hello_world_name,
.new_addr = (unsigned long)(xen_hello_world),
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 5e77360..03b32e4 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -21,6 +21,7 @@
#include <xen/wait.h>
#include <xen/xsplice_elf.h>
#include <xen/xsplice.h>
+#include <xen/xsplice_patch.h>
#include <asm/event.h>
#include <asm/nmi.h>
@@ -62,6 +63,10 @@ struct payload {
struct xsplice_symbol *symtab; /* All symbols. */
char *strtab; /* Pointer to .strtab. */
unsigned int nsyms; /* Nr of entries in .strtab and symbols. */
+ xsplice_loadcall_t *load_funcs; /* The array of funcs to call after */
+ xsplice_unloadcall_t *unload_funcs; /* load and unload of the payload. */
+ unsigned int n_load_funcs; /* Nr of the funcs to load and execute. */
+ unsigned int n_unload_funcs; /* Nr of funcs to call durung unload. */
char name[XEN_XSPLICE_NAME_SIZE]; /* Name of it. */
};
@@ -499,6 +504,28 @@ static int prepare_payload(struct payload *payload,
}
}
+ sec = xsplice_elf_sec_by_name(elf, ".xsplice.hooks.load");
+ if ( sec )
+ {
+ if ( !sec->sec->sh_size ||
+ (sec->sec->sh_size % sizeof (*payload->load_funcs)) )
+ return -EINVAL;
+
+ payload->load_funcs = (xsplice_loadcall_t *)sec->load_addr;
+ payload->n_load_funcs = sec->sec->sh_size / (sizeof *payload->load_funcs);
+ }
+
+ sec = xsplice_elf_sec_by_name(elf, ".xsplice.hooks.unload");
+ if ( sec )
+ {
+ if ( !sec->sec->sh_size ||
+ (sec->sec->sh_size % sizeof (*payload->unload_funcs)) )
+ return -EINVAL;
+
+ payload->unload_funcs = (xsplice_unloadcall_t *)sec->load_addr;
+ payload->n_unload_funcs = sec->sec->sh_size / (sizeof *payload->unload_funcs);
+ }
+
/* Setup the virtual region with proper data. */
region = &payload->region;
@@ -851,6 +878,11 @@ static int apply_payload(struct payload *data)
arch_xsplice_patching_leave();
+ spin_debug_disable();
+ for ( i = 0; i < data->n_load_funcs; i++ )
+ data->load_funcs[i]();
+ spin_debug_enable();
+
list_add_tail(&data->applied_list, &applied_list);
register_virtual_region(&data->region);
@@ -874,6 +906,11 @@ static int revert_payload(struct payload *data)
arch_xsplice_patching_leave();
+ spin_debug_disable();
+ for ( i = 0; i < data->n_unload_funcs; i++ )
+ data->unload_funcs[i]();
+ spin_debug_enable();
+
list_del_init(&data->applied_list);
unregister_virtual_region(&data->region);
diff --git a/xen/include/xen/xsplice_patch.h b/xen/include/xen/xsplice_patch.h
new file mode 100644
index 0000000..19d3f76
--- /dev/null
+++ b/xen/include/xen/xsplice_patch.h
@@ -0,0 +1,59 @@
+/*
+ * Copyright (C) 2016 Citrix Systems R&D Ltd.
+ */
+
+#ifndef __XEN_XSPLICE_PATCH_H__
+#define __XEN_XSPLICE_PATCH_H__
+
+/*
+ * The following definitions are to be used in patches. They are taken
+ * from kpatch.
+ */
+typedef void (*xsplice_loadcall_t)(void);
+typedef void (*xsplice_unloadcall_t)(void);
+
+/* This definition is taken from Linux. */
+#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
+/*
+ * XSPLICE_IGNORE_SECTION macro
+ *
+ * This macro is for ignoring sections that may change as a side effect of
+ * another change or might be a non-bundlable section; that is one that does
+ * not honor -ffunction-section and create a one-to-one relation from function
+ * symbol to section.
+ */
+#define XSPLICE_IGNORE_SECTION(_sec) \
+ char *__UNIQUE_ID(xsplice_ignore_section_) __section(".xsplice.ignore.sections") = _sec;
+
+/*
+ * XSPLICE_IGNORE_FUNCTION macro
+ *
+ * This macro is for ignoring functions that may change as a side effect of a
+ * change in another function.
+ */
+#define XSPLICE_IGNORE_FUNCTION(_fn) \
+ void *__xsplice_ignore_func_##_fn __section(".xsplice.ignore.functions") = _fn;
+
+/*
+ * XSPLICE_LOAD_HOOK macro
+ *
+ * Declares a function pointer to be allocated in a new
+ * .xsplice.hook.load section. This xsplice_load_data symbol is later
+ * stripped by create-diff-object so that it can be declared in multiple
+ * objects that are later linked together, avoiding global symbol
+ * collision. Since multiple hooks can be registered, the
+ * .xsplice.hook.load section is a table of functions that will be
+ * executed in series by the xsplice infrastructure at patch load time.
+ */
+#define XSPLICE_LOAD_HOOK(_fn) \
+ xsplice_loadcall_t __attribute__((weak)) xsplice_load_data __section(".xsplice.hooks.load") = _fn;
+
+/*
+ * XSPLICE_UNLOAD_HOOK macro
+ *
+ * Same as LOAD hook with s/load/unload/
+ */
+#define XSPLICE_UNLOAD_HOOK(_fn) \
+ xsplice_unloadcall_t __attribute__((weak)) xsplice_unload_data __section(".xsplice.hooks.unload") = _fn;
+
+#endif /* __XEN_XSPLICE_PATCH_H__ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 16/28] xsplice: Add support for bug frames.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (14 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 16:00 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 17/28] xsplice: Add support for exception tables Konrad Rzeszutek Wilk
` (11 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Jan Beulich, Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Add support for handling bug frames contained with xsplice modules. If a
trap occurs search either the kernel bug table or an applied payload's
bug table depending on the instruction pointer.
We also include a test-case - which will test the function that was
patched to make sure it has the right value. And will only be triggered
if something has gone horribly wrong.
P.S.
If one really wants to test, insert an WARN_ON(1) at the end of
the revert_hook.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v2:- s/module/payload/
- add build time check in case amount of bug frames expands.
- add define for the number of bug-frames.
v3:
- add missing BUGFRAME_NR, squash s/core_size/core/ in earlier patch.
- Moved code around.
- Changed per Andrew's recommendation.
- Fixed style changes.
- Made it compile under ARM (PRIu32,PRIu64)
v4: Use 'struct virtual_region'
- Rip more of the is_active_text code.
- Use one function for the ->skip
- Include test-case
v5: Rip out the ->skip function.
---
xen/arch/x86/test/xen_hello_world.c | 6 ++++++
xen/arch/x86/traps.c | 5 +++--
xen/common/xsplice.c | 40 +++++++++++++++++++++++++++++++++++++
xen/include/xen/xsplice.h | 5 +++++
4 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/test/xen_hello_world.c b/xen/arch/x86/test/xen_hello_world.c
index d2b3cc2..5364114 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -19,11 +19,17 @@ extern const char *xen_extra_version(void);
void apply_hook(void)
{
printk(KERN_DEBUG "Hook executing.\n");
+ /* The hook is called _after_ the patching. */
+ if ( strcmp(xen_extra_version(), "Hello World") )
+ BUG();
}
void revert_hook(void)
{
printk(KERN_DEBUG "Hook unloaded.\n");
+ /* The hook is called _after_ the unpatching. */
+ if ( !strcmp(xen_extra_version(), "Hello World") )
+ BUG();
}
XSPLICE_LOAD_HOOK(apply_hook);
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 6c73198..e05656a 100644
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -50,6 +50,7 @@
#include <xen/paging.h>
#include <xen/virtual_region.h>
#include <xen/watchdog.h>
+#include <xen/xsplice.h>
#include <asm/system.h>
#include <asm/io.h>
#include <asm/atomic.h>
@@ -1190,7 +1191,7 @@ void do_invalid_op(struct cpu_user_regs *regs)
/* WARN, BUG or ASSERT: decode the filename pointer and line number. */
filename = bug_ptr(bug);
- if ( !is_kernel(filename) )
+ if ( !is_kernel(filename) && !is_patch(filename) )
goto die;
fixup = strlen(filename);
if ( fixup > 50 )
@@ -1217,7 +1218,7 @@ void do_invalid_op(struct cpu_user_regs *regs)
case BUGFRAME_assert:
/* ASSERT: decode the predicate string pointer. */
predicate = bug_msg(bug);
- if ( !is_kernel(predicate) )
+ if ( !is_kernel(predicate) && !is_patch(predicate) )
predicate = "<unknown>";
printk("Assertion '%s' failed at %s%s:%d\n",
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 03b32e4..7b92602 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -120,6 +120,24 @@ static int verify_payload(const xen_sysctl_xsplice_upload_t *upload)
return 0;
}
+bool_t is_patch(const void *ptr)
+{
+ struct payload *data;
+
+ /*
+ * No locking since this list is only ever changed during apply or revert
+ * context.
+ */
+ list_for_each_entry ( data, &applied_list, applied_list )
+ {
+ if ( ptr >= data->ro_addr &&
+ ptr < (data->ro_addr + data->ro_size) )
+ return 1;
+ }
+
+ return 0;
+}
+
uint64_t xsplice_symbols_lookup_by_name(const char *symname)
{
struct payload *data;
@@ -533,6 +551,28 @@ static int prepare_payload(struct payload *payload,
region->start = (unsigned long)payload->text_addr;
region->end = (unsigned long)(payload->text_addr + payload->text_size);
+ /* Optional sections. */
+ for ( i = 0; i < BUGFRAME_NR; i++ )
+ {
+ char str[14];
+
+ snprintf(str, sizeof str, ".bug_frames.%u", i);
+ sec = xsplice_elf_sec_by_name(elf, str);
+ if ( !sec )
+ continue;
+
+ if ( !sec->sec->sh_size ||
+ (sec->sec->sh_size % sizeof (struct bug_frame)) )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .bug_frames.%u!\n",
+ XSPLICE, elf->name, i);
+ return -EINVAL;
+ }
+
+ region->frame[i].bugs = (struct bug_frame *)sec->load_addr;
+ region->frame[i].n_bugs = sec->sec->sh_size / sizeof(struct bug_frame);
+ }
+
return 0;
}
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
index 8bc55f3..47ef1c2 100644
--- a/xen/include/xen/xsplice.h
+++ b/xen/include/xen/xsplice.h
@@ -42,6 +42,7 @@ struct xsplice_symbol {
int xsplice_op(struct xen_sysctl_xsplice_op *);
void check_for_xsplice_work(void);
+bool_t is_patch(const void *addr);
uint64_t xsplice_symbols_lookup_by_name(const char *symname);
/* Arch hooks. */
@@ -106,6 +107,10 @@ static inline int xsplice_op(struct xen_sysctl_xsplice_op *op)
return -EOPNOTSUPP;
}
static inline void check_for_xsplice_work(void) { };
+static inline bool_t is_patch(const void *addr)
+{
+ return 0;
+}
#endif /* CONFIG_XSPLICE */
#endif /* __XEN_XSPLICE_H__ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 17/28] xsplice: Add support for exception tables.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (15 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 16/28] xsplice: Add support for bug frames Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 16:06 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 18/28] xsplice: Add support for alternatives Konrad Rzeszutek Wilk
` (10 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Jan Beulich, Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Add support for exception tables contained within xSplice payloads. If an
exception occurs search either the main exception table or a particular
active payload's exception table depending on the instruction pointer.
Also we add an test-case to make sure we have an exception that
is handled.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v3:
- s/module/payload/
- sanity checks.
- Move code around.
- s/module/payload/
v4: Use 'struct virtual_region'
v5:
- Expand test-case.
---
xen/arch/x86/extable.c | 30 +++++++++++++++++-------------
xen/arch/x86/test/xen_hello_world.c | 11 +++++++++++
xen/common/xsplice.c | 19 +++++++++++++++++++
xen/include/asm-x86/uaccess.h | 5 +++++
4 files changed, 52 insertions(+), 13 deletions(-)
diff --git a/xen/arch/x86/extable.c b/xen/arch/x86/extable.c
index c6c367a..a7f0144 100644
--- a/xen/arch/x86/extable.c
+++ b/xen/arch/x86/extable.c
@@ -20,7 +20,7 @@ static inline unsigned long ex_cont(const struct exception_table_entry *x)
return EX_FIELD(x, cont);
}
-static int __init cmp_ex(const void *a, const void *b)
+static int cmp_ex(const void *a, const void *b)
{
const struct exception_table_entry *l = a, *r = b;
unsigned long lip = ex_addr(l);
@@ -35,7 +35,7 @@ static int __init cmp_ex(const void *a, const void *b)
}
#ifndef swap_ex
-static void __init swap_ex(void *a, void *b, int size)
+static void swap_ex(void *a, void *b, int size)
{
struct exception_table_entry *l = a, *r = b, tmp;
long delta = b - a;
@@ -48,19 +48,23 @@ static void __init swap_ex(void *a, void *b, int size)
}
#endif
-void __init sort_exception_tables(void)
+void sort_exception_table(struct exception_table_entry *start,
+ struct exception_table_entry *stop)
{
- sort(__start___ex_table, __stop___ex_table - __start___ex_table,
- sizeof(struct exception_table_entry), cmp_ex, swap_ex);
- sort(__start___pre_ex_table,
- __stop___pre_ex_table - __start___pre_ex_table,
+ sort(start, stop - start,
sizeof(struct exception_table_entry), cmp_ex, swap_ex);
}
-static inline unsigned long
-search_one_table(const struct exception_table_entry *first,
- const struct exception_table_entry *last,
- unsigned long value)
+void __init sort_exception_tables(void)
+{
+ sort_exception_table(__start___ex_table, __stop___ex_table);
+ sort_exception_table(__start___pre_ex_table, __stop___pre_ex_table);
+}
+
+unsigned long
+search_one_extable(const struct exception_table_entry *first,
+ const struct exception_table_entry *last,
+ unsigned long value)
{
const struct exception_table_entry *mid;
long diff;
@@ -85,7 +89,7 @@ search_exception_table(unsigned long addr)
struct virtual_region *region = search_for_text(addr);
if ( region && region->ex )
- return search_one_table(region->ex, region->ex_end-1, addr);
+ return search_one_extable(region->ex, region->ex_end-1, addr);
return 0;
}
@@ -94,7 +98,7 @@ unsigned long
search_pre_exception_table(struct cpu_user_regs *regs)
{
unsigned long addr = (unsigned long)regs->eip;
- unsigned long fixup = search_one_table(
+ unsigned long fixup = search_one_extable(
__start___pre_ex_table, __stop___pre_ex_table-1, addr);
if ( fixup )
{
diff --git a/xen/arch/x86/test/xen_hello_world.c b/xen/arch/x86/test/xen_hello_world.c
index 5364114..0f26b06 100644
--- a/xen/arch/x86/test/xen_hello_world.c
+++ b/xen/arch/x86/test/xen_hello_world.c
@@ -12,6 +12,7 @@
static char xen_hello_world_name[] = "xen_hello_world";
extern const char *xen_hello_world(void);
+static unsigned long *non_canonical_addr = (unsigned long *)(1UL<<48);
/* External symbol. */
extern const char *xen_extra_version(void);
@@ -26,10 +27,20 @@ void apply_hook(void)
void revert_hook(void)
{
+ unsigned long tmp = 0xdeadbeef;
+ int rc;
+
printk(KERN_DEBUG "Hook unloaded.\n");
/* The hook is called _after_ the unpatching. */
if ( !strcmp(xen_extra_version(), "Hello World") )
BUG();
+ /*
+ * But before unregistering the virtual region. Which means any
+ * BUG, or WARN_ON will contain symbol name. And also exceptions
+ * will be caught and processed properly.
+ */
+ rc = __get_user(tmp, non_canonical_addr);
+ BUG_ON(rc != -EFAULT);
}
XSPLICE_LOAD_HOOK(apply_hook);
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 7b92602..4548b8b 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -573,6 +573,25 @@ static int prepare_payload(struct payload *payload,
region->frame[i].n_bugs = sec->sec->sh_size / sizeof(struct bug_frame);
}
+#ifdef CONFIG_X86
+ sec = xsplice_elf_sec_by_name(elf, ".ex_table");
+ if ( sec )
+ {
+ if ( !sec->sec->sh_size ||
+ (sec->sec->sh_size % sizeof (struct exception_table_entry)) )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .ex_table (exp:%lu vs %lu)!\n",
+ XSPLICE, elf->name, sizeof (struct exception_table_entry),
+ sec->sec->sh_size);
+ return -EINVAL;
+ }
+
+ region->ex = (struct exception_table_entry *)sec->load_addr;
+ region->ex_end = (struct exception_table_entry *)(sec->load_addr + sec->sec->sh_size);
+
+ sort_exception_table(region->ex, region->ex_end);
+ }
+#endif
return 0;
}
diff --git a/xen/include/asm-x86/uaccess.h b/xen/include/asm-x86/uaccess.h
index 947470d..9e67bf0 100644
--- a/xen/include/asm-x86/uaccess.h
+++ b/xen/include/asm-x86/uaccess.h
@@ -276,6 +276,11 @@ extern struct exception_table_entry __start___pre_ex_table[];
extern struct exception_table_entry __stop___pre_ex_table[];
extern unsigned long search_exception_table(unsigned long);
+extern unsigned long search_one_extable(const struct exception_table_entry *first,
+ const struct exception_table_entry *last,
+ unsigned long value);
extern void sort_exception_tables(void);
+extern void sort_exception_table(struct exception_table_entry *start,
+ struct exception_table_entry *stop);
#endif /* __X86_UACCESS_H__ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 18/28] xsplice: Add support for alternatives
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (16 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 17/28] xsplice: Add support for exception tables Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-01 16:20 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 19/28] build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
` (9 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Jan Beulich, Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Add support for applying alternative sections within xsplice payload.
At payload load time, apply an alternative sections that are found.
Also we add an test-case exercising a rather useless alternative
(patching a NOP with a NOP) - but it does exercise the code-path.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v2: Make a new alternative function that does not ASSERT on IRQs and
don't disable IRQs in the code when loading payload.
v4: Include test-case
Include check for size of alternatives and that it is not a 0 size
section.
---
xen/arch/x86/Makefile | 2 +-
xen/arch/x86/alternative.c | 20 ++++++++++++--------
xen/arch/x86/test/xen_hello_world_func.c | 3 +++
xen/common/xsplice.c | 16 ++++++++++++++++
xen/include/asm-x86/alternative.h | 6 ++++++
5 files changed, 38 insertions(+), 9 deletions(-)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index a1ef24b..d4a8069 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -6,7 +6,7 @@ subdir-y += mm
subdir-$(CONFIG_XENOPROF) += oprofile
subdir-y += x86_64
-obj-bin-y += alternative.init.o
+obj-bin-y += alternative.o
obj-y += apic.o
obj-y += bitops.o
obj-bin-y += bzimage.init.o
diff --git a/xen/arch/x86/alternative.c b/xen/arch/x86/alternative.c
index 26ad2b9..e423d3a 100644
--- a/xen/arch/x86/alternative.c
+++ b/xen/arch/x86/alternative.c
@@ -28,7 +28,7 @@
extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
#ifdef K8_NOP1
-static const unsigned char k8nops[] __initconst = {
+static const unsigned char k8nops[] = {
K8_NOP1,
K8_NOP2,
K8_NOP3,
@@ -52,7 +52,7 @@ static const unsigned char * const k8_nops[ASM_NOP_MAX+1] __initconstrel = {
#endif
#ifdef P6_NOP1
-static const unsigned char p6nops[] __initconst = {
+static const unsigned char p6nops[] = {
P6_NOP1,
P6_NOP2,
P6_NOP3,
@@ -75,7 +75,7 @@ static const unsigned char * const p6_nops[ASM_NOP_MAX+1] __initconstrel = {
};
#endif
-static const unsigned char * const *ideal_nops __initdata = k8_nops;
+static const unsigned char * const *ideal_nops = k8_nops;
static int __init mask_nmi_callback(const struct cpu_user_regs *regs, int cpu)
{
@@ -100,7 +100,7 @@ static void __init arch_init_ideal_nops(void)
}
/* Use this to add nops to a buffer, then text_poke the whole buffer. */
-static void __init add_nops(void *insns, unsigned int len)
+static void add_nops(void *insns, unsigned int len)
{
while ( len > 0 )
{
@@ -127,7 +127,7 @@ static void __init add_nops(void *insns, unsigned int len)
*
* This routine is called with local interrupt disabled.
*/
-static void *__init text_poke_early(void *addr, const void *opcode, size_t len)
+static void *text_poke_early(void *addr, const void *opcode, size_t len)
{
memcpy(addr, opcode, len);
sync_core();
@@ -142,15 +142,13 @@ static void *__init text_poke_early(void *addr, const void *opcode, size_t len)
* APs have less capabilities than the boot processor are not handled.
* Tough. Make sure you disable such features by hand.
*/
-static void __init apply_alternatives(struct alt_instr *start, struct alt_instr *end)
+void apply_alternatives_nocheck(struct alt_instr *start, struct alt_instr *end)
{
struct alt_instr *a;
u8 *instr, *replacement;
u8 insnbuf[MAX_PATCH_LEN];
unsigned long cr0 = read_cr0();
- ASSERT(!local_irq_is_enabled());
-
printk(KERN_INFO "alt table %p -> %p\n", start, end);
/* Disable WP to allow application of alternatives to read-only pages. */
@@ -190,6 +188,12 @@ static void __init apply_alternatives(struct alt_instr *start, struct alt_instr
write_cr0(cr0);
}
+void apply_alternatives(struct alt_instr *start, struct alt_instr *end)
+{
+ ASSERT(!local_irq_is_enabled());
+ apply_alternatives_nocheck(start, end);
+}
+
void __init alternative_instructions(void)
{
nmi_callback_t saved_nmi_callback;
diff --git a/xen/arch/x86/test/xen_hello_world_func.c b/xen/arch/x86/test/xen_hello_world_func.c
index 81380a6..2465ce9 100644
--- a/xen/arch/x86/test/xen_hello_world_func.c
+++ b/xen/arch/x86/test/xen_hello_world_func.c
@@ -5,10 +5,13 @@
#include <xen/config.h>
#include <xen/types.h>
+#include <asm/nops.h>
+#include <asm/alternative.h>
/* Our replacement function for xen_extra_version. */
const char *xen_hello_world(void)
{
+ alternative(ASM_NOP1, ASM_NOP1, 1);
return "Hello World";
}
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index 4548b8b..bf8cb1c 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -590,6 +590,22 @@ static int prepare_payload(struct payload *payload,
region->ex_end = (struct exception_table_entry *)(sec->load_addr + sec->sec->sh_size);
sort_exception_table(region->ex, region->ex_end);
+
+ }
+ sec = xsplice_elf_sec_by_name(elf, ".altinstructions");
+ if ( sec )
+ {
+ if ( !sec->sec->sh_size ||
+ (sec->sec->sh_size % sizeof (struct alt_instr)) )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .alt_instr (exp:%lu vs %lu)!\n",
+ XSPLICE, elf->name, sizeof (struct alt_instr),
+ sec->sec->sh_size);
+ return -EINVAL;
+ }
+ apply_alternatives_nocheck((struct alt_instr *)sec->load_addr,
+ (struct alt_instr *)(sec->load_addr +
+ sec->sec->sh_size));
}
#endif
return 0;
diff --git a/xen/include/asm-x86/alternative.h b/xen/include/asm-x86/alternative.h
index 1056630..d50c0b5 100644
--- a/xen/include/asm-x86/alternative.h
+++ b/xen/include/asm-x86/alternative.h
@@ -23,6 +23,12 @@ struct alt_instr {
u8 replacementlen; /* length of new instruction, <= instrlen */
};
+/*
+ * An variant to be used on code that can be patched without many checks.
+ */
+extern void apply_alternatives_nocheck(struct alt_instr *start,
+ struct alt_instr *end);
+extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
extern void alternative_instructions(void);
#define OLDINSTR(oldinstr) "661:\n\t" oldinstr "\n662:\n"
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (17 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 18/28] xsplice: Add support for alternatives Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-04 12:46 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id Konrad Rzeszutek Wilk
` (8 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Julien Grall, Stefano Stabellini, Jan Beulich,
Konrad Rzeszutek Wilk
This patch enables the Elf to be built with the build-id
and provide in the Xen hypervisor the code to extract it.
One can also retrieve the value of the build-id by doing
'readelf -n xen-syms'.
For EFI builds we re-use the same build-id that the xen-syms
was built with.
The version of ld that first implemented --build-id is v2.18.
Hence we check for that or later version - if older version
found we do not build the hypervisor with the build-id
(and the return code is -ENODATA for xen_build_id() call).
For x86 we have two binaries - the xen-syms and the xen - an
smaller version with lots of sections removed. To make it possible
for readelf -n xen we also modify mkelf32 and xen.lds.S to include
the PT_NOTE ELF section.
The EFI binary is more complicated. Having any non-recognizable
sections (.note, .data.note, etc) causes the boot to hang.
Moving the .note in the .data section makes it work. It is also
worth noting that the PE/COFF does not have any "comment"
sections to the author.
Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
symbol offsets don't changes (which means we have multiple binary
ids - except that the last one is the final one). Without this change,
the symbol table embedded in Xen are incorrect - some of the values it
contains are offset by the size of the included build id.
This obviously causes problems when resolving symbols.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v1: Rebase it on Martin's initial patch
v2: Move it to XENVER hypercall
v3: Fix EFI building (Ross's fix)
Don't use the third argument for length.
Use new structure for XENVER_build_id with variable buf.
Include Ross's fix.
Include detection of bin-utils for build-id support, add
probing for size, and return -EPERM for XSM denied calls.
Build xen_build_id under ARM, required adding ELFSIZE in proper file.
Rebase on top XSM version class.
v4:
Include the build-id .note in the xen ELF binary.
s/build_id/build_id_linker/
For EFI build, moved the --build-id values in .data section
Rebase on staging.
Split patch in two. Always do --build-id call. Include the .note in
.rodata. USe const void * and ssize_t
Use -S to make build_id.o and objcopy differently (Andrew suggested)
v5: Put back the #ifdef LOCK_PROFILE on ARM. (Bad change). Move the _erodata
around. s/ssize_t/unsigned int/
---
Config.mk | 11 ++++
xen/arch/arm/Makefile | 2 +-
xen/arch/arm/xen.lds.S | 14 ++++-
xen/arch/x86/Makefile | 30 ++++++++--
xen/arch/x86/boot/mkelf32.c | 137 ++++++++++++++++++++++++++++++++++++++------
xen/arch/x86/xen.lds.S | 23 ++++++++
xen/common/version.c | 51 +++++++++++++++++
xen/include/xen/version.h | 3 +
8 files changed, 248 insertions(+), 23 deletions(-)
diff --git a/Config.mk b/Config.mk
index 79eb2bd..c8e89fe 100644
--- a/Config.mk
+++ b/Config.mk
@@ -126,6 +126,17 @@ endef
check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least gcc-4.1")
$(eval $(check-y))
+ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \
+ grep -q unrecognized && echo n || echo y)
+
+# binutils 2.18 implement build-id.
+ifeq ($(call ld-ver-build-id,$(LD)),n)
+build_id_linker :=
+else
+CFLAGS += -DBUILD_ID
+build_id_linker := --build-id=sha1
+endif
+
# as-insn: Check whether assembler supports an instruction.
# Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index 17e9e3a..a3319ab 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -94,7 +94,7 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 9909595..aad26e3 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -22,6 +22,9 @@ OUTPUT_ARCH(FORMAT)
PHDRS
{
text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+#if defined(BUILD_ID)
+ note PT_NOTE ;
+#endif
}
SECTIONS
{
@@ -57,9 +60,18 @@ SECTIONS
*(.lockprofile.data)
__lock_profile_end = .;
#endif
+ } :text
- _erodata = .; /* End of read-only data */
+#if defined(BUILD_ID)
+ .note : {
+ __note_gnu_build_id_start = .;
+ *(.note.gnu.build-id)
+ __note_gnu_build_id_end = .;
+ *(.note)
+ *(.note.*)
} :text
+#endif
+ _erodata = .; /* End of read-only data */
.data : { /* Data */
. = ALIGN(PAGE_SIZE);
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index d4a8069..7a1f710 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -72,9 +72,16 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
-O $(BASEDIR)/include/xen/compile.h ]; then \
echo '$(TARGET).efi'; fi)
+ifdef build_id_linker
+num_phdrs = 2
+else
+num_phdrs = 1
+endif
+
$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
- `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+ `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'` \
+ $(num_phdrs)
$(MAKE) -f $(BASEDIR)/Rules.mk -C test
install:
@@ -110,22 +117,28 @@ $(BASEDIR)/common/symbols-dummy.o:
$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
| $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
>$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
>$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
+build_id.o: $(TARGET)-syms
+ $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
+ $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+ --rename-section=.data=.note.gnu.build-id -S $@.bin $@
+ rm -f $@.bin
+
EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10
EFI_LDFLAGS += --image-base=$(1) --stack=0,0 --heap=0,0 --strip-debug
EFI_LDFLAGS += --section-alignment=0x200000 --file-alignment=0x20
@@ -138,6 +151,13 @@ $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A VIR
$(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A ALT_START$$,,p')
# Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
$(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:)
+ifdef build_id_linker
+$(TARGET).efi: build_id.o
+build_id_file := build_id.o
+else
+build_id_file :=
+endif
+
$(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbols-dummy.o efi/mkreloc
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
$(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< efi/relocs-dummy.o \
@@ -154,7 +174,7 @@ $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbol
| $(guard) $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).1s.S
$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o
$(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
- $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o -o $@
+ $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(build_id_file) -o $@
if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
index 993a7ee..d230e4c 100644
--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -45,9 +45,9 @@ static Elf32_Ehdr out_ehdr = {
0, /* e_flags */
sizeof(Elf32_Ehdr), /* e_ehsize */
sizeof(Elf32_Phdr), /* e_phentsize */
- 1, /* e_phnum */
+ 1, /* modify based on num_phdrs */ /* e_phnum */
sizeof(Elf32_Shdr), /* e_shentsize */
- 3, /* e_shnum */
+ 3, /* modify based on num_phdrs */ /* e_shnum */
2 /* e_shstrndx */
};
@@ -61,8 +61,20 @@ static Elf32_Phdr out_phdr = {
PF_R|PF_W|PF_X, /* p_flags */
64 /* p_align */
};
+static Elf32_Phdr note_phdr = {
+ PT_NOTE, /* p_type */
+ DYNAMICALLY_FILLED, /* p_offset */
+ DYNAMICALLY_FILLED, /* p_vaddr */
+ DYNAMICALLY_FILLED, /* p_paddr */
+ DYNAMICALLY_FILLED, /* p_filesz */
+ DYNAMICALLY_FILLED, /* p_memsz */
+ PF_R, /* p_flags */
+ 4 /* p_align */
+};
static u8 out_shstrtab[] = "\0.text\0.shstrtab";
+/* If num_phdrs >= 2, we need to tack the .note. */
+static u8 out_shstrtab_extra[] = ".note\0";
static Elf32_Shdr out_shdr[] = {
{ 0 },
@@ -90,6 +102,23 @@ static Elf32_Shdr out_shdr[] = {
}
};
+/*
+ * The 17 points to the '.note' in the out_shstrtab and out_shstrtab_extra
+ * laid out in the file.
+ */
+static Elf32_Shdr out_shdr_extra = {
+ 17, /* sh_name */
+ SHT_NOTE, /* sh_type */
+ 0, /* sh_flags */
+ DYNAMICALLY_FILLED, /* sh_addr */
+ DYNAMICALLY_FILLED, /* sh_offset */
+ DYNAMICALLY_FILLED, /* sh_size */
+ 0, /* sh_link */
+ 0, /* sh_info */
+ 4, /* sh_addralign */
+ 0 /* sh_entsize */
+};
+
/* Some system header files define these macros and pollute our namespace. */
#undef swap16
#undef swap32
@@ -228,21 +257,22 @@ static void do_read(int fd, void *data, int len)
int main(int argc, char **argv)
{
u64 final_exec_addr;
- u32 loadbase, dat_siz, mem_siz;
+ u32 loadbase, dat_siz, mem_siz, note_base, note_sz, offset;
char *inimage, *outimage;
int infd, outfd;
char buffer[1024];
int bytes, todo, i;
+ int num_phdrs;
Elf32_Ehdr in32_ehdr;
Elf64_Ehdr in64_ehdr;
Elf64_Phdr in64_phdr;
- if ( argc != 5 )
+ if ( argc != 6 )
{
fprintf(stderr, "Usage: mkelf32 <in-image> <out-image> "
- "<load-base> <final-exec-addr>\n");
+ "<load-base> <final-exec-addr> <number of program headers>\n");
return 1;
}
@@ -250,7 +280,13 @@ int main(int argc, char **argv)
outimage = argv[2];
loadbase = strtoul(argv[3], NULL, 16);
final_exec_addr = strtoull(argv[4], NULL, 16);
-
+ num_phdrs = atoi(argv[5]);
+ if ( num_phdrs > 2 || num_phdrs < 1 )
+ {
+ fprintf(stderr, "Number of program headers MUST be 1 or 2, got %d!\n",
+ num_phdrs);
+ return 1;
+ }
infd = open(inimage, O_RDONLY);
if ( infd == -1 )
{
@@ -285,11 +321,10 @@ int main(int argc, char **argv)
(int)in64_ehdr.e_phentsize, (int)sizeof(in64_phdr));
return 1;
}
-
- if ( in64_ehdr.e_phnum != 1 )
+ if ( in64_ehdr.e_phnum != num_phdrs )
{
- fprintf(stderr, "Expect precisly 1 program header; found %d.\n",
- (int)in64_ehdr.e_phnum);
+ fprintf(stderr, "Expect precisly %d program header; found %d.\n",
+ num_phdrs, (int)in64_ehdr.e_phnum);
return 1;
}
@@ -299,11 +334,36 @@ int main(int argc, char **argv)
(void)lseek(infd, in64_phdr.p_offset, SEEK_SET);
dat_siz = (u32)in64_phdr.p_filesz;
-
/* Do not use p_memsz: it does not include BSS alignment padding. */
/*mem_siz = (u32)in64_phdr.p_memsz;*/
mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
+ note_sz = note_base = offset = 0;
+ if ( num_phdrs > 1 )
+ {
+ offset = in64_phdr.p_offset;
+ note_base = in64_phdr.p_vaddr;
+
+ (void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), SEEK_SET);
+ do_read(infd, &in64_phdr, sizeof(in64_phdr));
+ endianadjust_phdr64(&in64_phdr);
+
+ (void)lseek(infd, offset, SEEK_SET);
+
+ note_sz = in64_phdr.p_memsz;
+ note_base = in64_phdr.p_vaddr - note_base;
+
+ if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
+ {
+ fprintf(stderr, "Expected .note section within .text section!\n" \
+ "Offset %ld not within %d!\n",
+ in64_phdr.p_offset, dat_siz);
+ return 1;
+ }
+ /* Gets us the absolute offset within the .text section. */
+ offset = in64_phdr.p_offset - offset;
+ }
+
/*
* End the image on a page boundary. This gets round alignment bugs
* in the boot- or chain-loader (e.g., kexec on the XenoBoot CD).
@@ -322,6 +382,31 @@ int main(int argc, char **argv)
out_shdr[1].sh_size = dat_siz;
out_shdr[2].sh_offset = RAW_OFFSET + dat_siz + sizeof(out_shdr);
+ if ( num_phdrs > 1 )
+ {
+ /* We have two of them! */
+ out_ehdr.e_phnum = num_phdrs;
+ /* Extra .note section. */
+ out_ehdr.e_shnum++;
+
+ /* Fill out the PT_NOTE program header. */
+ note_phdr.p_vaddr = note_base;
+ note_phdr.p_paddr = note_base;
+ note_phdr.p_filesz = note_sz;
+ note_phdr.p_memsz = note_sz;
+ note_phdr.p_offset = offset;
+
+ /* Tack on the .note\0 */
+ out_shdr[2].sh_size += sizeof(out_shstrtab_extra);
+ /* And move it past the .note section. */
+ out_shdr[2].sh_offset += sizeof(out_shdr_extra);
+
+ /* Fill out the .note section. */
+ out_shdr_extra.sh_size = note_sz;
+ out_shdr_extra.sh_addr = note_base;
+ out_shdr_extra.sh_offset = RAW_OFFSET + offset;
+ }
+
outfd = open(outimage, O_WRONLY|O_CREAT|O_TRUNC, 0775);
if ( outfd == -1 )
{
@@ -335,8 +420,15 @@ int main(int argc, char **argv)
endianadjust_phdr32(&out_phdr);
do_write(outfd, &out_phdr, sizeof(out_phdr));
-
- if ( (bytes = RAW_OFFSET - sizeof(out_ehdr) - sizeof(out_phdr)) < 0 )
+
+ if ( num_phdrs > 1 )
+ {
+ endianadjust_phdr32(¬e_phdr);
+ do_write(outfd, ¬e_phdr, sizeof(note_phdr));
+ }
+
+ if ( (bytes = RAW_OFFSET - sizeof(out_ehdr) - sizeof(out_phdr) -
+ ( num_phdrs > 1 ? sizeof(note_phdr) : 0 ) ) < 0 )
{
fprintf(stderr, "Header overflow.\n");
return 1;
@@ -355,9 +447,22 @@ int main(int argc, char **argv)
endianadjust_shdr32(&out_shdr[i]);
do_write(outfd, &out_shdr[0], sizeof(out_shdr));
- do_write(outfd, out_shstrtab, sizeof(out_shstrtab));
- do_write(outfd, buffer, 4-((sizeof(out_shstrtab)+dat_siz)&3));
-
+ if ( num_phdrs > 1 )
+ {
+ endianadjust_shdr32(&out_shdr_extra);
+ /* Append the .note section. */
+ do_write(outfd, &out_shdr_extra, sizeof(out_shdr_extra));
+ /* The normal strings - .text\0.. */
+ do_write(outfd, out_shstrtab, sizeof(out_shstrtab));
+ /* Our .note */
+ do_write(outfd, out_shstrtab_extra, sizeof(out_shstrtab_extra));
+ do_write(outfd, buffer, 4-((sizeof(out_shstrtab)+sizeof(out_shstrtab_extra)+dat_siz)&3));
+ }
+ else
+ {
+ do_write(outfd, out_shstrtab, sizeof(out_shstrtab));
+ do_write(outfd, buffer, 4-((sizeof(out_shstrtab)+dat_siz)&3));
+ }
close(infd);
close(outfd);
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 5eb825e..d8661e3 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -31,6 +31,9 @@ OUTPUT_ARCH(i386:x86-64)
PHDRS
{
text PT_LOAD ;
+#if defined(BUILD_ID) && !defined(EFI)
+ note PT_NOTE ;
+#endif
}
SECTIONS
{
@@ -78,6 +81,11 @@ SECTIONS
*(.rodata)
*(.rodata.*)
+#if defined(BUILD_ID) && defined(EFI)
+ __note_gnu_build_id_start = .;
+ *(.note.gnu.build-id)
+ __note_gnu_build_id_end = .;
+#endif
. = ALIGN(8);
/* Exception table */
@@ -99,6 +107,21 @@ SECTIONS
_erodata = .;
} :text
+#if defined(BUILD_ID) && !defined(EFI)
+/*
+ * No mechanism to put an PT_NOTE in the EFI file - so put
+ * it in .data section.
+ */
+ . = ALIGN(4);
+ .note : {
+ __note_gnu_build_id_start = .;
+ *(.note.gnu.build-id)
+ __note_gnu_build_id_end = .;
+ *(.note)
+ *(.note.*)
+ } :note :text
+#endif
+
#ifdef EFI
. = ALIGN(MB(2));
#else
diff --git a/xen/common/version.c b/xen/common/version.c
index fc9bf42..35078c7 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -1,5 +1,9 @@
#include <xen/compile.h>
+#include <xen/errno.h>
+#include <xen/string.h>
+#include <xen/types.h>
#include <xen/version.h>
+#include <xen/elf.h>
const char *xen_compile_date(void)
{
@@ -61,6 +65,53 @@ const char *xen_deny(void)
return "<denied>";
}
+#ifdef BUILD_ID
+#define NT_GNU_BUILD_ID 3
+/* Defined in linker script. */
+extern const Elf_Note __note_gnu_build_id_start[], __note_gnu_build_id_end[];
+
+int xen_build_id(const void **p, unsigned int *len)
+{
+ const Elf_Note *n = __note_gnu_build_id_start;
+ static bool_t checked = 0;
+
+ if ( checked )
+ {
+ *len = n->descsz;
+ *p = ELFNOTE_DESC(n);
+ return 0;
+ }
+ /* --build-id invoked with wrong parameters. */
+ if ( __note_gnu_build_id_end <= __note_gnu_build_id_start )
+ return -ENODATA;
+
+ /* Check for full Note header. */
+ if ( &n[1] > __note_gnu_build_id_end )
+ return -ENODATA;
+
+ /* Check if we really have a build-id. */
+ if ( NT_GNU_BUILD_ID != n->type )
+ return -ENODATA;
+
+ /* Sanity check, name should be "GNU" for ld-generated build-id. */
+ if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
+ return -ENODATA;
+
+ *len = n->descsz;
+ *p = ELFNOTE_DESC(n);
+
+ checked = 1;
+ return 0;
+}
+
+#else
+
+int xen_build_id(const void **p, unsigned int *len)
+{
+ return -ENODATA;
+}
+#endif
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/xen/version.h b/xen/include/xen/version.h
index 2015c0b..4b57e18 100644
--- a/xen/include/xen/version.h
+++ b/xen/include/xen/version.h
@@ -14,4 +14,7 @@ const char *xen_changeset(void);
const char *xen_banner(void);
const char *xen_deny(void);
+#include <xen/types.h>
+int xen_build_id(const void **p, unsigned int *len);
+
#endif /* __XEN_VERSION_H__ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (18 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 19/28] build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-25 16:26 ` Daniel De Graaf
2016-04-04 13:35 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id Konrad Rzeszutek Wilk
` (7 subsequent siblings)
27 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Daniel De Graaf, Stefano Stabellini, Ian Jackson,
Konrad Rzeszutek Wilk
The VERSION hypercall provides the flexibility to expose
the size of the build-id (so the callers can allocate the
proper size before trying to retrieve it). It also allows
in one nice swoop to retrieve the hypervisor build-id in the
provided buffer.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
---
v4: New patch.
v5: Rebase - s/VERSION_OP/VERSION/
---
tools/flask/policy/policy/modules/xen/xen.te | 1 +
xen/common/kernel.c | 4 ++++
xen/include/public/version.h | 3 +++
xen/xsm/flask/hooks.c | 3 +++
xen/xsm/flask/policy/access_vectors | 2 ++
5 files changed, 13 insertions(+)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index 68ef6de..9ad5953 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -81,6 +81,7 @@ allow dom0_t xen_t:version {
xen_extraversion xen_compile_info xen_capabilities
xen_changeset xen_pagesize xen_guest_handle xen_commandline
extraversion capabilities changeset pagesize guest_handle commandline
+ build_id
};
allow dom0_t xen_t:mmu memorymap;
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index 5616c06..f0a5b04 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -475,6 +475,10 @@ DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
ptr = saved_cmdline;
break;
+ case XEN_VERSION_build_id:
+ rc = xen_build_id(&ptr, &sz);
+ break;
+
default:
rc = -ENOSYS;
}
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index d71ec5b..5d5565a 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -155,6 +155,9 @@ DEFINE_XEN_GUEST_HANDLE(xen_version_op_val_t);
/* arg = char[]. Contains NUL terminated utf-8 string. */
#define XEN_VERSION_commandline 9
+/* arg = void. Contains binary value of hypervisor build-id. */
+#define XEN_VERSION_build_id 10
+
#endif /* __XEN_PUBLIC_VERSION_H__ */
/*
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 3ef0441..f3a2160 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1693,6 +1693,9 @@ static int flask_version_op (uint32_t op)
case XEN_VERSION_commandline:
return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
VERSION__COMMANDLINE, NULL);
+ case XEN_VERSION_build_id:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__BUILD_ID, NULL);
default:
return -EPERM;
}
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index 1c59b58..6e7888c 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -536,4 +536,6 @@ class version
guest_handle
# Xen command line.
commandline
+# Build id of the hypervisor
+ build_id
}
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (19 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-25 13:25 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup Konrad Rzeszutek Wilk
` (6 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Stefano Stabellini, Ian Jackson, Konrad Rzeszutek Wilk
If the hypervisor is built with we will display it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
v3: Retry with different size if 1020 is not enough.
v4: Use VERSION_OP subops instead of the XENVER_ subops
v5: Change it per Wei's review. s/VERSION_OP/VERSION/
---
tools/libxl/libxl.c | 21 +++++++++++++++++++--
tools/libxl/libxl.h | 6 ++++++
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 1 +
4 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 6c3ec40..310a7f3 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5235,6 +5235,7 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
GC_INIT(ctx);
char *buf;
xen_version_op_val_t val = 0;
+ int r;
libxl_version_info *info = &ctx->version_info;
if (info->xen_version_extra != NULL)
@@ -5277,8 +5278,24 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
info->virt_start = val;
- (void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
- info->pagesize, &info->commandline);
+ if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
+ info->pagesize, &info->commandline) < 0)
+ goto out;
+
+ r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
+ if (r < 0)
+ {
+ info->build_id = libxl__strdup(NOGC, "");
+ }
+ else if (r > 0)
+ {
+ unsigned int i;
+
+ info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
+
+ for (i = 0; i < r; i++)
+ snprintf(&info->build_id[i * 2], 3, "%02hhx", buf[i]);
+ }
out:
GC_FREE;
return info;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f61bc4b..5baffdf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -230,6 +230,12 @@
#define LIBXL_HAVE_APIC_ASSIST 1
/*
+ * LIBXL_HAVE_BUILD_ID means that libxl_version_info has the extra
+ * field for the hypervisor build_id.
+ */
+#define LIBXL_HAVE_BUILD_ID 1
+
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 59b183c..e3a5707 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -363,6 +363,7 @@ libxl_version_info = Struct("version_info", [
("virt_start", uint64),
("pagesize", integer),
("commandline", string),
+ ("build_id", string),
], dir=DIR_OUT)
libxl_domain_create_info = Struct("domain_create_info",[
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a3610fc..23da95e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5861,6 +5861,7 @@ static void output_xeninfo(void)
printf("cc_compile_by : %s\n", info->compile_by);
printf("cc_compile_domain : %s\n", info->compile_domain);
printf("cc_compile_date : %s\n", info->compile_date);
+ printf("build_id : %s\n", info->build_id);
return;
}
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (20 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-04 13:38 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 23/28] xsplice: Stacking build-id dependency checking Konrad Rzeszutek Wilk
` (5 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
As it should be an useful debug mechanism.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
--
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v2: s/char */const void *
v5: s/ssize_t/unsigned int/
---
xen/common/xsplice.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index bf8cb1c..ec47f31 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -16,6 +16,7 @@
#include <xen/spinlock.h>
#include <xen/string.h>
#include <xen/symbols.h>
+#include <xen/version.h>
#include <xen/virtual_region.h>
#include <xen/vmap.h>
#include <xen/wait.h>
@@ -1385,8 +1386,13 @@ static const char *state2str(uint32_t state)
static void xsplice_printall(unsigned char key)
{
struct payload *data;
+ const void *binary_id = NULL;
+ unsigned int len = 0;
unsigned int i;
+ if ( !xen_build_id(&binary_id, &len) )
+ printk("build-id: %*phN\n", len, binary_id);
+
if ( !spin_trylock_recursive(&payload_lock) )
{
printk("Lock held. Try again.\n");
@@ -1414,10 +1420,16 @@ static void xsplice_printall(unsigned char key)
static int __init xsplice_init(void)
{
+ const void *binary_id = NULL;
+ unsigned int len = 0;
+
BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
+ if ( !xen_build_id(&binary_id, &len) )
+ printk(XENLOG_INFO "%s: build-id: %*phN\n", XSPLICE, len, binary_id);
+
register_keyhandler('x', xsplice_printall, "print xsplicing info", 1);
arch_xsplice_register_find_space(&find_hole);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (21 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-04 15:00 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 24/28] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE Konrad Rzeszutek Wilk
` (4 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Jan Beulich, Konrad Rzeszutek Wilk
We now expect that the ELF payloads be built with the
--build-id.
Also the .xsplice.deps section has to have the contents
of the hypervisor (or a preceding payload) build-id.
We already have the code to verify the Elf_Note build-id
so export parts of it.
This dependency means the hypervisor MUST be compiled with
--build-id - so we gate the build of xSplice on the availability
of said functionality.
This does not impact the ordering of how the payloads can
be loaded, but it does enforce an STRICT ordering when the
payloads are applied. Also the REPLACE is special - we need
to check that its dependency against the hypervisor - not
the last applied patch.
To make this easier to test we also add an extra test-case
to be used - which can only be applied on top of the
xen_hello_world payload.
As in, one can apply xen_hello_world and then xen_bye_world
on top of that. Not the other way.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v3: First time included.
v4: Andrew fix against the build_id.o mutilations.
Andrew fix to not include extra symbols in binary.id
v5: s/ssize_t/unsigned int/
---
.gitignore | 1 +
Config.mk | 1 +
docs/misc/xsplice.markdown | 84 ++++++++++++++++++---------
xen/arch/x86/test/Makefile | 41 +++++++++++--
xen/arch/x86/test/xen_bye_world.c | 34 +++++++++++
xen/arch/x86/test/xen_bye_world_func.c | 25 ++++++++
xen/common/Kconfig | 6 +-
xen/common/version.c | 40 +++++++++----
xen/common/xsplice.c | 103 ++++++++++++++++++++++++++++++++-
xen/include/xen/version.h | 3 +
xen/include/xen/xsplice.h | 5 ++
11 files changed, 297 insertions(+), 46 deletions(-)
create mode 100644 xen/arch/x86/test/xen_bye_world.c
create mode 100644 xen/arch/x86/test/xen_bye_world_func.c
diff --git a/.gitignore b/.gitignore
index 8dc76b5..f1cadcf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -247,6 +247,7 @@ xen/arch/x86/efi/disabled
xen/arch/x86/efi/mkreloc
xen/arch/x86/test/config.h
xen/arch/x86/test/xen_hello_world.xsplice
+xen/arch/x86/test/xen_bye_world.xsplice
xen/arch/*/efi/boot.c
xen/arch/*/efi/compat.c
xen/arch/*/efi/efi.h
diff --git a/Config.mk b/Config.mk
index c8e89fe..80629e3 100644
--- a/Config.mk
+++ b/Config.mk
@@ -134,6 +134,7 @@ ifeq ($(call ld-ver-build-id,$(LD)),n)
build_id_linker :=
else
CFLAGS += -DBUILD_ID
+export XEN_HAS_BUILD_ID=y
build_id_linker := --build-id=sha1
endif
diff --git a/docs/misc/xsplice.markdown b/docs/misc/xsplice.markdown
index be9cd71..8b9ce9c 100644
--- a/docs/misc/xsplice.markdown
+++ b/docs/misc/xsplice.markdown
@@ -283,8 +283,7 @@ The xSplice core code loads the payload as a standard ELF binary, relocates it
and handles the architecture-specifc sections as needed. This process is much
like what the Linux kernel module loader does.
-The payload contains a section (xsplice_patch_func) with an array of structures
-describing the functions to be patched:
+The payload contains at least three sections:
It optionally may contain the address of functions to be called right before
being applied and after being reverted:
@@ -292,6 +291,15 @@ being applied and after being reverted:
* `.xsplice.hooks.unload` - an array of function pointers.
+ * `.xsplice.funcs` - which is an array of xsplice_patch_func structures.
+ * `.xsplice.depends` - which is an ELF Note that describes what the payload
+ depends on.
+ * `.note.gnu.build-id` - the build-id of this payload.
+
+### .xsplice.funcs
+
+The `.xsplice.funcs` contains an array of xsplice_patch_func structures
+which describe the functions to be patched:
<pre>
struct xsplice_patch_func {
const char *name;
@@ -333,7 +341,7 @@ When reverting a patch, the hypervisor iterates over each `xsplice_patch_func`
and the core code copies the data from the undo buffer (private internal copy)
to `old_addr`.
-### Example
+### Example of .xsplice.funcs
A simple example of what a payload file can be:
@@ -379,10 +387,29 @@ Each entry in this array is eight bytes.
The type definition of the function are as follow:
+
<pre>
typedef void (*xsplice_loadcall_t)(void);
typedef void (*xsplice_unloadcall_t)(void);
</pre>
+
+### .xsplice.depends and .note.gnu.build-id
+
+To support dependencies checking and safe loading (to load the
+appropiate payload against the right hypervisor) there is a need
+to embbed an build-id dependency.
+
+This is done by the payload containing an section `.xsplice.depends`
+which follows the format of an ELF Note. The contents of this
+(name, and description) are specific to the linker utilized to
+build the hypevisor and payload.
+
+If GNU linker is used then the name is `GNU` and the description
+is an NT_GNU_BUILD_ID type ID. The description can be an SHA1
+checksum, MD5 checksum or any unique value.
+
+The size of these structures varies with the --build-id linker option.
+
## Hypercalls
We will employ the sub operations of the system management hypercall (sysctl).
@@ -879,30 +906,6 @@ This is implemented in the Xen Project hypervisor.
Only the privileged domain should be allowed to do this operation.
-
-# Not Yet Done
-
-This is for further development of xSplice.
-
-## Goals
-
-The implementation must also have a mechanism for:
-
- * An dependency mechanism for the payloads. To use that information to load:
- - The appropiate payload. To verify that payload is built against the
- hypervisor. This can be done via the `build-id`
- or via providing an copy of the old code - so that the hypervisor can
- verify it against the code in memory.
- - To construct an appropiate order of payloads to load in case they
- depend on each other.
- * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
- * Be able to patch .rodata, .bss, and .data sections.
- * Further safety checks (blacklist of which functions cannot be patched, check
- the stack, make sure the payload is built with same compiler as hypervisor,
- and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
- * NOP out the code sequence if `new_size` is zero.
- * Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64] in payload file.
-
### xSplice interdependencies
xSplice patches interdependencies are tricky.
@@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to match against.
The old code allows much more flexibility and an additional guard,
but is more complex to implement.
+The second option which requires an build-id of the hypervisor
+is implemented in the Xen Project hypervisor.
+
+Specifically each payload has two build-id ELF notes:
+ * The build-id of the payload itself (generated via --build-id).
+ * The build-id of the payload it depends on (extracted from the
+ the previous payload or hypervisor during build time).
+
+This means that the very first payload depends on the hypervisor
+build-id.
+
+# Not Yet Done
+
+This is for further development of xSplice.
+
+## Goals
+
+The implementation must also have a mechanism for:
+
+ * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
+ * Be able to patch .rodata, .bss, and .data sections.
+ * Further safety checks (blacklist of which functions cannot be patched, check
+ the stack, make sure the payload is built with same compiler as hypervisor,
+ and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
+ * NOP out the code sequence if `new_size` is zero.
+ * Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64] in payload file.
+
### Handle inlined __LINE__
This problem is related to hotpatch construction
diff --git a/xen/arch/x86/test/Makefile b/xen/arch/x86/test/Makefile
index 22fcb14..8d355fb 100644
--- a/xen/arch/x86/test/Makefile
+++ b/xen/arch/x86/test/Makefile
@@ -7,13 +7,16 @@ CODE_SZ=$(shell nm --defined -S $(1) | grep $(2) | awk '{ print "0x"$$2}')
ifdef CONFIG_XSPLICE
XSPLICE := xen_hello_world.xsplice
+XSPLICE_BYE := xen_bye_world.xsplice
default: xsplice
install: xsplice
$(INSTALL_DATA) $(XSPLICE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
+ $(INSTALL_DATA) $(XSPLICE_BYE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_BYE)
uninstall:
rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
+ rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_BYE)
else
@@ -25,7 +28,7 @@ endif
.PHONY: clean
clean::
- rm -f *.o .*.o.d $(XSPLICE) config.h
+ rm -f *.o .*.o.d $(XSPLICE) config.h build_id.o
#
# To compute these values we need the binary files: xen-syms
@@ -37,15 +40,43 @@ clean::
.PHONY: config.h
config.h: OLD_CODE_SZ=$(call CODE_SZ,$(BASEDIR)/xen-syms,xen_extra_version)
config.h: NEW_CODE_SZ=$(call CODE_SZ,$<,xen_hello_world)
-config.h: xen_hello_world_func.o
+config.h: xen_hello_world_func.o xen_bye_world_func.o
(set -e; \
echo "#define NEW_CODE_SZ $(NEW_CODE_SZ)"; \
echo "#define OLD_CODE_SZ $(OLD_CODE_SZ)") > $@
+#
+# This target is only accessible if CONFIG_XSPLICE is defined, which
+# depends on $(build_id_linker) being available. Hence we do not
+# need any checks.
+#
+.PHONY: build_id.o
+build_id.o:
+ $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
+ $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+ --rename-section=.data=.xsplice.depends -S $@.bin $@
+ rm -f $@.bin
+
+#
+# Extract the build-id of the xen_hello_world.xsplice
+# (which xen_bye_world will depend on).
+#
+.PHONY: hello_world_build_id.o
+hello_world_build_id.o:
+ $(OBJCOPY) -O binary --only-section=.note.gnu.build-id $(XSPLICE) $@.bin
+ $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+ --rename-section=.data=.xsplice.depends -S $@.bin $@
+ rm -f $@.bin
+
.PHONY: xsplice
-xsplice: config.h
+xsplice: config.h build_id.o
# Need to have these done in sequential order
$(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world_func.o
$(MAKE) -f $(BASEDIR)/Rules.mk xen_hello_world.o
- $(LD) $(LDFLAGS) -r -o $(XSPLICE) xen_hello_world_func.o \
- xen_hello_world.o
+ $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(XSPLICE) \
+ xen_hello_world_func.o xen_hello_world.o build_id.o
+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_bye_world_func.o
+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_bye_world.o
+ $(MAKE) -f $(BASEDIR)/Rules.mk hello_world_build_id.o
+ $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(XSPLICE_BYE) \
+ xen_bye_world_func.o xen_bye_world.o hello_world_build_id.o
diff --git a/xen/arch/x86/test/xen_bye_world.c b/xen/arch/x86/test/xen_bye_world.c
new file mode 100644
index 0000000..f9e3b8a
--- /dev/null
+++ b/xen/arch/x86/test/xen_bye_world.c
@@ -0,0 +1,34 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/types.h>
+#include <xen/xsplice_patch.h>
+#include <xen/xsplice.h>
+#include "config.h"
+#include <xen/lib.h>
+
+static char xen_bye_world_name[] = "xen_bye_world";
+extern const char *xen_bye_world(void);
+
+/* External symbol. */
+extern const char *xen_extra_version(void);
+
+struct xsplice_patch_func __section(".xsplice.funcs") xsplice_xen_bye_world = {
+ .name = xen_bye_world_name,
+ .new_addr = (unsigned long)(xen_bye_world),
+ .old_addr = (unsigned long)(xen_extra_version),
+ .new_size = NEW_CODE_SZ,
+ .old_size = OLD_CODE_SZ,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/test/xen_bye_world_func.c b/xen/arch/x86/test/xen_bye_world_func.c
new file mode 100644
index 0000000..574268c
--- /dev/null
+++ b/xen/arch/x86/test/xen_bye_world_func.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <asm/nops.h>
+#include <asm/alternative.h>
+
+/* Our replacement function for xen_hello_world. */
+const char *xen_bye_world(void)
+{
+ return "Bye World!";
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/common/Kconfig b/xen/common/Kconfig
index d80dddb..0b8917c 100644
--- a/xen/common/Kconfig
+++ b/xen/common/Kconfig
@@ -54,6 +54,10 @@ config HAS_GDBSX
config HAS_IOPORTS
bool
+config HAS_BUILD_ID
+ string
+ option env="XEN_HAS_BUILD_ID"
+
# Enable/Disable kexec support
config KEXEC
bool "kexec support"
@@ -186,7 +190,7 @@ endmenu
config XSPLICE
bool "xSplice live patching support"
default n
- depends on X86
+ depends on X86 && HAS_BUILD_ID = "y"
---help---
Allows a running Xen hypervisor to be dynamically patched using
binary patches without rebooting. This is primarily used to binarily
diff --git a/xen/common/version.c b/xen/common/version.c
index 35078c7..b722a38 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -70,10 +70,29 @@ const char *xen_deny(void)
/* Defined in linker script. */
extern const Elf_Note __note_gnu_build_id_start[], __note_gnu_build_id_end[];
+int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
+{
+ /* Check if we really have a build-id. */
+ if ( NT_GNU_BUILD_ID != n->type )
+ return -ENODATA;
+
+ /* Sanity check, name should be "GNU" for ld-generated build-id. */
+ if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
+ return -ENODATA;
+
+ if ( len )
+ *len = n->descsz;
+ if ( p )
+ *p = ELFNOTE_DESC(n);
+
+ return 0;
+}
+
int xen_build_id(const void **p, unsigned int *len)
{
const Elf_Note *n = __note_gnu_build_id_start;
static bool_t checked = 0;
+ int rc;
if ( checked )
{
@@ -89,23 +108,20 @@ int xen_build_id(const void **p, unsigned int *len)
if ( &n[1] > __note_gnu_build_id_end )
return -ENODATA;
- /* Check if we really have a build-id. */
- if ( NT_GNU_BUILD_ID != n->type )
- return -ENODATA;
-
- /* Sanity check, name should be "GNU" for ld-generated build-id. */
- if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
- return -ENODATA;
-
- *len = n->descsz;
- *p = ELFNOTE_DESC(n);
+ rc = xen_build_id_check(n, p, len);
+ if ( !rc )
+ checked = 1;
- checked = 1;
- return 0;
+ return rc;
}
#else
+int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
+{
+ return -ENODATA;
+}
+
int xen_build_id(const void **p, unsigned int *len)
{
return -ENODATA;
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index ec47f31..d7a65fe 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -4,6 +4,7 @@
*/
#include <xen/cpu.h>
+#include <xen/elf.h>
#include <xen/err.h>
#include <xen/guest_access.h>
#include <xen/keyhandler.h>
@@ -68,6 +69,8 @@ struct payload {
xsplice_unloadcall_t *unload_funcs; /* load and unload of the payload. */
unsigned int n_load_funcs; /* Nr of the funcs to load and execute. */
unsigned int n_unload_funcs; /* Nr of funcs to call durung unload. */
+ struct xsplice_build_id id; /* ELFNOTE_DESC(.note.gnu.build-id) of the payload. */
+ struct xsplice_build_id dep; /* ELFNOTE_DESC(.xsplice.depends). */
char name[XEN_XSPLICE_NAME_SIZE]; /* Name of it. */
};
@@ -440,7 +443,9 @@ static int check_special_sections(struct payload *payload,
struct xsplice_elf *elf)
{
unsigned int i;
- static const char *const names[] = { ".xsplice.funcs" };
+ static const char *const names[] = { ".xsplice.funcs" ,
+ ".xsplice.depends",
+ ".note.gnu.build-id"};
for ( i = 0; i < ARRAY_SIZE(names); i++ )
{
@@ -461,6 +466,8 @@ static int check_special_sections(struct payload *payload,
return 0;
}
+#define NT_GNU_BUILD_ID 3
+
static int prepare_payload(struct payload *payload,
struct xsplice_elf *elf)
{
@@ -468,6 +475,7 @@ static int prepare_payload(struct payload *payload,
unsigned int i;
struct xsplice_patch_func *f;
struct virtual_region *region;
+ Elf_Note *n;
sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs");
if ( sec )
@@ -545,6 +553,33 @@ static int prepare_payload(struct payload *payload,
payload->n_unload_funcs = sec->sec->sh_size / (sizeof *payload->unload_funcs);
}
+ sec = xsplice_elf_sec_by_name(elf, ".note.gnu.build-id");
+ if ( sec )
+ {
+ n = (Elf_Note *)sec->load_addr;
+ if ( sec->sec->sh_size <= sizeof *n )
+ return -EINVAL;
+
+ if ( xen_build_id_check(n, &payload->id.p, &payload->id.len) )
+ return -EINVAL;
+
+ if ( !payload->id.len || !payload->id.p )
+ return -EINVAL;
+ }
+
+ sec = xsplice_elf_sec_by_name(elf, ".xsplice.depends");
+ {
+ n = (Elf_Note *)sec->load_addr;
+ if ( sec->sec->sh_size <= sizeof *n )
+ return -EINVAL;
+
+ if ( xen_build_id_check(n, &payload->dep.p, &payload->dep.len) )
+ return -EINVAL;
+
+ if ( !payload->dep.len || !payload->dep.p )
+ return -EINVAL;
+ }
+
/* Setup the virtual region with proper data. */
region = &payload->region;
@@ -1261,6 +1296,54 @@ void check_for_xsplice_work(void)
}
}
+/*
+ * Only allow dependent payload is applied on top of the correct
+ * build-id.
+ *
+ * This enforces an stacking order - the first payload MUST be against the
+ * hypervisor. The second against the first payload, and so on.
+ *
+ * Unless the 'ignore' parameter is used - in which case we only
+ * check against the hypervisor.
+ */
+static int build_id_dep(struct payload *payload, bool_t ignore)
+{
+ const void *id = NULL;
+ unsigned int len = 0;
+ int rc;
+ const char *name = "hypervisor";
+
+ ASSERT(payload->dep.len && payload->dep.p);
+
+ /* First time user is against hypervisor. */
+ if ( ignore || list_empty(&applied_list) )
+ {
+ rc = xen_build_id(&id, &len);
+ if ( rc )
+ return rc;
+ }
+ else
+ {
+ /* We should be against the last applied one. */
+ struct payload *data = list_last_entry(&applied_list, struct payload,
+ applied_list);
+
+ id = data->id.p;
+ len = data->id.len;
+ name = data->name;
+ }
+
+ if ( payload->dep.len != len ||
+ memcmp(id, payload->dep.p, len) )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: check against %s build-id failed!\n",
+ XSPLICE, payload->name, name);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static int xsplice_action(xen_sysctl_xsplice_action_t *action)
{
struct payload *data;
@@ -1304,6 +1387,18 @@ static int xsplice_action(xen_sysctl_xsplice_action_t *action)
case XSPLICE_ACTION_REVERT:
if ( data->state == XSPLICE_STATE_APPLIED )
{
+ struct payload *p = list_last_entry(&applied_list, struct payload,
+ applied_list);
+
+ ASSERT(p);
+ /* We should be the last applied one. */
+ if ( p != data )
+ {
+ dprintk(XENLOG_DEBUG, "%s%s: can't unload. Top is %s!\n",
+ XSPLICE, data->name, p->name);
+ rc = -EBUSY;
+ break;
+ }
data->rc = -EAGAIN;
rc = schedule_work(data, action->cmd, action->timeout);
}
@@ -1312,6 +1407,9 @@ static int xsplice_action(xen_sysctl_xsplice_action_t *action)
case XSPLICE_ACTION_APPLY:
if ( data->state == XSPLICE_STATE_CHECKED )
{
+ rc = build_id_dep(data, 0 /* against top one. */);
+ if ( rc )
+ break;
data->rc = -EAGAIN;
rc = schedule_work(data, action->cmd, action->timeout);
}
@@ -1320,6 +1418,9 @@ static int xsplice_action(xen_sysctl_xsplice_action_t *action)
case XSPLICE_ACTION_REPLACE:
if ( data->state == XSPLICE_STATE_CHECKED )
{
+ rc = build_id_dep(data, 1 /* against hypervisor. */);
+ if ( rc )
+ break;
data->rc = -EAGAIN;
rc = schedule_work(data, action->cmd, action->timeout);
}
diff --git a/xen/include/xen/version.h b/xen/include/xen/version.h
index 4b57e18..a06bb61 100644
--- a/xen/include/xen/version.h
+++ b/xen/include/xen/version.h
@@ -17,4 +17,7 @@ const char *xen_deny(void);
#include <xen/types.h>
int xen_build_id(const void **p, unsigned int *len);
+#include <xen/elfstructs.h>
+int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len);
+
#endif /* __XEN_VERSION_H__ */
diff --git a/xen/include/xen/xsplice.h b/xen/include/xen/xsplice.h
index 47ef1c2..fa50fb5 100644
--- a/xen/include/xen/xsplice.h
+++ b/xen/include/xen/xsplice.h
@@ -40,6 +40,11 @@ struct xsplice_symbol {
bool_t new_symbol;
};
+struct xsplice_build_id {
+ const void *p;
+ unsigned int len;
+};
+
int xsplice_op(struct xen_sysctl_xsplice_op *);
void check_for_xsplice_work(void);
bool_t is_patch(const void *addr);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 24/28] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (22 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 23/28] xsplice: Stacking build-id dependency checking Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler Konrad Rzeszutek Wilk
` (3 subsequent siblings)
27 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Jan Beulich, Konrad Rzeszutek Wilk
With this third payload one can do:
-bash-4.1# xen-xsplice load xen_hello_world.xsplice
Uploading xen_hello_world.xsplice (10148 bytes)
Performing check: completed
Performing apply:. completed
[xen_hello_world depends on hypervisor build-id]
-bash-4.1# xen-xsplice load xen_bye_world.xsplice
Uploading xen_bye_world.xsplice (7076 bytes)
Performing check: completed
Performing apply:. completed
[xen_bye_world depends on xen_hello_world build-id]
-bash-4.1# xen-xsplice upload xen_replace_world xen_replace_world.xsplice
Uploading xen_replace_world.xsplice (7148 bytes)
-bash-4.1# xen-xsplice list
ID | status
----------------------------------------+------------
xen_hello_world | APPLIED
xen_bye_world | APPLIED
xen_replace_world | CHECKED
-bash-4.1# xen-xsplice replace xen_replace_world
Performing replace:. completed
-bash-4.1# xl info | grep extra
xen_extra : Hello Again World!
-bash-4.1# xen-xsplice list
ID | status
----------------------------------------+------------
xen_hello_world | CHECKED
xen_bye_world | CHECKED
xen_replace_world | APPLIED
and revert both of the previous payloads and apply
the xen_replace_world.
All the magic of this is in the Makefile - we extract
the build-id from the hypervisor (xen-syms) and jam it
in the xen_replace_world as .xsplice.depends.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v4: New. Make the objcopy use -S to strip the name.
---
---
.gitignore | 1 +
xen/arch/x86/test/Makefile | 8 +++++++
xen/arch/x86/test/xen_replace_world.c | 35 ++++++++++++++++++++++++++++++
xen/arch/x86/test/xen_replace_world_func.c | 25 +++++++++++++++++++++
4 files changed, 69 insertions(+)
create mode 100644 xen/arch/x86/test/xen_replace_world.c
create mode 100644 xen/arch/x86/test/xen_replace_world_func.c
diff --git a/.gitignore b/.gitignore
index f1cadcf..0d373e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -248,6 +248,7 @@ xen/arch/x86/efi/mkreloc
xen/arch/x86/test/config.h
xen/arch/x86/test/xen_hello_world.xsplice
xen/arch/x86/test/xen_bye_world.xsplice
+xen/arch/x86/test/xen_replace_world.xsplice
xen/arch/*/efi/boot.c
xen/arch/*/efi/compat.c
xen/arch/*/efi/efi.h
diff --git a/xen/arch/x86/test/Makefile b/xen/arch/x86/test/Makefile
index 8d355fb..99e5399 100644
--- a/xen/arch/x86/test/Makefile
+++ b/xen/arch/x86/test/Makefile
@@ -8,15 +8,18 @@ ifdef CONFIG_XSPLICE
XSPLICE := xen_hello_world.xsplice
XSPLICE_BYE := xen_bye_world.xsplice
+XSPLICE_REPLACE := xen_replace_world.xsplice
default: xsplice
install: xsplice
$(INSTALL_DATA) $(XSPLICE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
$(INSTALL_DATA) $(XSPLICE_BYE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_BYE)
+ $(INSTALL_DATA) $(XSPLICE_REPLACE) $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_REPLACE)
uninstall:
rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE)
rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_BYE)
+ rm -f $(DESTDIR)$(DEBUG_DIR)/$(XSPLICE_REPLACE)
else
@@ -80,3 +83,8 @@ xsplice: config.h build_id.o
$(MAKE) -f $(BASEDIR)/Rules.mk hello_world_build_id.o
$(LD) $(LDFLAGS) $(build_id_linker) -r -o $(XSPLICE_BYE) \
xen_bye_world_func.o xen_bye_world.o hello_world_build_id.o
+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_replace_world_func.o
+ $(MAKE) -f $(BASEDIR)/Rules.mk xen_replace_world.o
+ $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(XSPLICE_REPLACE) \
+ xen_replace_world_func.o \
+ xen_replace_world.o build_id.o
diff --git a/xen/arch/x86/test/xen_replace_world.c b/xen/arch/x86/test/xen_replace_world.c
new file mode 100644
index 0000000..72871f7
--- /dev/null
+++ b/xen/arch/x86/test/xen_replace_world.c
@@ -0,0 +1,35 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <xen/xsplice_patch.h>
+#include <xen/xsplice.h>
+#include "config.h"
+#include <xen/lib.h>
+
+static char xen_replace_world_name[] = "xen_replace_world";
+extern const char *xen_replace_world(void);
+
+/* External symbol. */
+extern const char *xen_extra_version(void);
+
+struct xsplice_patch_func __section(".xsplice.funcs") xsplice_xen_replace_world = {
+ .name = xen_replace_world_name,
+ .new_addr = (unsigned long)(xen_replace_world),
+ .old_addr = (unsigned long)(xen_extra_version),
+ .new_size = NEW_CODE_SZ,
+ .old_size = OLD_CODE_SZ,
+};
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
diff --git a/xen/arch/x86/test/xen_replace_world_func.c b/xen/arch/x86/test/xen_replace_world_func.c
new file mode 100644
index 0000000..75ee3b5
--- /dev/null
+++ b/xen/arch/x86/test/xen_replace_world_func.c
@@ -0,0 +1,25 @@
+/*
+ * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
+ *
+ */
+
+#include <xen/config.h>
+#include <xen/types.h>
+#include <asm/nops.h>
+#include <asm/alternative.h>
+
+/* Our replacement function for xen_hello_world. */
+const char *xen_replace_world(void)
+{
+ return "Hello Again World!";
+}
+
+/*
+ * Local variables:
+ * mode: C
+ * c-file-style: "BSD"
+ * c-basic-offset: 4
+ * tab-width: 4
+ * indent-tabs-mode: nil
+ * End:
+ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (23 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 24/28] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-04 15:03 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded Konrad Rzeszutek Wilk
` (2 subsequent siblings)
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
---
xen/common/xsplice.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index d7a65fe..d5d4b3c 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -1514,6 +1514,11 @@ static void xsplice_printall(unsigned char key)
if ( !(i % 100) )
process_pending_softirqs();
}
+ if ( data->id.len )
+ printk("build-id=%*phN\n", data->id.len, data->id.p);
+
+ if ( data->dep.len )
+ printk("depend-on=%*phN\n", data->dep.len, data->dep.p);
}
spin_unlock_recursive(&payload_lock);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (24 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-04 15:06 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 27/28] xsplice: Add support for shadow variables Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 28/28] MAINTAINERS/xsplice: Add myself and Ross as the maintainers Konrad Rzeszutek Wilk
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
---
---
xen/common/xsplice.c | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/xen/common/xsplice.c b/xen/common/xsplice.c
index d5d4b3c..a03b81a 100644
--- a/xen/common/xsplice.c
+++ b/xen/common/xsplice.c
@@ -566,6 +566,27 @@ static int prepare_payload(struct payload *payload,
if ( !payload->id.len || !payload->id.p )
return -EINVAL;
}
+ /* Make sure it is not a duplicate. */
+ if ( payload->id.len )
+ {
+ struct payload *data;
+
+ spin_lock_recursive(&payload_lock);
+ list_for_each_entry ( data, &payload_list, list )
+ {
+ /* No way payload is on the list. */
+ ASSERT( data != payload );
+ if ( data->id.len &&
+ !memcmp(data->id.p, payload->id.p, data->id.len) )
+ {
+ spin_unlock_recursive(&payload_lock);
+ dprintk(XENLOG_DEBUG, "%s%s: Already loaded as %s!\n",
+ XSPLICE, elf->name, data->name);
+ return -EEXIST;
+ }
+ }
+ spin_unlock_recursive(&payload_lock);
+ }
sec = xsplice_elf_sec_by_name(elf, ".xsplice.depends");
{
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 27/28] xsplice: Add support for shadow variables.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (25 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
2016-04-04 15:18 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 28/28] MAINTAINERS/xsplice: Add myself and Ross as the maintainers Konrad Rzeszutek Wilk
27 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Ian Jackson, Jan Beulich, Tim Deegan
From: Ross Lagerwall <ross.lagerwall@citrix.com>
Shadow variables are a piece of infrastructure to be used by xsplice
modules. They are used to attach a new piece of data to an existing
structure in memory.
Martin Pohlack also mentions that using the SHADOW_SLOTS of small
prime numbers has the advantage of having a simple hash function.
Using round numbers (such as 256) will give "lot's of hash collisions
at the price of very fast hash computations as compilers, linkers, and
memory allocators tend to align starting addresses." (Martin)
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v4: Add Copyright
v5: Change SHADOW_SLOTS to 257 per Martin's suggestion.
---
---
xen/common/Makefile | 1 +
xen/common/xsplice_shadow.c | 109 ++++++++++++++++++++++++++++++++++++++++
xen/include/xen/xsplice_patch.h | 36 +++++++++++++
3 files changed, 146 insertions(+)
create mode 100644 xen/common/xsplice_shadow.c
diff --git a/xen/common/Makefile b/xen/common/Makefile
index afd84b6..8371e2c 100644
--- a/xen/common/Makefile
+++ b/xen/common/Makefile
@@ -60,6 +60,7 @@ obj-$(CONFIG_XENOPROF) += xenoprof.o
obj-y += xmalloc_tlsf.o
obj-$(CONFIG_XSPLICE) += xsplice.o
obj-$(CONFIG_XSPLICE) += xsplice_elf.o
+obj-$(CONFIG_XSPLICE) += xsplice_shadow.o
obj-bin-$(CONFIG_X86) += $(foreach n,decompress bunzip2 unxz unlzma unlzo unlz4 earlycpio,$(n).init.o)
diff --git a/xen/common/xsplice_shadow.c b/xen/common/xsplice_shadow.c
new file mode 100644
index 0000000..8c63d62
--- /dev/null
+++ b/xen/common/xsplice_shadow.c
@@ -0,0 +1,109 @@
+/*
+ * Copyright (C) 2016 Citrix Systems R&D Ltd.
+ */
+
+#include <xen/init.h>
+#include <xen/kernel.h>
+#include <xen/lib.h>
+#include <xen/list.h>
+#include <xen/spinlock.h>
+#include <xen/xsplice_patch.h>
+
+#define SHADOW_SLOTS 257
+struct hlist_head shadow_tbl[SHADOW_SLOTS];
+static DEFINE_SPINLOCK(shadow_lock);
+
+struct shadow_var {
+ struct hlist_node list; /* Linked to 'shadow_tbl' */
+ void *data;
+ const void *obj;
+ char var[16];
+};
+
+void *xsplice_shadow_alloc(const void *obj, const char *var, size_t size)
+{
+ struct shadow_var *shadow;
+ unsigned int slot;
+
+ shadow = xmalloc(struct shadow_var);
+ if ( !shadow )
+ return NULL;
+
+ shadow->obj = obj;
+ strlcpy(shadow->var, var, sizeof shadow->var);
+ shadow->data = xmalloc_bytes(size);
+ if ( !shadow->data )
+ {
+ xfree(shadow);
+ return NULL;
+ }
+
+ slot = (unsigned long)obj % SHADOW_SLOTS;
+ spin_lock(&shadow_lock);
+ hlist_add_head(&shadow->list, &shadow_tbl[slot]);
+ spin_unlock(&shadow_lock);
+
+ return shadow->data;
+}
+
+void xsplice_shadow_free(const void *obj, const char *var)
+{
+ struct shadow_var *entry, *shadow = NULL;
+ unsigned int slot;
+ struct hlist_node *next;
+
+ slot = (unsigned long)obj % SHADOW_SLOTS;
+
+ spin_lock(&shadow_lock);
+ hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
+ {
+ if ( entry->obj == obj &&
+ !strcmp(entry->var, var) )
+ {
+ shadow = entry;
+ break;
+ }
+ }
+ if (shadow)
+ {
+ hlist_del(&shadow->list);
+ xfree(shadow->data);
+ xfree(shadow);
+ }
+ spin_unlock(&shadow_lock);
+}
+
+void *xsplice_shadow_get(const void *obj, const char *var)
+{
+ struct shadow_var *entry;
+ unsigned int slot;
+ struct hlist_node *next;
+ void *ret = NULL;
+
+ slot = (unsigned long)obj % SHADOW_SLOTS;
+
+ spin_lock(&shadow_lock);
+ hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
+ {
+ if ( entry->obj == obj &&
+ !strcmp(entry->var, var) )
+ {
+ ret = entry->data;
+ break;
+ }
+ }
+
+ spin_unlock(&shadow_lock);
+ return ret;
+}
+
+static int __init xsplice_shadow_init(void)
+{
+ int i;
+
+ for ( i = 0; i < SHADOW_SLOTS; i++ )
+ INIT_HLIST_HEAD(&shadow_tbl[i]);
+
+ return 0;
+}
+__initcall(xsplice_shadow_init);
diff --git a/xen/include/xen/xsplice_patch.h b/xen/include/xen/xsplice_patch.h
index 19d3f76..e297fe1 100644
--- a/xen/include/xen/xsplice_patch.h
+++ b/xen/include/xen/xsplice_patch.h
@@ -56,4 +56,40 @@ typedef void (*xsplice_unloadcall_t)(void);
#define XSPLICE_UNLOAD_HOOK(_fn) \
xsplice_unloadcall_t __attribute__((weak)) xsplice_unload_data __section(".xsplice.hooks.unload") = _fn;
+
+/*
+ * The following definitions are to be used in patches. They are taken
+ * from kpatch.
+ */
+
+/*
+ * xsplice shadow variables
+ *
+ * These functions can be used to add new "shadow" fields to existing data
+ * structures. For example, to allocate a "newpid" variable associated with an
+ * instance of task_struct, and assign it a value of 1000:
+ *
+ * struct task_struct *tsk = current;
+ * int *newpid;
+ * newpid = xsplice_shadow_alloc(tsk, "newpid", sizeof(int));
+ * if (newpid)
+ * *newpid = 1000;
+ *
+ * To retrieve a pointer to the variable:
+ *
+ * struct task_struct *tsk = current;
+ * int *newpid;
+ * newpid = xsplice_shadow_get(tsk, "newpid");
+ * if (newpid)
+ * printk("task newpid = %d\n", *newpid); // prints "task newpid = 1000"
+ *
+ * To free it:
+ *
+ * xsplice_shadow_free(tsk, "newpid");
+ */
+
+void *xsplice_shadow_alloc(const void *obj, const char *var, size_t size);
+void xsplice_shadow_free(const void *obj, const char *var);
+void *xsplice_shadow_get(const void *obj, const char *var);
+
#endif /* __XEN_XSPLICE_PATCH_H__ */
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* [PATCH v5 28/28] MAINTAINERS/xsplice: Add myself and Ross as the maintainers.
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
` (26 preceding siblings ...)
2016-03-24 20:00 ` [PATCH v5 27/28] xsplice: Add support for shadow variables Konrad Rzeszutek Wilk
@ 2016-03-24 20:00 ` Konrad Rzeszutek Wilk
27 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 20:00 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Keir Fraser, Tim Deegan, Ian Jackson, Jan Beulich, Konrad Rzeszutek Wilk
If you have a patch for xSplice send it our way!
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v5: Sort them F: fields (Jan)
---
---
MAINTAINERS | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 52cc538..64036e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -420,6 +420,16 @@ F: xen/include/xsm/
F: xen/xsm/
F: docs/misc/xsm-flask.txt
+XSPLICE
+M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+M: Ross Lagerwall <ross.lagerwall@citrix.com>
+S: Supported
+F: docs/misc/xsplice.markdown
+F: tools/misc/xen-xsplice.c
+F: xen/arch/*/xsplice*
+F: xen/common/xsplice*
+F: xen/include/xen/xsplice*
+
THE REST
M: Ian Jackson <ian.jackson@eu.citrix.com>
M: Jan Beulich <jbeulich@suse.com>
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-24 20:00 ` [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane Konrad Rzeszutek Wilk
@ 2016-03-24 20:22 ` Andrew Cooper
2016-03-24 21:07 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Andrew Cooper @ 2016-03-24 20:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, xen-devel, ross.lagerwall, konrad,
mpohlack, sasha.levin
Cc: Wei Liu, Stefano Stabellini, Ian Jackson, Julien Grall,
Stefano Stabellini, Jan Beulich, Keir Fraser, Daniel De Graaf
On 24/03/16 20:00, Konrad Rzeszutek Wilk wrote:
> This hypercall mirrors the XENVER_ in that it has similar functionality.
> However it is designed differently:
> - No compat layer. The data structures are the same size on 32
> as on 64-bit.
> - The hypercall accepts three arguments - the command, pointer to
> an buffer, and the length of the buffer.
"a buffer"
> +/* Computed by kernel_cache_init. */
> +static xen_capabilities_info_t __read_mostly cached_cap;
> +static unsigned int __read_mostly cached_cap_len;
> +
> +/*
> + * Similar to HYPERVISOR_xen_version but with a sane interface
> + * (has a length, one can probe for the length) and with one less sub-ops:
> + * missing XENVER_compile_info.
> + */
> +DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
> + unsigned int len)
> +{
> + union {
> + xen_version_op_val_t val;
> + xen_feature_info_t fi;
> + } u = {};
> + unsigned int sz = 0;
> + const void *ptr = NULL;
> + int rc = xsm_version_op(XSM_OTHER, cmd);
> +
> + /* We can safely return -EPERM! */
> + if ( rc )
> + return rc;
> +
> + /*
> + * The HYPERVISOR_xen_version differs in that some return the value,
> + * and some copy it on back on argument. We follow the same rule for all
> + * sub-ops: return 0 on success, positive value of bytes returned, and
You can't return both 0 and a positive number for success. I would
recommend "return the number of bytes written, or negative errno on
failure".
Other than these, LGTM.
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-24 20:22 ` Andrew Cooper
@ 2016-03-24 21:07 ` Konrad Rzeszutek Wilk
2016-03-24 21:30 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 21:07 UTC (permalink / raw)
To: Andrew Cooper, xen-devel, ross.lagerwall, konrad, mpohlack, sasha.levin
Cc: Wei Liu, Stefano Stabellini, Ian Jackson, Julien Grall,
Stefano Stabellini, Jan Beulich, Keir Fraser, Daniel De Graaf
On March 24, 2016 4:22:29 PM EDT, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>On 24/03/16 20:00, Konrad Rzeszutek Wilk wrote:
>> This hypercall mirrors the XENVER_ in that it has similar
>functionality.
>> However it is designed differently:
>> - No compat layer. The data structures are the same size on 32
>> as on 64-bit.
>> - The hypercall accepts three arguments - the command, pointer to
>> an buffer, and the length of the buffer.
>
>"a buffer"
>
>> +/* Computed by kernel_cache_init. */
>> +static xen_capabilities_info_t __read_mostly cached_cap;
>> +static unsigned int __read_mostly cached_cap_len;
>> +
>> +/*
>> + * Similar to HYPERVISOR_xen_version but with a sane interface
>> + * (has a length, one can probe for the length) and with one less
>sub-ops:
>> + * missing XENVER_compile_info.
>> + */
>> +DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
>> + unsigned int len)
>> +{
>> + union {
>> + xen_version_op_val_t val;
>> + xen_feature_info_t fi;
>> + } u = {};
>> + unsigned int sz = 0;
>> + const void *ptr = NULL;
>> + int rc = xsm_version_op(XSM_OTHER, cmd);
>> +
>> + /* We can safely return -EPERM! */
>> + if ( rc )
>> + return rc;
>> +
>> + /*
>> + * The HYPERVISOR_xen_version differs in that some return the
>value,
>> + * and some copy it on back on argument. We follow the same rule
>for all
>> + * sub-ops: return 0 on success, positive value of bytes
>returned, and
>
>You can't return both 0 and a positive number for success. I would
>recommend "return the number of bytes written, or negative errno on
>failure".
Thanks!
And Argh!
I neglected to change the name of kernel_cache_init as Jan requested.
>
>Other than these, LGTM.
>
>Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Yeey!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall
2016-03-24 20:00 ` [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall Konrad Rzeszutek Wilk
@ 2016-03-24 21:24 ` Wei Liu
2016-03-25 13:21 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Wei Liu @ 2016-03-24 21:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, ross.lagerwall, George Dunlap, andrew.cooper3,
Stefano Stabellini, Ian Jackson, mpohlack, Julien Grall,
sasha.levin, David Scott, xen-devel
On Thu, Mar 24, 2016 at 04:00:14PM -0400, Konrad Rzeszutek Wilk wrote:
[...]
> +
> +static int libxl__xc_version_wrapper(libxl__gc *gc, unsigned int cmd, char *buf, ssize_t len, char **dst)
Please wrap this long line.
> +{
> + int r;
> +
> + r = xc_version(CTX->xch, cmd, buf, len);
> + if ( r == -EPERM )
> + {
> + buf[0] = '\0';
> + }
> + else if ( r < 0 )
> + {
> + return r;
> + }
if (r == -EPERM) {
buf[0] = '\0';
} else if (r < 0) {
return r;
}
You seem to have mixed different coding styles ...
With those nits fixed:
Acked-by: Wei Liu <wei.liu2@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-24 21:07 ` Konrad Rzeszutek Wilk
@ 2016-03-24 21:30 ` Konrad Rzeszutek Wilk
2016-03-30 15:43 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-24 21:30 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
Jan Beulich, xen-devel, sasha.levin, Daniel De Graaf,
Keir Fraser
> Thanks!
>
> And Argh!
>
> I neglected to change the name of kernel_cache_init as Jan requested.
Jan, here is an updated patch. I changed the name to
capabilities_cache_init. Sorry about that!
From e766ddb37acda16c3adbd65179d532b9381bda8e Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Tue, 22 Mar 2016 16:53:19 -0400
Subject: [PATCH] HYPERCALL_version_op. New hypercall mirroring XENVER_ but
sane.
This hypercall mirrors the XENVER_ in that it has similar functionality.
However it is designed differently:
- No compat layer. The data structures are the same size on 32
as on 64-bit.
- The hypercall accepts three arguments - the command, pointer to
an buffer, and the length of the buffer.
- Each sub-ops can be "probed" for size by returning the size of
buffer that will be needed - if the buffer is NULL.
- Subops can complete even if the buffer is too small - truncated
data will be filled and hypercall will return -ENOBUFS.
- VERSION_commandline, VERSION_changeset are privileged.
- There is no XENVER_compile_info equivalent.
- The hypercall can return -EPERM and toolstack/OSes are expected
to deal with. However there are three subops: XEN_VERSION_version,
XEN_VERSION_platform_parameters and XEN_VERSION_get_features
that will always return an value as guests cannot survive without them.
While we combine some of the common code between XENVER_ and VERSION_
take the liberty of moving pae_extended_cr3 in x86 area.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> [XSM bits]
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
---
Cc: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v1-v3: Was not part of the series.
v4: New posting.
v5: Remove memset and use {}. Tweak copy_to_guest and capabilities_info,
add ASSERT(sz) per Andrew's review. Add cached=1 back in.
Per Jan, s/VERSION_OP/VERSION/, squash size check with do_version_op,
update the comments. Dropped Andrew's Review-by. Ate newlines.
Added initcall to guard against garbage being set in cached data.
Folded code populating cache in __init. s/char/char[]/ in public.h
---
---
tools/flask/policy/policy/modules/xen/xen.te | 7 +-
xen/arch/arm/traps.c | 1 +
xen/arch/x86/hvm/hvm.c | 1 +
xen/arch/x86/x86_64/compat/entry.S | 2 +
xen/arch/x86/x86_64/entry.S | 2 +
xen/common/compat/kernel.c | 2 +
xen/common/kernel.c | 213 ++++++++++++++++++++++-----
xen/include/public/arch-arm.h | 2 +
xen/include/public/version.h | 70 ++++++++-
xen/include/public/xen.h | 1 +
xen/include/xen/hypercall.h | 4 +
xen/include/xsm/dummy.h | 21 +++
xen/include/xsm/xsm.h | 6 +
xen/xsm/dummy.c | 1 +
xen/xsm/flask/hooks.c | 35 +++++
xen/xsm/flask/policy/access_vectors | 21 ++-
16 files changed, 346 insertions(+), 43 deletions(-)
diff --git a/tools/flask/policy/policy/modules/xen/xen.te b/tools/flask/policy/policy/modules/xen/xen.te
index e174e48..7e69ce9 100644
--- a/tools/flask/policy/policy/modules/xen/xen.te
+++ b/tools/flask/policy/policy/modules/xen/xen.te
@@ -74,11 +74,12 @@ allow dom0_t xen_t:xen2 {
get_symbol
};
-# Allow dom0 to use all XENVER_ subops that have checks.
+# Allow dom0 to use all XENVER_ subops and VERSION subops that have checks.
# Note that dom0 is part of domain_type so this has duplicates.
allow dom0_t xen_t:version {
xen_extraversion xen_compile_info xen_capabilities
xen_changeset xen_pagesize xen_guest_handle xen_commandline
+ extraversion capabilities changeset pagesize guest_handle commandline
};
allow dom0_t xen_t:mmu memorymap;
@@ -145,10 +146,12 @@ if (guest_writeconsole) {
# pmu_ctrl is for)
allow domain_type xen_t:xen2 pmu_use;
-# For normal guests all possible except XENVER_commandline.
+# For normal guests all possible except XENVER_commandline, VERSION_changeset,
+# and VERSION_commandline
allow domain_type xen_t:version {
xen_extraversion xen_compile_info xen_capabilities
xen_changeset xen_pagesize xen_guest_handle
+ extraversion capabilities pagesize guest_handle
};
###############################################################################
diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 83744e8..31d2115 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -1235,6 +1235,7 @@ static arm_hypercall_t arm_hypercall_table[] = {
HYPERCALL(multicall, 2),
HYPERCALL(platform_op, 1),
HYPERCALL_ARM(vcpu_op, 3),
+ HYPERCALL(version_op, 3),
};
#ifndef NDEBUG
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 80d59ff..f16b590 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -5322,6 +5322,7 @@ static const struct {
COMPAT_CALL(platform_op),
COMPAT_CALL(mmuext_op),
HYPERCALL(xenpmu_op),
+ HYPERCALL(version_op),
HYPERCALL(arch_1)
};
diff --git a/xen/arch/x86/x86_64/compat/entry.S b/xen/arch/x86/x86_64/compat/entry.S
index 33e2c12..fd25e84 100644
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -394,6 +394,7 @@ ENTRY(compat_hypercall_table)
.quad do_tmem_op
.quad do_ni_hypercall /* reserved for XenClient */
.quad do_xenpmu_op /* 40 */
+ .quad do_version_op
.rept __HYPERVISOR_arch_0-((.-compat_hypercall_table)/8)
.quad compat_ni_hypercall
.endr
@@ -445,6 +446,7 @@ ENTRY(compat_hypercall_args_table)
.byte 1 /* do_tmem_op */
.byte 0 /* reserved for XenClient */
.byte 2 /* do_xenpmu_op */ /* 40 */
+ .byte 3 /* do_version_op */
.rept __HYPERVISOR_arch_0-(.-compat_hypercall_args_table)
.byte 0 /* compat_ni_hypercall */
.endr
diff --git a/xen/arch/x86/x86_64/entry.S b/xen/arch/x86/x86_64/entry.S
index 07ef096..b0e7257 100644
--- a/xen/arch/x86/x86_64/entry.S
+++ b/xen/arch/x86/x86_64/entry.S
@@ -730,6 +730,7 @@ ENTRY(hypercall_table)
.quad do_tmem_op
.quad do_ni_hypercall /* reserved for XenClient */
.quad do_xenpmu_op /* 40 */
+ .quad do_version_op
.rept __HYPERVISOR_arch_0-((.-hypercall_table)/8)
.quad do_ni_hypercall
.endr
@@ -781,6 +782,7 @@ ENTRY(hypercall_args_table)
.byte 1 /* do_tmem_op */
.byte 0 /* reserved for XenClient */
.byte 2 /* do_xenpmu_op */ /* 40 */
+ .byte 3 /* do_version_op */
.rept __HYPERVISOR_arch_0-(.-hypercall_args_table)
.byte 0 /* do_ni_hypercall */
.endr
diff --git a/xen/common/compat/kernel.c b/xen/common/compat/kernel.c
index df93fdd..7a7ca53 100644
--- a/xen/common/compat/kernel.c
+++ b/xen/common/compat/kernel.c
@@ -39,6 +39,8 @@ CHECK_TYPE(capabilities_info);
CHECK_TYPE(domain_handle);
+CHECK_TYPE(version_op_val);
+
#define xennmi_callback compat_nmi_callback
#define xennmi_callback_t compat_nmi_callback_t
diff --git a/xen/common/kernel.c b/xen/common/kernel.c
index a4a3c36..f6d2676 100644
--- a/xen/common/kernel.c
+++ b/xen/common/kernel.c
@@ -221,6 +221,47 @@ void __init do_initcalls(void)
#endif
+static int get_features(struct domain *d, xen_feature_info_t *fi)
+{
+ switch ( fi->submap_idx )
+ {
+ case 0:
+ fi->submap = (1U << XENFEAT_memory_op_vnode_supported);
+ if ( paging_mode_translate(d) )
+ fi->submap |=
+ (1U << XENFEAT_writable_page_tables) |
+ (1U << XENFEAT_auto_translated_physmap);
+ if ( is_hardware_domain(d) )
+ fi->submap |= 1U << XENFEAT_dom0;
+#ifdef CONFIG_X86
+ if ( VM_ASSIST(d, pae_extended_cr3) )
+ fi->submap |= (1U << XENFEAT_pae_pgdir_above_4gb);
+ switch ( d->guest_type )
+ {
+ case guest_type_pv:
+ fi->submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
+ (1U << XENFEAT_highmem_assist) |
+ (1U << XENFEAT_gnttab_map_avail_bits);
+ break;
+ case guest_type_pvh:
+ fi->submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+ (1U << XENFEAT_supervisor_mode_kernel) |
+ (1U << XENFEAT_hvm_callback_vector);
+ break;
+ case guest_type_hvm:
+ fi->submap |= (1U << XENFEAT_hvm_safe_pvclock) |
+ (1U << XENFEAT_hvm_callback_vector) |
+ (1U << XENFEAT_hvm_pirqs);
+ break;
+ }
+#endif
+ break;
+ default:
+ return -EINVAL;
+ }
+ return 0;
+}
+
/*
* Simple hypercalls.
*/
@@ -298,47 +339,14 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
case XENVER_get_features:
{
xen_feature_info_t fi;
- struct domain *d = current->domain;
+ int rc;
if ( copy_from_guest(&fi, arg, 1) )
return -EFAULT;
- switch ( fi.submap_idx )
- {
- case 0:
- fi.submap = (1U << XENFEAT_memory_op_vnode_supported);
- if ( VM_ASSIST(d, pae_extended_cr3) )
- fi.submap |= (1U << XENFEAT_pae_pgdir_above_4gb);
- if ( paging_mode_translate(d) )
- fi.submap |=
- (1U << XENFEAT_writable_page_tables) |
- (1U << XENFEAT_auto_translated_physmap);
- if ( is_hardware_domain(d) )
- fi.submap |= 1U << XENFEAT_dom0;
-#ifdef CONFIG_X86
- switch ( d->guest_type )
- {
- case guest_type_pv:
- fi.submap |= (1U << XENFEAT_mmu_pt_update_preserve_ad) |
- (1U << XENFEAT_highmem_assist) |
- (1U << XENFEAT_gnttab_map_avail_bits);
- break;
- case guest_type_pvh:
- fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
- (1U << XENFEAT_supervisor_mode_kernel) |
- (1U << XENFEAT_hvm_callback_vector);
- break;
- case guest_type_hvm:
- fi.submap |= (1U << XENFEAT_hvm_safe_pvclock) |
- (1U << XENFEAT_hvm_callback_vector) |
- (1U << XENFEAT_hvm_pirqs);
- break;
- }
-#endif
- break;
- default:
- return -EINVAL;
- }
+ rc = get_features(current->domain, &fi);
+ if ( rc )
+ return rc;
if ( __copy_to_guest(arg, &fi, 1) )
return -EFAULT;
@@ -381,6 +389,123 @@ DO(xen_version)(int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
return -ENOSYS;
}
+/* Computed by capabilities_cache_init. */
+static xen_capabilities_info_t __read_mostly cached_cap;
+static unsigned int __read_mostly cached_cap_len;
+
+/*
+ * Similar to HYPERVISOR_xen_version but with a sane interface
+ * (has a length, one can probe for the length) and with one less sub-ops:
+ * missing XENVER_compile_info.
+ */
+DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
+ unsigned int len)
+{
+ union {
+ xen_version_op_val_t val;
+ xen_feature_info_t fi;
+ } u = {};
+ unsigned int sz = 0;
+ const void *ptr = NULL;
+ int rc = xsm_version_op(XSM_OTHER, cmd);
+
+ /* We can safely return -EPERM! */
+ if ( rc )
+ return rc;
+
+ /*
+ * The HYPERVISOR_xen_version differs in that some return the value,
+ * and some copy it on back on argument. We follow the same rule for all
+ * sub-ops: return the number of bytes written, or negative errno on
+ * failure, and always copy the result in arg. Yeey sanity!
+ */
+ switch ( cmd )
+ {
+ case XEN_VERSION_version:
+ sz = sizeof(xen_version_op_val_t);
+ u.val = (xen_major_version() << 16) | xen_minor_version();
+ break;
+
+ case XEN_VERSION_extraversion:
+ sz = strlen(xen_extra_version()) + 1;
+ ptr = xen_extra_version();
+ break;
+
+ case XEN_VERSION_capabilities:
+ sz = cached_cap_len;
+ ptr = cached_cap;
+ break;
+
+ case XEN_VERSION_changeset:
+ sz = strlen(xen_changeset()) + 1;
+ ptr = xen_changeset();
+ break;
+
+ case XEN_VERSION_platform_parameters:
+ sz = sizeof(xen_version_op_val_t);
+ u.val = HYPERVISOR_VIRT_START;
+ break;
+
+ case XEN_VERSION_get_features:
+ sz = sizeof(xen_feature_info_t);
+
+ if ( guest_handle_is_null(arg) )
+ break;
+
+ if ( copy_from_guest(&u.fi, arg, 1) )
+ {
+ rc = -EFAULT;
+ break;
+ }
+ rc = get_features(current->domain, &u.fi);
+ break;
+
+ case XEN_VERSION_pagesize:
+ sz = sizeof(xen_version_op_val_t);
+ u.val = PAGE_SIZE;
+ break;
+
+ case XEN_VERSION_guest_handle:
+ sz = ARRAY_SIZE(current->domain->handle);
+ ptr = current->domain->handle;
+ break;
+
+ case XEN_VERSION_commandline:
+ sz = strlen(saved_cmdline) + 1;
+ ptr = saved_cmdline;
+ break;
+
+ default:
+ rc = -ENOSYS;
+ }
+
+ if ( rc )
+ return rc;
+
+ /*
+ * This hypercall also allows the client to probe. If it provides
+ * a NULL arg we will return the size of the space it has to
+ * allocate for the specific sub-op.
+ */
+ ASSERT(sz);
+ if ( guest_handle_is_null(arg) )
+ return sz;
+
+ if ( !rc )
+ {
+ unsigned int bytes = min(sz, len);
+
+ if ( copy_to_guest(arg, ptr ? : &u, bytes) )
+ rc = -EFAULT;
+
+ /* We return len (truncate) worth of data even if we fail. */
+ if ( !rc && sz > len )
+ rc = -ENOBUFS;
+ }
+
+ return rc == 0 ? sz : rc;
+}
+
DO(nmi_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
{
struct xennmi_callback cb;
@@ -418,6 +543,20 @@ DO(ni_hypercall)(void)
return -ENOSYS;
}
+static int __init capabilities_cache_init(void)
+{
+ /*
+ * Pre-allocate the cache so we do not have to worry about
+ * simultaneous invocations on safe_strcat by guests and the cache
+ * data becoming garbage.
+ */
+ arch_get_xen_caps(&cached_cap);
+ cached_cap_len = strlen(cached_cap) + 1;
+
+ return 0;
+}
+__initcall(capabilities_cache_init);
+
/*
* Local variables:
* mode: C
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index 870bc3b..5f90718 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -128,6 +128,8 @@
* * VCPUOP_register_vcpu_info
* * VCPUOP_register_runstate_memory_area
*
+ * HYPERVISOR_version_op
+ * All generic sub-operations
*
* Other notes on the ARM ABI:
*
diff --git a/xen/include/public/version.h b/xen/include/public/version.h
index 24a582f..d71ec5b 100644
--- a/xen/include/public/version.h
+++ b/xen/include/public/version.h
@@ -30,7 +30,14 @@
#include "xen.h"
-/* NB. All ops return zero on success, except XENVER_{version,pagesize} */
+/*
+ * There are two hypercalls mentioned in here. The XENVER_ are for
+ * HYPERCALL_xen_version (17), while VERSION_ are for the
+ * HYPERCALL_version_op (41).
+ *
+ * The subops are very similar except that the later hypercall has a
+ * sane interface.
+ */
/* arg == NULL; returns major:minor (16:16). */
#define XENVER_version 0
@@ -87,6 +94,67 @@ typedef struct xen_feature_info xen_feature_info_t;
#define XENVER_commandline 9
typedef char xen_commandline_t[1024];
+/*
+ * The HYPERCALL_version_op has a set of sub-ops which mirror the
+ * sub-ops of HYPERCALL_xen_version. However this hypercall differs
+ * radically from the former:
+ * - It returns the amount of bytes returned.
+ * - It will return -XEN_EPERM if the guest is not permitted
+ * (Albeit XEN_VERSION_version, XEN_VERSION_platform_parameters, and
+ * XEN_VERSION_get_features will always return an value as guest cannot
+ * survive without this information).
+ * - It will return the requested data in arg.
+ * - It requires an third argument (len) for the length of the
+ * arg. Naturally the arg has to fit the requested data otherwise
+ * -XEN_ENOBUFS is returned.
+ *
+ * It also offers an mechanism to probe for the amount of bytes an
+ * sub-op will require. Having the arg have an NULL handle will
+ * return the number of bytes requested for the operation. Or an
+ * negative value if an error is encountered.
+ */
+
+typedef uint64_t xen_version_op_val_t;
+DEFINE_XEN_GUEST_HANDLE(xen_version_op_val_t);
+
+/*
+ * arg == xen_version_op_val_t. Encoded as major:minor (31..16:15..0), while
+ * 63..32 are zero.
+ */
+#define XEN_VERSION_version 0
+
+/* arg == char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_extraversion 1
+
+/* arg == char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_capabilities 3
+
+/* arg == char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_changeset 4
+
+/* arg == xen_version_op_val_t. */
+#define XEN_VERSION_platform_parameters 5
+
+/*
+ * arg = xen_feature_info_t - shares the same structure
+ * as the XENVER_get_features.
+ */
+#define XEN_VERSION_get_features 6
+
+/* arg == xen_version_op_val_t. */
+#define XEN_VERSION_pagesize 7
+
+/*
+ * arg == void.
+ *
+ * The toolstack fills it out for guest consumption. It is intended to hold
+ * the UUID of the guest.
+ */
+#define XEN_VERSION_guest_handle 8
+
+/* arg = char[]. Contains NUL terminated utf-8 string. */
+#define XEN_VERSION_commandline 9
+
#endif /* __XEN_PUBLIC_VERSION_H__ */
/*
diff --git a/xen/include/public/xen.h b/xen/include/public/xen.h
index 64ba7ab..1a99929 100644
--- a/xen/include/public/xen.h
+++ b/xen/include/public/xen.h
@@ -115,6 +115,7 @@ DEFINE_XEN_GUEST_HANDLE(xen_ulong_t);
#define __HYPERVISOR_tmem_op 38
#define __HYPERVISOR_xc_reserved_op 39 /* reserved for XenClient */
#define __HYPERVISOR_xenpmu_op 40
+#define __HYPERVISOR_version_op 41 /* supersedes xen_version (17) */
/* Architecture-specific hypercall definitions. */
#define __HYPERVISOR_arch_0 48
diff --git a/xen/include/xen/hypercall.h b/xen/include/xen/hypercall.h
index 0c8ae0e..e8d2b81 100644
--- a/xen/include/xen/hypercall.h
+++ b/xen/include/xen/hypercall.h
@@ -147,6 +147,10 @@ do_xenoprof_op(int op, XEN_GUEST_HANDLE_PARAM(void) arg);
extern long
do_xenpmu_op(unsigned int op, XEN_GUEST_HANDLE_PARAM(xen_pmu_params_t) arg);
+extern long
+do_version_op(unsigned int cmd,
+ XEN_GUEST_HANDLE_PARAM(void) arg, unsigned int len);
+
#ifdef CONFIG_COMPAT
extern int
diff --git a/xen/include/xsm/dummy.h b/xen/include/xsm/dummy.h
index abbe282..e5dad35 100644
--- a/xen/include/xsm/dummy.h
+++ b/xen/include/xsm/dummy.h
@@ -751,3 +751,24 @@ static XSM_INLINE int xsm_xen_version (XSM_DEFAULT_ARG uint32_t op)
return xsm_default_action(XSM_PRIV, current->domain, NULL);
}
}
+
+static XSM_INLINE int xsm_version_op (XSM_DEFAULT_ARG uint32_t op)
+{
+ XSM_ASSERT_ACTION(XSM_OTHER);
+ switch ( op )
+ {
+ case XEN_VERSION_version:
+ case XEN_VERSION_platform_parameters:
+ case XEN_VERSION_get_features:
+ /* These MUST always be accessible to any guest by default. */
+ return 0;
+ case XEN_VERSION_extraversion:
+ case XEN_VERSION_capabilities:
+ case XEN_VERSION_pagesize:
+ case XEN_VERSION_guest_handle:
+ /* These can be accessible to a guest. */
+ return xsm_default_action(XSM_HOOK, current->domain, NULL);
+ default:
+ return xsm_default_action(XSM_PRIV, current->domain, NULL);
+ }
+}
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 5ecbee0..ac80472 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -194,6 +194,7 @@ struct xsm_operations {
int (*pmu_op) (struct domain *d, unsigned int op);
#endif
int (*xen_version) (uint32_t cmd);
+ int (*version_op) (uint32_t cmd);
};
#ifdef CONFIG_XSM
@@ -737,6 +738,11 @@ static inline int xsm_xen_version (xsm_default_t def, uint32_t op)
return xsm_ops->xen_version(op);
}
+static inline int xsm_version_op (xsm_default_t def, uint32_t op)
+{
+ return xsm_ops->version_op(op);
+}
+
#endif /* XSM_NO_WRAPPERS */
#ifdef CONFIG_MULTIBOOT
diff --git a/xen/xsm/dummy.c b/xen/xsm/dummy.c
index 9791ad4..776dd09 100644
--- a/xen/xsm/dummy.c
+++ b/xen/xsm/dummy.c
@@ -163,4 +163,5 @@ void xsm_fixup_ops (struct xsm_operations *ops)
set_to_dummy_if_null(ops, pmu_op);
#endif
set_to_dummy_if_null(ops, xen_version);
+ set_to_dummy_if_null(ops, version_op);
}
diff --git a/xen/xsm/flask/hooks.c b/xen/xsm/flask/hooks.c
index 2069cb3..1eaec58 100644
--- a/xen/xsm/flask/hooks.c
+++ b/xen/xsm/flask/hooks.c
@@ -1658,6 +1658,40 @@ static int flask_xen_version (uint32_t op)
}
}
+static int flask_version_op (uint32_t op)
+{
+ u32 dsid = domain_sid(current->domain);
+
+ switch ( op )
+ {
+ case XEN_VERSION_version:
+ case XEN_VERSION_platform_parameters:
+ case XEN_VERSION_get_features:
+ /* These MUST always be accessible to any guest by default. */
+ return 0;
+ case XEN_VERSION_extraversion:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__EXTRAVERSION, NULL);
+ case XEN_VERSION_capabilities:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__CAPABILITIES, NULL);
+ case XEN_VERSION_changeset:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__CHANGESET, NULL);
+ case XEN_VERSION_pagesize:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__PAGESIZE, NULL);
+ case XEN_VERSION_guest_handle:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__GUEST_HANDLE, NULL);
+ case XEN_VERSION_commandline:
+ return avc_has_perm(dsid, SECINITSID_XEN, SECCLASS_VERSION,
+ VERSION__COMMANDLINE, NULL);
+ default:
+ return -EPERM;
+ }
+}
+
long do_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
int compat_flask_op(XEN_GUEST_HANDLE_PARAM(xsm_op_t) u_flask_op);
@@ -1797,6 +1831,7 @@ static struct xsm_operations flask_ops = {
.pmu_op = flask_pmu_op,
#endif
.xen_version = flask_xen_version,
+ .version_op = flask_version_op,
};
static __init void flask_init(void)
diff --git a/xen/xsm/flask/policy/access_vectors b/xen/xsm/flask/policy/access_vectors
index badcf1c..56600bb 100644
--- a/xen/xsm/flask/policy/access_vectors
+++ b/xen/xsm/flask/policy/access_vectors
@@ -496,12 +496,14 @@ class security
del_ocontext
}
-# Class version is used to describe the XENVER_ hypercall.
+# Class version is used to describe the XENVER_ and VERSION hypercall.
# Almost all sub-ops are described here - in the default case all of them should
-# be allowed except the XENVER_commandline.
+# be allowed except the XENVER_commandline, VERSION_commandline, and
+# VERSION_changeset.
#
# The ones that are omitted are XENVER_version, XENVER_platform_parameters,
-# and XENVER_get_features - as they MUST always be returned to a guest.
+# XENVER_get_features, XEN_VERSION_version, XEN_VERSION_platform_parameters,
+# and XEN_VERSION_get_features - as they MUST always be returned to a guest.
#
class version
{
@@ -519,4 +521,17 @@ class version
xen_guest_handle
# Xen command line.
xen_commandline
+# --- VERSION hypercall ---
+# Extra informations (-unstable).
+ extraversion
+# Such as "xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64".
+ capabilities
+# Source code changeset.
+ changeset
+# Page size the hypervisor uses.
+ pagesize
+# An value that the control stack can choose.
+ guest_handle
+# Xen command line.
+ commandline
}
--
2.4.3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall
2016-03-24 21:24 ` Wei Liu
@ 2016-03-25 13:21 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-25 13:21 UTC (permalink / raw)
To: Wei Liu
Cc: ross.lagerwall, George Dunlap, andrew.cooper3,
Stefano Stabellini, Ian Jackson, mpohlack, Julien Grall,
sasha.levin, David Scott, xen-devel
On Thu, Mar 24, 2016 at 09:24:01PM +0000, Wei Liu wrote:
> On Thu, Mar 24, 2016 at 04:00:14PM -0400, Konrad Rzeszutek Wilk wrote:
> [...]
> > +
> > +static int libxl__xc_version_wrapper(libxl__gc *gc, unsigned int cmd, char *buf, ssize_t len, char **dst)
>
> Please wrap this long line.
>
> > +{
> > + int r;
> > +
> > + r = xc_version(CTX->xch, cmd, buf, len);
> > + if ( r == -EPERM )
> > + {
> > + buf[0] = '\0';
> > + }
> > + else if ( r < 0 )
> > + {
> > + return r;
> > + }
>
> if (r == -EPERM) {
> buf[0] = '\0';
> } else if (r < 0) {
> return r;
> }
>
>
> You seem to have mixed different coding styles ...
Duh! Yes!
>
> With those nits fixed:
>
> Acked-by: Wei Liu <wei.liu2@citrix.com>
Thank you!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id
2016-03-24 20:00 ` [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id Konrad Rzeszutek Wilk
@ 2016-03-25 13:25 ` Konrad Rzeszutek Wilk
2016-03-25 15:27 ` Wei Liu
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-25 13:25 UTC (permalink / raw)
To: xen-devel, ross.lagerwall, konrad, andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Ian Jackson, Stefano Stabellini
On Thu, Mar 24, 2016 at 04:00:33PM -0400, Konrad Rzeszutek Wilk wrote:
> If the hypervisor is built with we will display it.
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Acked-by: Wei Liu <wei.liu2@citrix.com>
Hey Wei,
It has you Ack, but I think when I carried over the change (it used
to be its own function with switch) I messed up the Style:
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 6c3ec40..310a7f3 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5277,8 +5278,24 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
>
> info->virt_start = val;
>
> - (void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> - info->pagesize, &info->commandline);
> + if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> + info->pagesize, &info->commandline) < 0)
> + goto out;
> +
> + r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
> + if (r < 0)
> + {
> + info->build_id = libxl__strdup(NOGC, "");
> + }
> + else if (r > 0)
> + {
> + unsigned int i;
> +
> + info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
> +
> + for (i = 0; i < r; i++)
> + snprintf(&info->build_id[i * 2], 3, "%02hhx", buf[i]);
> + }
> out:
> GC_FREE;
> return info;
So I fixed it up to be:
From bc4ed9d93162325342a37122fcab7223fcd61430 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Fri, 18 Mar 2016 14:56:13 -0400
Subject: [PATCH] libxl: info: Display build_id of the hypervisor using
XEN_VERSION_build_id
If the hypervisor is built with we will display it.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
v3: Retry with different size if 1020 is not enough.
v4: Use VERSION_OP subops instead of the XENVER_ subops
v5: Change it per Wei's review. s/VERSION_OP/VERSION/
And actually use the proper Style!
---
tools/libxl/libxl.c | 18 ++++++++++++++++--
tools/libxl/libxl.h | 6 ++++++
tools/libxl/libxl_types.idl | 1 +
tools/libxl/xl_cmdimpl.c | 1 +
4 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
index 704e7b4..dea5d25 100644
--- a/tools/libxl/libxl.c
+++ b/tools/libxl/libxl.c
@@ -5233,6 +5233,7 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
GC_INIT(ctx);
char *buf;
xen_version_op_val_t val = 0;
+ int r;
libxl_version_info *info = &ctx->version_info;
if (info->xen_version_extra != NULL)
@@ -5275,8 +5276,21 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
info->virt_start = val;
- (void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
- info->pagesize, &info->commandline);
+ if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
+ info->pagesize, &info->commandline) < 0)
+ goto out;
+
+ r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
+ if (r < 0) {
+ info->build_id = libxl__strdup(NOGC, "");
+ } else if (r > 0) {
+ unsigned int i;
+
+ info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
+
+ for (i = 0; i < r; i++)
+ snprintf(&info->build_id[i * 2], 3, "%02hhx", buf[i]);
+ }
out:
GC_FREE;
return info;
diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
index f61bc4b..5baffdf 100644
--- a/tools/libxl/libxl.h
+++ b/tools/libxl/libxl.h
@@ -230,6 +230,12 @@
#define LIBXL_HAVE_APIC_ASSIST 1
/*
+ * LIBXL_HAVE_BUILD_ID means that libxl_version_info has the extra
+ * field for the hypervisor build_id.
+ */
+#define LIBXL_HAVE_BUILD_ID 1
+
+/*
* libxl ABI compatibility
*
* The only guarantee which libxl makes regarding ABI compatibility
diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
index 59b183c..e3a5707 100644
--- a/tools/libxl/libxl_types.idl
+++ b/tools/libxl/libxl_types.idl
@@ -363,6 +363,7 @@ libxl_version_info = Struct("version_info", [
("virt_start", uint64),
("pagesize", integer),
("commandline", string),
+ ("build_id", string),
], dir=DIR_OUT)
libxl_domain_create_info = Struct("domain_create_info",[
diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
index a3610fc..23da95e 100644
--- a/tools/libxl/xl_cmdimpl.c
+++ b/tools/libxl/xl_cmdimpl.c
@@ -5861,6 +5861,7 @@ static void output_xeninfo(void)
printf("cc_compile_by : %s\n", info->compile_by);
printf("cc_compile_domain : %s\n", info->compile_domain);
printf("cc_compile_date : %s\n", info->compile_date);
+ printf("build_id : %s\n", info->build_id);
return;
}
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id
2016-03-25 13:25 ` Konrad Rzeszutek Wilk
@ 2016-03-25 15:27 ` Wei Liu
0 siblings, 0 replies; 190+ messages in thread
From: Wei Liu @ 2016-03-25 15:27 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, ross.lagerwall, andrew.cooper3, Stefano Stabellini,
Ian Jackson, mpohlack, sasha.levin, xen-devel
On Fri, Mar 25, 2016 at 09:25:22AM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Mar 24, 2016 at 04:00:33PM -0400, Konrad Rzeszutek Wilk wrote:
> > If the hypervisor is built with we will display it.
> >
> > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> > Acked-by: Wei Liu <wei.liu2@citrix.com>
>
> Hey Wei,
>
> It has you Ack, but I think when I carried over the change (it used
> to be its own function with switch) I messed up the Style:
>
> > diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> > index 6c3ec40..310a7f3 100644
> > --- a/tools/libxl/libxl.c
> > +++ b/tools/libxl/libxl.c
> > @@ -5277,8 +5278,24 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
> >
> > info->virt_start = val;
> >
> > - (void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> > - info->pagesize, &info->commandline);
> > + if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> > + info->pagesize, &info->commandline) < 0)
> > + goto out;
> > +
> > + r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
> > + if (r < 0)
> > + {
> > + info->build_id = libxl__strdup(NOGC, "");
> > + }
> > + else if (r > 0)
> > + {
> > + unsigned int i;
> > +
> > + info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
> > +
> > + for (i = 0; i < r; i++)
> > + snprintf(&info->build_id[i * 2], 3, "%02hhx", buf[i]);
> > + }
> > out:
> > GC_FREE;
> > return info;
>
> So I fixed it up to be:
>
> From bc4ed9d93162325342a37122fcab7223fcd61430 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Fri, 18 Mar 2016 14:56:13 -0400
> Subject: [PATCH] libxl: info: Display build_id of the hypervisor using
> XEN_VERSION_build_id
>
> If the hypervisor is built with we will display it.
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
>
I skim-read it. Looks fine:
Acked-by: Wei Liu <wei.liu2@citrix.com>
> ---
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
>
> v2: Include HAVE_*, use libxl_zalloc, s/rc/ret/
> v3: Retry with different size if 1020 is not enough.
> v4: Use VERSION_OP subops instead of the XENVER_ subops
> v5: Change it per Wei's review. s/VERSION_OP/VERSION/
> And actually use the proper Style!
> ---
> tools/libxl/libxl.c | 18 ++++++++++++++++--
> tools/libxl/libxl.h | 6 ++++++
> tools/libxl/libxl_types.idl | 1 +
> tools/libxl/xl_cmdimpl.c | 1 +
> 4 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c
> index 704e7b4..dea5d25 100644
> --- a/tools/libxl/libxl.c
> +++ b/tools/libxl/libxl.c
> @@ -5233,6 +5233,7 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
> GC_INIT(ctx);
> char *buf;
> xen_version_op_val_t val = 0;
> + int r;
> libxl_version_info *info = &ctx->version_info;
>
> if (info->xen_version_extra != NULL)
> @@ -5275,8 +5276,21 @@ const libxl_version_info* libxl_get_version_info(libxl_ctx *ctx)
>
> info->virt_start = val;
>
> - (void)libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> - info->pagesize, &info->commandline);
> + if (libxl__xc_version_wrapper(gc, XEN_VERSION_commandline, buf,
> + info->pagesize, &info->commandline) < 0)
> + goto out;
> +
> + r = xc_version(ctx->xch, XEN_VERSION_build_id, buf, info->pagesize);
> + if (r < 0) {
> + info->build_id = libxl__strdup(NOGC, "");
> + } else if (r > 0) {
> + unsigned int i;
> +
> + info->build_id = libxl__zalloc(NOGC, (r * 2) + 1);
> +
> + for (i = 0; i < r; i++)
> + snprintf(&info->build_id[i * 2], 3, "%02hhx", buf[i]);
> + }
> out:
> GC_FREE;
> return info;
> diff --git a/tools/libxl/libxl.h b/tools/libxl/libxl.h
> index f61bc4b..5baffdf 100644
> --- a/tools/libxl/libxl.h
> +++ b/tools/libxl/libxl.h
> @@ -230,6 +230,12 @@
> #define LIBXL_HAVE_APIC_ASSIST 1
>
> /*
> + * LIBXL_HAVE_BUILD_ID means that libxl_version_info has the extra
> + * field for the hypervisor build_id.
> + */
> +#define LIBXL_HAVE_BUILD_ID 1
> +
> +/*
> * libxl ABI compatibility
> *
> * The only guarantee which libxl makes regarding ABI compatibility
> diff --git a/tools/libxl/libxl_types.idl b/tools/libxl/libxl_types.idl
> index 59b183c..e3a5707 100644
> --- a/tools/libxl/libxl_types.idl
> +++ b/tools/libxl/libxl_types.idl
> @@ -363,6 +363,7 @@ libxl_version_info = Struct("version_info", [
> ("virt_start", uint64),
> ("pagesize", integer),
> ("commandline", string),
> + ("build_id", string),
> ], dir=DIR_OUT)
>
> libxl_domain_create_info = Struct("domain_create_info",[
> diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> index a3610fc..23da95e 100644
> --- a/tools/libxl/xl_cmdimpl.c
> +++ b/tools/libxl/xl_cmdimpl.c
> @@ -5861,6 +5861,7 @@ static void output_xeninfo(void)
> printf("cc_compile_by : %s\n", info->compile_by);
> printf("cc_compile_domain : %s\n", info->compile_domain);
> printf("cc_compile_date : %s\n", info->compile_date);
> + printf("build_id : %s\n", info->build_id);
>
> return;
> }
> --
> 2.5.0
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id.
2016-03-24 20:00 ` [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id Konrad Rzeszutek Wilk
@ 2016-03-25 16:26 ` Daniel De Graaf
2016-04-04 13:35 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Daniel De Graaf @ 2016-03-25 16:26 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, xen-devel, ross.lagerwall, konrad,
andrew.cooper3, mpohlack, sasha.levin
Cc: Wei Liu, Ian Jackson, Stefano Stabellini
On 03/24/2016 04:00 PM, Konrad Rzeszutek Wilk wrote:
> The VERSION hypercall provides the flexibility to expose
> the size of the build-id (so the callers can allocate the
> proper size before trying to retrieve it). It also allows
> in one nice swoop to retrieve the hypervisor build-id in the
> provided buffer.
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 05/28] xsplice: Design document
2016-03-24 20:00 ` [PATCH v5 05/28] xsplice: Design document Konrad Rzeszutek Wilk
@ 2016-03-29 9:36 ` Jan Beulich
2016-03-29 20:46 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-03-29 9:36 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Ian Jackson,
Tim Deegan, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> +struct xen_sysctl_xsplice_list {
> + uint32_t version; /* OUT: Hypervisor stamps value.
> + If varies between calls, we are
> + getting stale data. */
> + uint32_t idx; /* IN: Index into hypervisor array.
> + Should be between [0, nr). */
This is now actively wrong, when comparing with the implementation
in the next patch, namely
if ( list->idx > i++ )
continue;
E.g. on some subsequent invocation you might have idx=55 and
nr=32, making you populate array slots [0,31] with data for payloads
[55,86]. Why don't you just say "Index into hypervisor list"?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 05/28] xsplice: Design document
2016-03-29 9:36 ` Jan Beulich
@ 2016-03-29 20:46 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-29 20:46 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Ian Jackson,
Tim Deegan, mpohlack, sasha.levin, xen-devel
On Tue, Mar 29, 2016 at 03:36:12AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > +struct xen_sysctl_xsplice_list {
> > + uint32_t version; /* OUT: Hypervisor stamps value.
> > + If varies between calls, we are
> > + getting stale data. */
> > + uint32_t idx; /* IN: Index into hypervisor array.
> > + Should be between [0, nr). */
>
> This is now actively wrong, when comparing with the implementation
> in the next patch, namely
>
> if ( list->idx > i++ )
> continue;
>
> E.g. on some subsequent invocation you might have idx=55 and
> nr=32, making you populate array slots [0,31] with data for payloads
> [55,86]. Why don't you just say "Index into hypervisor list"?
>
/me smacks himself in the head.
Yes.
Updated it to say that and also updated the hypervisor patch (sysctl.h)
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-24 21:30 ` Konrad Rzeszutek Wilk
@ 2016-03-30 15:43 ` Jan Beulich
2016-03-31 6:30 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-03-30 15:43 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
sasha.levin, xen-devel, Daniel De Graaf, Keir Fraser
>>> On 24.03.16 at 22:30, <konrad@kernel.org> wrote:
> From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Date: Tue, 22 Mar 2016 16:53:19 -0400
> Subject: [PATCH] HYPERCALL_version_op. New hypercall mirroring XENVER_ but
> sane.
>
> This hypercall mirrors the XENVER_ in that it has similar functionality.
> However it is designed differently:
> - No compat layer. The data structures are the same size on 32
> as on 64-bit.
> - The hypercall accepts three arguments - the command, pointer to
> an buffer, and the length of the buffer.
> - Each sub-ops can be "probed" for size by returning the size of
> buffer that will be needed - if the buffer is NULL.
> - Subops can complete even if the buffer is too small - truncated
> data will be filled and hypercall will return -ENOBUFS.
> - VERSION_commandline, VERSION_changeset are privileged.
> - There is no XENVER_compile_info equivalent.
> - The hypercall can return -EPERM and toolstack/OSes are expected
> to deal with. However there are three subops: XEN_VERSION_version,
> XEN_VERSION_platform_parameters and XEN_VERSION_get_features
> that will always return an value as guests cannot survive without them.
>
> While we combine some of the common code between XENVER_ and VERSION_
> take the liberty of moving pae_extended_cr3 in x86 area.
>
> Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> [XSM bits]
> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
This last line doesn't seem to match up with ...
> v1-v3: Was not part of the series.
> v4: New posting.
> v5: Remove memset and use {}. Tweak copy_to_guest and capabilities_info,
> add ASSERT(sz) per Andrew's review. Add cached=1 back in.
> Per Jan, s/VERSION_OP/VERSION/, squash size check with do_version_op,
> update the comments. Dropped Andrew's Review-by. Ate newlines.
... the middle sentence here.
> +DO(version_op)(unsigned int cmd, XEN_GUEST_HANDLE_PARAM(void) arg,
> + unsigned int len)
> +{
> + union {
> + xen_version_op_val_t val;
> + xen_feature_info_t fi;
> + } u = {};
> + unsigned int sz = 0;
> + const void *ptr = NULL;
> + int rc = xsm_version_op(XSM_OTHER, cmd);
> +
> + /* We can safely return -EPERM! */
So what again was this comment supposed to tell us?
> + if ( rc )
> + return rc;
> +
> + /*
> + * The HYPERVISOR_xen_version differs in that some return the value,
I think there's a "subop" missing somewhere.
> +static int __init capabilities_cache_init(void)
> +{
> + /*
> + * Pre-allocate the cache so we do not have to worry about
"Pre-fill" or "Pre-populate"?
> --- a/xen/include/public/version.h
> +++ b/xen/include/public/version.h
> @@ -30,7 +30,14 @@
>
> #include "xen.h"
>
> -/* NB. All ops return zero on success, except XENVER_{version,pagesize} */
Perhaps this comment doesn't belong here anymore, but I don't think
it should be deleted altogether.
> +/*
> + * There are two hypercalls mentioned in here. The XENVER_ are for
> + * HYPERCALL_xen_version (17), while VERSION_ are for the
XEN_VERSION_
> @@ -87,6 +94,67 @@ typedef struct xen_feature_info xen_feature_info_t;
> #define XENVER_commandline 9
> typedef char xen_commandline_t[1024];
>
> +/*
> + * The HYPERCALL_version_op has a set of sub-ops which mirror the
> + * sub-ops of HYPERCALL_xen_version. However this hypercall differs
> + * radically from the former:
> + * - It returns the amount of bytes returned.
"returns ... returned" is a little strange. Perhaps "returns ... copied"?
> + * - It will return -XEN_EPERM if the guest is not permitted
> + * (Albeit XEN_VERSION_version, XEN_VERSION_platform_parameters, and
> + * XEN_VERSION_get_features will always return an value as guest cannot
> + * survive without this information).
Isn't there an object missing here, to say what is not permitted?
> + * - It will return the requested data in arg.
> + * - It requires an third argument (len) for the length of the
> + * arg. Naturally the arg has to fit the requested data otherwise
> + * -XEN_ENOBUFS is returned.
> + *
> + * It also offers an mechanism to probe for the amount of bytes an
... a mechanism ...
> + * sub-op will require. Having the arg have an NULL handle will
... a NULL ...
> + * return the number of bytes requested for the operation. Or an
> + * negative value if an error is encountered.
... a negative ...
Since they're all cosmetic, if you take care of all of them, feel free
to stick my ack on the result.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup.
2016-03-24 20:00 ` [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup Konrad Rzeszutek Wilk
@ 2016-03-30 16:09 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-03-30 16:09 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> @@ -1077,27 +1080,33 @@ void do_unexpected_trap(const char *msg, struct cpu_user_regs *regs)
>
> int do_bug_frame(struct cpu_user_regs *regs, vaddr_t pc)
> {
> - const struct bug_frame *bug;
> + const struct bug_frame *bug = NULL;
> const char *prefix = "", *filename, *predicate;
> unsigned long fixup;
> - int id, lineno;
> - static const struct bug_frame *const stop_frames[] = {
> - __stop_bug_frames_0,
> - __stop_bug_frames_1,
> - __stop_bug_frames_2,
> - NULL
> - };
> + int id = -1, lineno;
> + struct virtual_region *region;
>
> - for ( bug = __start_bug_frames, id = 0; stop_frames[id]; ++bug )
> + region = search_for_text(pc);
find_text_region() maybe? And "virtual_region" then perhaps could
also become "text_region"?
> --- /dev/null
> +++ b/xen/common/virtual_region.c
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + *
> + */
> +
> +#include <xen/init.h>
> +#include <xen/kernel.h>
> +#include <xen/rcupdate.h>
> +#include <xen/spinlock.h>
> +#include <xen/virtual_region.h>
> +
> +#ifdef CONFIG_X86
> +#include <asm/uaccess.h>
> +#endif
I can't spot what code below needs this.
> +static struct virtual_region core = {
> + .list = LIST_HEAD_INIT(core.list),
> + .start = (unsigned long)_stext,
> + .end = (unsigned long)_etext,
> +#ifdef CONFIG_X86
> + .ex = (struct exception_table_entry *)__start___ex_table,
> + .ex_end = (struct exception_table_entry *)__stop___ex_table,
> +#endif
And I continue to be unhappy about these #ifdef-s, the more that
I think that ARM is more the exception than the norm in not needing
these tables. Couldn't the arch pass the two pointers to
setup_virtual_regions() instead?
> +struct virtual_region* search_for_text(unsigned long addr)
I think I had said before that this should return a pointer to const.
And the * also is still misplaced.
> +{
> + struct virtual_region *region;
> +
> + rcu_read_lock(&rcu_virtual_region_lock);
> +
> + list_for_each_entry_rcu( region, &virtual_region_list, list )
Inconsistent style: Either you need another blank ahead of the
opening paren, or you don't need any immediately inside.
> +int register_virtual_region(struct virtual_region *r)
> +{
> + ASSERT(!local_irq_is_enabled());
> +
> + list_add_tail_rcu(&r->list, &virtual_region_list);
> +
> + return 0;
> +}
Is it really useful for this function to return non-void?
> --- /dev/null
> +++ b/xen/include/xen/virtual_region.h
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + *
> + */
> +
> +#ifndef __XEN_VIRTUAL_REGION_LIST__
> +#define __XEN_VIRTUAL_REGION_LIST__
Still inconsistent with the header's name.
> +struct virtual_region
> +{
> + struct list_head list;
> + unsigned long start; /* Virtual address start. */
> + unsigned long end; /* Virtual address start. */
> +
> + /*
> + * If this is NULL the default lookup mechanism is used.
> + */
Still wrongly a multi line comment.
> + symbols_lookup_t *symbols_lookup;
> +
> + struct {
> + const struct bug_frame *bugs; /* The pointer to array of bug frames. */
> + ssize_t n_bugs; /* The number of them. */
> + } frame[BUGFRAME_NR];
> +
> + struct exception_table_entry *ex;
> + struct exception_table_entry *ex_end;
So you nicely constified "bugs", but what about these two?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
2016-03-24 20:00 ` [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb Konrad Rzeszutek Wilk
@ 2016-03-30 16:24 ` Jan Beulich
2016-03-30 16:44 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-03-30 16:24 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Ian Jackson,
Tim Deegan, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> @@ -266,16 +275,15 @@ void *vzalloc(size_t size)
> return p;
> }
>
> -void vfree(void *va)
> +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc)
Just to repeat: This "caller provides size" worries me, the more that
this doesn't mirror anything the allocation side does. Would you mind
providing a case where using vm_size() instead is not correct?
> --- a/xen/include/xen/vmap.h
> +++ b/xen/include/xen/vmap.h
> @@ -12,9 +12,23 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
> void *vmap(const mfn_t *mfn, unsigned int nr);
> void vunmap(const void *);
> void *vmalloc(size_t size);
> +
> +/*
> + * Callback for vmalloc_cb to use when vmap-ing.
> + */
Comment style.
> +typedef void *(vmap_cb_t)(const mfn_t *mfn, unsigned int pages);
Stray parentheses (again).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
2016-03-30 16:24 ` Jan Beulich
@ 2016-03-30 16:44 ` Konrad Rzeszutek Wilk
2016-03-31 6:46 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-30 16:44 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Ian Jackson,
Tim Deegan, mpohlack, sasha.levin, xen-devel
On Wed, Mar 30, 2016 at 10:24:41AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > @@ -266,16 +275,15 @@ void *vzalloc(size_t size)
> > return p;
> > }
> >
> > -void vfree(void *va)
> > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc)
>
> Just to repeat: This "caller provides size" worries me, the more that
> this doesn't mirror anything the allocation side does. Would you mind
> providing a case where using vm_size() instead is not correct?
When the virtual addresses (to which we will stitch the pages allocated
by vmalloc) are not allocated (provided?) by vmap.
vm_size() will be very unhappy if that virtual address it is provided with
are not from the 'vmap' pool and will return 0.
>
> > --- a/xen/include/xen/vmap.h
> > +++ b/xen/include/xen/vmap.h
> > @@ -12,9 +12,23 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
> > void *vmap(const mfn_t *mfn, unsigned int nr);
> > void vunmap(const void *);
> > void *vmalloc(size_t size);
> > +
> > +/*
> > + * Callback for vmalloc_cb to use when vmap-ing.
> > + */
>
> Comment style.
>
> > +typedef void *(vmap_cb_t)(const mfn_t *mfn, unsigned int pages);
>
> Stray parentheses (again).
<sigh> I swore I fixed it and then did a pass through the rest to fix
others!
But a grep tells me:
+typedef void *(vmap_cb_t)(const mfn_t *mfn, unsigned int pages);
+typedef void (vfree_cb_t)(void *va, unsigned int pages);
+typedef int (find_space_t)(size_t, unsigned long *, unsigned long *);
+typedef void (*xsplice_loadcall_t)(void);
+typedef void (*xsplice_unloadcall_t)(void);
I need to fix those. Sorry about that - I really though I had them fixed.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-30 15:43 ` Jan Beulich
@ 2016-03-31 6:30 ` Jan Beulich
2016-03-31 11:43 ` Konrad Rzeszutek Wilk
2016-04-08 17:24 ` George Dunlap
0 siblings, 2 replies; 190+ messages in thread
From: Jan Beulich @ 2016-03-31 6:30 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
sasha.levin, xen-devel, Daniel De Graaf, Keir Fraser
>>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
> Since they're all cosmetic, if you take care of all of them, feel free
> to stick my ack on the result.
Actually - no, please don't. While the patch is fine content wise
then from my perspective, I'm still lacking a convincing argument
of why this new hypercall is needed in the first place. If others
are convinced by the argumentation between (mostly, iirc) you
and Andrew, I'm not going to stand in the way, but I'm also not
going to approve of the code addition without being myself
convinced.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
2016-03-30 16:44 ` Konrad Rzeszutek Wilk
@ 2016-03-31 6:46 ` Jan Beulich
2016-03-31 11:49 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-03-31 6:46 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Ian Jackson,
Tim Deegan, mpohlack, sasha.levin, xen-devel
>>> On 30.03.16 at 18:44, <konrad.wilk@oracle.com> wrote:
> On Wed, Mar 30, 2016 at 10:24:41AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > @@ -266,16 +275,15 @@ void *vzalloc(size_t size)
>> > return p;
>> > }
>> >
>> > -void vfree(void *va)
>> > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc)
>>
>> Just to repeat: This "caller provides size" worries me, the more that
>> this doesn't mirror anything the allocation side does. Would you mind
>> providing a case where using vm_size() instead is not correct?
>
> When the virtual addresses (to which we will stitch the pages allocated
> by vmalloc) are not allocated (provided?) by vmap.
>
> vm_size() will be very unhappy if that virtual address it is provided with
> are not from the 'vmap' pool and will return 0.
Hmm, okay, I now see that I got mislead by "This allows users (such
as xSplice) to provide their own mechanism to set the page flags",
which suggested to me that all you want is control over those flags.
Now that I look again I realize that I could have easily spotted the
actual intention right away. If all you really want to re-use from the
existing vmalloc() is the allocation mechanism of the set of pages,
then no, I don't think this should be done by playing with vmalloc().
Just have your caller do that allocation itself.
If, otoh, you left that VA management to (an extended version of)
vmap(), by e.g. allowing the caller to request allocation from a
different VA range (much like iirc x86-64 Linux handles its modules
address range allocation), things would be different. After all the
VA management is the important part here, while the backing
memory allocation is just a trivial auxiliary operation.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 06/28] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op
2016-03-24 20:00 ` [PATCH v5 06/28] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
@ 2016-03-31 9:45 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-03-31 9:45 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, andrew.cooper3, Ian Jackson,
mpohlack, ross.lagerwall, xen-devel, Daniel De Graaf,
sasha.levin
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> +static struct payload *find_payload(const xen_xsplice_name_t *name)
> +{
> + struct payload *data, *found = NULL;
> + char n[XEN_XSPLICE_NAME_SIZE];
> + int rc;
> +
> + rc = verify_name(name);
> + if ( rc )
> + return ERR_PTR(rc);
> +
> + if ( __copy_from_guest(n, name->name, name->size) )
> + return ERR_PTR(-EFAULT);
> +
> + if ( n[name->size - 1] )
> + return ERR_PTR(-EINVAL);
> +
> + spin_lock_recursive(&payload_lock);
> +
> + list_for_each_entry ( data, &payload_list, list )
> + {
> + if ( !strcmp(data->name, n) )
> + {
> + found = data;
> + break;
> + }
> + }
> +
> + spin_unlock_recursive(&payload_lock);
> +
> + return found;
> +}
So I've mentioned this before: Dropping the lock here means the
caller may (in general) not de-reference the returned pointer. While
it's only xsplice_upload() that calls this with the lock not held, and
that function indeed doesn't de-ref the pointer, it's still racy: Two
xsplice_upload() invocations for identically named payloads would
then possibly insert both instead of one of them detecting the
collision reliably. Hence I think all callers need to hold the lock, and
hence the need for a recursive lock goes away.
> +static int xsplice_upload(xen_sysctl_xsplice_upload_t *upload)
> +{
> + struct payload *data;
> + int rc;
> +
> + rc = verify_payload(upload);
> + if ( rc )
> + return rc;
> +
> + data = find_payload(&upload->name);
> + if ( data && !IS_ERR(data) /* Found. */ )
> + return -EEXIST;
> +
> + if ( IS_ERR(data) )
> + return PTR_ERR(data);
> +
> + data = xzalloc(struct payload);
> + if ( !data )
> + return -ENOMEM;
> +
> + rc = -EFAULT;
> + if ( __copy_from_guest(data->name, upload->name.name, upload->name.size) )
> + goto out;
You're reading the string from guest memory a second time here,
invalidating the verification done earlier.
> +static int xsplice_list(xen_sysctl_xsplice_list_t *list)
> +{
> + xen_xsplice_status_t status;
> + struct payload *data;
> + unsigned int idx = 0, i = 0;
> + int rc = 0;
> +
> + if ( list->nr > 1024 )
> + return -E2BIG;
> +
> + if ( list->pad )
> + return -EINVAL;
> +
> + if ( list->nr &&
> + (!guest_handle_okay(list->status, list->nr) ||
> + !guest_handle_okay(list->name, XEN_XSPLICE_NAME_SIZE * list->nr) ||
> + !guest_handle_okay(list->len, list->nr)) )
> + return -EINVAL;
> +
> + spin_lock_recursive(&payload_lock);
> + if ( list->idx > payload_cnt )
>= ?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-31 6:30 ` Jan Beulich
@ 2016-03-31 11:43 ` Konrad Rzeszutek Wilk
2016-03-31 12:07 ` Jan Beulich
2016-04-08 17:24 ` George Dunlap
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-31 11:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Andrew Cooper, Stefano Stabellini, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
sasha.levin, xen-devel, Daniel De Graaf, Keir Fraser
On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
> > Since they're all cosmetic, if you take care of all of them, feel free
> > to stick my ack on the result.
>
> Actually - no, please don't. While the patch is fine content wise
> then from my perspective, I'm still lacking a convincing argument
> of why this new hypercall is needed in the first place. If others
> are convinced by the argumentation between (mostly, iirc) you
> and Andrew, I'm not going to stand in the way, but I'm also not
> going to approve of the code addition without being myself
> convinced.
Damm. I pushed the patch in yesterday in 'staging'!
We can always revert them..
"Others" being other maintainers I presume?
The underlaying reason for me doing this is to expose the build-id.
It (build-id) originally was in sysctl, then folks wanted it in XENVER_.
Got it working in there as sub-ops, but Andrew last minute decided that
it should not really be there but in a new hypercall that can do
three arguments (the length) and be able to return -EPERM. A sane
one, not the cobbled up XENVER one.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb
2016-03-31 6:46 ` Jan Beulich
@ 2016-03-31 11:49 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-31 11:49 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
ross.lagerwall, sasha.levin, xen-devel
On Thu, Mar 31, 2016 at 12:46:24AM -0600, Jan Beulich wrote:
> >>> On 30.03.16 at 18:44, <konrad.wilk@oracle.com> wrote:
> > On Wed, Mar 30, 2016 at 10:24:41AM -0600, Jan Beulich wrote:
> >> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> >> > @@ -266,16 +275,15 @@ void *vzalloc(size_t size)
> >> > return p;
> >> > }
> >> >
> >> > -void vfree(void *va)
> >> > +void vfree_cb(void *va, unsigned int pages, vfree_cb_t *vfree_cb_fnc)
> >>
> >> Just to repeat: This "caller provides size" worries me, the more that
> >> this doesn't mirror anything the allocation side does. Would you mind
> >> providing a case where using vm_size() instead is not correct?
> >
> > When the virtual addresses (to which we will stitch the pages allocated
> > by vmalloc) are not allocated (provided?) by vmap.
> >
> > vm_size() will be very unhappy if that virtual address it is provided with
> > are not from the 'vmap' pool and will return 0.
>
> Hmm, okay, I now see that I got mislead by "This allows users (such
> as xSplice) to provide their own mechanism to set the page flags",
> which suggested to me that all you want is control over those flags.
Sorry about that! That was the initial part which didn't work out
as the displacement from kernel virtual address ranges to vmap ones
was 34-bits. And that broke ELF relocations which were 32-bit!
> Now that I look again I realize that I could have easily spotted the
> actual intention right away. If all you really want to re-use from the
> existing vmalloc() is the allocation mechanism of the set of pages,
> then no, I don't think this should be done by playing with vmalloc().
> Just have your caller do that allocation itself.
Like it was in v4 :-)
I will drop this and rework the patch that does the backing memory operation
to use its own version.
>
> If, otoh, you left that VA management to (an extended version of)
> vmap(), by e.g. allowing the caller to request allocation from a
> different VA range (much like iirc x86-64 Linux handles its modules
> address range allocation), things would be different. After all the
> VA management is the important part here, while the backing
> memory allocation is just a trivial auxiliary operation.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 09/28] xsplice: Add helper elf routines
2016-03-24 20:00 ` [PATCH v5 09/28] xsplice: Add helper elf routines Konrad Rzeszutek Wilk
@ 2016-03-31 12:03 ` Jan Beulich
2016-04-06 1:38 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-03-31 12:03 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- /dev/null
> +++ b/xen/common/xsplice_elf.c
> @@ -0,0 +1,294 @@
> +/*
> + * Copyright (C) 2016 Citrix Systems R&D Ltd.
> + */
> +
> +#include <xen/errno.h>
> +#include <xen/lib.h>
> +#include <xen/xsplice_elf.h>
> +#include <xen/xsplice.h>
> +
> +struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf *elf,
> + const char *name)
> +{
> + unsigned int i;
> +
> + for ( i = 0; i < elf->hdr->e_shnum; i++ )
Unless you do something unusual (which would be undesirable),
useful ELF section number start from 1.
> +static int elf_resolve_sections(struct xsplice_elf *elf, const void *data)
> +{
> + struct xsplice_elf_sec *sec;
> + unsigned int i;
> +
> + /* xsplice_elf_load sanity checked e_shnum checked. */
redundant "checked"
> + sec = xmalloc_array(struct xsplice_elf_sec, elf->hdr->e_shnum);
> + if ( !sec )
> + {
> + printk(XENLOG_ERR "%s%s: Could not allocate memory for section table!\n",
> + XSPLICE, elf->name);
> + return -ENOMEM;
> + }
> +
> + elf->sec = sec;
> +
> + /* N.B. We also will ingest SHN_UNDEF sections. */
Because of? The meaning of the fields in the 0-th section header is
different from that of ordinary ones.
> + for ( i = 0; i < elf->hdr->e_shnum; i++ )
> + {
> + ssize_t delta = elf->hdr->e_shoff + i * elf->hdr->e_shentsize;
Why ssize_t? (This anyway should be a suitable ELF type.)
> +
> + if ( delta + sizeof(Elf_Shdr) > elf->len )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Section header [%d] is past end of payload!\n",
> + XSPLICE, elf->name, i);
XSPLICE is a string literal, so should be prepended to the format
string instead of forced through %s. And %u please for unsigned
arguments.
Also this check doesn't need doing inside the loop - you can simply
check once (using e_shnum) that the entire section table is valid.
> + return -EINVAL;
> + }
> +
> + sec[i].sec = (Elf_Shdr *)(data + delta);
Pointless cast bogusly casting away constness.
> + delta = sec[i].sec->sh_offset;
> +
> + if ( delta > elf->len )
This is relevant only for sections having non-zero size. And then you of
course need to take size into account when dong the bounds check.
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Section [%d] data is past end of payload!\n",
> + XSPLICE, elf->name, i);
> + return -EINVAL;
> + }
> +
> + sec[i].data = data + delta;
> + /* Name is populated in xsplice_elf_sections_name. */
> + sec[i].name = NULL;
> +
> + if ( sec[i].sec->sh_type == SHT_SYMTAB )
> + {
> + if ( elf->symtab )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Multiple symbol tables!\n",
> + XSPLICE, elf->name);
> + return -EINVAL;
There's nothing invalid about this, it's simply unsupported by the
implementation (read: a better error code please).
> + }
> +
> + elf->symtab = &sec[i];
> +
> + /*
> + * elf->symtab->sec->sh_link would point to the right section
> + * but we hadn't finished parsing all the sections.
> + */
> + if ( elf->symtab->sec->sh_link > elf->hdr->e_shnum )
>=
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Symbol table idx (%d) to strtab past end (%d)\n",
> + XSPLICE, elf->name, elf->symtab->sec->sh_link,
> + elf->hdr->e_shnum);
> + return -EINVAL;
> + }
> + }
> + }
> +
> + if ( !elf->symtab )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: No symbol table found!\n",
> + XSPLICE, elf->name);
> + return -EINVAL;
> + }
> +
> + /* There can be multiple SHT_STRTAB so pick the right one. */
> + elf->strtab = &sec[elf->symtab->sec->sh_link];
How about checking this really is a SHT_STRTAB section?
> + if ( !elf->symtab->sec->sh_size || !elf->symtab->sec->sh_entsize ||
> + elf->symtab->sec->sh_entsize != sizeof(Elf_Sym) )
The first sh_entsize check is redundant with the second, and the
second is too strict (< suffices).
Also shouldn't the string table section also have at least non-zero
size? And its first and last bytes be NUL?
> +static int elf_resolve_section_names(struct xsplice_elf *elf, const void *data)
> +{
> + const char *shstrtab;
> + unsigned int i;
> + unsigned int offset, delta;
> +
> + /*
> + * The elf->sec[0 -> e_shnum] structures have been verified by
> + * elf_resolve_sections. Find file offset for section string table.
> + */
> + offset = elf->sec[elf->hdr->e_shstrndx].sec->sh_offset;
Truncating the value on 64-bit ELF.
> + if ( offset > elf->len )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: shstrtab section offset (%u) past end of payload!\n",
> + XSPLICE, elf->name, elf->hdr->e_shstrndx);
> + return -EINVAL;
> + }
> +
> + shstrtab = (data + offset);
Pointless parentheses.
> + /* We could ignore the first as it is reserved.. */
Double full stop.
> + for ( i = 0; i < elf->hdr->e_shnum; i++ )
> + {
> + delta = elf->sec[i].sec->sh_name;
> +
> + if ( offset + delta > elf->len )
This is too weak: After having bounds checked the string table section
to be inside the image, you now need to bounds check the string offset
to be inside the string table. Also it seems (just like above) you
no-where check that the referenced section actually is a string table.
> +static int elf_get_sym(struct xsplice_elf *elf, const void *data)
> +{
> + struct xsplice_elf_sec *symtab_sec, *strtab_sec;
> + struct xsplice_elf_sym *sym;
> + unsigned int i, delta, offset, nsym;
> +
> + symtab_sec = elf->symtab;
> + strtab_sec = elf->strtab;
> +
> + /* Pointers arithmetic to get file offset. */
> + offset = strtab_sec->data - data;
> +
> + ASSERT(offset == strtab_sec->sec->sh_offset);
> +
> + /* symtab_sec->data was computed in elf_resolve_sections. */
> + ASSERT((symtab_sec->sec->sh_offset + data) == symtab_sec->data);
> +
> + /* No need to check values as elf_resolve_sections did it. */
> + nsym = symtab_sec->sec->sh_size / symtab_sec->sec->sh_entsize;
> +
> + sym = xmalloc_array(struct xsplice_elf_sym, nsym);
> + if ( !sym )
> + {
> + printk(XENLOG_ERR "%s%s: Could not allocate memory for symbols\n",
> + XSPLICE, elf->name);
> + return -ENOMEM;
> + }
> +
> + /* So we don't leak memory. */
> + elf->sym = sym;
> + for ( i = 0; i < nsym; i++ )
As with sections, the 0th symbol table entry is special too.
> + {
> + Elf_Sym *s;
> +
> + if ( i * sizeof(Elf_Sym) > elf->len )
Considering that we know the symbol table section is within bounds,
I don't think this check does any good. Plus it ought to be adding 1
to i and take the section file offset into account.
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Symbol header [%d] is past end of payload!\n",
> + XSPLICE, elf->name, i);
> + return -EINVAL;
> + }
> +
> + s = &((Elf_Sym *)symtab_sec->data)[i];
> +
> + /* If st->name is STN_UNDEF is zero, the check will always be true. */
Odd double use of "is".
> + delta = s->st_name;
> +
> + /* Offset has been computed earlier. */
> + if ( offset + delta > elf->len )
This should again check against the string table size and again use >= .
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Symbol [%u] data is past end of payload!\n",
> + XSPLICE, elf->name, i);
> + return -EINVAL;
> + }
> +
> + sym[i].sym = s;
> + if ( s->st_name == STN_UNDEF )
> + sym[i].name = NULL;
I don't think this is a good idea - since the first byte of a string table
needs to be NUL, you can as well just point there (without any need
for a conditional).
> + else
> + sym[i].name = data + ( delta + offset );
Stray blanks.
> +static int xsplice_header_check(const struct xsplice_elf *elf)
> +{
> + if ( sizeof(*elf->hdr) >= elf->len )
Strictly speaking just > .
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Section header is bigger than payload!\n",
> + XSPLICE, elf->name);
> + return -EINVAL;
> + }
> +
> + if ( elf->hdr->e_shstrndx == SHN_UNDEF )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Section name idx is undefined!?\n",
> + XSPLICE, elf->name);
> + return -EINVAL;
> + }
> +
> + /* Check that section name index is within the sections. */
> + if ( elf->hdr->e_shstrndx > elf->hdr->e_shnum )
>=
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Section name idx (%d) is past end of sections (%d)!\n",
> + XSPLICE, elf->name, elf->hdr->e_shstrndx, elf->hdr->e_shnum);
> + return -EINVAL;
> + }
> +
> + if ( elf->hdr->e_shnum > 64 )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Too many (%d) sections!\n",
> + XSPLICE, elf->name, elf->hdr->e_shnum);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
Assuming there are no further checks hidden in other patches, I'm
afraid there's quite a bit of stuff missing - there are plenty of other
header fields most if not all of which need sanity checking.
> +int xsplice_elf_load(struct xsplice_elf *elf, void *data)
> +{
> + int rc;
> +
> + elf->hdr = data;
> +
> + rc = xsplice_header_check(elf);
> + if ( rc )
> + return rc;
> +
> + rc = elf_resolve_sections(elf, data);
> + if ( rc )
> + return rc;
> +
> + rc = elf_resolve_section_names(elf, data);
> + if ( rc )
> + return rc;
> +
> + rc = elf_get_sym(elf, data);
> + if ( rc )
> + return rc;
> +
> + return 0;
> +}
> +
> +void xsplice_elf_free(struct xsplice_elf *elf)
> +{
> + xfree(elf->sec);
> + elf->sec = NULL;
> + xfree(elf->sym);
> + elf->sym = NULL;
> + elf->nsym = 0;
> + elf->name = NULL;
> + elf->len = 0;
> +}
Instead of zeroing these fields, wouldn't it make sense to simply
xfree(elf) as the last action here?
> --- /dev/null
> +++ b/xen/include/xen/xsplice_elf.h
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (C) 2016 Citrix Systems R&D Ltd.
> + */
> +
> +#ifndef __XEN_XSPLICE_ELF_H__
> +#define __XEN_XSPLICE_ELF_H__
> +
> +#include <xen/types.h>
> +#include <xen/elfstructs.h>
> +
> +/* The following describes an Elf file as consumed by xSplice. */
> +struct xsplice_elf_sec {
> + Elf_Shdr *sec; /* Hooked up in elf_resolve_sections. */
const?
> + const char *name; /* Human readable name hooked in
> + elf_resolve_section_names. */
> + const void *data; /* Pointer to the section (done by
> + elf_resolve_sections). */
> +};
> +
> +struct xsplice_elf_sym {
> + Elf_Sym *sym;
const?
> + const char *name;
> +};
> +
> +struct xsplice_elf {
> + const char *name; /* Pointer to payload->name. */
> + ssize_t len; /* Length of the ELF file. */
Why ssize_t?
> + Elf_Ehdr *hdr; /* ELF file. */
> + struct xsplice_elf_sec *sec; /* Array of sections, allocated by us. */
> + struct xsplice_elf_sym *sym; /* Array of symbols , allocated by us. */
> + unsigned int nsym;
> + struct xsplice_elf_sec *symtab;/* Pointer to .symtab section - aka to sec[x]. */
> + struct xsplice_elf_sec *strtab;/* Pointer to .strtab section - aka to sec[y]. */
Many times - const?
> +};
> +
> +struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf *elf,
> + const char *name);
const (return value)?
> +int xsplice_elf_load(struct xsplice_elf *elf, void *data);
const (second parameter)?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-31 11:43 ` Konrad Rzeszutek Wilk
@ 2016-03-31 12:07 ` Jan Beulich
2016-03-31 13:28 ` REST MAINTAINERS feedback requested Was:Re: " Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-03-31 12:07 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
sasha.levin, xen-devel, Daniel De Graaf, Keir Fraser
>>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
> On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
>> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
>> > Since they're all cosmetic, if you take care of all of them, feel free
>> > to stick my ack on the result.
>>
>> Actually - no, please don't. While the patch is fine content wise
>> then from my perspective, I'm still lacking a convincing argument
>> of why this new hypercall is needed in the first place. If others
>> are convinced by the argumentation between (mostly, iirc) you
>> and Andrew, I'm not going to stand in the way, but I'm also not
>> going to approve of the code addition without being myself
>> convinced.
>
> Damm. I pushed the patch in yesterday in 'staging'!
>
> We can always revert them..
>
> "Others" being other maintainers I presume?
Any one of the REST maintainers, yes.
> The underlaying reason for me doing this is to expose the build-id.
>
> It (build-id) originally was in sysctl, then folks wanted it in XENVER_.
> Got it working in there as sub-ops, but Andrew last minute decided that
> it should not really be there but in a new hypercall that can do
> three arguments (the length) and be able to return -EPERM. A sane
> one, not the cobbled up XENVER one.
Well, -EPERM is now possible with the old one too. And nothing
in that existing interface prevents a length to be passed in/out
for new sub-ops. Nor do I really see anything truly insane with
that existing interface.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-31 12:07 ` Jan Beulich
@ 2016-03-31 13:28 ` Konrad Rzeszutek Wilk
2016-03-31 13:50 ` Jan Beulich
2016-04-08 16:33 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-31 13:28 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, ross.lagerwall, Andrew Cooper, Stefano Stabellini,
Ian Jackson, mpohlack, Julien Grall, Stefano Stabellini,
sasha.levin, xen-devel, Daniel De Graaf, Keir Fraser
On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
> > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
> >> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
> >> > Since they're all cosmetic, if you take care of all of them, feel free
> >> > to stick my ack on the result.
> >>
> >> Actually - no, please don't. While the patch is fine content wise
> >> then from my perspective, I'm still lacking a convincing argument
> >> of why this new hypercall is needed in the first place. If others
> >> are convinced by the argumentation between (mostly, iirc) you
> >> and Andrew, I'm not going to stand in the way, but I'm also not
> >> going to approve of the code addition without being myself
> >> convinced.
> >
> > Damm. I pushed the patch in yesterday in 'staging'!
> >
> > We can always revert them..
> >
> > "Others" being other maintainers I presume?
>
> Any one of the REST maintainers, yes.
Changing the title to get their attention.
>
> > The underlaying reason for me doing this is to expose the build-id.
> >
> > It (build-id) originally was in sysctl, then folks wanted it in XENVER_.
> > Got it working in there as sub-ops, but Andrew last minute decided that
Here is the link to v3 which had it in XENVER_ subops:
http://lists.xen.org/archives/html/xen-devel/2016-02/msg04110.html
And this one v5 (in case folks had deleted this thread, v4 is almost
the same except it had VERSION instead of XEN_VERSION):
http://lists.xen.org/archives/html/xen-devel/2016-03/msg03302.html
> > it should not really be there but in a new hypercall that can do
> > three arguments (the length) and be able to return -EPERM. A sane
> > one, not the cobbled up XENVER one.
>
> Well, -EPERM is now possible with the old one too. And nothing
> in that existing interface prevents a length to be passed in/out
> for new sub-ops. Nor do I really see anything truly insane with
We cannot expand the hypercall to have three arguments - it MUST
have two (as you had pointed out earlier). The length must be jammed
in the sub-ops:
/* Return value is the number of bytes written, or XEN_Exx on error.
* Calling with empty parameter returns the size of build_id. */
#define XENVER_build_id 10
struct xen_build_id {
uint32_t len; /* IN: size of buf[]. */
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
unsigned char buf[];
#elif defined(__GNUC__)
unsigned char buf[1]; /* OUT: Variable length buffer with build_id. */
#endif
};
typedef struct xen_build_id xen_build_id_t;
> that existing interface.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-03-24 20:00 ` [PATCH v5 10/28] xsplice: Implement payload loading Konrad Rzeszutek Wilk
@ 2016-03-31 13:45 ` Jan Beulich
2016-03-31 21:26 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-03-31 13:45 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, Julien Grall,
Stefano Stabellini, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -100,6 +100,9 @@ unsigned long __read_mostly xen_phys_start;
>
> unsigned long __read_mostly xen_virt_end;
>
> +unsigned long __read_mostly avail_virt_start;
> +unsigned long __read_mostly avail_virt_end;
> +
> DEFINE_PER_CPU(struct tss_struct, init_tss);
>
> char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE];
> @@ -1211,6 +1214,10 @@ void __init noreturn __start_xen(unsigned long mbi_p)
> ~((1UL << L2_PAGETABLE_SHIFT) - 1);
> destroy_xen_mappings(xen_virt_end, XEN_VIRT_START + BOOTSTRAP_MAP_BASE);
>
> + avail_virt_start = xen_virt_end;
> + avail_virt_end = XEN_VIRT_END - NR_CPUS * PAGE_SIZE;
> + BUG_ON(avail_virt_end <= avail_virt_start);
Is there a specific reason this needs to be here? I'd prefer the two
symbols above to become static in the file really using them, and
their initialization then be done there too (in an initcall function
perhaps).
> +int arch_xsplice_verify_elf(const struct xsplice_elf *elf, void *data)
> +{
> +
> + Elf_Ehdr *hdr = data;
> +
> + if ( !IS_ELF(*hdr) )
> + {
> + printk(XENLOG_ERR "%s%s: Not an ELF payload!\n", XSPLICE, elf->name);
> + return -EINVAL;
> + }
> +
> + if ( elf->len < (sizeof *hdr) ||
> + !IS_ELF(*hdr) ||
> + hdr->e_ident[EI_CLASS] != ELFCLASS64 ||
> + hdr->e_ident[EI_DATA] != ELFDATA2LSB ||
> + hdr->e_ident[EI_OSABI] != ELFOSABI_SYSV ||
> + hdr->e_machine != EM_X86_64 ||
> + hdr->e_type != ET_REL ||
> + hdr->e_phnum != 0 )
Ah, some of the checks missing from the previous patch are here!
But many don't belong here - perhaps everything but the e_machine
check. And even that could be abstracted out so that it can be done
in common code.
> +int arch_xsplice_perform_rel(struct xsplice_elf *elf,
> + const struct xsplice_elf_sec *base,
> + const struct xsplice_elf_sec *rela)
> +{
> + dprintk(XENLOG_ERR, "%s%s: SHR_REL relocation unsupported\n",
SHR? DYM SHT?
> +int arch_xsplice_perform_rela(struct xsplice_elf *elf,
> + const struct xsplice_elf_sec *base,
> + const struct xsplice_elf_sec *rela)
> +{
> + Elf_RelA *r;
const (and also perhaps better to move down into the for() scope)
> + unsigned int symndx, i;
> + uint64_t val;
> + uint8_t *dest;
> +
> + if ( !rela->sec->sh_entsize || !rela->sec->sh_size ||
> + rela->sec->sh_entsize != sizeof(Elf_RelA) )
Needless redundancy and too strict a check again. Also sh_size
should be a multiple of sh_entsize.
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Section relative header is corrupted!\n",
"Section relative"? DYM "Relocation section"? And perhaps the base
section name should be printed as well.
> + XSPLICE, elf->name);
> + return -EINVAL;
> + }
> +
> + for ( i = 0; i < (rela->sec->sh_size / rela->sec->sh_entsize); i++ )
> + {
> + r = (Elf_RelA *)(rela->data + i * rela->sec->sh_entsize);
Pointless cast bogusly casting away constness.
> + if ( (unsigned long)r > (unsigned long)(elf->hdr + elf->len) )
if ( (unsigned long)(r + 1) > (unsigned long)elf->hdr + elf->len )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Relative entry %u in %s is past end!\n",
> + XSPLICE, elf->name, i, rela->name);
> + return -EINVAL;
> + }
> +
> + symndx = ELF64_R_SYM(r->r_info);
> + if ( symndx > elf->nsym )
>= (I'm afraid I'll give up pointing out all these off-by-ones - there's
just too many of them. One of you will need to go through all of the
code and audit all the checks to actually be correct.)
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Relative symbol wants symbol@%u which is past end!\n",
> + XSPLICE, elf->name, symndx);
> + return -EINVAL;
> + }
> +
> + dest = base->load_addr + r->r_offset;
Missing sanity check on r_offset.
> + val = r->r_addend + elf->sym[symndx].sym->st_value;
> +
> + switch ( ELF64_R_TYPE(r->r_info) )
> + {
> + case R_X86_64_NONE:
Too deep indentation.
> + break;
> +
> + case R_X86_64_64:
> + *(uint64_t *)dest = val;
> + break;
> +
> + case R_X86_64_PLT32:
> + /*
> + * Xen uses -fpic which normally uses PLT relocations
> + * except that it sets visibility to hidden which means
> + * that they are not used. However, when gcc cannot
> + * inline memcpy it emits memcpy with default visibility
> + * which then creates a PLT relocation. It can just be
> + * treated the same as R_X86_64_PC32.
> + */
> + /* Fall through */
> +
> + case R_X86_64_PC32:
No need for this second comment or the blank line.
> + *(uint32_t *)dest = val - (uint64_t)dest;
We're dealing with signed quantities here, and the reduction in
width requires checking that no truncation occurs.
> + break;
> +
> + default:
> + printk(XENLOG_ERR "%s%s: Unhandled relocation %lu\n",
> + XSPLICE, elf->name, ELF64_R_TYPE(r->r_info));
Some rate limiting mechanism needs to be used here.
> +static find_space_t *find_space_fnc = NULL;
Pointless initializer.
> +void arch_xsplice_register_find_space(find_space_t *cb)
> +{
> + ASSERT(!find_space_fnc);
> +
> + find_space_fnc = cb;
> +}
> +
> +static void* xsplice_map_rwx(const mfn_t *mfn, unsigned int pages)
Misplaced *.
> +{
> + unsigned long cur;
> + unsigned long start, end;
> +
> + start = (unsigned long)avail_virt_start;
> + end = start + pages * PAGE_SIZE;
> +
> + ASSERT(find_space_fnc);
I don't think this is a good idea: If not set, we'll immediately have a
security issue. Either explicitly return NULL if this is NULL, or make
it point to a dummy (returning an error) until registered.
> + if ( find_space_fnc(pages, &start, &end) )
Why both start and end? The latter should be derivable from start
and pages.
> + return NULL;
> +
> + if ( end >= avail_virt_end )
> + return NULL;
> +
> + for ( cur = start; pages--; ++mfn, cur += PAGE_SIZE )
> + {
> + /*
> + * We would like to to RX, but we need to copy data in it first.
> + * See arch_xsplice_secure for how we lockdown.
> + */
> + if ( map_pages_to_xen(cur, mfn_x(*mfn), 1, PAGE_HYPERVISOR_RWX) )
> + {
> + if ( cur != start )
> + destroy_xen_mappings(start, cur);
> + return NULL;
> + }
> + }
> +
> + return (void*)start;
Missing blank.
> +int arch_xsplice_secure(void *va, unsigned int pages, enum va_type type,
> + const mfn_t *mfn)
This and other functions around here: Why arch_*? What prevents
them being put in common code?
> @@ -28,6 +29,15 @@ struct payload {
> uint32_t state; /* One of the XSPLICE_STATE_*. */
> int32_t rc; /* 0 or -XEN_EXX. */
> struct list_head list; /* Linked to 'payload_list'. */
> + void *text_addr; /* Virtual address of .text. */
> + size_t text_size; /* .. and its size. */
> + void *rw_addr; /* Virtual address of .data. */
> + size_t rw_size; /* .. and its size (if any). */
> + void *ro_addr; /* Virtual address of .rodata. */
> + size_t ro_size; /* .. and its size (if any). */
> + size_t payload_pages; /* Nr of the pages for the text_addr;
> + rw_addr, and ro_addr (if any) */
> + mfn_t *mfn; /* Array of MFNs of the pages. */
const (several times)?
> +static void calc_section(struct xsplice_elf_sec *sec, size_t *size)
> +{
> + size_t align_size = ROUNDUP(*size, sec->sec->sh_addralign);
> +
> + sec->sec->sh_entsize = align_size;
> + *size = sec->sec->sh_size + align_size;
> +}
> +
> +static int find_hole(size_t pages, unsigned long *hole_start,
> + unsigned long *hole_end)
> +{
> + struct payload *data, *data2;
> +
> + spin_lock_recursive(&payload_lock);
> + list_for_each_entry ( data, &payload_list, list )
> + {
> + list_for_each_entry ( data2, &payload_list, list )
> + {
> + unsigned long start, end;
> +
> + start = (unsigned long)data2->text_addr;
> + end = start + data2->payload_pages * PAGE_SIZE;
> + if ( *hole_end > start && *hole_start < end )
> + {
> + *hole_start = end;
> + *hole_end = end + pages * PAGE_SIZE;
> + break;
> + }
> + }
> + if ( &data2->list == &payload_list )
> + break;
> + }
> + spin_unlock_recursive(&payload_lock);
> +
> + return 0;
> +}
How will the caller know you didn't find a hole? If via the value
pointed to by the two function arguments, what use is the return
value?
Also - how well will this O(n^2) lookup work once there are enough
payloads? I think this calls for the alternative vmap() extension I've
been suggesting earlier.
> +static int move_payload(struct payload *payload, struct xsplice_elf *elf)
> +{
> + uint8_t *buf;
> + unsigned int i;
> + size_t size = 0;
> +
> + /* Compute text regions. */
> + for ( i = 0; i < elf->hdr->e_shnum; i++ )
> + {
> + if ( (elf->sec[i].sec->sh_flags & (SHF_ALLOC|SHF_EXECINSTR)) ==
> + (SHF_ALLOC|SHF_EXECINSTR) )
> + calc_section(&elf->sec[i], &payload->text_size);
> + }
> +
> + /* Compute rw data. */
> + for ( i = 0; i < elf->hdr->e_shnum; i++ )
> + {
> + if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
> + !(elf->sec[i].sec->sh_flags & SHF_EXECINSTR) &&
> + (elf->sec[i].sec->sh_flags & SHF_WRITE) )
> + calc_section(&elf->sec[i], &payload->rw_size);
> + }
> +
> + /* Compute ro data. */
> + for ( i = 0; i < elf->hdr->e_shnum; i++ )
> + {
> + if ( (elf->sec[i].sec->sh_flags & SHF_ALLOC) &&
> + !(elf->sec[i].sec->sh_flags & SHF_EXECINSTR) &&
> + !(elf->sec[i].sec->sh_flags & SHF_WRITE) )
> + calc_section(&elf->sec[i], &payload->ro_size);
> + }
So you handle X, W, and r/o, but you do nothing for WX. If you
don#t want to allow for this, you need to error out if there's any
such section.
> + /*
> + * Total of all three regions - RX, RW, and RO. We have to have
> + * keep them in seperate pages so we PAGE_ALIGN the RX and RW to have
> + * them on seperate pages. The last one will by default fall on its
> + * own page.
> + */
> + size = PAGE_ALIGN(payload->text_size) + PAGE_ALIGN(payload->rw_size) +
> + payload->ro_size;
> +
> + size = PFN_UP(size);
> + buf = arch_xsplice_alloc_payload(size, &payload->mfn);
> + if ( !buf ) {
Coding style.
> + printk(XENLOG_ERR "%s%s: Could not allocate memory for payload!\n",
> + XSPLICE, elf->name);
> + return -ENOMEM;
> + }
> +
> + payload->payload_pages = size;
> + payload->text_addr = buf;
> + payload->rw_addr = payload->text_addr + PAGE_ALIGN(payload->text_size);
> + payload->ro_addr = payload->rw_addr + PAGE_ALIGN(payload->rw_size);
> +
> + for ( i = 0; i < elf->hdr->e_shnum; i++ )
> + {
> + if ( elf->sec[i].sec->sh_flags & SHF_ALLOC )
> + {
> + if ( (elf->sec[i].sec->sh_flags & SHF_EXECINSTR) )
> + buf = payload->text_addr;
> + else if ( (elf->sec[i].sec->sh_flags & SHF_WRITE) )
> + buf = payload->rw_addr;
> + else
> + buf = payload->ro_addr;
> +
> + elf->sec[i].load_addr = buf + elf->sec[i].sec->sh_entsize;
> +
> + /* Don't copy NOBITS - such as BSS. */
Not copying is correct, but you need to zero these.
> + if ( elf->sec[i].sec->sh_type != SHT_NOBITS )
> + {
> + memcpy(elf->sec[i].load_addr, elf->sec[i].data,
> + elf->sec[i].sec->sh_size);
> + dprintk(XENLOG_DEBUG, "%s%s: Loaded %s at 0x%p\n", XSPLICE,
0x%p is bogus.
> +static int secure_payload(struct payload *payload, struct xsplice_elf *elf)
> +{
> + int rc;
> + unsigned int text_pages, rw_pages, ro_pages;
> +
> + ASSERT(payload->mfn);
> +
> + text_pages = PFN_UP(payload->text_size);
> + ASSERT(text_pages);
Where is the earlier check that allows you to ASSERT() here? I
anyway wonder whether requiring non-empty .text is really
necessary / useful.
> +static int load_payload_data(struct payload *payload, void *raw, ssize_t len)
> +{
> + struct xsplice_elf elf;
> + int rc = 0;
> +
> + memset(&elf, 0, sizeof(elf));
> + elf.name = payload->name;
> + elf.len = len;
Perhaps better done via initializer?
> @@ -382,8 +635,9 @@ static void xsplice_printall(unsigned char key)
> }
>
> list_for_each_entry ( data, &payload_list, list )
> - printk(" name=%s state=%s(%d)\n", data->name,
> - state2str(data->state), data->state);
> + printk(" name=%s state=%s(%d) %p (.data=%p, .rodata=%p) using %zu pages.\n",
No full stop at the end of log messages please.
> --- a/xen/common/xsplice_elf.c
> +++ b/xen/common/xsplice_elf.c
> @@ -213,6 +213,97 @@ static int elf_get_sym(struct xsplice_elf *elf, const
> void *data)
> return 0;
> }
>
> +int xsplice_elf_resolve_symbols(struct xsplice_elf *elf)
> +{
> + unsigned int i;
> +
> + /*
> + * The first entry of an ELF symbol table is the "undefined symbol index".
> + * aka reserved so we skip it.
> + */
> + ASSERT( elf->sym );
Stray blanks.
> + for ( i = 1; i < elf->nsym; i++ )
> + {
> + uint16_t idx = elf->sym[i].sym->st_shndx;
> +
> + switch ( idx )
> + {
> + case SHN_COMMON:
Too deep indentation.
> + printk(XENLOG_ERR "%s%s: Unexpected common symbol: %s\n",
> + XSPLICE, elf->name, elf->sym[i].name);
> + return -EINVAL;
> + break;
> +
> + case SHN_UNDEF:
> + printk(XENLOG_ERR "%s%s: Unknown symbol: %s\n",
> + XSPLICE, elf->name, elf->sym[i].name);
> + return -ENOENT;
> + break;
> +
> + case SHN_ABS:
> + dprintk(XENLOG_DEBUG, "%s%s: Absolute symbol: %s => 0x%"PRIx64"\n",
%# instead of 0x% please.
> + XSPLICE, elf->name, elf->sym[i].name,
> + elf->sym[i].sym->st_value);
> + break;
> +
> + default:
> + if ( elf->sec[idx].sec->sh_flags & SHF_ALLOC )
What if idx is beyond the range of valid section index, namely
another of the unhandled values in the reserved range?
> + {
> + elf->sym[i].sym->st_value +=
> + (unsigned long)elf->sec[idx].load_addr;
> + if ( elf->sym[i].name )
> + printk(XENLOG_DEBUG "%s%s: Symbol resolved: %s => 0x%"PRIx64"(%s)\n",
> + XSPLICE, elf->name, elf->sym[i].name,
> + (uint64_t)elf->sym[i].sym->st_value,
Instead of casts like this, please introduce ELF-specific format macros.
> +int xsplice_elf_perform_relocs(struct xsplice_elf *elf)
> +{
> + struct xsplice_elf_sec *rela, *base;
> + unsigned int i;
> + int rc;
> +
> + /*
> + * The first entry of an ELF symbol table is the "undefined symbol index".
> + * aka reserved so we skip it.
> + */
> + ASSERT( elf->sym );
> + for ( i = 1; i < elf->hdr->e_shnum; i++ )
> + {
> + rela = &elf->sec[i];
> +
> + if ( (rela->sec->sh_type != SHT_RELA ) &&
> + (rela->sec->sh_type != SHT_REL ) )
Stray blanks.
> + continue;
> +
> + /* Is it a valid relocation section? */
> + if ( rela->sec->sh_info >= elf->hdr->e_shnum )
> + continue;
> +
> + base = &elf->sec[rela->sec->sh_info];
> +
> + /* Don't relocate non-allocated sections. */
> + if ( !(base->sec->sh_flags & SHF_ALLOC) )
> + continue;
> +
> + if ( elf->sec[i].sec->sh_type == SHT_RELA )
> + rc = arch_xsplice_perform_rela(elf, base, rela);
> + else /* SHT_REL */
> + rc = arch_xsplice_perform_rel(elf, base, rela);
Please at least validate sh_link somewhere above.
> --- a/xen/include/xen/xsplice_elf.h
> +++ b/xen/include/xen/xsplice_elf.h
> @@ -15,6 +15,8 @@ struct xsplice_elf_sec {
> elf_resolve_section_names. */
> const void *data; /* Pointer to the section (done by
> elf_resolve_sections). */
> + uint8_t *load_addr; /* A pointer to the allocated destination.
> + Done by load_payload_data. */
void perhaps? And const?
> @@ -38,6 +40,9 @@ struct xsplice_elf_sec *xsplice_elf_sec_by_name(const struct xsplice_elf *elf,
> int xsplice_elf_load(struct xsplice_elf *elf, void *data);
> void xsplice_elf_free(struct xsplice_elf *elf);
>
> +int xsplice_elf_resolve_symbols(struct xsplice_elf *elf);
> +int xsplice_elf_perform_relocs(struct xsplice_elf *elf);
const?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-31 13:28 ` REST MAINTAINERS feedback requested Was:Re: " Konrad Rzeszutek Wilk
@ 2016-03-31 13:50 ` Jan Beulich
2016-04-08 16:33 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-03-31 13:50 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
xen-devel, Daniel De Graaf, Keir Fraser, sasha.levin
>>> On 31.03.16 at 15:28, <konrad.wilk@oracle.com> wrote:
> On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
>> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
>> > it should not really be there but in a new hypercall that can do
>> > three arguments (the length) and be able to return -EPERM. A sane
>> > one, not the cobbled up XENVER one.
>>
>> Well, -EPERM is now possible with the old one too. And nothing
>> in that existing interface prevents a length to be passed in/out
>> for new sub-ops. Nor do I really see anything truly insane with
>
> We cannot expand the hypercall to have three arguments - it MUST
> have two (as you had pointed out earlier). The length must be jammed
> in the sub-ops:
Right, that's what I had implied.
Jan
> /* Return value is the number of bytes written, or XEN_Exx on error.
> * Calling with empty parameter returns the size of build_id. */
>
> #define XENVER_build_id 10
> struct xen_build_id {
> uint32_t len; /* IN: size of buf[]. */
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> unsigned char buf[];
> #elif defined(__GNUC__)
> unsigned char buf[1]; /* OUT: Variable length buffer with
> build_id. */
> #endif
> };
> typedef struct xen_build_id xen_build_id_t;
>
>> that existing interface.
>>
>> Jan
>>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-03-31 13:45 ` Jan Beulich
@ 2016-03-31 21:26 ` Konrad Rzeszutek Wilk
2016-04-01 9:18 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-03-31 21:26 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel, sasha.levin
> Also - how well will this O(n^2) lookup work once there are enough
> payloads? I think this calls for the alternative vmap() extension I've
> been suggesting earlier.
Could you elaborate on the vmap extension a bit please?
Your earlier email seems to say: drop the vmap API and just
allocate the underlaying pages yourself.
Such as:
http://xenbits.xen.org/gitweb/?p=people/konradwilk/xen.git;a=blobdiff;f=xen/common/xsplice.c;h=fbd6129bd362a9034db9da495c5cd5e80c367541;hp=125d9b8eee995c7321dce4baa866d4bcac8eaa36;hb=b9bba0be36caf2e00734689765f15f2b8a529bb0;hpb=d8f5dba5e0ac65163576db65ae92e3e59a5dedd1
(see the alloc_payload function)?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-03-31 21:26 ` Konrad Rzeszutek Wilk
@ 2016-04-01 9:18 ` Jan Beulich
2016-04-04 19:44 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 9:18 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
>>> On 31.03.16 at 23:26, <konrad@darnok.org> wrote:
>> Also - how well will this O(n^2) lookup work once there are enough
>> payloads? I think this calls for the alternative vmap() extension I've
>> been suggesting earlier.
>
> Could you elaborate on the vmap extension a bit please?
>
> Your earlier email seems to say: drop the vmap API and just
> allocate the underlaying pages yourself.
Actually I had also said in that earlier mail: "If, otoh, you left that
VA management to (an extended version of) vmap(), by e.g.
allowing the caller to request allocation from a different VA range
(much like iirc x86-64 Linux handles its modules address range
allocation), things would be different. After all the VA
management is the important part here, while the backing
memory allocation is just a trivial auxiliary operation."
I.e. elaboration here really just consists of the referral to the
respective Linux approach.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-03-24 20:00 ` [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches Konrad Rzeszutek Wilk
@ 2016-04-01 13:28 ` Jan Beulich
2016-04-01 21:04 ` Konrad Rzeszutek Wilk
2016-04-07 3:09 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 13:28 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Kevin Tian, Keir Fraser, Suravee Suthikulpanit, andrew.cooper3,
mpohlack, Julien Grall, Stefano Stabellini, Jun Nakajima,
sasha.levin, xen-devel, Boris Ostrovsky
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> From: Ross Lagerwall <ross.lagerwall@citrix.com>
>
> Implement support for the apply, revert and replace actions.
>
> To perform and action on a payload, the hypercall sets up a data
> structure to schedule the work. A hook is added in all the
> return-to-guest paths to check for work to do and execute it if needed.
Looking at the diffstat alone I cannot see this being the case.
Perhaps it's just the description here which needs to become
more precise.
> In this way, patches can be applied with all CPUs idle and without
> stacks. The first CPU to do_xsplice() becomes the master and triggers a
> reschedule softirq to trigger all the other CPUs to enter do_xsplice()
> with no stack. Once all CPUs have rendezvoused, all CPUs disable IRQs
> and NMIs are ignored. The system is then quiscient and the master
> performs the action. After this, all CPUs enable IRQs and NMIs are
> re-enabled.
>
> Note that it is unsafe to patch do_nmi and the xSplice internal functions.
> Patching functions on NMI/MCE path is liable to end in disaster.
So what measures are (planned to be) taken to make sure this
doesn't happen by accident?
> The action to perform is one of:
> - APPLY: For each function in the module, store the first 5 bytes of the
> old function and replace it with a jump to the new function.
> - REVERT: Copy the previously stored bytes into the first 5 bytes of the
> old function.
> - REPLACE: Revert each applied module and then apply the new module.
>
> To prevent a deadlock with any other barrier in the system, the master
> will wait for up to 30ms before timing out.
> Measurements found that the patch application to take about 100 μs on a
> 72 CPU system, whether idle or fully loaded.
That's for an individual patch I suppose? What if REPLACE has to
revert dozens or hundreds of patches?
> We also add an BUILD_ON to make sure that the size of the structure
> of the payload is not inadvertly changed.
>
> Lastly we unroll the 'vmap_to_page' on x86 as inside the macro there
> is a posibility of a NULL pointer. Hence we unroll it with extra
> ASSERTS. Note that asserts on non-debug builds are compiled out hence
> the extra checks that will just return (and leak memory).
I'm afraid I can't really make sense of this: What does "unroll" mean
here? There's no loop involved. And where's that potential for NULL?
> --- a/docs/misc/xsplice.markdown
> +++ b/docs/misc/xsplice.markdown
> @@ -841,7 +841,8 @@ The implementation must also have a mechanism for:
> * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
> * Be able to patch .rodata, .bss, and .data sections.
> * Further safety checks (blacklist of which functions cannot be patched, check
> - the stack, make sure the payload is built with same compiler as hypervisor).
> + the stack, make sure the payload is built with same compiler as hypervisor,
> + and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
The whole thing doesn't parse anymore for me with the addition,
so I can't really conclude what you mean to say here (and hence
whether that addresses the earlier question).
> @@ -120,6 +121,7 @@ static void idle_loop(void)
> (*pm_idle)();
> do_tasklet();
> do_softirq();
> + check_for_xsplice_work(); /* Must be last. */
> }
> }
>
> @@ -136,6 +138,7 @@ void startup_cpu_idle_loop(void)
>
> static void noreturn continue_idle_domain(struct vcpu *v)
> {
> + check_for_xsplice_work();
> reset_stack_and_jump(idle_loop);
> }
The placement here kind of contradicts the comment right above.
And anyway - why in both places? And why here and not in
common code, e.g. in do_softirq(), or - considering the further
addition below - inside reset_stack_and_jump() _after_ having
reset the stack (after all by doing it up front you do not really
meet your goal of doing the action "without stacks")?
> +void arch_xsplice_apply_jmp(struct xsplice_patch_func *func)
> +{
> + uint32_t val;
The way it's being used below, it clearly should be int32_t.
> + uint8_t *old_ptr;
> +
> + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> +
> + old_ptr = (uint8_t *)func->old_addr;
(Considering this cast, the "old_addr" member should be
unsigned long (or void *), not uint64_t: The latest on ARM32
such would otherwise cause problems.)
Also - where is the verification that
func->old_size >= PATCH_INSN_SIZE?
> +void arch_xsplice_revert_jmp(struct xsplice_patch_func *func)
const
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -3,6 +3,7 @@
> *
> */
>
> +#include <xen/cpu.h>
> #include <xen/err.h>
> #include <xen/guest_access.h>
> #include <xen/keyhandler.h>
> @@ -11,17 +12,29 @@
> #include <xen/mm.h>
> #include <xen/sched.h>
> #include <xen/smp.h>
> +#include <xen/softirq.h>
> #include <xen/spinlock.h>
> #include <xen/vmap.h>
> +#include <xen/wait.h>
> #include <xen/xsplice_elf.h>
> #include <xen/xsplice.h>
>
> #include <asm/event.h>
> +#include <asm/nmi.h>
Urgh?
> #include <public/sysctl.h>
>
> +/*
> + * Protects against payload_list operations and also allows only one
> + * caller in schedule_work.
> + */
> static DEFINE_SPINLOCK(payload_lock);
> static LIST_HEAD(payload_list);
>
> +/*
> + * Patches which have been applied.
> + */
Comment style.
> +struct xsplice_work
> +{
> + atomic_t semaphore; /* Used for rendezvous. First to grab it will
> + do the patching. */
"First to grab it" doesn't seem to make sense for an atomic_t variable.
> + atomic_t irq_semaphore; /* Used to signal all IRQs disabled. */
> + uint32_t timeout; /* Timeout to do the operation. */
> + struct payload *data; /* The payload on which to act. */
> + volatile bool_t do_work; /* Signals work to do. */
> + volatile bool_t ready; /* Signals all CPUs synchronized. */
> + uint32_t cmd; /* Action request: XSPLICE_ACTION_* */
> +};
Please can you do without fixed size types when the fixed size
isn't really a requirement?
> +/* There can be only one outstanding patching action. */
> +static struct xsplice_work xsplice_work;
> +
> +/* Indicate whether the CPU needs to consult xsplice_work structure. */
> +static DEFINE_PER_CPU(bool_t, work_to_do);
Peeking ahead to the uses of this, I can't see why this is needed
alongside xsplice_work.do_work.
> @@ -296,6 +331,77 @@ static int secure_payload(struct payload *payload, struct xsplice_elf *elf)
> return rc;
> }
>
> +static int check_special_sections(struct payload *payload,
> + struct xsplice_elf *elf)
const (twice, but the first parameter appears to be unused anyway)
> +{
> + unsigned int i;
> + static const char *const names[] = { ".xsplice.funcs" };
> +
> + for ( i = 0; i < ARRAY_SIZE(names); i++ )
> + {
> + struct xsplice_elf_sec *sec;
const
> + sec = xsplice_elf_sec_by_name(elf, names[i]);
> + if ( !sec )
> + {
> + printk(XENLOG_ERR "%s%s: %s is missing!\n",
> + XSPLICE, elf->name, names[i]);
> + return -EINVAL;
> + }
> +
> + if ( !sec->sec->sh_size )
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
So you check for there being one such section. Is having multiple
of them okay / meaningful?
> +static int prepare_payload(struct payload *payload,
> + struct xsplice_elf *elf)
> +{
> + struct xsplice_elf_sec *sec;
> + unsigned int i;
> + struct xsplice_patch_func *f;
const (multiple times, and I'm not going to further make this remark:
Please deal with this throughout the series)
> + sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs");
> + if ( sec )
Assuming check_special_sections() got invoked before you get here,
why the conditional?
> + {
> + if ( sec->sec->sh_size % sizeof *payload->funcs )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .xsplice.funcs!\n",
> + XSPLICE, elf->name);
> + return -EINVAL;
> + }
> +
> + payload->funcs = (struct xsplice_patch_func *)sec->load_addr;
> + payload->nfuncs = sec->sec->sh_size / (sizeof *payload->funcs);
Since this repeats (so far I thought this was more like a mistake),
and despite being a matter of taste to some degree - may I ask
that the canonical sizeof() be used, instead of (sizeof ...) or
whatever else variants?
> + }
> +
> + for ( i = 0; i < payload->nfuncs; i++ )
> + {
> + unsigned int j;
> +
> + f = &(payload->funcs[i]);
> +
> + if ( !f->new_addr || !f->old_addr || !f->old_size || !f->new_size )
Isn't new_size == 0 a particularly easy to deal with case?
> @@ -499,6 +614,321 @@ static int xsplice_list(xen_sysctl_xsplice_list_t *list)
> return rc ? : idx;
> }
>
> +/*
> + * The following functions get the CPUs into an appropriate state and
> + * apply (or revert) each of the payload's functions. This is needed
> + * for XEN_SYSCTL_XSPLICE_ACTION operation (see xsplice_action).
> + */
> +
> +static int apply_payload(struct payload *data)
> +{
> + unsigned int i;
> +
> + dprintk(XENLOG_DEBUG, "%s%s: Applying %u functions.\n", XSPLICE,
> + data->name, data->nfuncs);
> +
> + arch_xsplice_patching_enter();
> +
> + for ( i = 0; i < data->nfuncs; i++ )
> + arch_xsplice_apply_jmp(&data->funcs[i]);
> +
> + arch_xsplice_patching_leave();
> +
> + list_add_tail(&data->applied_list, &applied_list);
> +
> + return 0;
> +}
> +
> +/*
> + * This function is executed having all other CPUs with no stack (we may
> + * have cpu_idle on it) and IRQs disabled.
> + */
> +static int revert_payload(struct payload *data)
Wouldn't the same comment apply to apply_payload()? I.e. is it
useful to have here but not there (i.e. isn't the comment ahead
of xsplice_do_action() sufficient)?
> +static void xsplice_do_action(void)
> +{
> + int rc;
> + struct payload *data, *other, *tmp;
> +
> + data = xsplice_work.data;
> + /* Now this function should be the only one on any stack.
> + * No need to lock the payload list or applied list. */
Comment style.
> + switch ( xsplice_work.cmd )
> + {
> + case XSPLICE_ACTION_APPLY:
> + rc = apply_payload(data);
> + if ( rc == 0 )
> + data->state = XSPLICE_STATE_APPLIED;
> + break;
> +
> + case XSPLICE_ACTION_REVERT:
> + rc = revert_payload(data);
> + if ( rc == 0 )
> + data->state = XSPLICE_STATE_CHECKED;
> + break;
> +
> + case XSPLICE_ACTION_REPLACE:
> + rc = 0;
> + /* N.B: Use 'applied_list' member, not 'list'. */
> + list_for_each_entry_safe_reverse ( other, tmp, &applied_list, applied_list )
> + {
> + other->rc = revert_payload(other);
Why does this set ->rc, but the two earlier ones only set the local
variable?
> + if ( other->rc == 0 )
> + other->state = XSPLICE_STATE_CHECKED;
> + else
> + {
> + rc = -EINVAL;
> + break;
> + }
> + }
> +
> + if ( rc != -EINVAL )
Perhaps better "rc == 0"?
> + {
> + rc = apply_payload(data);
> + if ( rc == 0 )
> + data->state = XSPLICE_STATE_APPLIED;
> + }
> + break;
> +
> + default:
> + rc = -EINVAL;
> + break;
> + }
> +
> + data->rc = rc;
Oh, here it is. But why would an xsplice_work.cmd (which probably
shouldn't make it here anyway) mark the payload having an error?
It didn't change state or anything after all.
> +/*
> + * MUST be holding the payload_lock.
> + */
comment style (another comment I'm not going to repeat any further)
> +static int schedule_work(struct payload *data, uint32_t cmd, uint32_t timeout)
> +{
> + unsigned int cpu;
> +
> + ASSERT(spin_is_locked(&payload_lock));
Also the comment above is clearly redundant with this ASSERT().
> + /* Fail if an operation is already scheduled. */
> + if ( xsplice_work.do_work )
> + return -EBUSY;
> +
> + if ( !get_cpu_maps() )
> + {
> + printk(XENLOG_ERR "%s%s: unable to get cpu_maps lock!\n",
> + XSPLICE, data->name);
> + return -EBUSY;
> + }
> +
> + xsplice_work.cmd = cmd;
> + xsplice_work.data = data;
> + xsplice_work.timeout = timeout ?: MILLISECS(30);
> +
> + dprintk(XENLOG_DEBUG, "%s%s: timeout is %"PRI_stime"ms\n",
> + XSPLICE, data->name, xsplice_work.timeout / MILLISECS(1));
> +
> + /*
> + * Once the patching has been completed, the semaphore value will
> + * be num_online_cpus()-1.
> + */
Is this comment really useful? I.e. is that final value meaningful
for anything?
> + atomic_set(&xsplice_work.semaphore, -1);
> + atomic_set(&xsplice_work.irq_semaphore, -1);
> +
> + xsplice_work.ready = 0;
> + smp_wmb();
> + xsplice_work.do_work = 1;
> + smp_wmb();
> + /*
> + * Above smp_wmb() gives us an compiler barrier, as we MUST do this
> + * after setting the global structure.
> + */
"a compiler barrier"
> +static int mask_nmi_callback(const struct cpu_user_regs *regs, int cpu)
> +{
> + /* TODO: Handle missing NMI/MCE.*/
> + return 1;
> +}
Aren't we in common code here?
> +void check_for_xsplice_work(void)
> +{
> + unsigned int cpu = smp_processor_id();
> + nmi_callback_t saved_nmi_callback;
This again looks very x86-ish.
> + s_time_t timeout;
> + unsigned long flags;
> +
> + /* Fast path: no work to do. */
> + if ( !per_cpu(work_to_do, cpu ) )
> + return;
> +
> + /* In case we aborted, other CPUs can skip right away. */
> + if ( (!xsplice_work.do_work) )
Stray parentheses.
> + {
> + per_cpu(work_to_do, cpu) = 0;
> + return;
> + }
> +
> + ASSERT(local_irq_is_enabled());
> +
> + /* Set at -1, so will go up to num_online_cpus - 1. */
> + if ( atomic_inc_and_test(&xsplice_work.semaphore) )
> + {
> + struct payload *p;
> + unsigned int total_cpus;
> +
> + p = xsplice_work.data;
> + if ( !get_cpu_maps() )
> + {
> + printk(XENLOG_ERR "%s%s: CPU%u - unable to get cpu_maps lock!\n",
> + XSPLICE, p->name, cpu);
> + per_cpu(work_to_do, cpu) = 0;
> + xsplice_work.data->rc = -EBUSY;
> + xsplice_work.do_work = 0;
On x86 such possibly simultaneous accesses may be okay, but is
that universally the case? Wouldn't it better be only the monarch
which updates shared data?
> + /*
> + * Do NOT decrement semaphore down - as that may cause the other
> + * CPU (which may be at this exact moment checking the ASSERT)
Which ASSERT()? (I guess the one a few lines up - but does that
matter?)
> + * to assume the role of master and then needlessly time out
> + * out (as do_work is zero).
> + */
> + return;
> + }
> +
> + barrier(); /* MUST do it after get_cpu_maps. */
> + total_cpus = num_online_cpus() - 1;
Considering this the variable (and earlier function parameter) is
misnamed.
> + if ( total_cpus )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: CPU%u - IPIing the %u CPUs\n",
Not being a native speaker, I've previously observed too many
articles - the "the" here again looks quite odd, or there is an
"other" missing.
> + XSPLICE, p->name, cpu, total_cpus);
> + smp_call_function(reschedule_fn, NULL, 0);
> + }
> +
> + timeout = xsplice_work.timeout + NOW();
> + if ( xsplice_do_wait(&xsplice_work.semaphore, timeout, total_cpus,
> + "Timed out on CPU semaphore") )
> + goto abort;
> +
> + /* "Mask" NMIs. */
> + saved_nmi_callback = set_nmi_callback(mask_nmi_callback);
So what if an NMI got raised on a remote CPU right before you set
this? I.e. doesn't this need to move earlier?
> + /* All CPUs are waiting, now signal to disable IRQs. */
> + xsplice_work.ready = 1;
> + smp_wmb();
> +
> + atomic_inc(&xsplice_work.irq_semaphore);
> + if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout, total_cpus,
> + "Timed out on IRQ semaphore") )
I'd prefer if the common parts of that message moved into
xsplice_do_wait() - no reason to have more string literal space
occupied than really needed. Also, looking back, the respective
function parameter could do with a more descriptive name.
And then - does it make sense to wait the perhaps full 30ms
on this second step? Rendezvoused CPUs should react rather
quickly to the signal to disable interrupts.
> + {
> + local_irq_save(flags);
> + /* Do the patching. */
> + xsplice_do_action();
> + /* To flush out pipeline. */
> + arch_xsplice_post_action();
The comment needs to become more generic, and maybe the
function name more specific.
> + local_irq_restore(flags);
> + }
> + set_nmi_callback(saved_nmi_callback);
> +
> + abort:
> + per_cpu(work_to_do, cpu) = 0;
> + xsplice_work.do_work = 0;
> +
> + smp_wmb(); /* Synchronize with waiting CPUs. */
What "synchronization" does this barrier do?
> + ASSERT(local_irq_is_enabled());
Is there really anything between the earlier identical ASSERT() and
this one which could leave interrupts off?
> + put_cpu_maps();
> +
> + printk(XENLOG_INFO "%s%s finished with rc=%d\n", XSPLICE,
> + p->name, p->rc);
And no record left of what was done with that payload?
> + }
> + else
> + {
> + /* Wait for all CPUs to rendezvous. */
> + while ( xsplice_work.do_work && !xsplice_work.ready )
> + {
> + cpu_relax();
> + smp_rmb();
What is the barrier doing inside this and the other loop below?
> @@ -635,15 +1063,30 @@ static void xsplice_printall(unsigned char key)
> }
>
> list_for_each_entry ( data, &payload_list, list )
> + {
> printk(" name=%s state=%s(%d) %p (.data=%p, .rodata=%p) using %zu pages.\n",
> data->name, state2str(data->state), data->state, data->text_addr,
> data->rw_addr, data->ro_addr, data->payload_pages);
>
> + for ( i = 0; i < data->nfuncs; i++ )
> + {
> + struct xsplice_patch_func *f = &(data->funcs[i]);
> + printk(" %s patch 0x%"PRIx64"(%u) with 0x%"PRIx64"(%u)\n",
%# again please.
> + f->name, f->old_addr, f->old_size, f->new_addr, f->new_size);
> + if ( !(i % 100) )
Using a power of 2 in situations like this is going to produce both
smaller and faster code (the faster aspect may not matter here,
but anyway). Also I don't think you want to do this on the first
iteration.
> + process_pending_softirqs();
With a lock held?
> static int __init xsplice_init(void)
> {
> + BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
> + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
> + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
What assumptions get broken if these sizes change?
> --- a/xen/include/xen/xsplice.h
> +++ b/xen/include/xen/xsplice.h
> @@ -11,12 +11,30 @@ struct xsplice_elf_sec;
> struct xsplice_elf_sym;
> struct xen_sysctl_xsplice_op;
>
> +#include <xen/elfstructs.h>
> +/*
> + * The structure which defines the patching. This is what the hypervisor
> + * expects in the '.xsplice.func' section of the ELF file.
> + *
> + * This MUST be in sync with what the tools generate.
In which case this need to be part of the public interface, I would
say.
> + */
> +struct xsplice_patch_func {
> + const char *name;
> + uint64_t new_addr;
> + uint64_t old_addr;
> + uint32_t new_size;
> + uint32_t old_size;
> + uint8_t undo[8];
Shouldn't the size of this array be a per-arch constant?
> + uint8_t pad[24];
What is this padding field good for?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.
2016-03-24 20:00 ` [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version' Konrad Rzeszutek Wilk
@ 2016-04-01 13:33 ` Jan Beulich
2016-04-06 2:03 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 13:33 UTC (permalink / raw)
To: mpohlack, andrew.cooper3, ross.lagerwall, konrad, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
Cc: Keir Fraser, Julien Grall, Stefano Stabellini
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -75,6 +75,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
> fi; \
> fi
> + $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) install
>
> .PHONY: _uninstall
> _uninstall: D=$(DESTDIR)
> @@ -92,6 +93,7 @@ _uninstall:
> rm -f $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi
> rm -f $(D)$(EFI_DIR)/$(T).efi
> rm -f $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi
> + $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) uninstall
Pretty certainly stray changes, or they'd need a really good
explanation.
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -75,7 +75,12 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
> $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
> ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
> `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
> + $(MAKE) -f $(BASEDIR)/Rules.mk -C test
>
> +install:
> + $(MAKE) -f $(BASEDIR)/Rules.mk -C test install
> +uninstall:
> + $(MAKE) -f $(BASEDIR)/Rules.mk -C test uninstall
Tests or examples should not be built by default.
> --- /dev/null
> +++ b/xen/arch/x86/test/xen_hello_world.c
> @@ -0,0 +1,30 @@
> +/*
> + * Copyright (c) 2016 Oracle and/or its affiliates. All rights reserved.
> + *
> + */
> +
> +#include <xen/config.h>
Another of these things needing taking care of throughout the
entire series.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-03-24 20:00 ` [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address Konrad Rzeszutek Wilk
@ 2016-04-01 15:11 ` Jan Beulich
2016-04-07 3:14 ` Konrad Rzeszutek Wilk
[not found] ` <5707D68A.8090006@citrix.com>
0 siblings, 2 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 15:11 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
> - | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
> + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
> + >$(@D)/.$(@F).0.S
> $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
> - | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
> + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
> + >$(@D)/.$(@F).1.S
This addition should be dependent on CONFIG_XSPLICE, not the
least because I expect it to bloat the symbol table quite a bit. And
then - how come this is needed here, but not in the xen.efi rule?
> +uint64_t symbols_lookup_by_name(const char *symname)
I don't think such a function can reasonably return other than void *
or unsigned long.
> +{
> + uint32_t symnum = 0;
> + uint64_t addr = 0, outaddr = 0;
> + int rc;
> + char type;
> + char name[KSYM_NAME_LEN + 1] = {0};
This and likely addr's initializer seem pointless. (And it's questionable
whether you really need both addr and outaddr.)
> + do {
> + rc = xensyms_read(&symnum, &type, &addr, name);
> + if ( rc )
> + break;
> +
> + if ( !strcmp(name, symname) )
> + {
> + outaddr = addr;
> + break;
> + }
> + } while ( name[0] != '\0' );
> +
> + return outaddr;
> +}
Huh - a brute force linear lookup. We've got some 7,000 symbols
right now, and I think we can't expect that to go down.
> +uint64_t xsplice_symbols_lookup_by_name(const char *symname)
> +{
> + struct payload *data;
> + unsigned int i;
> + uint64_t value = 0;
> +
> + spin_lock_recursive(&payload_lock);
> +
> + list_for_each_entry ( data, &payload_list, list )
> + {
> + for ( i = 0; i < data->nsyms; i++ )
> + {
> + if ( !data->symtab[i].new_symbol )
> + continue;
> +
> + if ( !strcmp(data->symtab[i].name, symname) )
> + {
> + value = data->symtab[i].value;
> + goto out;
> + }
> + }
> + }
> +
> +out:
Label indentation.
> @@ -397,8 +429,126 @@ static int prepare_payload(struct payload *payload,
> for ( j = 0; j < 24; j++ )
> if ( f->pad[j] )
> return -EINVAL;
> +
> + /* Lookup function's old address if not already resolved. */
> + if ( !f->old_addr )
> + {
> + f->old_addr = symbols_lookup_by_name(f->name);
> + if ( !f->old_addr )
> + {
> + f->old_addr = xsplice_symbols_lookup_by_name(f->name);
This returns with the lock not held - can you really rely on the symbol
staying around?
> + if ( !f->old_addr )
> + {
> + printk(XENLOG_ERR "%s%s: Could not resolve old address of %s\n",
> + XSPLICE, elf->name, f->name);
Any log messages not rate limited by default need careful
consideration. I don't think this is one which needs to be
XENLOG_ERR, even if the condition is an error one.
> +static bool_t is_core_symbol(const struct xsplice_elf *elf,
> + const struct xsplice_elf_sym *sym)
What does "core" here mean?
> +{
> + if ( sym->sym->st_shndx == SHN_UNDEF ||
> + sym->sym->st_shndx >= elf->hdr->e_shnum )
> + return 0;
> +
> + return !!( (elf->sec[sym->sym->st_shndx].sec->sh_flags & SHF_ALLOC) &&
> + (ELF64_ST_TYPE(sym->sym->st_info) == STT_OBJECT ||
> + ELF64_ST_TYPE(sym->sym->st_info) == STT_FUNC) );
> +}
How does the symbol type matter? Don't you rather mean to
ignore static symbols? Or maybe even just section ones?
Also - stray blanks and !!.
> +static int build_symbol_table(struct payload *payload,
> + const struct xsplice_elf *elf)
> +{
> + unsigned int i, j, nsyms = 0;
> + size_t strtab_len = 0;
> + struct xsplice_symbol *symtab;
> + char *strtab;
> +
> + ASSERT(payload->nfuncs);
> +
> + /* Recall that section @0 is always NULL. */
> + for ( i = 1; i < elf->nsym; i++ )
> + {
> + if ( is_core_symbol(elf, elf->sym + i) )
> + {
> + nsyms++;
> + strtab_len += strlen(elf->sym[i].name) + 1;
> + }
> + }
> +
> + symtab = xmalloc_array(struct xsplice_symbol, nsyms);
> + if ( !symtab )
> + return -ENOMEM;
> +
> + strtab = xmalloc_bytes(strtab_len);
xmalloc_array(char, strtab_len);
> + if ( !strtab )
> + {
> + xfree(symtab);
> + return -ENOMEM;
> + }
To limit the number of return paths, could I talk you into doing both
allocations and only then checking both return values?
> + nsyms = 0;
> + strtab_len = 0;
> + for ( i = 1; i < elf->nsym; i++ )
> + {
> + if ( is_core_symbol(elf, elf->sym + i) )
> + {
> + symtab[nsyms].name = strtab + strtab_len;
> + symtab[nsyms].size = elf->sym[i].sym->st_size;
> + symtab[nsyms].value = elf->sym[i].sym->st_value;
> + symtab[nsyms].new_symbol = 0; /* To be checked below. */
> + strtab_len += strlcpy(strtab + strtab_len, elf->sym[i].name,
> + KSYM_NAME_LEN) + 1;
> + nsyms++;
> + }
> + }
> +
> + for ( i = 0; i < nsyms; i++ )
> + {
> + bool_t found = 0;
> +
> + for ( j = 0; j < payload->nfuncs; j++ )
> + {
> + if ( symtab[i].value == payload->funcs[j].new_addr )
> + {
> + found = 1;
> + break;
> + }
> + }
> +
> + if ( !found )
> + {
> + if ( xsplice_symbols_lookup_by_name(symtab[i].name) )
> + {
> + printk(XENLOG_ERR "%s%s: duplicate new symbol: %s\n",
> + XSPLICE, elf->name, symtab[i].name);
> + xfree(symtab);
> + xfree(strtab);
> + return -EEXIST;
> + }
> + symtab[i].new_symbol = 1;
> + dprintk(XENLOG_DEBUG, "%s%s: new symbol %s\n",
> + XSPLICE, elf->name, symtab[i].name);
> + }
> + else
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: overriding symbol %s\n",
> + XSPLICE, elf->name, symtab[i].name);
Since you don't do anything here - how is this an override of some
sort?
> @@ -235,15 +236,27 @@ int xsplice_elf_resolve_symbols(struct xsplice_elf *elf)
> break;
>
> case SHN_UNDEF:
> - printk(XENLOG_ERR "%s%s: Unknown symbol: %s\n",
> - XSPLICE, elf->name, elf->sym[i].name);
> - return -ENOENT;
> + elf->sym[i].sym->st_value = symbols_lookup_by_name(elf->sym[i].name);
> + if ( !elf->sym[i].sym->st_value )
> + {
> + elf->sym[i].sym->st_value =
> + xsplice_symbols_lookup_by_name(elf->sym[i].name);
> + if ( !elf->sym[i].sym->st_value )
> + {
> + printk(XENLOG_ERR "%s%s: Unknown symbol: %s\n",
> + XSPLICE, elf->name, elf->sym[i].name);
> + return -ENOENT;
> + }
> + }
> + dprintk(XENLOG_DEBUG, "%s%s: Undefined symbol resolved: %s => 0x%"PRIx64"\n",
> + XSPLICE, elf->name, elf->sym[i].name,
> + (uint64_t)elf->sym[i].sym->st_value);
> break;
>
> case SHN_ABS:
> dprintk(XENLOG_DEBUG, "%s%s: Absolute symbol: %s => 0x%"PRIx64"\n",
> XSPLICE, elf->name, elf->sym[i].name,
> - elf->sym[i].sym->st_value);
> + (uint64_t)elf->sym[i].sym->st_value);
This change does not seem to belong here.
> --- a/xen/include/xen/xsplice.h
> +++ b/xen/include/xen/xsplice.h
> @@ -33,8 +33,16 @@ struct xsplice_patch_func {
> /* Convenience define for printk. */
> #define XSPLICE "xsplice: "
>
> +struct xsplice_symbol {
> + const char *name;
> + uint64_t value;
> + ssize_t size;
While mentioned in the revision log - why signed?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces
2016-03-24 20:00 ` [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces Konrad Rzeszutek Wilk
@ 2016-04-01 15:23 ` Jan Beulich
2016-04-06 2:39 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 15:23 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> @@ -331,16 +332,17 @@ static char *pointer(char *str, char *end, const char **fmt_ptr,
> {
> unsigned long sym_size, sym_offset;
> char namebuf[KSYM_NAME_LEN+1];
> + bool_t payload = 0;
>
> /* Advance parents fmt string, as we have consumed 's' or 'S' */
> ++*fmt_ptr;
>
> s = symbols_lookup((unsigned long)arg, &sym_size, &sym_offset, namebuf);
> -
> - /* If the symbol is not found, fall back to printing the address */
> + /* If the symbol is not found, fall back to printing the address. */
> if ( !s )
> break;
> -
Please don't drop blank lines like this.
> + if ( strncmp(namebuf, s, KSYM_NAME_LEN) )
> + payload = 1;
What is this about? A comment is absolutely needed here, the
more that without context "payload" is also an unclear term.
And then - would simply comparing the two pointers suffice?
> +static const char *xsplice_symbols_lookup(unsigned long addr,
> + unsigned long *symbolsize,
> + unsigned long *offset,
> + char *namebuf)
> +{
> + struct payload *data;
> + unsigned int i;
> + int best;
> +
> + /*
> + * No locking since this list is only ever changed during apply or revert
> + * context.
> + */
> + list_for_each_entry ( data, &applied_list, applied_list )
> + {
> + if ( !((void *)addr >= data->text_addr &&
> + (void *)addr < (data->text_addr + data->text_size)) )
> + continue;
It may be just me, but I find such !() constructs harder to understand
than the equivalent without that negation.
> + best = -1;
> +
> + for ( i = 0; i < data->nsyms; i++ )
> + {
> + if ( data->symtab[i].value <= addr &&
> + ( best == -1 ||
Stray blank.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-03-24 20:00 ` [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case Konrad Rzeszutek Wilk
@ 2016-04-01 15:50 ` Jan Beulich
2016-04-06 2:42 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 15:50 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> From: Ross Lagerwall <ross.lagerwall@citrix.com>
>
> Add hook functions which run during patch apply and patch revert.
> Hook functions are used by xsplice payloads to manipulate data structures
> during patching, etc.
Since the added documentation here didn't enlighten me, I've gone
back to the design doc, and found a single trivial mentioning of hooks.
No example of what they would be useful for, nothing. Unless these
can be shown to be needed if any recent XSA fix would be converted
to an xSplice patch, I'd recommend dropping this for now.
> @@ -851,6 +878,11 @@ static int apply_payload(struct payload *data)
>
> arch_xsplice_patching_leave();
>
> + spin_debug_disable();
> + for ( i = 0; i < data->n_load_funcs; i++ )
> + data->load_funcs[i]();
> + spin_debug_enable();
The spin debug disabling needs explanation. And shouldn't this be
done before arch_xsplice_patching_leave()? Or wait,
documentation above says "before payload is being applied", so it
would need to go even further up, and ...
> @@ -874,6 +906,11 @@ static int revert_payload(struct payload *data)
>
> arch_xsplice_patching_leave();
>
> + spin_debug_disable();
> + for ( i = 0; i < data->n_unload_funcs; i++ )
> + data->unload_funcs[i]();
> + spin_debug_enable();
... it would be this one which may need to move up by just a few
lines.
> --- /dev/null
> +++ b/xen/include/xen/xsplice_patch.h
> @@ -0,0 +1,59 @@
> +/*
> + * Copyright (C) 2016 Citrix Systems R&D Ltd.
> + */
> +
> +#ifndef __XEN_XSPLICE_PATCH_H__
> +#define __XEN_XSPLICE_PATCH_H__
> +
> +/*
> + * The following definitions are to be used in patches. They are taken
> + * from kpatch.
> + */
> +typedef void (*xsplice_loadcall_t)(void);
> +typedef void (*xsplice_unloadcall_t)(void);
Plain function types please.
> +/* This definition is taken from Linux. */
> +#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
> +/*
> + * XSPLICE_IGNORE_SECTION macro
> + *
> + * This macro is for ignoring sections that may change as a side effect of
> + * another change or might be a non-bundlable section; that is one that does
> + * not honor -ffunction-section and create a one-to-one relation from function
> + * symbol to section.
> + */
> +#define XSPLICE_IGNORE_SECTION(_sec) \
> + char *__UNIQUE_ID(xsplice_ignore_section_) __section(".xsplice.ignore.sections") = _sec;
> +
> +/*
> + * XSPLICE_IGNORE_FUNCTION macro
> + *
> + * This macro is for ignoring functions that may change as a side effect of a
> + * change in another function.
> + */
> +#define XSPLICE_IGNORE_FUNCTION(_fn) \
> + void *__xsplice_ignore_func_##_fn __section(".xsplice.ignore.functions") = _fn;
Despite mentioned in the commit message, all of the above seems
unrelated (and unclear in this context). Even more so that - afaict -
they're unusable as we don't seem to have any __PASTE().
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 16/28] xsplice: Add support for bug frames.
2016-03-24 20:00 ` [PATCH v5 16/28] xsplice: Add support for bug frames Konrad Rzeszutek Wilk
@ 2016-04-01 16:00 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 16:00 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -120,6 +120,24 @@ static int verify_payload(const xen_sysctl_xsplice_upload_t *upload)
> return 0;
> }
>
> +bool_t is_patch(const void *ptr)
> +{
> + struct payload *data;
> +
> + /*
> + * No locking since this list is only ever changed during apply or revert
> + * context.
> + */
> + list_for_each_entry ( data, &applied_list, applied_list )
> + {
> + if ( ptr >= data->ro_addr &&
> + ptr < (data->ro_addr + data->ro_size) )
> + return 1;
> + }
> +
> + return 0;
> +}
A function with this name can't look at just .rodata. Nor may you
assume in the first place that the file names you look for are
guaranteed to be in .rodata.
> @@ -533,6 +551,28 @@ static int prepare_payload(struct payload *payload,
> region->start = (unsigned long)payload->text_addr;
> region->end = (unsigned long)(payload->text_addr + payload->text_size);
>
> + /* Optional sections. */
> + for ( i = 0; i < BUGFRAME_NR; i++ )
> + {
> + char str[14];
> +
> + snprintf(str, sizeof str, ".bug_frames.%u", i);
> + sec = xsplice_elf_sec_by_name(elf, str);
> + if ( !sec )
> + continue;
> +
> + if ( !sec->sec->sh_size ||
I don't think there's anything wrong with this section being empty.
> + (sec->sec->sh_size % sizeof (struct bug_frame)) )
Please use sizeof(*region->frame->bugs) here to avoid a possible
disconnect between the expression here and the actual type
needed.
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .bug_frames.%u!\n",
> + XSPLICE, elf->name, i);
> + return -EINVAL;
> + }
> +
> + region->frame[i].bugs = (struct bug_frame *)sec->load_addr;
The more of these casts I see the more convinced I am that - if
they're needed - the type of load_addr was badly chosen.
> + region->frame[i].n_bugs = sec->sec->sh_size / sizeof(struct bug_frame);
Same remark for the sizeof() as above.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 17/28] xsplice: Add support for exception tables.
2016-03-24 20:00 ` [PATCH v5 17/28] xsplice: Add support for exception tables Konrad Rzeszutek Wilk
@ 2016-04-01 16:06 ` Jan Beulich
2016-04-06 14:41 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 16:06 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -573,6 +573,25 @@ static int prepare_payload(struct payload *payload,
> region->frame[i].n_bugs = sec->sec->sh_size / sizeof(struct bug_frame);
> }
>
> +#ifdef CONFIG_X86
> + sec = xsplice_elf_sec_by_name(elf, ".ex_table");
> + if ( sec )
> + {
> + if ( !sec->sec->sh_size ||
> + (sec->sec->sh_size % sizeof (struct exception_table_entry)) )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .ex_table (exp:%lu vs %lu)!\n",
> + XSPLICE, elf->name, sizeof (struct exception_table_entry),
> + sec->sec->sh_size);
> + return -EINVAL;
> + }
> +
> + region->ex = (struct exception_table_entry *)sec->load_addr;
> + region->ex_end = (struct exception_table_entry *)(sec->load_addr + sec->sec->sh_size);
> +
> + sort_exception_table(region->ex, region->ex_end);
> + }
> +#endif
Nothing here is really x86-specific, so the earlier comment on the
conditionals better going away applies here too.
> --- a/xen/include/asm-x86/uaccess.h
> +++ b/xen/include/asm-x86/uaccess.h
> @@ -276,6 +276,11 @@ extern struct exception_table_entry
> __start___pre_ex_table[];
> extern struct exception_table_entry __stop___pre_ex_table[];
>
> extern unsigned long search_exception_table(unsigned long);
> +extern unsigned long search_one_extable(const struct exception_table_entry *first,
> + const struct exception_table_entry *last,
> + unsigned long value);
I can't seem to find a use of the outside its defining file. Why is
this being made global?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 18/28] xsplice: Add support for alternatives
2016-03-24 20:00 ` [PATCH v5 18/28] xsplice: Add support for alternatives Konrad Rzeszutek Wilk
@ 2016-04-01 16:20 ` Jan Beulich
2016-04-07 3:11 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-01 16:20 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/arch/x86/alternative.c
> +++ b/xen/arch/x86/alternative.c
> @@ -28,7 +28,7 @@
> extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
>
> #ifdef K8_NOP1
> -static const unsigned char k8nops[] __initconst = {
> +static const unsigned char k8nops[] = {
Just like in Linux these init annotations should become conditional
upon CONFIG_XSPLICE (and I realize this applies to at least the
previous patch too).
> @@ -127,7 +127,7 @@ static void __init add_nops(void *insns, unsigned int len)
> *
> * This routine is called with local interrupt disabled.
> */
> -static void *__init text_poke_early(void *addr, const void *opcode, size_t len)
> +static void *text_poke_early(void *addr, const void *opcode, size_t len)
I'm afraid this function's name as well as the comment preceding it
need to change.
> -static void __init apply_alternatives(struct alt_instr *start, struct alt_instr *end)
> +void apply_alternatives_nocheck(struct alt_instr *start, struct alt_instr *end)
Same here - the preceding comment needs adjustment.
> --- a/xen/arch/x86/test/xen_hello_world_func.c
> +++ b/xen/arch/x86/test/xen_hello_world_func.c
> @@ -5,10 +5,13 @@
>
> #include <xen/config.h>
> #include <xen/types.h>
> +#include <asm/nops.h>
> +#include <asm/alternative.h>
>
> /* Our replacement function for xen_extra_version. */
> const char *xen_hello_world(void)
> {
> + alternative(ASM_NOP1, ASM_NOP1, 1);
Above you say the code is being exercised by this: How can you be
sure that whatever feature has value 1 is actually present? The
pending SMEP/SMAP patches add X86_FEATURE_ALWAYS for such
a purpose.
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -590,6 +590,22 @@ static int prepare_payload(struct payload *payload,
> region->ex_end = (struct exception_table_entry *)(sec->load_addr + sec->sec->sh_size);
>
> sort_exception_table(region->ex, region->ex_end);
> +
> + }
These two lines want to be swapped.
> + sec = xsplice_elf_sec_by_name(elf, ".altinstructions");
> + if ( sec )
> + {
> + if ( !sec->sec->sh_size ||
> + (sec->sec->sh_size % sizeof (struct alt_instr)) )
> + {
> + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .alt_instr (exp:%lu vs %lu)!\n",
> + XSPLICE, elf->name, sizeof (struct alt_instr),
> + sec->sec->sh_size);
> + return -EINVAL;
> + }
> + apply_alternatives_nocheck((struct alt_instr *)sec->load_addr,
> + (struct alt_instr *)(sec->load_addr +
> + sec->sec->sh_size));
I think alternative patching needs to enforce that only code/data
within the owning image gets patched, to avoid abuse.
> --- a/xen/include/asm-x86/alternative.h
> +++ b/xen/include/asm-x86/alternative.h
> @@ -23,6 +23,12 @@ struct alt_instr {
> u8 replacementlen; /* length of new instruction, <= instrlen */
> };
>
> +/*
> + * An variant to be used on code that can be patched without many checks.
> + */
"A variant", comment style, and - what does "many" mean?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-01 13:28 ` Jan Beulich
@ 2016-04-01 21:04 ` Konrad Rzeszutek Wilk
2016-04-04 7:07 ` Jan Beulich
2016-04-07 3:09 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-01 21:04 UTC (permalink / raw)
To: Jan Beulich, ross.lagerwall
Cc: Kevin Tian, Keir Fraser, Suravee Suthikulpanit, andrew.cooper3,
mpohlack, Julien Grall, Stefano Stabellini, Jun Nakajima,
sasha.levin, xen-devel, Boris Ostrovsky
Hey Jan,
Thank you for your review!
Please see below my answers.
Ross,
Could you answer one question below please.
On Fri, Apr 01, 2016 at 07:28:00AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > From: Ross Lagerwall <ross.lagerwall@citrix.com>
> >
> > Implement support for the apply, revert and replace actions.
> >
> > To perform and action on a payload, the hypercall sets up a data
> > structure to schedule the work. A hook is added in all the
> > return-to-guest paths to check for work to do and execute it if needed.
>
> Looking at the diffstat alone I cannot see this being the case.
> Perhaps it's just the description here which needs to become
> more precise.
s/all the/common/ ?
>
> > In this way, patches can be applied with all CPUs idle and without
> > stacks. The first CPU to do_xsplice() becomes the master and triggers a
> > reschedule softirq to trigger all the other CPUs to enter do_xsplice()
> > with no stack. Once all CPUs have rendezvoused, all CPUs disable IRQs
> > and NMIs are ignored. The system is then quiscient and the master
> > performs the action. After this, all CPUs enable IRQs and NMIs are
> > re-enabled.
> >
> > Note that it is unsafe to patch do_nmi and the xSplice internal functions.
> > Patching functions on NMI/MCE path is liable to end in disaster.
>
> So what measures are (planned to be) taken to make sure this
> doesn't happen by accident?
None in this patch.
Please keep in mind that this issue is not only a problem with
xSplice but also with alternative assembler patching.
I haven't figured out a nice way to take care of this and was hoping
to brainstorm that. For right now this part is left out as 'TODO'.
>
> > The action to perform is one of:
> > - APPLY: For each function in the module, store the first 5 bytes of the
> > old function and replace it with a jump to the new function.
> > - REVERT: Copy the previously stored bytes into the first 5 bytes of the
> > old function.
> > - REPLACE: Revert each applied module and then apply the new module.
> >
> > To prevent a deadlock with any other barrier in the system, the master
> > will wait for up to 30ms before timing out.
> > Measurements found that the patch application to take about 100 μs on a
> > 72 CPU system, whether idle or fully loaded.
>
> That's for an individual patch I suppose? What if REPLACE has to
> revert dozens or hundreds of patches?
The user-space can change the timeout to a larger value.
>
> > We also add an BUILD_ON to make sure that the size of the structure
> > of the payload is not inadvertly changed.
> >
> > Lastly we unroll the 'vmap_to_page' on x86 as inside the macro there
> > is a posibility of a NULL pointer. Hence we unroll it with extra
> > ASSERTS. Note that asserts on non-debug builds are compiled out hence
> > the extra checks that will just return (and leak memory).
>
> I'm afraid I can't really make sense of this: What does "unroll" mean
> here? There's no loop involved. And where's that potential for NULL?
That is a very stale comment. That should have been deleted!
>
> > --- a/docs/misc/xsplice.markdown
> > +++ b/docs/misc/xsplice.markdown
> > @@ -841,7 +841,8 @@ The implementation must also have a mechanism for:
> > * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
> > * Be able to patch .rodata, .bss, and .data sections.
> > * Further safety checks (blacklist of which functions cannot be patched, check
> > - the stack, make sure the payload is built with same compiler as hypervisor).
> > + the stack, make sure the payload is built with same compiler as hypervisor,
> > + and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
>
> The whole thing doesn't parse anymore for me with the addition,
> so I can't really conclude what you mean to say here (and hence
> whether that addresses the earlier question).
It is adding handling of NMI/MCE on the 'TODO' list so that I don't forget
about it.
>
> > @@ -120,6 +121,7 @@ static void idle_loop(void)
> > (*pm_idle)();
> > do_tasklet();
> > do_softirq();
> > + check_for_xsplice_work(); /* Must be last. */
> > }
> > }
> >
> > @@ -136,6 +138,7 @@ void startup_cpu_idle_loop(void)
> >
> > static void noreturn continue_idle_domain(struct vcpu *v)
> > {
> > + check_for_xsplice_work();
> > reset_stack_and_jump(idle_loop);
> > }
>
> The placement here kind of contradicts the comment right above.
> And anyway - why in both places? And why here and not in
> common code, e.g. in do_softirq(), or - considering the further
> addition below - inside reset_stack_and_jump() _after_ having
> reset the stack (after all by doing it up front you do not really
> meet your goal of doing the action "without stacks")?
Ross?
>
> > +void arch_xsplice_apply_jmp(struct xsplice_patch_func *func)
> > +{
> > + uint32_t val;
>
> The way it's being used below, it clearly should be int32_t.
>
> > + uint8_t *old_ptr;
> > +
> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> > +
> > + old_ptr = (uint8_t *)func->old_addr;
>
> (Considering this cast, the "old_addr" member should be
> unsigned long (or void *), not uint64_t: The latest on ARM32
> such would otherwise cause problems.)
>
> Also - where is the verification that
> func->old_size >= PATCH_INSN_SIZE?
Missing..
..snip..
> > +/* There can be only one outstanding patching action. */
> > +static struct xsplice_work xsplice_work;
> > +
> > +/* Indicate whether the CPU needs to consult xsplice_work structure. */
> > +static DEFINE_PER_CPU(bool_t, work_to_do);
>
> Peeking ahead to the uses of this, I can't see why this is needed
> alongside xsplice_work.do_work.
Andrew asked for this - he noticed that we pound on the xsplice_work
structure quite often across a lot of CPUs. Instead of pounding on the same
cache line - we could just read from a per-cpu cache line. Hence this addition.
>
> > @@ -296,6 +331,77 @@ static int secure_payload(struct payload *payload, struct xsplice_elf *elf)
> > return rc;
> > }
> >
> > +static int check_special_sections(struct payload *payload,
> > + struct xsplice_elf *elf)
>
> const (twice, but the first parameter appears to be unused anyway)
>
> > +{
> > + unsigned int i;
> > + static const char *const names[] = { ".xsplice.funcs" };
> > +
> > + for ( i = 0; i < ARRAY_SIZE(names); i++ )
> > + {
> > + struct xsplice_elf_sec *sec;
>
> const
>
> > + sec = xsplice_elf_sec_by_name(elf, names[i]);
> > + if ( !sec )
> > + {
> > + printk(XENLOG_ERR "%s%s: %s is missing!\n",
> > + XSPLICE, elf->name, names[i]);
> > + return -EINVAL;
> > + }
> > +
> > + if ( !sec->sec->sh_size )
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
>
> So you check for there being one such section. Is having multiple
> of them okay / meaningful?
/me blinks. You can have multiple ELF sections with the same name?
I will double-check the spec over the weekend to see.
.. snip..
> > + sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs");
> > + if ( sec )
>
> Assuming check_special_sections() got invoked before you get here,
> why the conditional?
Andrew asked for it. Albeit it is pointless as 'check_special_sections'
will bail halt the process if this section is not found.
>
> > + {
> > + if ( sec->sec->sh_size % sizeof *payload->funcs )
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .xsplice.funcs!\n",
> > + XSPLICE, elf->name);
> > + return -EINVAL;
> > + }
> > +
> > + payload->funcs = (struct xsplice_patch_func *)sec->load_addr;
> > + payload->nfuncs = sec->sec->sh_size / (sizeof *payload->funcs);
>
> Since this repeats (so far I thought this was more like a mistake),
> and despite being a matter of taste to some degree - may I ask
> that the canonical sizeof() be used, instead of (sizeof ...) or
> whatever else variants?
Sure. I will convert Ross's use of it.
>
> > + }
> > +
> > + for ( i = 0; i < payload->nfuncs; i++ )
> > + {
> > + unsigned int j;
> > +
> > + f = &(payload->funcs[i]);
> > +
> > + if ( !f->new_addr || !f->old_addr || !f->old_size || !f->new_size )
>
> Isn't new_size == 0 a particularly easy to deal with case?
To NOP func? No. I would have to include the headers for the nop[] in the arch xSplice
and expand on its patching (or expose the text_poke code).
That will grow this patch which is big enough. I don't mind doing it in further patches
(and I believe it is mentioned as a TODO in the design doc so that I won't forget).
.. snip..
> > + case XSPLICE_ACTION_REPLACE:
> > + rc = 0;
> > + /* N.B: Use 'applied_list' member, not 'list'. */
> > + list_for_each_entry_safe_reverse ( other, tmp, &applied_list, applied_list )
> > + {
> > + other->rc = revert_payload(other);
>
> Why does this set ->rc, but the two earlier ones only set the local
> variable?
>
> > + if ( other->rc == 0 )
> > + other->state = XSPLICE_STATE_CHECKED;
> > + else
> > + {
> > + rc = -EINVAL;
> > + break;
> > + }
> > + }
> > +
> > + if ( rc != -EINVAL )
>
> Perhaps better "rc == 0"?
>
> > + {
> > + rc = apply_payload(data);
> > + if ( rc == 0 )
> > + data->state = XSPLICE_STATE_APPLIED;
> > + }
> > + break;
> > +
> > + default:
> > + rc = -EINVAL;
> > + break;
> > + }
> > +
> > + data->rc = rc;
>
> Oh, here it is. But why would an xsplice_work.cmd (which probably
> shouldn't make it here anyway) mark the payload having an error?
In xsplice_action() we set data->rc to -EAGAIN right before we kick
of the schedule_work(). That way the user can check the 'status'
of the patching as we attempt to do it.
But once the patching has been complete we MUST set it to zero
(or to an error if the patching failed).
> It didn't change state or anything after all.
.. snip..
> > +void check_for_xsplice_work(void)
> > +{
> > + /* Set at -1, so will go up to num_online_cpus - 1. */
> > + if ( atomic_inc_and_test(&xsplice_work.semaphore) )
> > + {
> > + struct payload *p;
> > + unsigned int total_cpus;
> > +
> > + p = xsplice_work.data;
> > + if ( !get_cpu_maps() )
> > + {
> > + printk(XENLOG_ERR "%s%s: CPU%u - unable to get cpu_maps lock!\n",
> > + XSPLICE, p->name, cpu);
> > + per_cpu(work_to_do, cpu) = 0;
> > + xsplice_work.data->rc = -EBUSY;
> > + xsplice_work.do_work = 0;
>
> On x86 such possibly simultaneous accesses may be okay, but is
> that universally the case? Wouldn't it better be only the monarch
> which updates shared data?
Monarch? Oh you mean arch specific code path?
>
> > + /*
> > + * Do NOT decrement semaphore down - as that may cause the other
> > + * CPU (which may be at this exact moment checking the ASSERT)
>
> Which ASSERT()? (I guess the one a few lines up - but does that
> matter?)
It messed me up when I was working on it so thought I would leave that in here
in case anybody wants to modify the code. Or more likely - if I rework
this code that I will recall this.
> > + /* "Mask" NMIs. */
> > + saved_nmi_callback = set_nmi_callback(mask_nmi_callback);
>
> So what if an NMI got raised on a remote CPU right before you set
> this? I.e. doesn't this need to move earlier?
Hmm. Yes we should. Thanks!
>
> > + /* All CPUs are waiting, now signal to disable IRQs. */
> > + xsplice_work.ready = 1;
> > + smp_wmb();
> > +
> > + atomic_inc(&xsplice_work.irq_semaphore);
> > + if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout, total_cpus,
> > + "Timed out on IRQ semaphore") )
>
> I'd prefer if the common parts of that message moved into
> xsplice_do_wait() - no reason to have more string literal space
> occupied than really needed. Also, looking back, the respective
> function parameter could do with a more descriptive name.
>
> And then - does it make sense to wait the perhaps full 30ms
> on this second step? Rendezvoused CPUs should react rather
> quickly to the signal to disable interrupts.
We don't reset the timeout - the timeout is for both calls
to xsplice_do_wait.
>
> > + {
> > + local_irq_save(flags);
> > + /* Do the patching. */
> > + xsplice_do_action();
> > + /* To flush out pipeline. */
> > + arch_xsplice_post_action();
>
> The comment needs to become more generic, and maybe the
> function name more specific.
Serialize CPUs? Flush CPU pipeline? Flush CPU i-cache?
>
> > + local_irq_restore(flags);
> > + }
> > + set_nmi_callback(saved_nmi_callback);
> > +
> > + abort:
> > + per_cpu(work_to_do, cpu) = 0;
> > + xsplice_work.do_work = 0;
> > +
> > + smp_wmb(); /* Synchronize with waiting CPUs. */
>
> What "synchronization" does this barrier do?
For the ->do_work being set to zero - as they are reading and reading it.
>
> > + ASSERT(local_irq_is_enabled());
>
> Is there really anything between the earlier identical ASSERT() and
> this one which could leave interrupts off?
The patching calls (in later patches) - the load and unload hooks. Those
could inadvertly enabled interrupts.
>
> > + put_cpu_maps();
> > +
> > + printk(XENLOG_INFO "%s%s finished with rc=%d\n", XSPLICE,
> > + p->name, p->rc);
>
> And no record left of what was done with that payload?
? But it does. The rc is mentioned.. Or are you saying that it should
also say whether it was applied/reverted/replaced, etc?
>
> > + }
> > + else
> > + {
> > + /* Wait for all CPUs to rendezvous. */
> > + while ( xsplice_work.do_work && !xsplice_work.ready )
> > + {
> > + cpu_relax();
> > + smp_rmb();
>
> What is the barrier doing inside this and the other loop below?
The goal is to get the updated value from ->do_work and ->ready.
That is to do the same thing we do with frontend and backends - sync
out the rp/rc so that the other end can read it the updated value.
.. snip..
> > static int __init xsplice_init(void)
> > {
> > + BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
> > + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
> > + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
>
> What assumptions get broken if these sizes change?
I think you mean the offsets? They can change. I added them to make sure
that on 32-bit hypervisor (ARM) the offsets would be the same as on 64-bit
hypervisor (x86).
The size however MUST remain the same - otherwise the toolstack won't produce
proper payloads anymore.
>
> > --- a/xen/include/xen/xsplice.h
> > +++ b/xen/include/xen/xsplice.h
> > @@ -11,12 +11,30 @@ struct xsplice_elf_sec;
> > struct xsplice_elf_sym;
> > struct xen_sysctl_xsplice_op;
> >
> > +#include <xen/elfstructs.h>
> > +/*
> > + * The structure which defines the patching. This is what the hypervisor
> > + * expects in the '.xsplice.func' section of the ELF file.
> > + *
> > + * This MUST be in sync with what the tools generate.
>
> In which case this need to be part of the public interface, I would
> say.
Ah yes. Where should it go? sysctl.h is where the XSPLICE ops are - or
should this have it is own public/xsplice.h header file?
>
> > + */
> > +struct xsplice_patch_func {
> > + const char *name;
> > + uint64_t new_addr;
> > + uint64_t old_addr;
> > + uint32_t new_size;
> > + uint32_t old_size;
> > + uint8_t undo[8];
>
> Shouldn't the size of this array be a per-arch constant?
Yes.
>
> > + uint8_t pad[24];
>
> What is this padding field good for?
I want the size of the structure to be exactly 64-bytes across
all architectures. That way I don't have to mess with compat layer
or have the design doc be different for ARM vs x86.
It gives us enough of space to stash other 'private' fields we may want
or even expand this structure in the future and fill it out
with extra fields. ARgh, but for that we need a version field
somewhere... Maybe another section .xsplice_version which just
has a value of 1?
However the one thing I am not sure about is the padding.
The 'const char *name' on 32-bit ARM will be 4 bytes hence
it will insert 4 byte padding (at least that is what pahole tells me,
and the BUILD_BUG_ON confirms). But if I built with clang or other
compiler it may very well ignore me.
Any suggestions? I could do:
struct xsplice_patch_func {
const char *name;
#ifdef CONFIG_32
uint32_t _name_pad;
#endif
uint64_t new_addr;
uint64_t old_addr;
uint32_t new_size;
uint32_t old_size;
uint8_t undo[8];
uint8_t pad[24];
}
But that is not very nice.
Also if we make this a public header I can't very well expose the
'undo' internals - it ought to be opaque. Ideas?
Thanks!
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-01 21:04 ` Konrad Rzeszutek Wilk
@ 2016-04-04 7:07 ` Jan Beulich
2016-04-07 3:05 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 7:07 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
>>> On 01.04.16 at 23:04, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 01, 2016 at 07:28:00AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > From: Ross Lagerwall <ross.lagerwall@citrix.com>
>> >
>> > Implement support for the apply, revert and replace actions.
>> >
>> > To perform and action on a payload, the hypercall sets up a data
>> > structure to schedule the work. A hook is added in all the
>> > return-to-guest paths to check for work to do and execute it if needed.
>>
>> Looking at the diffstat alone I cannot see this being the case.
>> Perhaps it's just the description here which needs to become
>> more precise.
>
> s/all the/common/ ?
Considering that non of the entry.S files get touched, I think it's
the "return-to-guest paths" part which is wrong.
>> > In this way, patches can be applied with all CPUs idle and without
>> > stacks. The first CPU to do_xsplice() becomes the master and triggers a
>> > reschedule softirq to trigger all the other CPUs to enter do_xsplice()
>> > with no stack. Once all CPUs have rendezvoused, all CPUs disable IRQs
>> > and NMIs are ignored. The system is then quiscient and the master
>> > performs the action. After this, all CPUs enable IRQs and NMIs are
>> > re-enabled.
>> >
>> > Note that it is unsafe to patch do_nmi and the xSplice internal functions.
>> > Patching functions on NMI/MCE path is liable to end in disaster.
>>
>> So what measures are (planned to be) taken to make sure this
>> doesn't happen by accident?
>
> None in this patch.
>
> Please keep in mind that this issue is not only a problem with
> xSplice but also with alternative assembler patching.
Except that an issue there would cause only a boot failure, which
would be unlikely to re-occur on the next boot attempt. Whereas
things going wrong at runtime would likely mean worse
consequences.
> I haven't figured out a nice way to take care of this and was hoping
> to brainstorm that. For right now this part is left out as 'TODO'.
That's what I've assumed, which is fine for the moment. Just maybe
make this more explicit by adding (to the above) something like "For
now this needs to be ensured by the people creating patches."
>> > The action to perform is one of:
>> > - APPLY: For each function in the module, store the first 5 bytes of the
>> > old function and replace it with a jump to the new function.
>> > - REVERT: Copy the previously stored bytes into the first 5 bytes of the
>> > old function.
>> > - REPLACE: Revert each applied module and then apply the new module.
>> >
>> > To prevent a deadlock with any other barrier in the system, the master
>> > will wait for up to 30ms before timing out.
>> > Measurements found that the patch application to take about 100 μs on a
>> > 72 CPU system, whether idle or fully loaded.
>>
>> That's for an individual patch I suppose? What if REPLACE has to
>> revert dozens or hundreds of patches?
>
> The user-space can change the timeout to a larger value.
The question wasn't about the timeout expiring, but about the latency
of the operation (and the resulting effect on the system).
>> > --- a/docs/misc/xsplice.markdown
>> > +++ b/docs/misc/xsplice.markdown
>> > @@ -841,7 +841,8 @@ The implementation must also have a mechanism for:
>> > * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
>> > * Be able to patch .rodata, .bss, and .data sections.
>> > * Further safety checks (blacklist of which functions cannot be patched, check
>> > - the stack, make sure the payload is built with same compiler as hypervisor).
>> > + the stack, make sure the payload is built with same compiler as hypervisor,
>> > + and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
>>
>> The whole thing doesn't parse anymore for me with the addition,
>> so I can't really conclude what you mean to say here (and hence
>> whether that addresses the earlier question).
>
> It is adding handling of NMI/MCE on the 'TODO' list so that I don't forget
> about it.
Please try to re-word the addition then to make the result readable
again.
>> > +/* There can be only one outstanding patching action. */
>> > +static struct xsplice_work xsplice_work;
>> > +
>> > +/* Indicate whether the CPU needs to consult xsplice_work structure. */
>> > +static DEFINE_PER_CPU(bool_t, work_to_do);
>>
>> Peeking ahead to the uses of this, I can't see why this is needed
>> alongside xsplice_work.do_work.
>
> Andrew asked for this - he noticed that we pound on the xsplice_work
> structure quite often across a lot of CPUs. Instead of pounding on the same
> cache line - we could just read from a per-cpu cache line. Hence this
> addition.
Then please make the comment say so in a more explicit way.
>> > + sec = xsplice_elf_sec_by_name(elf, names[i]);
>> > + if ( !sec )
>> > + {
>> > + printk(XENLOG_ERR "%s%s: %s is missing!\n",
>> > + XSPLICE, elf->name, names[i]);
>> > + return -EINVAL;
>> > + }
>> > +
>> > + if ( !sec->sec->sh_size )
>> > + return -EINVAL;
>> > + }
>> > +
>> > + return 0;
>> > +}
>>
>> So you check for there being one such section. Is having multiple
>> of them okay / meaningful?
>
> /me blinks. You can have multiple ELF sections with the same name?
> I will double-check the spec over the weekend to see.
Of course you can. Remember me telling you that using section
names for identification is a bad idea (even if widely done that
way)? That's precisely because section names in the spec serve
no meaning other than making sections identifiable to the human
eye. For certain sections there's a more or less strict convention
on what their names should be, but that's all there is to names.
Section types and attributes really are what describe their
purposes.
And even if that really was forbidden by the spec, you'd still need
to make sure the binary meets the spec.
>> > + sec = xsplice_elf_sec_by_name(elf, ".xsplice.funcs");
>> > + if ( sec )
>>
>> Assuming check_special_sections() got invoked before you get here,
>> why the conditional?
>
> Andrew asked for it. Albeit it is pointless as 'check_special_sections'
> will bail halt the process if this section is not found.
It's not clear why he would have wanted the check here. Imo, if
anything this should be an ASSERT() then.
>> > + }
>> > +
>> > + for ( i = 0; i < payload->nfuncs; i++ )
>> > + {
>> > + unsigned int j;
>> > +
>> > + f = &(payload->funcs[i]);
>> > +
>> > + if ( !f->new_addr || !f->old_addr || !f->old_size || !f->new_size )
>>
>> Isn't new_size == 0 a particularly easy to deal with case?
>
> To NOP func? No. I would have to include the headers for the nop[] in the
> arch xSplice
> and expand on its patching (or expose the text_poke code).
>
> That will grow this patch which is big enough. I don't mind doing it in
> further patches
> (and I believe it is mentioned as a TODO in the design doc so that I won't
> forget).
That's fine, except for one aspect: The error value resulting from
this: EINVAL is appropriate only for invalid input. When valid input
just doesn't get handled suitably, EOPNOTSUPP or some such should
be used instead.
>> > + default:
>> > + rc = -EINVAL;
>> > + break;
>> > + }
>> > +
>> > + data->rc = rc;
>>
>> Oh, here it is. But why would an xsplice_work.cmd (which probably
>> shouldn't make it here anyway) mark the payload having an error?
>
> In xsplice_action() we set data->rc to -EAGAIN right before we kick
> of the schedule_work(). That way the user can check the 'status'
> of the patching as we attempt to do it.
>
> But once the patching has been complete we MUST set it to zero
> (or to an error if the patching failed).
Okay, makes sense. But I realize a word was missing from my reply.
I meant "But why would an invalid xsplice_work.cmd (which probably
shouldn't make it here anyway) mark the payload having an error?"
I.e. the question particularly is about the default case (with the
suggestion to just ditch it, or make in an ASSERT_UNREACHABLE()).
>> It didn't change state or anything after all.
> .. snip..
>> > +void check_for_xsplice_work(void)
>> > +{
>> > + /* Set at -1, so will go up to num_online_cpus - 1. */
>> > + if ( atomic_inc_and_test(&xsplice_work.semaphore) )
>> > + {
>> > + struct payload *p;
>> > + unsigned int total_cpus;
>> > +
>> > + p = xsplice_work.data;
>> > + if ( !get_cpu_maps() )
>> > + {
>> > + printk(XENLOG_ERR "%s%s: CPU%u - unable to get cpu_maps lock!\n",
>> > + XSPLICE, p->name, cpu);
>> > + per_cpu(work_to_do, cpu) = 0;
>> > + xsplice_work.data->rc = -EBUSY;
>> > + xsplice_work.do_work = 0;
>>
>> On x86 such possibly simultaneous accesses may be okay, but is
>> that universally the case? Wouldn't it better be only the monarch
>> which updates shared data?
>
> Monarch? Oh you mean arch specific code path?
Oh, I think you call it "master" elsewhere. IA64 terminology which
I came to like.
>> > + /* All CPUs are waiting, now signal to disable IRQs. */
>> > + xsplice_work.ready = 1;
>> > + smp_wmb();
>> > +
>> > + atomic_inc(&xsplice_work.irq_semaphore);
>> > + if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout, total_cpus,
>> > + "Timed out on IRQ semaphore") )
>>
>> I'd prefer if the common parts of that message moved into
>> xsplice_do_wait() - no reason to have more string literal space
>> occupied than really needed. Also, looking back, the respective
>> function parameter could do with a more descriptive name.
>>
>> And then - does it make sense to wait the perhaps full 30ms
>> on this second step? Rendezvoused CPUs should react rather
>> quickly to the signal to disable interrupts.
>
> We don't reset the timeout - the timeout is for both calls
> to xsplice_do_wait.
I understand that's the way it's right now, but that's what I'm putting
under question. Rendezvousing CPUs is quite a bit more at risk of
taking some time compared to having already rendezvoused CPUs
disable their IRQs.
>>
>> > + {
>> > + local_irq_save(flags);
>> > + /* Do the patching. */
>> > + xsplice_do_action();
>> > + /* To flush out pipeline. */
>> > + arch_xsplice_post_action();
>>
>> The comment needs to become more generic, and maybe the
>> function name more specific.
>
> Serialize CPUs? Flush CPU pipeline? Flush CPU i-cache?
Perhaps mention all of these as examples of what may need doing
in that hook.
>> > + local_irq_restore(flags);
>> > + }
>> > + set_nmi_callback(saved_nmi_callback);
>> > +
>> > + abort:
>> > + per_cpu(work_to_do, cpu) = 0;
>> > + xsplice_work.do_work = 0;
>> > +
>> > + smp_wmb(); /* Synchronize with waiting CPUs. */
>>
>> What "synchronization" does this barrier do?
>
> For the ->do_work being set to zero - as they are reading and reading it.
But barriers don't do any synchronization, they only guarantee
certain ordering requirements. I.e. a comment on a barrier would
normally indicate which operations it is that it enforces ordering
for.
>> > + ASSERT(local_irq_is_enabled());
>>
>> Is there really anything between the earlier identical ASSERT() and
>> this one which could leave interrupts off?
>
> The patching calls (in later patches) - the load and unload hooks. Those
> could inadvertly enabled interrupts.
In which case the ASSERT() would better be placed right after those
hooks (and get added alongside adding the hooks, which is pending
a decision on whether those should stay anyway).
>> > + put_cpu_maps();
>> > +
>> > + printk(XENLOG_INFO "%s%s finished with rc=%d\n", XSPLICE,
>> > + p->name, p->rc);
>>
>> And no record left of what was done with that payload?
>
> ? But it does. The rc is mentioned.. Or are you saying that it should
> also say whether it was applied/reverted/replaced, etc?
Yes, exactly.
>> > + }
>> > + else
>> > + {
>> > + /* Wait for all CPUs to rendezvous. */
>> > + while ( xsplice_work.do_work && !xsplice_work.ready )
>> > + {
>> > + cpu_relax();
>> > + smp_rmb();
>>
>> What is the barrier doing inside this and the other loop below?
>
> The goal is to get the updated value from ->do_work and ->ready.
>
> That is to do the same thing we do with frontend and backends - sync
> out the rp/rc so that the other end can read it the updated value.
But that's guaranteed already by cpu_relax() being a barrier (see
other loops in the code base invoking cpu_relax()). You have no
ordering requirement here, all you want is that the compiler not
move the two reads out of the loop.
>> > static int __init xsplice_init(void)
>> > {
>> > + BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
>> > + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
>> > + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
>>
>> What assumptions get broken if these sizes change?
>
> I think you mean the offsets? They can change. I added them to make sure
> that on 32-bit hypervisor (ARM) the offsets would be the same as on 64-bit
> hypervisor (x86).
>
> The size however MUST remain the same - otherwise the toolstack won't
> produce proper payloads anymore.
Well, that's a very bad thing then imo. You'd better version the
structure instead.
>> > --- a/xen/include/xen/xsplice.h
>> > +++ b/xen/include/xen/xsplice.h
>> > @@ -11,12 +11,30 @@ struct xsplice_elf_sec;
>> > struct xsplice_elf_sym;
>> > struct xen_sysctl_xsplice_op;
>> >
>> > +#include <xen/elfstructs.h>
>> > +/*
>> > + * The structure which defines the patching. This is what the hypervisor
>> > + * expects in the '.xsplice.func' section of the ELF file.
>> > + *
>> > + * This MUST be in sync with what the tools generate.
>>
>> In which case this need to be part of the public interface, I would
>> say.
>
> Ah yes. Where should it go? sysctl.h is where the XSPLICE ops are - or
> should this have it is own public/xsplice.h header file?
If it's just this, then I don't think a separate header is warranted,
and hence putting it in sysctl.h would seem fine to me.
>> > + uint8_t pad[24];
>>
>> What is this padding field good for?
>
> I want the size of the structure to be exactly 64-bytes across
> all architectures. That way I don't have to mess with compat layer
> or have the design doc be different for ARM vs x86.
For avoiding the compat layer, guaranteeing same size is not
sufficient anyway. And the design doc doesn't need to mention
structure sizes at all.
> It gives us enough of space to stash other 'private' fields we may want
> or even expand this structure in the future and fill it out
> with extra fields. ARgh, but for that we need a version field
> somewhere... Maybe another section .xsplice_version which just
> has a value of 1?
>
> However the one thing I am not sure about is the padding.
>
> The 'const char *name' on 32-bit ARM will be 4 bytes hence
> it will insert 4 byte padding (at least that is what pahole tells me,
> and the BUILD_BUG_ON confirms). But if I built with clang or other
> compiler it may very well ignore me.
>
> Any suggestions? I could do:
>
> struct xsplice_patch_func {
> const char *name;
> #ifdef CONFIG_32
> uint32_t _name_pad;
> #endif
> uint64_t new_addr;
> uint64_t old_addr;
> uint32_t new_size;
> uint32_t old_size;
> uint8_t undo[8];
> uint8_t pad[24];
> }
>
> But that is not very nice.
Indeed. Perhaps a union, but I'm questioning the need of uniformity
across architectures in the first place.
> Also if we make this a public header I can't very well expose the
> 'undo' internals - it ought to be opaque. Ideas?
Split it, and link the image provided structure from the internally
used one. Or have the internally used one be a superset of the
one coming from the image, and simply copy the data (at once
allowing you to discard the respective section after loading the
image).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-03-24 20:00 ` [PATCH v5 19/28] build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
@ 2016-04-04 12:46 ` Jan Beulich
2016-04-07 2:58 ` Konrad Rzeszutek Wilk
2016-04-08 0:18 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 12:46 UTC (permalink / raw)
To: mpohlack, Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Julien Grall,
Stefano Stabellini, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> The version of ld that first implemented --build-id is v2.18.
> Hence we check for that or later version - if older version
> found we do not build the hypervisor with the build-id
> (and the return code is -ENODATA for xen_build_id() call).
This appears to be stale.
> The EFI binary is more complicated. Having any non-recognizable
> sections (.note, .data.note, etc) causes the boot to hang.
> Moving the .note in the .data section makes it work. It is also
> worth noting that the PE/COFF does not have any "comment"
> sections to the author.
I'm afraid this is too vague: What exactly is happening there? And
is this due to binutils doing something wrong, or an issue with the
firmware on the box you've tried? While the placement of .note is
not really a big deal, any unusual placement needs a source
comment attached explaining the whys, to prevent people down
the road moving the section back into the "expected" place. But
see also below.
> Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
> symbol offsets don't changes (which means we have multiple binary
> ids - except that the last one is the final one). Without this change,
> the symbol table embedded in Xen are incorrect - some of the values it
> contains are offset by the size of the included build id.
> This obviously causes problems when resolving symbols.
Would this also be a problem if you place the notes segment/section
last in the binary?
> --- a/Config.mk
> +++ b/Config.mk
> @@ -126,6 +126,17 @@ endef
> check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least gcc-4.1")
> $(eval $(check-y))
>
> +ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \
> + grep -q unrecognized && echo n || echo y)
> +
> +# binutils 2.18 implement build-id.
I don't think this comment is really relevant anymore.
> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -22,6 +22,9 @@ OUTPUT_ARCH(FORMAT)
> PHDRS
> {
> text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
> +#if defined(BUILD_ID)
> + note PT_NOTE ;
> +#endif
Is this in line with ...
> @@ -57,9 +60,18 @@ SECTIONS
> *(.lockprofile.data)
> __lock_profile_end = .;
> #endif
> + } :text
>
> - _erodata = .; /* End of read-only data */
> +#if defined(BUILD_ID)
> + .note : {
> + __note_gnu_build_id_start = .;
> + *(.note.gnu.build-id)
> + __note_gnu_build_id_end = .;
> + *(.note)
> + *(.note.*)
> } :text
> +#endif
... there not being any :note here? And if so, why the earlier
"} :text"?
> --- a/xen/arch/x86/Makefile
> +++ b/xen/arch/x86/Makefile
> @@ -72,9 +72,16 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h
> -o \
> -O $(BASEDIR)/include/xen/compile.h ]; then \
> echo '$(TARGET).efi'; fi)
>
> +ifdef build_id_linker
According to Config.mk this is always true. DYM
"ifneq ($(build_id_linker),)"?
> +build_id.o: $(TARGET)-syms
> + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
Considering your xen.lds.S changes, won't this potentially copy quite
a bit more than just the build ID (i.e. all notes)? This may be okay, and
may be even intended, but then the generate file's name should
reflect this to not misguide people.
> + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
Since you put the notes into .rodata anyway, why name the
section .note.*? Just name it .rodata.*, avoiding to mislead
others who also think that a section's name has much of a
meaning.
> @@ -138,6 +151,13 @@ $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A VIR
> $(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A ALT_START$$,,p')
> # Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
> $(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:)
> +ifdef build_id_linker
See above.
> @@ -228,21 +257,22 @@ static void do_read(int fd, void *data, int len)
> int main(int argc, char **argv)
> {
> u64 final_exec_addr;
> - u32 loadbase, dat_siz, mem_siz;
> + u32 loadbase, dat_siz, mem_siz, note_base, note_sz, offset;
> char *inimage, *outimage;
> int infd, outfd;
> char buffer[1024];
> int bytes, todo, i;
> + int num_phdrs;
>
> Elf32_Ehdr in32_ehdr;
>
> Elf64_Ehdr in64_ehdr;
> Elf64_Phdr in64_phdr;
>
> - if ( argc != 5 )
> + if ( argc != 6 )
> {
> fprintf(stderr, "Usage: mkelf32 <in-image> <out-image> "
> - "<load-base> <final-exec-addr>\n");
> + "<load-base> <final-exec-addr> <number of program headers>\n");
Even if only an internally used tool, I think this is a bad interface:
You want notes copied, and this only happens to result in a second
PHDR. Hence I think there should be an option "--notes" or some
such.
> @@ -299,11 +334,36 @@ int main(int argc, char **argv)
>
> (void)lseek(infd, in64_phdr.p_offset, SEEK_SET);
> dat_siz = (u32)in64_phdr.p_filesz;
> -
> /* Do not use p_memsz: it does not include BSS alignment padding. */
Stray deletion of a blank line.
> @@ -322,6 +382,31 @@ int main(int argc, char **argv)
> out_shdr[1].sh_size = dat_siz;
> out_shdr[2].sh_offset = RAW_OFFSET + dat_siz + sizeof(out_shdr);
>
> + if ( num_phdrs > 1 )
> + {
> + /* We have two of them! */
> + out_ehdr.e_phnum = num_phdrs;
> + /* Extra .note section. */
> + out_ehdr.e_shnum++;
> +
> + /* Fill out the PT_NOTE program header. */
> + note_phdr.p_vaddr = note_base;
> + note_phdr.p_paddr = note_base;
> + note_phdr.p_filesz = note_sz;
> + note_phdr.p_memsz = note_sz;
> + note_phdr.p_offset = offset;
> +
> + /* Tack on the .note\0 */
> + out_shdr[2].sh_size += sizeof(out_shstrtab_extra);
> + /* And move it past the .note section. */
> + out_shdr[2].sh_offset += sizeof(out_shdr_extra);
Why "extra" and not "note" or "notes"?
> @@ -335,8 +420,15 @@ int main(int argc, char **argv)
>
> endianadjust_phdr32(&out_phdr);
> do_write(outfd, &out_phdr, sizeof(out_phdr));
> -
> - if ( (bytes = RAW_OFFSET - sizeof(out_ehdr) - sizeof(out_phdr)) < 0 )
> +
> + if ( num_phdrs > 1 )
> + {
> + endianadjust_phdr32(¬e_phdr);
> + do_write(outfd, ¬e_phdr, sizeof(note_phdr));
> + }
> +
> + if ( (bytes = RAW_OFFSET - sizeof(out_ehdr) - sizeof(out_phdr) -
> + ( num_phdrs > 1 ? sizeof(note_phdr) : 0 ) ) < 0 )
Stray blanks. Also with each PHDR being the same size, why not
just num_phdrs * sizeof()?
> @@ -99,6 +107,21 @@ SECTIONS
> _erodata = .;
> } :text
>
> +#if defined(BUILD_ID) && !defined(EFI)
> +/*
> + * No mechanism to put an PT_NOTE in the EFI file - so put
> + * it in .data section.
> + */
I think this comment really belongs into the earlier addition.
> + . = ALIGN(4);
I think this would better be added in the EFI case too.
> + .note : {
> + __note_gnu_build_id_start = .;
> + *(.note.gnu.build-id)
> + __note_gnu_build_id_end = .;
> + *(.note)
> + *(.note.*)
The last two don't get dealt with in the EFI case - why? And if you
include all notes here and copy them in their entirety into xen.efi,
how is __note_gnu_build_id_end expected to be correct then?
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -1,5 +1,9 @@
> #include <xen/compile.h>
> +#include <xen/errno.h>
> +#include <xen/string.h>
> +#include <xen/types.h>
> #include <xen/version.h>
> +#include <xen/elf.h>
Please put this last one into its designated slot as well, considering
that you arrange for all the rest to be nicely sorted.
> +int xen_build_id(const void **p, unsigned int *len)
> +{
> + const Elf_Note *n = __note_gnu_build_id_start;
> + static bool_t checked = 0;
> +
> + if ( checked )
> + {
> + *len = n->descsz;
> + *p = ELFNOTE_DESC(n);
> + return 0;
> + }
> + /* --build-id invoked with wrong parameters. */
> + if ( __note_gnu_build_id_end <= __note_gnu_build_id_start )
Please use the local variable here, just like you do ...
> + return -ENODATA;
> +
> + /* Check for full Note header. */
> + if ( &n[1] > __note_gnu_build_id_end )
... here.
> + return -ENODATA;
> +
> + /* Check if we really have a build-id. */
> + if ( NT_GNU_BUILD_ID != n->type )
> + return -ENODATA;
> +
> + /* Sanity check, name should be "GNU" for ld-generated build-id. */
> + if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
> + return -ENODATA;
> +
> + *len = n->descsz;
> + *p = ELFNOTE_DESC(n);
> +
> + checked = 1;
All this checking would perhaps better be done in an initcall, at once
avoiding it to be done over and over if it fails for some reason.
> + return 0;
> +}
> +
> +#else
> +
> +int xen_build_id(const void **p, unsigned int *len)
> +{
> + return -ENODATA;
> +}
> +#endif
Is this #else part really needed? If you omitted the BUILD_ID
dependency in xen.lds.S, wouldn't you just find an empty section
here when the linker is incapable of --build-id?
> --- a/xen/include/xen/version.h
> +++ b/xen/include/xen/version.h
> @@ -14,4 +14,7 @@ const char *xen_changeset(void);
> const char *xen_banner(void);
> const char *xen_deny(void);
>
> +#include <xen/types.h>
Why? And if really needed, it doesn't belong in the middle of the file.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id.
2016-03-24 20:00 ` [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id Konrad Rzeszutek Wilk
2016-03-25 16:26 ` Daniel De Graaf
@ 2016-04-04 13:35 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 13:35 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, andrew.cooper3, Ian Jackson,
mpohlack, ross.lagerwall, xen-devel, Daniel De Graaf,
sasha.levin
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> The VERSION hypercall provides the flexibility to expose
> the size of the build-id (so the callers can allocate the
> proper size before trying to retrieve it). It also allows
> in one nice swoop to retrieve the hypervisor build-id in the
> provided buffer.
>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Non-XSM bits
Acked-by: Jan Beulich <jbeulich@suse.com>
provided the patch introducing version_op gets a replacement ack
and hence doesn't need to be reverted.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup.
2016-03-24 20:00 ` [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup Konrad Rzeszutek Wilk
@ 2016-04-04 13:38 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 13:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Ian Jackson,
Tim Deegan, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> @@ -1414,10 +1420,16 @@ static void xsplice_printall(unsigned char key)
>
> static int __init xsplice_init(void)
> {
> + const void *binary_id = NULL;
> + unsigned int len = 0;
Pointless initializer.
> BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
> BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
> BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
>
> + if ( !xen_build_id(&binary_id, &len) )
> + printk(XENLOG_INFO "%s: build-id: %*phN\n", XSPLICE, len, binary_id);
With the above corrected and the string literal not handed to %s
Acked-by: Jan Beulich <jbeulich@suse.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-03-24 20:00 ` [PATCH v5 23/28] xsplice: Stacking build-id dependency checking Konrad Rzeszutek Wilk
@ 2016-04-04 15:00 ` Jan Beulich
2016-04-04 20:01 ` Konrad Rzeszutek Wilk
2016-04-06 20:05 ` Konrad Rzeszutek Wilk
0 siblings, 2 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 15:00 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to match against.
> The old code allows much more flexibility and an additional guard,
> but is more complex to implement.
>
> +The second option which requires an build-id of the hypervisor
> +is implemented in the Xen Project hypervisor.
> +
> +Specifically each payload has two build-id ELF notes:
> + * The build-id of the payload itself (generated via --build-id).
> + * The build-id of the payload it depends on (extracted from the
> + the previous payload or hypervisor during build time).
> +
> +This means that the very first payload depends on the hypervisor
> +build-id.
So this is mean to be a singly linked chain, not something with
branches and alike, allowing independent patches to be applied
solely based on the base build ID? Is such a restriction not going
to get in the way rather sooner than later?
> +# Not Yet Done
> +
> +This is for further development of xSplice.
> +
> +## Goals
> +
> +The implementation must also have a mechanism for:
> +
> + * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
> + * Be able to patch .rodata, .bss, and .data sections.
> + * Further safety checks (blacklist of which functions cannot be patched, check
> + the stack, make sure the payload is built with same compiler as hypervisor,
> + and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
> + * NOP out the code sequence if `new_size` is zero.
> + * Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64] in payload file.
Does this belong here? Doesn't this duplicate something I saw earlier?
> --- a/xen/common/version.c
> +++ b/xen/common/version.c
> @@ -70,10 +70,29 @@ const char *xen_deny(void)
> /* Defined in linker script. */
> extern const Elf_Note __note_gnu_build_id_start[],
> __note_gnu_build_id_end[];
>
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
> +{
> + /* Check if we really have a build-id. */
> + if ( NT_GNU_BUILD_ID != n->type )
> + return -ENODATA;
> +
> + /* Sanity check, name should be "GNU" for ld-generated build-id. */
> + if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
> + return -ENODATA;
For the embedded notes this suffices as verification, but I question
this being enough for a patch module: No part of the note should
exceed the containing section. And maybe there are other things.
> #else
>
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len)
> +{
> + return -ENODATA;
> +}
What case is this needed for, considering that only xSplice code
should be calling it, and that code depends on build ID availability.
> +static int build_id_dep(struct payload *payload, bool_t ignore)
> +{
> + const void *id = NULL;
> + unsigned int len = 0;
> + int rc;
> + const char *name = "hypervisor";
> +
> + ASSERT(payload->dep.len && payload->dep.p);
> +
> + /* First time user is against hypervisor. */
> + if ( ignore || list_empty(&applied_list) )
"ignore" is perhaps not the most descriptive name, as you aren't
ignoring anything here. Maybe "internal"? And then maybe have
the caller pass the argument using list_empty(&applied_list)
instead of you checking it here?
> --- a/xen/include/xen/version.h
> +++ b/xen/include/xen/version.h
> @@ -17,4 +17,7 @@ const char *xen_deny(void);
> #include <xen/types.h>
> int xen_build_id(const void **p, unsigned int *len);
>
> +#include <xen/elfstructs.h>
> +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len);
The #include is misplaced again, and I'm rather hesitant to see
version.h gain this dependency. Couldn't this go into xen/elf.h?
> --- a/xen/include/xen/xsplice.h
> +++ b/xen/include/xen/xsplice.h
> @@ -40,6 +40,11 @@ struct xsplice_symbol {
> bool_t new_symbol;
> };
>
> +struct xsplice_build_id {
> + const void *p;
> + unsigned int len;
> +};
This isn't being used outside of xsplice.c, so please define the
structure there.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler.
2016-03-24 20:00 ` [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler Konrad Rzeszutek Wilk
@ 2016-04-04 15:03 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 15:03 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, Ian Jackson,
Tim Deegan, mpohlack, sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -1514,6 +1514,11 @@ static void xsplice_printall(unsigned char key)
> if ( !(i % 100) )
> process_pending_softirqs();
> }
> + if ( data->id.len )
> + printk("build-id=%*phN\n", data->id.len, data->id.p);
> +
> + if ( data->dep.len )
> + printk("depend-on=%*phN\n", data->dep.len, data->dep.p);
> }
>
> spin_unlock_recursive(&payload_lock);
Looks certainly fine, but wouldn't this better be part of patch 23?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded.
2016-03-24 20:00 ` [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded Konrad Rzeszutek Wilk
@ 2016-04-04 15:06 ` Jan Beulich
2016-04-04 19:52 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 15:06 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> --- a/xen/common/xsplice.c
> +++ b/xen/common/xsplice.c
> @@ -566,6 +566,27 @@ static int prepare_payload(struct payload *payload,
> if ( !payload->id.len || !payload->id.p )
> return -EINVAL;
> }
> + /* Make sure it is not a duplicate. */
> + if ( payload->id.len )
The conditional is pointless considering the one visible in context
above.
> + {
> + struct payload *data;
> +
> + spin_lock_recursive(&payload_lock);
> + list_for_each_entry ( data, &payload_list, list )
> + {
> + /* No way payload is on the list. */
> + ASSERT( data != payload );
> + if ( data->id.len &&
> + !memcmp(data->id.p, payload->id.p, data->id.len) )
> + {
> + spin_unlock_recursive(&payload_lock);
> + dprintk(XENLOG_DEBUG, "%s%s: Already loaded as %s!\n",
> + XSPLICE, elf->name, data->name);
> + return -EEXIST;
> + }
> + }
> + spin_unlock_recursive(&payload_lock);
Similar question as asked elsewhere - with the lock getting dropped
here, how is the "no duplicate" state going to be ensured by the
time you actually load and insert this payload?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 27/28] xsplice: Add support for shadow variables.
2016-03-24 20:00 ` [PATCH v5 27/28] xsplice: Add support for shadow variables Konrad Rzeszutek Wilk
@ 2016-04-04 15:18 ` Jan Beulich
2016-04-06 2:26 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-04 15:18 UTC (permalink / raw)
To: ross.lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
sasha.levin, xen-devel
>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> Shadow variables are a piece of infrastructure to be used by xsplice
> modules. They are used to attach a new piece of data to an existing
> structure in memory.
An already known question again: Out of recent XSAs, how many
needed such? I.e. can#t we put this off for now?
> Martin Pohlack also mentions that using the SHADOW_SLOTS of small
> prime numbers has the advantage of having a simple hash function.
This reads kind of backwards.
> +void xsplice_shadow_free(const void *obj, const char *var)
> +{
> + struct shadow_var *entry, *shadow = NULL;
> + unsigned int slot;
> + struct hlist_node *next;
> +
> + slot = (unsigned long)obj % SHADOW_SLOTS;
> +
> + spin_lock(&shadow_lock);
> + hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
> + {
> + if ( entry->obj == obj &&
> + !strcmp(entry->var, var) )
> + {
> + shadow = entry;
> + break;
> + }
> + }
> + if (shadow)
Coding style.
> + {
> + hlist_del(&shadow->list);
> + xfree(shadow->data);
> + xfree(shadow);
> + }
> + spin_unlock(&shadow_lock);
> +}
Uniqueness not being guaranteed by the allocation function, how
can you free the first hit here ...
> +void *xsplice_shadow_get(const void *obj, const char *var)
> +{
> + struct shadow_var *entry;
> + unsigned int slot;
> + struct hlist_node *next;
> + void *ret = NULL;
> +
> + slot = (unsigned long)obj % SHADOW_SLOTS;
> +
> + spin_lock(&shadow_lock);
> + hlist_for_each_entry(entry, next, &shadow_tbl[slot], list)
> + {
> + if ( entry->obj == obj &&
> + !strcmp(entry->var, var) )
> + {
> + ret = entry->data;
> + break;
> + }
> + }
> +
> + spin_unlock(&shadow_lock);
> + return ret;
> +}
.. or return the first match here?
> +static int __init xsplice_shadow_init(void)
> +{
> + int i;
unsigned int
> --- a/xen/include/xen/xsplice_patch.h
> +++ b/xen/include/xen/xsplice_patch.h
> @@ -56,4 +56,40 @@ typedef void (*xsplice_unloadcall_t)(void);
> #define XSPLICE_UNLOAD_HOOK(_fn) \
> xsplice_unloadcall_t __attribute__((weak)) xsplice_unload_data
> __section(".xsplice.hooks.unload") = _fn;
>
> +
> +/*
> + * The following definitions are to be used in patches. They are taken
> + * from kpatch.
> + */
> +
> +/*
> + * xsplice shadow variables
> + *
> + * These functions can be used to add new "shadow" fields to existing data
> + * structures. For example, to allocate a "newpid" variable associated with an
> + * instance of task_struct, and assign it a value of 1000:
> + *
> + * struct task_struct *tsk = current;
> + * int *newpid;
> + * newpid = xsplice_shadow_alloc(tsk, "newpid", sizeof(int));
> + * if (newpid)
> + * *newpid = 1000;
> + *
> + * To retrieve a pointer to the variable:
> + *
> + * struct task_struct *tsk = current;
> + * int *newpid;
> + * newpid = xsplice_shadow_get(tsk, "newpid");
> + * if (newpid)
> + * printk("task newpid = %d\n", *newpid); // prints "task newpid = 1000"
> + *
> + * To free it:
> + *
> + * xsplice_shadow_free(tsk, "newpid");
> + */
While this indeed provides some basic understanding, I think this
should be using a more Xen-affine example, and I fail to see how
with particularly the example given this is going to be useful: How
would the patch module sanely and within reasonable time get
hold of all instances of a particular type?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-01 9:18 ` Jan Beulich
@ 2016-04-04 19:44 ` Konrad Rzeszutek Wilk
2016-04-05 1:57 ` Konrad Rzeszutek Wilk
2016-04-05 7:34 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-04 19:44 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
> >>> On 31.03.16 at 23:26, <konrad@darnok.org> wrote:
> >> Also - how well will this O(n^2) lookup work once there are enough
> >> payloads? I think this calls for the alternative vmap() extension I've
> >> been suggesting earlier.
> >
> > Could you elaborate on the vmap extension a bit please?
> >
> > Your earlier email seems to say: drop the vmap API and just
> > allocate the underlaying pages yourself.
>
> Actually I had also said in that earlier mail: "If, otoh, you left that
> VA management to (an extended version of) vmap(), by e.g.
> allowing the caller to request allocation from a different VA range
> (much like iirc x86-64 Linux handles its modules address range
> allocation), things would be different. After all the VA
> management is the important part here, while the backing
> memory allocation is just a trivial auxiliary operation."
>
> I.e. elaboration here really just consists of the referral to the
> respective Linux approach.
I am in need here of guidance I am afraid.
Let me explain (did this in IRC but this will have a broader scope):
In Linux we have the 'struct vm_area' which internally contains the start
and end address (amongst other things). The callers usually use __vmalloc_node_range
to an provide those addresses. Internally the vmalloc API allocates the
'struct vm_area' from the normal SLAB allocator. Vmalloc API also has an
vmap block area (allocated within vmalloc area) which is a red and black tree
for all the users of its API. When vm_size() is called this tree is searched
to find the 'vm_area' for the provided virtual address. There is a lot
of code in this. Copying it and jamming does not look easy so it would be
better to take concepts of this an implement this..
On Xen we setup a bitmap that covers the full vmalloc area (128MB on my
4GB box, but can go up to 64GB) - the 128MB vmalloc area requires about
32K bits.
For every allocation we "waste" an page (and a bit) so that there is a gap.
This gap is needed when trying to to determine the size of the allocated
region - when scanning the bitmap we can easily figure out the cleared
bit which is akin to a fencepost.
To make Xen's vmalloc API be generic I need to wholesale make it able
to deal with virtual addresses that are not part of its space (as in
not in VMAP_VIRT_START to vm_top). At the start I the input to vm_size()
needs to get the size of the virtual address (either the ones from
the vmalloc areas or the ones provided earlier by vmalloc_cb).
One easy mechanism is to embedded an array of simplified 'struct vm_area' structure:
struct vm_area {
unsigned long va;
}
for every slot in the VMAP_VIRT_START area (that is have 32K entries).
The vm_size and all the rest can check for this array if the virtual
address provided is not within the vmalloc virtual addresses. If there
is a match we just need to consult the vm_bitmap at the same index and
figure out where the empty bit is set.
The downside is that I've to walk the full array (32K entries).
But when you think about it - most of the time we use normal vmalloc addresses
and only in exceptional cases do we need the alternate ones. And the only reason
to keep track of it is to know the size.
The easier way would be to track them via a linked list:
struct vm_area {
struct list_head list;
unsigned long va;
size_t nr;
}
And vm_size, vm_index, etc would consult this list for the virtual address and
could get the proper information. (See inline patch)
But if we are doing that this, then why even put it in the vmalloc API? Why not
track all of this with the user of this? (like it was done in v4 of this patch series?)
Please advise.
From a0e3015bbf4d99fc8e5428634dc3b281cf8eedb7 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 14 Mar 2016 12:02:05 -0400
Subject: [PATCH] vmap: Add vmalloc_cb
For those users who want to supply their own vmap callback.
This callback will be called _after_ the pages have been
allocated and instead of using the vmap internal API, it will
call the callback which will be responsible for providing the
virtual addresses.
The vmap API also keeps track of this virtual address (along
with the size) so that vunmap, vm_size, and vm_free can operate
on these virtual addresses.
This allows users (such as xSplice) to provide their own
mechanism to change the the page flags, and also use virtual
addresses closer to the hypervisor virtual addresses (at least
on x86).
The users (such as patch titled "xsplice: Implement payload
loading") can wrap the calls to __vmap for this.
Note that the displacement of the hypervisor virtual addresses to the
vmalloc (on x86) is more than 32-bits - which means that ELF relocations
(which are limited to 32-bits) - won't work (we truncate the 34 and 33th
bit). Hence we cannot use on vmalloc virtual addresses but must
supply our own ranges.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v4: New patch.
v5: Update per Jan's comments.
v6: Drop the stray parentheses on typedefs.
Ditch the vunmap callback. Stash away the virtual addresses in lists.
---
---
xen/common/vmap.c | 80 ++++++++++++++++++++++++++++++++++++++++++++++++--
xen/include/xen/vmap.h | 5 ++++
2 files changed, 82 insertions(+), 3 deletions(-)
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 134eda0..0289e22 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -19,6 +19,16 @@ static unsigned int __read_mostly vm_end;
/* lowest known clear bit in the bitmap */
static unsigned int vm_low;
+static LIST_HEAD(vm_area_list);
+
+struct vm_area {
+ struct list_head list;
+ void *va;
+ unsigned int pages;
+};
+
+static DEFINE_SPINLOCK(vm_area_lock);
+
void __init vm_init(void)
{
unsigned int i, nr;
@@ -146,12 +156,34 @@ static unsigned int vm_index(const void *va)
test_bit(idx, vm_bitmap) ? idx : 0;
}
+static const struct vm_area *vm_find(const void *va)
+{
+ const struct vm_area *found = NULL, *vm;
+
+ spin_lock(&vm_area_lock);
+ list_for_each_entry( vm, &vm_area_list, list )
+ {
+ if ( vm->va != va )
+ continue;
+ found = vm;
+ break;
+ }
+ spin_unlock(&vm_area_lock);
+
+ return found;
+}
+
static unsigned int vm_size(const void *va)
{
unsigned int start = vm_index(va), end;
if ( !start )
+ {
+ const struct vm_area *vm = vm_find(va);
+ if ( vm )
+ return vm->pages;
return 0;
+ }
end = find_next_zero_bit(vm_bitmap, vm_top, start + 1);
@@ -164,6 +196,16 @@ void vm_free(const void *va)
if ( !bit )
{
+ struct vm_area *vm = (struct vm_area *)vm_find(va);
+
+ if ( vm )
+ {
+ spin_lock(&vm_area_lock);
+ list_del(&vm->list);
+ spin_unlock(&vm_area_lock);
+ xfree(vm);
+ return;
+ }
WARN_ON(va != NULL);
return;
}
@@ -216,12 +258,13 @@ void vunmap(const void *va)
vm_free(va);
}
-void *vmalloc(size_t size)
+void *vmalloc_cb(size_t size, vmap_cb_t *vmap_cb, mfn_t **mfn_array)
{
mfn_t *mfn;
size_t pages, i;
struct page_info *pg;
void *va;
+ struct vm_area *vm = NULL;
ASSERT(size);
@@ -230,6 +273,17 @@ void *vmalloc(size_t size)
if ( mfn == NULL )
return NULL;
+ if ( vmap_cb )
+ {
+ vm = xmalloc(struct vm_area);
+
+ if ( !vm )
+ {
+ xfree(mfn);
+ return NULL;
+ }
+ }
+
for ( i = 0; i < pages; i++ )
{
pg = alloc_domheap_page(NULL, 0);
@@ -238,20 +292,40 @@ void *vmalloc(size_t size)
mfn[i] = _mfn(page_to_mfn(pg));
}
- va = vmap(mfn, pages);
+ va = vmap_cb ? vmap_cb(mfn, pages) : vmap(mfn, pages);
if ( va == NULL )
goto error;
- xfree(mfn);
+ if ( vm )
+ {
+ vm->va = va;
+ vm->pages = pages;
+
+ spin_lock(&vm_area_lock);
+ list_add(&vm->list, &vm_area_list);
+ spin_unlock(&vm_area_lock);
+ }
+ if ( mfn_array )
+ *mfn_array = mfn;
+ else
+ xfree(mfn);
+
return va;
error:
while ( i-- )
free_domheap_page(mfn_to_page(mfn_x(mfn[i])));
xfree(mfn);
+ if ( vm )
+ xfree(vm);
return NULL;
}
+void *vmalloc(size_t size)
+{
+ return vmalloc_cb(size, NULL, NULL);
+}
+
void *vzalloc(size_t size)
{
void *p = vmalloc(size);
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 5671ac8..6cd0707 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -12,6 +12,11 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
void *vmap(const mfn_t *mfn, unsigned int nr);
void vunmap(const void *);
void *vmalloc(size_t size);
+
+/* Callback for vmalloc_cb to use when vmap-ing. */
+typedef void *vmap_cb_t(const mfn_t *mfn, unsigned int pages);
+void *vmalloc_cb(size_t size, vmap_cb_t *vmap_cb, mfn_t **);
+
void *vzalloc(size_t size);
void vfree(void *va);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded.
2016-04-04 15:06 ` Jan Beulich
@ 2016-04-04 19:52 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-04 19:52 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
ross.lagerwall, sasha.levin, xen-devel
On Mon, Apr 04, 2016 at 09:06:47AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > --- a/xen/common/xsplice.c
> > +++ b/xen/common/xsplice.c
> > @@ -566,6 +566,27 @@ static int prepare_payload(struct payload *payload,
> > if ( !payload->id.len || !payload->id.p )
> > return -EINVAL;
> > }
> > + /* Make sure it is not a duplicate. */
> > + if ( payload->id.len )
>
> The conditional is pointless considering the one visible in context
> above.
/me nods. Let me move it inside the braces above.
>
> > + {
> > + struct payload *data;
> > +
> > + spin_lock_recursive(&payload_lock);
> > + list_for_each_entry ( data, &payload_list, list )
> > + {
> > + /* No way payload is on the list. */
> > + ASSERT( data != payload );
> > + if ( data->id.len &&
> > + !memcmp(data->id.p, payload->id.p, data->id.len) )
> > + {
> > + spin_unlock_recursive(&payload_lock);
> > + dprintk(XENLOG_DEBUG, "%s%s: Already loaded as %s!\n",
> > + XSPLICE, elf->name, data->name);
> > + return -EEXIST;
> > + }
> > + }
> > + spin_unlock_recursive(&payload_lock);
>
> Similar question as asked elsewhere - with the lock getting dropped
> here, how is the "no duplicate" state going to be ensured by the
> time you actually load and insert this payload?
It won't. I've removed the spinlock usage here and we are keeping the spinlock
held at xsplice_upload.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-04-04 15:00 ` Jan Beulich
@ 2016-04-04 20:01 ` Konrad Rzeszutek Wilk
2016-04-05 7:43 ` Jan Beulich
2016-04-08 16:15 ` Ross Lagerwall
2016-04-06 20:05 ` Konrad Rzeszutek Wilk
1 sibling, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-04 20:01 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
sasha.levin, xen-devel
On Mon, Apr 04, 2016 at 09:00:00AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to match against.
> > The old code allows much more flexibility and an additional guard,
> > but is more complex to implement.
> >
> > +The second option which requires an build-id of the hypervisor
> > +is implemented in the Xen Project hypervisor.
> > +
> > +Specifically each payload has two build-id ELF notes:
> > + * The build-id of the payload itself (generated via --build-id).
> > + * The build-id of the payload it depends on (extracted from the
> > + the previous payload or hypervisor during build time).
> > +
> > +This means that the very first payload depends on the hypervisor
> > +build-id.
>
> So this is mean to be a singly linked chain, not something with
> branches and alike, allowing independent patches to be applied
> solely based on the base build ID? Is such a restriction not going
Correct.
> to get in the way rather sooner than later?
Here is what the design doc says:
"
### xSplice interdependencies
xSplice patches interdependencies are tricky.
There are the ways this can be addressed:
* A single large patch that subsumes and replaces all previous ones.
Over the life-time of patching the hypervisor this large patch
grows to accumulate all the code changes.
* Hotpatch stack - where an mechanism exists that loads the hotpatches
in the same order they were built in. We would need an build-id
of the hypevisor to make sure the hot-patches are build against the
correct build.
* Payload containing the old code to check against that. That allows
the hotpatches to be loaded indepedently (if they don't overlap) - or
if the old code also containst previously patched code - even if they
overlap.
The disadvantage of the first large patch is that it can grow over
time and not provide an bisection mechanism to identify faulty patches.
The hot-patch stack puts stricts requirements on the order of the patches
being loaded and requires an hypervisor build-id to match against.
The old code allows much more flexibility and an additional guard,
but is more complex to implement.
The second option which requires an build-id of the hypervisor
is implemented in the Xen Project hypervisor.
"
I was all for "old_code to check against" but that would incur quite a lot
of implementation. The 'stacking' (suggested by Martin) is much easier
to implement. I am hoping that in next major milestone the 'old code' checking
can be implemented such that the admin has the choice to use both.
>
> > +# Not Yet Done
> > +
> > +This is for further development of xSplice.
> > +
> > +## Goals
> > +
> > +The implementation must also have a mechanism for:
> > +
> > + * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
> > + * Be able to patch .rodata, .bss, and .data sections.
> > + * Further safety checks (blacklist of which functions cannot be patched, check
> > + the stack, make sure the payload is built with same compiler as hypervisor,
> > + and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
> > + * NOP out the code sequence if `new_size` is zero.
> > + * Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64] in payload file.
>
> Does this belong here? Doesn't this duplicate something I saw earlier?
? This is just shrinking the "TODO Goals" section and removing the:
"- * An dependency mechanism for the payloads. To use that information to load:
- - The appropiate payload. To verify that payload is built against the
- hypervisor. This can be done via the `build-id`
- or via providing an copy of the old code - so that the hypervisor can
- verify it against the code in memory.
- - To construct an appropiate order of payloads to load in case they
- depend on each other.
"
The other TODOs are not added.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-04 19:44 ` Konrad Rzeszutek Wilk
@ 2016-04-05 1:57 ` Konrad Rzeszutek Wilk
2016-04-05 7:34 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-05 1:57 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
On Mon, Apr 04, 2016 at 03:44:44PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
> > >>> On 31.03.16 at 23:26, <konrad@darnok.org> wrote:
> > >> Also - how well will this O(n^2) lookup work once there are enough
> > >> payloads? I think this calls for the alternative vmap() extension I've
> > >> been suggesting earlier.
> > >
> > > Could you elaborate on the vmap extension a bit please?
> > >
> > > Your earlier email seems to say: drop the vmap API and just
> > > allocate the underlaying pages yourself.
> >
> > Actually I had also said in that earlier mail: "If, otoh, you left that
> > VA management to (an extended version of) vmap(), by e.g.
> > allowing the caller to request allocation from a different VA range
> > (much like iirc x86-64 Linux handles its modules address range
> > allocation), things would be different. After all the VA
> > management is the important part here, while the backing
> > memory allocation is just a trivial auxiliary operation."
> >
> > I.e. elaboration here really just consists of the referral to the
> > respective Linux approach.
>
> I am in need here of guidance I am afraid.
>
> Let me explain (did this in IRC but this will have a broader scope):
>
> In Linux we have the 'struct vm_area' which internally contains the start
> and end address (amongst other things). The callers usually use __vmalloc_node_range
> to an provide those addresses. Internally the vmalloc API allocates the
> 'struct vm_area' from the normal SLAB allocator. Vmalloc API also has an
> vmap block area (allocated within vmalloc area) which is a red and black tree
> for all the users of its API. When vm_size() is called this tree is searched
> to find the 'vm_area' for the provided virtual address. There is a lot
> of code in this. Copying it and jamming does not look easy so it would be
> better to take concepts of this an implement this..
>
>
> On Xen we setup a bitmap that covers the full vmalloc area (128MB on my
> 4GB box, but can go up to 64GB) - the 128MB vmalloc area requires about
> 32K bits.
>
> For every allocation we "waste" an page (and a bit) so that there is a gap.
> This gap is needed when trying to to determine the size of the allocated
> region - when scanning the bitmap we can easily figure out the cleared
> bit which is akin to a fencepost.
>
>
> To make Xen's vmalloc API be generic I need to wholesale make it able
> to deal with virtual addresses that are not part of its space (as in
> not in VMAP_VIRT_START to vm_top). At the start I the input to vm_size()
> needs to get the size of the virtual address (either the ones from
> the vmalloc areas or the ones provided earlier by vmalloc_cb).
>
> One easy mechanism is to embedded an array of simplified 'struct vm_area' structure:
>
> struct vm_area {
> unsigned long va;
> }
>
> for every slot in the VMAP_VIRT_START area (that is have 32K entries).
> The vm_size and all the rest can check for this array if the virtual
> address provided is not within the vmalloc virtual addresses. If there
> is a match we just need to consult the vm_bitmap at the same index and
> figure out where the empty bit is set.
> The downside is that I've to walk the full array (32K entries).
>
> But when you think about it - most of the time we use normal vmalloc addresses
> and only in exceptional cases do we need the alternate ones. And the only reason
> to keep track of it is to know the size.
>
> The easier way would be to track them via a linked list:
>
> struct vm_area {
> struct list_head list;
> unsigned long va;
> size_t nr;
> }
>
> And vm_size, vm_index, etc would consult this list for the virtual address and
> could get the proper information. (See inline patch)
>
> But if we are doing that this, then why even put it in the vmalloc API? Why not
> track all of this with the user of this? (like it was done in v4 of this patch series?)
>
> Please advise.
I re-read your previous email and I think you were leaning
towards not even having a callback but rather supplying
the virtual address to the vmalloc APIs and it tracking
it afterwards. Like this:
From 738ed247bf214a061c6822ad183c365a4f5731b9 Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 14 Mar 2016 12:02:05 -0400
Subject: [PATCH] vmap: Add vmalloc_range
For those users who want to supply their own virtual
address for which to allocate the underlaying pages.
The vmap API also keeps track of this virtual address (along
with the size) so that vunmap, vm_size, and vm_free can operate
on these virtual addresses.
This allows users (such as xSplice) to provide their own
mechanism to change the the page flags, and also use virtual
addresses closer to the hypervisor virtual addresses (at least
on x86) while not having to deal with the allocation of
pages.
For example of users, see patch titled "xsplice: Implement payload
loading".
Note that the displacement of the hypervisor virtual addresses to the
vmalloc (on x86) is more than 32-bits - which means that ELF relocations
(which are limited to 32-bits) - won't work (we truncate the 34 and 33th
bit). Hence we cannot use on vmalloc virtual addresses but must
supply our own ranges.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v4: New patch.
v5: Update per Jan's comments.
v6: Drop the stray parentheses on typedefs.
Ditch the vunmap callback. Stash away the virtual addresses in lists.
Ditch the vmap callback. Just provide virtual address.
---
---
xen/common/vmap.c | 104 +++++++++++++++++++++++++++++++++++++++++++++++++
xen/include/xen/vmap.h | 10 +++++
2 files changed, 114 insertions(+)
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 134eda0..b63886b 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -19,6 +19,10 @@ static unsigned int __read_mostly vm_end;
/* lowest known clear bit in the bitmap */
static unsigned int vm_low;
+static LIST_HEAD(vm_area_list);
+
+static DEFINE_SPINLOCK(vm_area_lock);
+
void __init vm_init(void)
{
unsigned int i, nr;
@@ -146,12 +150,34 @@ static unsigned int vm_index(const void *va)
test_bit(idx, vm_bitmap) ? idx : 0;
}
+static const struct vm_area *vm_find(const void *va)
+{
+ const struct vm_area *found = NULL, *vm;
+
+ spin_lock(&vm_area_lock);
+ list_for_each_entry( vm, &vm_area_list, list )
+ {
+ if ( vm->va != va )
+ continue;
+ found = vm;
+ break;
+ }
+ spin_unlock(&vm_area_lock);
+
+ return found;
+}
+
static unsigned int vm_size(const void *va)
{
unsigned int start = vm_index(va), end;
if ( !start )
+ {
+ const struct vm_area *vm = vm_find(va);
+ if ( vm )
+ return vm->pages;
return 0;
+ }
end = find_next_zero_bit(vm_bitmap, vm_top, start + 1);
@@ -164,6 +190,17 @@ void vm_free(const void *va)
if ( !bit )
{
+ struct vm_area *vm = (struct vm_area *)vm_find(va);
+
+ if ( vm )
+ {
+ spin_lock(&vm_area_lock);
+ list_del(&vm->list);
+ spin_unlock(&vm_area_lock);
+ xfree(vm->mfn);
+ xfree(vm);
+ return;
+ }
WARN_ON(va != NULL);
return;
}
@@ -199,6 +236,23 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
return va;
}
+static bool_t vmap_range(const mfn_t *mfn, unsigned long va, unsigned int nr)
+{
+ unsigned long cur = va;
+
+ for ( ; va && nr--; ++mfn, cur += PAGE_SIZE )
+ {
+ if ( map_pages_to_xen(cur, mfn_x(*mfn), 1, PAGE_HYPERVISOR) )
+ {
+ if ( cur != va )
+ destroy_xen_mappings(va, cur);
+ return 0;
+ }
+ }
+
+ return 1;
+}
+
void *vmap(const mfn_t *mfn, unsigned int nr)
{
return __vmap(mfn, 1, nr, 1, PAGE_HYPERVISOR);
@@ -216,6 +270,56 @@ void vunmap(const void *va)
vm_free(va);
}
+struct vm_area *vmalloc_range(size_t size, unsigned long start)
+{
+ mfn_t *mfn;
+ size_t pages, i;
+ struct page_info *pg;
+ struct vm_area *vm = NULL;
+
+ ASSERT(size);
+
+ pages = PFN_UP(size);
+ mfn = xmalloc_array(mfn_t, pages);
+ if ( mfn == NULL )
+ return NULL;
+
+ vm = xmalloc(struct vm_area);
+ if ( !vm )
+ {
+ xfree(mfn);
+ return NULL;
+ }
+ vm->mfn = mfn;
+
+ for ( i = 0; i < pages; i++ )
+ {
+ pg = alloc_domheap_page(NULL, 0);
+ if ( pg == NULL )
+ goto error;
+ mfn[i] = _mfn(page_to_mfn(pg));
+ }
+
+ if ( !vmap_range(mfn, start, pages) )
+ goto error;
+
+ vm->va = (void *)start;
+ vm->pages = pages;
+
+ spin_lock(&vm_area_lock);
+ list_add(&vm->list, &vm_area_list);
+ spin_unlock(&vm_area_lock);
+
+ return vm;
+
+ error:
+ while ( i-- )
+ free_domheap_page(mfn_to_page(mfn_x(mfn[i])));
+ xfree(vm->mfn);
+ xfree(vm);
+ return NULL;
+}
+
void *vmalloc(size_t size)
{
mfn_t *mfn;
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 5671ac8..4c9a350 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -12,6 +12,16 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
void *vmap(const mfn_t *mfn, unsigned int nr);
void vunmap(const void *);
void *vmalloc(size_t size);
+
+struct vm_area {
+ struct list_head list;
+ mfn_t *mfn;
+ void *va;
+ unsigned int pages;
+};
+
+struct vm_area *vmalloc_range(size_t size, unsigned long start);
+
void *vzalloc(size_t size);
void vfree(void *va);
--
2.5.0
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-04 19:44 ` Konrad Rzeszutek Wilk
2016-04-05 1:57 ` Konrad Rzeszutek Wilk
@ 2016-04-05 7:34 ` Jan Beulich
2016-04-05 15:50 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-05 7:34 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
>>> On 04.04.16 at 21:44, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 01, 2016 at 03:18:45AM -0600, Jan Beulich wrote:
>> >>> On 31.03.16 at 23:26, <konrad@darnok.org> wrote:
>> >> Also - how well will this O(n^2) lookup work once there are enough
>> >> payloads? I think this calls for the alternative vmap() extension I've
>> >> been suggesting earlier.
>> >
>> > Could you elaborate on the vmap extension a bit please?
>> >
>> > Your earlier email seems to say: drop the vmap API and just
>> > allocate the underlaying pages yourself.
>>
>> Actually I had also said in that earlier mail: "If, otoh, you left that
>> VA management to (an extended version of) vmap(), by e.g.
>> allowing the caller to request allocation from a different VA range
>> (much like iirc x86-64 Linux handles its modules address range
>> allocation), things would be different. After all the VA
>> management is the important part here, while the backing
>> memory allocation is just a trivial auxiliary operation."
>>
>> I.e. elaboration here really just consists of the referral to the
>> respective Linux approach.
>
> I am in need here of guidance I am afraid.
>
> Let me explain (did this in IRC but this will have a broader scope):
>
> In Linux we have the 'struct vm_area' which internally contains the start
> and end address (amongst other things). The callers usually use
> __vmalloc_node_range
> to an provide those addresses. Internally the vmalloc API allocates the
> 'struct vm_area' from the normal SLAB allocator. Vmalloc API also has an
> vmap block area (allocated within vmalloc area) which is a red and black
> tree
> for all the users of its API. When vm_size() is called this tree is searched
> to find the 'vm_area' for the provided virtual address. There is a lot
> of code in this. Copying it and jamming does not look easy so it would be
> better to take concepts of this an implement this..
>
>
> On Xen we setup a bitmap that covers the full vmalloc area (128MB on my
> 4GB box, but can go up to 64GB) - the 128MB vmalloc area requires about
> 32K bits.
>
> For every allocation we "waste" an page (and a bit) so that there is a gap.
> This gap is needed when trying to to determine the size of the allocated
> region - when scanning the bitmap we can easily figure out the cleared
> bit which is akin to a fencepost.
>
>
> To make Xen's vmalloc API be generic I need to wholesale make it able
> to deal with virtual addresses that are not part of its space (as in
> not in VMAP_VIRT_START to vm_top). At the start I the input to vm_size()
> needs to get the size of the virtual address (either the ones from
> the vmalloc areas or the ones provided earlier by vmalloc_cb).
>
> One easy mechanism is to embedded an array of simplified 'struct vm_area'
> structure:
>
> struct vm_area {
> unsigned long va;
> }
>
> for every slot in the VMAP_VIRT_START area (that is have 32K entries).
> The vm_size and all the rest can check for this array if the virtual
> address provided is not within the vmalloc virtual addresses. If there
> is a match we just need to consult the vm_bitmap at the same index and
> figure out where the empty bit is set.
> The downside is that I've to walk the full array (32K entries).
>
> But when you think about it - most of the time we use normal vmalloc
> addresses
> and only in exceptional cases do we need the alternate ones. And the only
> reason
> to keep track of it is to know the size.
>
> The easier way would be to track them via a linked list:
>
> struct vm_area {
> struct list_head list;
> unsigned long va;
> size_t nr;
> }
>
> And vm_size, vm_index, etc would consult this list for the virtual address
> and
> could get the proper information. (See inline patch)
>
> But if we are doing that this, then why even put it in the vmalloc API? Why
> not
> track all of this with the user of this? (like it was done in v4 of this
> patch series?)
>
> Please advise.
Well, I certainly didn't think of it getting done that way. To me the
most natural generalization would be for an arch to register one or
more secondary ranges (which could even get referred to by an
enum) at boot time (or maybe that could even be arranged for at
compile time, i.e. no active registration necessary), with each such
area getting the same data structures set up as is being done right
now for the "base" VA range.
But if that's too cumbersome for now, I'm certainly fine with
xSplice code dealing with the VA management itself. We can
always add such an extension later (and then make xSplice use it).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-04-04 20:01 ` Konrad Rzeszutek Wilk
@ 2016-04-05 7:43 ` Jan Beulich
2016-04-08 16:15 ` Ross Lagerwall
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-05 7:43 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
>>> On 04.04.16 at 22:01, <konrad.wilk@oracle.com> wrote:
> On Mon, Apr 04, 2016 at 09:00:00AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to match against.
>> > The old code allows much more flexibility and an additional guard,
>> > but is more complex to implement.
>> >
>> > +The second option which requires an build-id of the hypervisor
>> > +is implemented in the Xen Project hypervisor.
>> > +
>> > +Specifically each payload has two build-id ELF notes:
>> > + * The build-id of the payload itself (generated via --build-id).
>> > + * The build-id of the payload it depends on (extracted from the
>> > + the previous payload or hypervisor during build time).
>> > +
>> > +This means that the very first payload depends on the hypervisor
>> > +build-id.
>>
>> So this is mean to be a singly linked chain, not something with
>> branches and alike, allowing independent patches to be applied
>> solely based on the base build ID? Is such a restriction not going
>
> Correct.
>> to get in the way rather sooner than later?
>
> Here is what the design doc says:
>
> "
> ### xSplice interdependencies
>
> xSplice patches interdependencies are tricky.
>
> There are the ways this can be addressed:
> * A single large patch that subsumes and replaces all previous ones.
> Over the life-time of patching the hypervisor this large patch
> grows to accumulate all the code changes.
> * Hotpatch stack - where an mechanism exists that loads the hotpatches
> in the same order they were built in. We would need an build-id
> of the hypevisor to make sure the hot-patches are build against the
> correct build.
> * Payload containing the old code to check against that. That allows
> the hotpatches to be loaded indepedently (if they don't overlap) - or
> if the old code also containst previously patched code - even if they
> overlap.
>
> The disadvantage of the first large patch is that it can grow over
> time and not provide an bisection mechanism to identify faulty patches.
>
> The hot-patch stack puts stricts requirements on the order of the patches
> being loaded and requires an hypervisor build-id to match against.
>
> The old code allows much more flexibility and an additional guard,
> but is more complex to implement.
>
> The second option which requires an build-id of the hypervisor
> is implemented in the Xen Project hypervisor.
>
> "
>
> I was all for "old_code to check against" but that would incur quite a lot
> of implementation. The 'stacking' (suggested by Martin) is much easier
> to implement. I am hoping that in next major milestone the 'old code'
> checking
> can be implemented such that the admin has the choice to use both.
In which case could both the design doc and the commit message
be made say that this is intended to be a temporary thing, to be
replaced by the more flexible model?
>> > +# Not Yet Done
>> > +
>> > +This is for further development of xSplice.
>> > +
>> > +## Goals
>> > +
>> > +The implementation must also have a mechanism for:
>> > +
>> > + * Be able to lookup in the Xen hypervisor the symbol names of functions from the ELF payload.
>> > + * Be able to patch .rodata, .bss, and .data sections.
>> > + * Further safety checks (blacklist of which functions cannot be patched, check
>> > + the stack, make sure the payload is built with same compiler as hypervisor,
>> > + and NMI/MCE handlers and do_nmi for right now - until an safe solution is found).
>> > + * NOP out the code sequence if `new_size` is zero.
>> > + * Deal with other relocation types: R_X86_64_[8,16,32,32S], R_X86_64_PC[8,16,64] in payload file.
>>
>> Does this belong here? Doesn't this duplicate something I saw earlier?
>
> ? This is just shrinking the "TODO Goals" section and removing the:
> "- * An dependency mechanism for the payloads. To use that information to load:
> - - The appropiate payload. To verify that payload is built against the
> - hypervisor. This can be done via the `build-id`
> - or via providing an copy of the old code - so that the hypervisor can
> - verify it against the code in memory.
> - - To construct an appropiate order of payloads to load in case they
> - depend on each other.
> "
>
> The other TODOs are not added.
Oh, I didn't realize that the block gets moved. That's certainly not
very fortunate for review (the base document structure would
better remain the same).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-05 7:34 ` Jan Beulich
@ 2016-04-05 15:50 ` Konrad Rzeszutek Wilk
2016-04-05 16:15 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-05 15:50 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
> > Please advise.
>
> Well, I certainly didn't think of it getting done that way. To me the
> most natural generalization would be for an arch to register one or
> more secondary ranges (which could even get referred to by an
> enum) at boot time (or maybe that could even be arranged for at
> compile time, i.e. no active registration necessary), with each such
The start of this region - xen_virt_end is computed during boottime
so part of this is will be runtime.
> area getting the same data structures set up as is being done right
> now for the "base" VA range.
That actually ended up pretty simple. It won't compile for ARM yet,
see below please.
>
> But if that's too cumbersome for now, I'm certainly fine with
> xSplice code dealing with the VA management itself. We can
> always add such an extension later (and then make xSplice use it).
From 45906039b18f1995b26c97b560244ac90308597f Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Mon, 14 Mar 2016 12:02:05 -0400
Subject: [RFC PATCH] vmap: Add vmalloc_type WIP
TODO:
- Check what happens on !CONFIG_XSPLICE
- Move arch specific to arch specific (and make it compile under ARM)
For those users who want to use the virtual addresses that
are in the hypervisor's virtual address space - this new
function allows that. Along with providing the underlaying
MFNs for the user's (such as changing page table permissions).
Implementation wise the vmap API keeps track of two virtual
address regions now:
a) VMAP_VIRT_START
b) xen_virt_end up to XEN_VIRT_END (minus some other space).
The a) one is the default one and the existing behavior
for users of vmalloc, vmap, etc is the same.
If however one wishes to use the b) one only has to use
the vmalloc_type API on these virtual addresses.
This allows users (such as xSplice) to provide their own
mechanism to change the the page flags, and also use virtual
addresses closer to the hypervisor virtual addresses (at least
on x86) while not having to deal with the allocation of
pages.
For example of users, see patch titled "xsplice: Implement payload
loading", where we parse the payload's ELF relocations - which
is defined to be signed 32-bit (so max displacement is 2GB virtual
spacE). The displacement of the hypervisor virtual addresses to the
vmalloc (on x86) is more than 32-bits - which means that ELF relocations
would truncate the 34 and 33th bit. Hence this alternate API
Since there is only one user of this - it is conditional on
CONFIG_XSPLICE - and the generic vmalloc code had added checks
in case the b) range has not been initialized.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Suggested-by: Jan Beulich <jbeulich@suse.com>
---
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
v4: New patch.
v5: Update per Jan's comments.
v6: Drop the stray parentheses on typedefs.
Ditch the vunmap callback. Stash away the virtual addresses in lists.
Ditch the vmap callback. Just provide virtual address.
Ditch the vmalloc_range. Allocate on startup the vmalloc[XEN_VIRT]
ranges.
---
---
xen/arch/x86/mm.c | 2 +-
xen/arch/x86/setup.c | 3 +
xen/common/vmap.c | 194 +++++++++++++++++++++++++-------------
xen/drivers/acpi/osl.c | 2 +-
xen/include/asm-x86/x86_64/page.h | 2 +
xen/include/xen/vmap.h | 15 ++-
6 files changed, 148 insertions(+), 70 deletions(-)
diff --git a/xen/arch/x86/mm.c b/xen/arch/x86/mm.c
index bca7532..6fa9208 100644
--- a/xen/arch/x86/mm.c
+++ b/xen/arch/x86/mm.c
@@ -6124,7 +6124,7 @@ void __iomem *ioremap(paddr_t pa, size_t len)
unsigned int offs = pa & (PAGE_SIZE - 1);
unsigned int nr = PFN_UP(offs + len);
- va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE) + offs;
+ va = __vmap(&mfn, nr, 1, 1, PAGE_HYPERVISOR_NOCACHE, VMAP_VIRT) + offs;
}
return (void __force __iomem *)va;
diff --git a/xen/arch/x86/setup.c b/xen/arch/x86/setup.c
index 0b4f94f..9b502b6 100644
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -100,6 +100,9 @@ unsigned long __read_mostly xen_phys_start;
unsigned long __read_mostly xen_virt_end;
+unsigned long __read_mostly avail_virt_start;
+unsigned long __read_mostly avail_virt_end;
+
DEFINE_PER_CPU(struct tss_struct, init_tss);
char __section(".bss.stack_aligned") cpu0_stack[STACK_SIZE];
diff --git a/xen/common/vmap.c b/xen/common/vmap.c
index 134eda0..343a25a 100644
--- a/xen/common/vmap.c
+++ b/xen/common/vmap.c
@@ -10,40 +10,61 @@
#include <asm/page.h>
static DEFINE_SPINLOCK(vm_lock);
-static void *__read_mostly vm_base;
-#define vm_bitmap ((unsigned long *)vm_base)
+static void *__read_mostly vm_base[VMAP_TYPE_MAX];
+#define vm_bitmap(x) ((unsigned long *)vm_base[x])
/* highest allocated bit in the bitmap */
-static unsigned int __read_mostly vm_top;
+static unsigned int __read_mostly vm_top[VMAP_TYPE_MAX];
/* total number of bits in the bitmap */
-static unsigned int __read_mostly vm_end;
+static unsigned int __read_mostly vm_end[VMAP_TYPE_MAX];
/* lowest known clear bit in the bitmap */
-static unsigned int vm_low;
+static unsigned int vm_low[VMAP_TYPE_MAX];
-void __init vm_init(void)
+void __init vm_init_type(enum vmap_type type)
{
unsigned int i, nr;
unsigned long va;
+ void *end;
+
+ if ( type == VMAP_VIRT )
+ {
+ vm_base[VMAP_VIRT] = (void *)VMAP_VIRT_START;
+ end = arch_vmap_virt_end();
+ }
+ else
+ {
+ vm_base[XEN_VIRT] = (void *)xen_virt_end;
+ end = (void *)(XEN_VIRT_END - NR_CPUS * PAGE_SIZE);
- vm_base = (void *)VMAP_VIRT_START;
- vm_end = PFN_DOWN(arch_vmap_virt_end() - vm_base);
- vm_low = PFN_UP((vm_end + 7) / 8);
- nr = PFN_UP((vm_low + 7) / 8);
- vm_top = nr * PAGE_SIZE * 8;
+ BUG_ON(end <= vm_base[XEN_VIRT]);
+ }
+ vm_end[type] = PFN_DOWN(end - vm_base[type]);
+ vm_low[type]= PFN_UP((vm_end[type] + 7) / 8);
+ nr = PFN_UP((vm_low[type] + 7) / 8);
+ vm_top[type] = nr * PAGE_SIZE * 8;
- for ( i = 0, va = (unsigned long)vm_bitmap; i < nr; ++i, va += PAGE_SIZE )
+ for ( i = 0, va = (unsigned long)vm_bitmap(type); i < nr; ++i, va += PAGE_SIZE )
{
struct page_info *pg = alloc_domheap_page(NULL, 0);
map_pages_to_xen(va, page_to_mfn(pg), 1, PAGE_HYPERVISOR);
clear_page((void *)va);
}
- bitmap_fill(vm_bitmap, vm_low);
+ bitmap_fill(vm_bitmap(type), vm_low[type]);
/* Populate page tables for the bitmap if necessary. */
- populate_pt_range(va, 0, vm_low - nr);
+ populate_pt_range(va, 0, vm_low[type] - nr);
}
-void *vm_alloc(unsigned int nr, unsigned int align)
+void __init vm_init(void)
+{
+ vm_init_type(VMAP_VIRT);
+#ifdef CONFIG_XSPLICE
+ vm_init_type(XEN_VIRT);
+#endif
+}
+
+static void *vm_alloc_type(unsigned int nr, unsigned int align,
+ enum vmap_type t)
{
unsigned int start, bit;
@@ -52,27 +73,30 @@ void *vm_alloc(unsigned int nr, unsigned int align)
else if ( align & (align - 1) )
align &= -align;
+ if ( !vm_base[t] )
+ return NULL;
+
spin_lock(&vm_lock);
for ( ; ; )
{
struct page_info *pg;
- ASSERT(vm_low == vm_top || !test_bit(vm_low, vm_bitmap));
- for ( start = vm_low; start < vm_top; )
+ ASSERT(vm_low[t] == vm_top[t] || !test_bit(vm_low[t], vm_bitmap(t)));
+ for ( start = vm_low[t]; start < vm_top[t]; )
{
- bit = find_next_bit(vm_bitmap, vm_top, start + 1);
- if ( bit > vm_top )
- bit = vm_top;
+ bit = find_next_bit(vm_bitmap(t), vm_top[t], start + 1);
+ if ( bit > vm_top[t] )
+ bit = vm_top[t];
/*
* Note that this skips the first bit, making the
* corresponding page a guard one.
*/
start = (start + align) & ~(align - 1);
- if ( bit < vm_top )
+ if ( bit < vm_top[t] )
{
if ( start + nr < bit )
break;
- start = find_next_zero_bit(vm_bitmap, vm_top, bit + 1);
+ start = find_next_zero_bit(vm_bitmap(t), vm_top[t], bit + 1);
}
else
{
@@ -82,12 +106,12 @@ void *vm_alloc(unsigned int nr, unsigned int align)
}
}
- if ( start < vm_top )
+ if ( start < vm_top[t] )
break;
spin_unlock(&vm_lock);
- if ( vm_top >= vm_end )
+ if ( vm_top[t] >= vm_end[t] )
return NULL;
pg = alloc_domheap_page(NULL, 0);
@@ -96,23 +120,23 @@ void *vm_alloc(unsigned int nr, unsigned int align)
spin_lock(&vm_lock);
- if ( start >= vm_top )
+ if ( start >= vm_top[t] )
{
- unsigned long va = (unsigned long)vm_bitmap + vm_top / 8;
+ unsigned long va = (unsigned long)vm_bitmap(t) + vm_top[t] / 8;
if ( !map_pages_to_xen(va, page_to_mfn(pg), 1, PAGE_HYPERVISOR) )
{
clear_page((void *)va);
- vm_top += PAGE_SIZE * 8;
- if ( vm_top > vm_end )
- vm_top = vm_end;
+ vm_top[t] += PAGE_SIZE * 8;
+ if ( vm_top[t] > vm_end[t] )
+ vm_top[t] = vm_end[t];
continue;
}
}
free_domheap_page(pg);
- if ( start >= vm_top )
+ if ( start >= vm_top[t] )
{
spin_unlock(&vm_lock);
return NULL;
@@ -120,47 +144,56 @@ void *vm_alloc(unsigned int nr, unsigned int align)
}
for ( bit = start; bit < start + nr; ++bit )
- __set_bit(bit, vm_bitmap);
- if ( bit < vm_top )
- ASSERT(!test_bit(bit, vm_bitmap));
+ __set_bit(bit, vm_bitmap(t));
+ if ( bit < vm_top[t] )
+ ASSERT(!test_bit(bit, vm_bitmap(t)));
else
- ASSERT(bit == vm_top);
- if ( start <= vm_low + 2 )
- vm_low = bit;
+ ASSERT(bit == vm_top[t]);
+ if ( start <= vm_low[t] + 2 )
+ vm_low[t] = bit;
spin_unlock(&vm_lock);
- return vm_base + start * PAGE_SIZE;
+ return vm_base[t] + start * PAGE_SIZE;
}
-static unsigned int vm_index(const void *va)
+void *vm_alloc(unsigned int nr, unsigned int align)
+{
+ return vm_alloc_type(nr, align, VMAP_VIRT);
+}
+
+static unsigned int vm_index(const void *va, enum vmap_type type)
{
unsigned long addr = (unsigned long)va & ~(PAGE_SIZE - 1);
unsigned int idx;
+ unsigned long start = (unsigned long)vm_base[type];
+
+ if ( !start)
+ return 0;
- if ( addr < VMAP_VIRT_START + (vm_end / 8) ||
- addr >= VMAP_VIRT_START + vm_top * PAGE_SIZE )
+ if ( addr < start + (vm_end[type] / 8) ||
+ addr >= start + vm_top[type] * PAGE_SIZE )
return 0;
- idx = PFN_DOWN(va - vm_base);
- return !test_bit(idx - 1, vm_bitmap) &&
- test_bit(idx, vm_bitmap) ? idx : 0;
+ idx = PFN_DOWN(va - vm_base[type]);
+ return !test_bit(idx - 1, vm_bitmap(type)) &&
+ test_bit(idx, vm_bitmap(type)) ? idx : 0;
}
-static unsigned int vm_size(const void *va)
+static unsigned int vm_size(const void *va, enum vmap_type type)
{
- unsigned int start = vm_index(va), end;
+ unsigned int start = vm_index(va, type), end;
if ( !start )
return 0;
- end = find_next_zero_bit(vm_bitmap, vm_top, start + 1);
+ end = find_next_zero_bit(vm_bitmap(type), vm_top[type], start + 1);
- return min(end, vm_top) - start;
+ return min(end, vm_top[type]) - start;
}
-void vm_free(const void *va)
+static void vm_free_type(const void *va, enum vmap_type type)
{
- unsigned int bit = vm_index(va);
+ unsigned int bit = vm_index(va, type);
if ( !bit )
{
@@ -169,22 +202,28 @@ void vm_free(const void *va)
}
spin_lock(&vm_lock);
- if ( bit < vm_low )
+ if ( bit < vm_low[type] )
{
- vm_low = bit - 1;
- while ( !test_bit(vm_low - 1, vm_bitmap) )
- --vm_low;
+ vm_low[type] = bit - 1;
+ while ( !test_bit(vm_low[type] - 1, vm_bitmap(type)) )
+ --vm_low[type];
}
- while ( __test_and_clear_bit(bit, vm_bitmap) )
- if ( ++bit == vm_top )
+ while ( __test_and_clear_bit(bit, vm_bitmap(type)) )
+ if ( ++bit == vm_top[type] )
break;
spin_unlock(&vm_lock);
}
+void vm_free(const void *va)
+{
+ vm_free_type(va, VMAP_VIRT);
+}
+
void *__vmap(const mfn_t *mfn, unsigned int granularity,
- unsigned int nr, unsigned int align, unsigned int flags)
+ unsigned int nr, unsigned int align, unsigned int flags,
+ enum vmap_type type)
{
- void *va = vm_alloc(nr * granularity, align);
+ void *va = vm_alloc_type(nr * granularity, align, type);
unsigned long cur = (unsigned long)va;
for ( ; va && nr--; ++mfn, cur += PAGE_SIZE * granularity )
@@ -201,22 +240,33 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
void *vmap(const mfn_t *mfn, unsigned int nr)
{
- return __vmap(mfn, 1, nr, 1, PAGE_HYPERVISOR);
+ return __vmap(mfn, 1, nr, 1, PAGE_HYPERVISOR, VMAP_VIRT);
}
void vunmap(const void *va)
{
+ enum vmap_type type = VMAP_VIRT;
+ unsigned int size = vm_size(va, type);
+#ifndef _PAGE_NONE
+ unsigned long addr;
+#endif
+
+ if ( !size )
+ {
+ type = XEN_VIRT;
+ size = vm_size(va, type);
+ }
#ifndef _PAGE_NONE
- unsigned long addr = (unsigned long)va;
+ addr = (unsigned long)va;
- destroy_xen_mappings(addr, addr + PAGE_SIZE * vm_size(va));
+ destroy_xen_mappings(addr, addr + PAGE_SIZE * size);
#else /* Avoid tearing down intermediate page tables. */
- map_pages_to_xen((unsigned long)va, 0, vm_size(va), _PAGE_NONE);
+ map_pages_to_xen((unsigned long)va, 0, size, _PAGE_NONE);
#endif
- vm_free(va);
+ vm_free_type(va, type);
}
-void *vmalloc(size_t size)
+void *vmalloc_type(size_t size, enum vmap_type type, mfn_t **mfn_array)
{
mfn_t *mfn;
size_t pages, i;
@@ -238,11 +288,15 @@ void *vmalloc(size_t size)
mfn[i] = _mfn(page_to_mfn(pg));
}
- va = vmap(mfn, pages);
+ va = __vmap(mfn, 1, pages, 1, PAGE_HYPERVISOR, type);
if ( va == NULL )
goto error;
- xfree(mfn);
+ if ( mfn_array )
+ *mfn_array = mfn;
+ else
+ xfree(mfn);
+
return va;
error:
@@ -252,6 +306,11 @@ void *vmalloc(size_t size)
return NULL;
}
+void *vmalloc(size_t size)
+{
+ return vmalloc_type(size, VMAP_VIRT, NULL);
+}
+
void *vzalloc(size_t size)
{
void *p = vmalloc(size);
@@ -275,7 +334,10 @@ void vfree(void *va)
if ( !va )
return;
- pages = vm_size(va);
+ pages = vm_size(va, VMAP_VIRT);
+ if ( !pages )
+ pages = vm_size(va, XEN_VIRT);
+
ASSERT(pages);
for ( i = 0; i < pages; i++ )
diff --git a/xen/drivers/acpi/osl.c b/xen/drivers/acpi/osl.c
index 8a28d87..66bec78 100644
--- a/xen/drivers/acpi/osl.c
+++ b/xen/drivers/acpi/osl.c
@@ -97,7 +97,7 @@ acpi_os_map_memory(acpi_physical_address phys, acpi_size size)
if (IS_ENABLED(CONFIG_X86) && !((phys + size - 1) >> 20))
return __va(phys);
return __vmap(&mfn, PFN_UP(offs + size), 1, 1,
- ACPI_MAP_MEM_ATTR) + offs;
+ ACPI_MAP_MEM_ATTR, VMAP_VIRT) + offs;
}
return __acpi_map_table(phys, size);
}
diff --git a/xen/include/asm-x86/x86_64/page.h b/xen/include/asm-x86/x86_64/page.h
index 86abb94..a854e05 100644
--- a/xen/include/asm-x86/x86_64/page.h
+++ b/xen/include/asm-x86/x86_64/page.h
@@ -38,6 +38,8 @@
#include <xen/pdx.h>
extern unsigned long xen_virt_end;
+extern unsigned long avail_virt_start;
+extern unsigned long avail_virt_end;
#define spage_to_pdx(spg) (((spg) - spage_table)<<(SUPERPAGE_SHIFT-PAGE_SHIFT))
#define pdx_to_spage(pdx) (spage_table + ((pdx)>>(SUPERPAGE_SHIFT-PAGE_SHIFT)))
diff --git a/xen/include/xen/vmap.h b/xen/include/xen/vmap.h
index 5671ac8..492d3e7 100644
--- a/xen/include/xen/vmap.h
+++ b/xen/include/xen/vmap.h
@@ -4,14 +4,25 @@
#include <xen/mm.h>
#include <asm/page.h>
+/* These two functions operate only on VMAP_VIRT address space. */
void *vm_alloc(unsigned int nr, unsigned int align);
void vm_free(const void *);
-void *__vmap(const mfn_t *mfn, unsigned int granularity,
- unsigned int nr, unsigned int align, unsigned int flags);
+enum vmap_type {
+ VMAP_VIRT,
+ XEN_VIRT,
+ VMAP_TYPE_MAX,
+};
+
+void *__vmap(const mfn_t *mfn, unsigned int granularity, unsigned int nr,
+ unsigned int align, unsigned int flags, enum vmap_type);
void *vmap(const mfn_t *mfn, unsigned int nr);
void vunmap(const void *);
+/* Only operates on VMAP_VIRT. */
void *vmalloc(size_t size);
+
+void *vmalloc_type(size_t size, enum vmap_type type, mfn_t **mfn_array);
+
void *vzalloc(size_t size);
void vfree(void *va);
--
2.4.3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-05 15:50 ` Konrad Rzeszutek Wilk
@ 2016-04-05 16:15 ` Jan Beulich
2016-04-05 16:45 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-05 16:15 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
>>> On 05.04.16 at 17:50, <konrad.wilk@oracle.com> wrote:
> That actually ended up pretty simple. It won't compile for ARM yet,
> see below please.
This comes pretty close. A few minor comments below.
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -100,6 +100,9 @@ unsigned long __read_mostly xen_phys_start;
>
> unsigned long __read_mostly xen_virt_end;
>
> +unsigned long __read_mostly avail_virt_start;
> +unsigned long __read_mostly avail_virt_end;
These now appear to be unused.
> -void __init vm_init(void)
> +void __init vm_init_type(enum vmap_type type)
> {
> unsigned int i, nr;
> unsigned long va;
> + void *end;
> +
> + if ( type == VMAP_VIRT )
> + {
> + vm_base[VMAP_VIRT] = (void *)VMAP_VIRT_START;
> + end = arch_vmap_virt_end();
> + }
> + else
> + {
> + vm_base[XEN_VIRT] = (void *)xen_virt_end;
> + end = (void *)(XEN_VIRT_END - NR_CPUS * PAGE_SIZE);
>
> - vm_base = (void *)VMAP_VIRT_START;
> - vm_end = PFN_DOWN(arch_vmap_virt_end() - vm_base);
> - vm_low = PFN_UP((vm_end + 7) / 8);
> - nr = PFN_UP((vm_low + 7) / 8);
> - vm_top = nr * PAGE_SIZE * 8;
> + BUG_ON(end <= vm_base[XEN_VIRT]);
> + }
> + vm_end[type] = PFN_DOWN(end - vm_base[type]);
> + vm_low[type]= PFN_UP((vm_end[type] + 7) / 8);
> + nr = PFN_UP((vm_low[type] + 7) / 8);
> + vm_top[type] = nr * PAGE_SIZE * 8;
>
> - for ( i = 0, va = (unsigned long)vm_bitmap; i < nr; ++i, va += PAGE_SIZE )
> + for ( i = 0, va = (unsigned long)vm_bitmap(type); i < nr; ++i, va += PAGE_SIZE )
> {
> struct page_info *pg = alloc_domheap_page(NULL, 0);
>
> map_pages_to_xen(va, page_to_mfn(pg), 1, PAGE_HYPERVISOR);
> clear_page((void *)va);
> }
> - bitmap_fill(vm_bitmap, vm_low);
> + bitmap_fill(vm_bitmap(type), vm_low[type]);
>
> /* Populate page tables for the bitmap if necessary. */
> - populate_pt_range(va, 0, vm_low - nr);
> + populate_pt_range(va, 0, vm_low[type] - nr);
> }
>
> -void *vm_alloc(unsigned int nr, unsigned int align)
> +void __init vm_init(void)
> +{
> + vm_init_type(VMAP_VIRT);
> +#ifdef CONFIG_XSPLICE
> + vm_init_type(XEN_VIRT);
> +#endif
> +}
I think we should leave it to the arch to call vm_init_type() for
the non-default type(s) it cares about, namely allowing for this to
be done at a different (later) time. Which means vm_init() could
simply become an inline/macro wrapper of vm_init_type(VMAP_VIRT).
> +void *vm_alloc(unsigned int nr, unsigned int align)
> +{
> + return vm_alloc_type(nr, align, VMAP_VIRT);
> +}
Inline/macro wrapper?
> +void vm_free(const void *va)
> +{
> + vm_free_type(va, VMAP_VIRT);
> +}
Again.
> void vunmap(const void *va)
> {
> + enum vmap_type type = VMAP_VIRT;
> + unsigned int size = vm_size(va, type);
> +#ifndef _PAGE_NONE
> + unsigned long addr;
> +#endif
> +
> + if ( !size )
> + {
> + type = XEN_VIRT;
> + size = vm_size(va, type);
> + }
I don't think such automatic fallback should be tried - the caller ought
to know which region it mapped, so it could call vunmap_type().
> @@ -238,11 +288,15 @@ void *vmalloc(size_t size)
> mfn[i] = _mfn(page_to_mfn(pg));
> }
>
> - va = vmap(mfn, pages);
> + va = __vmap(mfn, 1, pages, 1, PAGE_HYPERVISOR, type);
> if ( va == NULL )
> goto error;
>
> - xfree(mfn);
> + if ( mfn_array )
> + *mfn_array = mfn;
> + else
> + xfree(mfn);
What's this? I certainly assumed this wouldn't be needed anymore
now.
> @@ -275,7 +334,10 @@ void vfree(void *va)
> if ( !va )
> return;
>
> - pages = vm_size(va);
> + pages = vm_size(va, VMAP_VIRT);
> + if ( !pages )
> + pages = vm_size(va, XEN_VIRT);
Same comment as as for vunmap().
> +enum vmap_type {
> + VMAP_VIRT,
> + XEN_VIRT,
> + VMAP_TYPE_MAX,
> +};
I think these would benefit from using a common prefix, e.g.
enum vmap_type {
VMAP_DEFAULT,
VMAP_XEN,
VMAP_nr
};
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-05 16:15 ` Jan Beulich
@ 2016-04-05 16:45 ` Konrad Rzeszutek Wilk
2016-04-05 17:48 ` Konrad Rzeszutek Wilk
2016-04-07 0:46 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-05 16:45 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
> > -void *vm_alloc(unsigned int nr, unsigned int align)
> > +void __init vm_init(void)
> > +{
> > + vm_init_type(VMAP_VIRT);
> > +#ifdef CONFIG_XSPLICE
> > + vm_init_type(XEN_VIRT);
> > +#endif
> > +}
>
> I think we should leave it to the arch to call vm_init_type() for
> the non-default type(s) it cares about, namely allowing for this to
> be done at a different (later) time. Which means vm_init() could
> simply become an inline/macro wrapper of vm_init_type(VMAP_VIRT).
Yup, and then I've an arch_xsplice_init which nicely calls vm_init_type
for the VMAP_VIRT_XEN.
>
> > +void *vm_alloc(unsigned int nr, unsigned int align)
> > +{
> > + return vm_alloc_type(nr, align, VMAP_VIRT);
> > +}
>
> Inline/macro wrapper?
>
> > +void vm_free(const void *va)
> > +{
> > + vm_free_type(va, VMAP_VIRT);
> > +}
>
> Again.
>
> > void vunmap(const void *va)
> > {
> > + enum vmap_type type = VMAP_VIRT;
> > + unsigned int size = vm_size(va, type);
> > +#ifndef _PAGE_NONE
> > + unsigned long addr;
> > +#endif
> > +
> > + if ( !size )
> > + {
> > + type = XEN_VIRT;
> > + size = vm_size(va, type);
> > + }
>
> I don't think such automatic fallback should be tried - the caller ought
> to know which region it mapped, so it could call vunmap_type().
OK.
>
> > @@ -238,11 +288,15 @@ void *vmalloc(size_t size)
> > mfn[i] = _mfn(page_to_mfn(pg));
> > }
> >
> > - va = vmap(mfn, pages);
> > + va = __vmap(mfn, 1, pages, 1, PAGE_HYPERVISOR, type);
> > if ( va == NULL )
> > goto error;
> >
> > - xfree(mfn);
> > + if ( mfn_array )
> > + *mfn_array = mfn;
> > + else
> > + xfree(mfn);
>
> What's this? I certainly assumed this wouldn't be needed anymore
> now.
I still need the MFNs so I can change the page table attributes once
I've finished copying the ELF.
I can walk the virtual addresses and gather them from the PTE,
but I figured it would be easier to have them stashed away somewhere?
>
> > @@ -275,7 +334,10 @@ void vfree(void *va)
> > if ( !va )
> > return;
> >
> > - pages = vm_size(va);
> > + pages = vm_size(va, VMAP_VIRT);
> > + if ( !pages )
> > + pages = vm_size(va, XEN_VIRT);
>
> Same comment as as for vunmap().
>
> > +enum vmap_type {
> > + VMAP_VIRT,
> > + XEN_VIRT,
> > + VMAP_TYPE_MAX,
> > +};
>
> I think these would benefit from using a common prefix, e.g.
>
> enum vmap_type {
> VMAP_DEFAULT,
> VMAP_XEN,
> VMAP_nr
> };
Thanks!
>
> Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-05 16:45 ` Konrad Rzeszutek Wilk
@ 2016-04-05 17:48 ` Konrad Rzeszutek Wilk
2016-04-07 0:49 ` Jan Beulich
2016-04-07 0:46 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-05 17:48 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, xen-devel,
Konrad Rzeszutek Wilk, sasha.levin
On Tue, Apr 05, 2016 at 12:45:44PM -0400, Konrad Rzeszutek Wilk wrote:
> > > -void *vm_alloc(unsigned int nr, unsigned int align)
> > > +void __init vm_init(void)
> > > +{
> > > + vm_init_type(VMAP_VIRT);
> > > +#ifdef CONFIG_XSPLICE
> > > + vm_init_type(XEN_VIRT);
> > > +#endif
> > > +}
> >
> > I think we should leave it to the arch to call vm_init_type() for
> > the non-default type(s) it cares about, namely allowing for this to
> > be done at a different (later) time. Which means vm_init() could
> > simply become an inline/macro wrapper of vm_init_type(VMAP_VIRT).
>
> Yup, and then I've an arch_xsplice_init which nicely calls vm_init_type
> for the VMAP_VIRT_XEN.
>
> >
> > > +void *vm_alloc(unsigned int nr, unsigned int align)
> > > +{
> > > + return vm_alloc_type(nr, align, VMAP_VIRT);
> > > +}
> >
> > Inline/macro wrapper?
I would prefer to have this inside the common/vmap.c file as I would
need to expose vm_alloc_type in the header file - which is really not
to be used by users of the vmalloc API.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 09/28] xsplice: Add helper elf routines
2016-03-31 12:03 ` Jan Beulich
@ 2016-04-06 1:38 ` Konrad Rzeszutek Wilk
2016-04-07 0:38 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-06 1:38 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
ross.lagerwall, sasha.levin, xen-devel
> > +static int elf_resolve_sections(struct xsplice_elf *elf, const void *data)
> > +{
.. snip..
> > + /* N.B. We also will ingest SHN_UNDEF sections. */
>
> Because of? The meaning of the fields in the 0-th section header is
> different from that of ordinary ones.
>
> > + for ( i = 0; i < elf->hdr->e_shnum; i++ )
The reason for this is not obvious .. In the payload loading patch I
iterate over each elf->sec (starting at zero) and immediately
dereference the sh_type:
if ( (elf->sec[i].sec->sh_flags .. )
As you can imagine if I don't set elf->sec[0].sec this blows up. Hence
the odd start at zero.
However one can as well just fix the loop in 'move_payload' to start
at 1 instead of 0 - which is what I did.
> > + {
> > + ssize_t delta = elf->hdr->e_shoff + i * elf->hdr->e_shentsize;
>
> Why ssize_t? (This anyway should be a suitable ELF type.)
>
> > +
> > + if ( delta + sizeof(Elf_Shdr) > elf->len )
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: Section header [%d] is past end of payload!\n",
> > + XSPLICE, elf->name, i);
>
> XSPLICE is a string literal, so should be prepended to the format
> string instead of forced through %s. And %u please for unsigned
> arguments.
>
> Also this check doesn't need doing inside the loop - you can simply
> check once (using e_shnum) that the entire section table is valid.
>
> > + return -EINVAL;
> > + }
> > +
> > + sec[i].sec = (Elf_Shdr *)(data + delta);
>
> Pointless cast bogusly casting away constness.
>
> > + delta = sec[i].sec->sh_offset;
> > +
> > + if ( delta > elf->len )
>
> This is relevant only for sections having non-zero size. And then you of
> course need to take size into account when dong the bounds check.
>
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: Section [%d] data is past end of payload!\n",
> > + XSPLICE, elf->name, i);
> > + return -EINVAL;
> > + }
> > +
> > + sec[i].data = data + delta;
> > + /* Name is populated in xsplice_elf_sections_name. */
> > + sec[i].name = NULL;
> > +
> > + if ( sec[i].sec->sh_type == SHT_SYMTAB )
> > + {
> > + if ( elf->symtab )
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: Multiple symbol tables!\n",
> > + XSPLICE, elf->name);
> > + return -EINVAL;
>
> There's nothing invalid about this, it's simply unsupported by the
> implementation (read: a better error code please).
>
> > + }
> > +
> > + elf->symtab = &sec[i];
> > +
> > + /*
> > + * elf->symtab->sec->sh_link would point to the right section
> > + * but we hadn't finished parsing all the sections.
> > + */
> > + if ( elf->symtab->sec->sh_link > elf->hdr->e_shnum )
>
> >=
>
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: Symbol table idx (%d) to strtab past end (%d)\n",
> > + XSPLICE, elf->name, elf->symtab->sec->sh_link,
> > + elf->hdr->e_shnum);
> > + return -EINVAL;
> > + }
> > + }
> > + }
> > +
> > + if ( !elf->symtab )
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: No symbol table found!\n",
> > + XSPLICE, elf->name);
> > + return -EINVAL;
> > + }
> > +
> > + /* There can be multiple SHT_STRTAB so pick the right one. */
> > + elf->strtab = &sec[elf->symtab->sec->sh_link];
>
> How about checking this really is a SHT_STRTAB section?
>
> > + if ( !elf->symtab->sec->sh_size || !elf->symtab->sec->sh_entsize ||
> > + elf->symtab->sec->sh_entsize != sizeof(Elf_Sym) )
>
> The first sh_entsize check is redundant with the second, and the
> second is too strict (< suffices).
>
> Also shouldn't the string table section also have at least non-zero
> size? And its first and last bytes be NUL?
>
> > +static int elf_resolve_section_names(struct xsplice_elf *elf, const void *data)
> > +{
> > + const char *shstrtab;
> > + unsigned int i;
> > + unsigned int offset, delta;
> > +
> > + /*
> > + * The elf->sec[0 -> e_shnum] structures have been verified by
> > + * elf_resolve_sections. Find file offset for section string table.
> > + */
> > + offset = elf->sec[elf->hdr->e_shstrndx].sec->sh_offset;
>
> Truncating the value on 64-bit ELF.
>
> > + if ( offset > elf->len )
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: shstrtab section offset (%u) past end of payload!\n",
> > + XSPLICE, elf->name, elf->hdr->e_shstrndx);
> > + return -EINVAL;
> > + }
> > +
> > + shstrtab = (data + offset);
>
> Pointless parentheses.
>
> > + /* We could ignore the first as it is reserved.. */
>
> Double full stop.
>
> > + for ( i = 0; i < elf->hdr->e_shnum; i++ )
> > + {
> > + delta = elf->sec[i].sec->sh_name;
> > +
> > + if ( offset + delta > elf->len )
>
> This is too weak: After having bounds checked the string table section
> to be inside the image, you now need to bounds check the string offset
> to be inside the string table. Also it seems (just like above) you
> no-where check that the referenced section actually is a string table.
>
> > +static int elf_get_sym(struct xsplice_elf *elf, const void *data)
> > +{
> > + struct xsplice_elf_sec *symtab_sec, *strtab_sec;
> > + struct xsplice_elf_sym *sym;
> > + unsigned int i, delta, offset, nsym;
> > +
> > + symtab_sec = elf->symtab;
> > + strtab_sec = elf->strtab;
> > +
> > + /* Pointers arithmetic to get file offset. */
> > + offset = strtab_sec->data - data;
> > +
> > + ASSERT(offset == strtab_sec->sec->sh_offset);
> > +
> > + /* symtab_sec->data was computed in elf_resolve_sections. */
> > + ASSERT((symtab_sec->sec->sh_offset + data) == symtab_sec->data);
> > +
> > + /* No need to check values as elf_resolve_sections did it. */
> > + nsym = symtab_sec->sec->sh_size / symtab_sec->sec->sh_entsize;
> > +
> > + sym = xmalloc_array(struct xsplice_elf_sym, nsym);
> > + if ( !sym )
> > + {
> > + printk(XENLOG_ERR "%s%s: Could not allocate memory for symbols\n",
> > + XSPLICE, elf->name);
> > + return -ENOMEM;
> > + }
> > +
> > + /* So we don't leak memory. */
> > + elf->sym = sym;
> > + for ( i = 0; i < nsym; i++ )
>
> As with sections, the 0th symbol table entry is special too.
>
> > + {
> > + Elf_Sym *s;
> > +
> > + if ( i * sizeof(Elf_Sym) > elf->len )
>
> Considering that we know the symbol table section is within bounds,
> I don't think this check does any good. Plus it ought to be adding 1
> to i and take the section file offset into account.
>
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: Symbol header [%d] is past end of payload!\n",
> > + XSPLICE, elf->name, i);
> > + return -EINVAL;
> > + }
> > +
> > + s = &((Elf_Sym *)symtab_sec->data)[i];
> > +
> > + /* If st->name is STN_UNDEF is zero, the check will always be true. */
>
> Odd double use of "is".
>
> > + delta = s->st_name;
> > +
> > + /* Offset has been computed earlier. */
> > + if ( offset + delta > elf->len )
>
> This should again check against the string table size and again use >= .
I reworked this a bit (borrowed your idea of checking the full size of
the section before the loop) - which removes the need to check
the offset.
What I ended up is something much simpler (as I know the offset
is OK - I just need to check that the delta is within the section):
if ( delta && (delta > strtab_sec->sec->sec_sh_size) )
..
The offset gets (in the new patchset) checked in elf_resolve_section.
Albeit I am not sure about the >= instead of >, .. I need to think of
that.
.. snip..
> > +void xsplice_elf_free(struct xsplice_elf *elf)
> > +{
> > + xfree(elf->sec);
> > + elf->sec = NULL;
> > + xfree(elf->sym);
> > + elf->sym = NULL;
> > + elf->nsym = 0;
> > + elf->name = NULL;
> > + elf->len = 0;
> > +}
>
> Instead of zeroing these fields, wouldn't it make sense to simply
> xfree(elf) as the last action here?
The struct xsplice_elf is allocated on the stack (in the next
patch).
> > --- /dev/null
> > +++ b/xen/include/xen/xsplice_elf.h
.. snip..
> > +struct xsplice_elf_sym {
> > + Elf_Sym *sym;
>
> const?
.. this is much harder. I end up computing the values for
these symbols and have to write to this this structure a couple of times
(at worst).
>
> > + const char *name;
> > +};
> > +
> > +struct xsplice_elf {
> > + const char *name; /* Pointer to payload->name. */
> > + ssize_t len; /* Length of the ELF file. */
>
> Why ssize_t?
Made it 'size_t'
>
> > + Elf_Ehdr *hdr; /* ELF file. */
> > + struct xsplice_elf_sec *sec; /* Array of sections, allocated by us. */
> > + struct xsplice_elf_sym *sym; /* Array of symbols , allocated by us. */
> > + unsigned int nsym;
> > + struct xsplice_elf_sec *symtab;/* Pointer to .symtab section - aka to sec[x]. */
> > + struct xsplice_elf_sec *strtab;/* Pointer to .strtab section - aka to sec[y]. */
>
> Many times - const?
I have made the symtab and strtab const, but the 'sec' and 'sym'
I can't easily. There are many instances where I poke in the
section (like for ELF relocations) and have to modify this.
I can do some casting but it gets a bit .. messy.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.
2016-04-01 13:33 ` Jan Beulich
@ 2016-04-06 2:03 ` Konrad Rzeszutek Wilk
2016-04-07 1:03 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-06 2:03 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
On Fri, Apr 01, 2016 at 07:33:54AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > --- a/xen/Makefile
> > +++ b/xen/Makefile
> > @@ -75,6 +75,7 @@ _install: $(TARGET)$(CONFIG_XEN_INSTALL_SUFFIX)
> > echo 'EFI installation only partially done (EFI_VENDOR not set)' >&2; \
> > fi; \
> > fi
> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) install
> >
> > .PHONY: _uninstall
> > _uninstall: D=$(DESTDIR)
> > @@ -92,6 +93,7 @@ _uninstall:
> > rm -f $(D)$(EFI_DIR)/$(T)-$(XEN_VERSION).efi
> > rm -f $(D)$(EFI_DIR)/$(T).efi
> > rm -f $(D)$(EFI_MOUNTPOINT)/efi/$(EFI_VENDOR)/$(T)-$(XEN_FULLVERSION).efi
> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C arch/$(TARGET_ARCH) uninstall
>
> Pretty certainly stray changes, or they'd need a really good
> explanation.
It is used to remove the test-cases. Perhaps it should be called
'uninstall-tests' ? I will skip this for right now - and figure out
later how to make the OSSTest harvest these.
>
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -75,7 +75,12 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
> > $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
> > ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
> > `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C test
> >
> > +install:
> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C test install
> > +uninstall:
> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C test uninstall
>
> Tests or examples should not be built by default.
I can certainly make a seperate top destination called 'test' that will
take care of this? Or should it be called 'xsplice' ? 'xsplice-test' ?
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 27/28] xsplice: Add support for shadow variables.
2016-04-04 15:18 ` Jan Beulich
@ 2016-04-06 2:26 ` Konrad Rzeszutek Wilk
2016-04-08 15:58 ` Ross Lagerwall
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-06 2:26 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
ross.lagerwall, sasha.levin, xen-devel
On Mon, Apr 04, 2016 at 09:18:34AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > Shadow variables are a piece of infrastructure to be used by xsplice
> > modules. They are used to attach a new piece of data to an existing
> > structure in memory.
>
> An already known question again: Out of recent XSAs, how many
> needed such? I.e. can#t we put this off for now?
Yes I believe we can.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces
2016-04-01 15:23 ` Jan Beulich
@ 2016-04-06 2:39 ` Konrad Rzeszutek Wilk
2016-04-07 1:07 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-06 2:39 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
ross.lagerwall, sasha.levin, xen-devel
On Fri, Apr 01, 2016 at 09:23:15AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > @@ -331,16 +332,17 @@ static char *pointer(char *str, char *end, const char **fmt_ptr,
> > {
> > unsigned long sym_size, sym_offset;
> > char namebuf[KSYM_NAME_LEN+1];
> > + bool_t payload = 0;
> >
> > /* Advance parents fmt string, as we have consumed 's' or 'S' */
> > ++*fmt_ptr;
> >
> > s = symbols_lookup((unsigned long)arg, &sym_size, &sym_offset, namebuf);
> > -
> > - /* If the symbol is not found, fall back to printing the address */
> > + /* If the symbol is not found, fall back to printing the address. */
> > if ( !s )
> > break;
> > -
>
> Please don't drop blank lines like this.
>
> > + if ( strncmp(namebuf, s, KSYM_NAME_LEN) )
> > + payload = 1;
>
> What is this about? A comment is absolutely needed here, the
> more that without context "payload" is also an unclear term.
> And then - would simply comparing the two pointers suffice?
Sadly no. The namebuf is defined on the stack (and the value copied in)
while the 's' is a pointer to the char* in the symbols.
For all Xen hypervisor built-in symbols the 'namebuf' contents and 's'
are exactly the same. The only difference is when xSplice comes in
and the 'namebuf' has the name of the xSplice payload.
I will put a comment here.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-01 15:50 ` Jan Beulich
@ 2016-04-06 2:42 ` Konrad Rzeszutek Wilk
2016-04-06 6:39 ` Martin Pohlack
2016-04-07 1:11 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-06 2:42 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
On Fri, Apr 01, 2016 at 09:50:31AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > From: Ross Lagerwall <ross.lagerwall@citrix.com>
> >
> > Add hook functions which run during patch apply and patch revert.
> > Hook functions are used by xsplice payloads to manipulate data structures
> > during patching, etc.
>
> Since the added documentation here didn't enlighten me, I've gone
> back to the design doc, and found a single trivial mentioning of hooks.
> No example of what they would be useful for, nothing. Unless these
> can be shown to be needed if any recent XSA fix would be converted
> to an xSplice patch, I'd recommend dropping this for now.
I do like this for the test-case uses (and regression testing).
The normal use-case is to modify structures values where we have to
be delicate about it and can't just replace the value. As in we
may have to recompute the value.
>
> > @@ -851,6 +878,11 @@ static int apply_payload(struct payload *data)
> >
> > arch_xsplice_patching_leave();
> >
> > + spin_debug_disable();
> > + for ( i = 0; i < data->n_load_funcs; i++ )
> > + data->load_funcs[i]();
> > + spin_debug_enable();
>
> The spin debug disabling needs explanation. And shouldn't this be
> done before arch_xsplice_patching_leave()? Or wait,
> documentation above says "before payload is being applied", so it
> would need to go even further up, and ...
>
> > @@ -874,6 +906,11 @@ static int revert_payload(struct payload *data)
> >
> > arch_xsplice_patching_leave();
> >
> > + spin_debug_disable();
> > + for ( i = 0; i < data->n_unload_funcs; i++ )
> > + data->unload_funcs[i]();
> > + spin_debug_enable();
>
> ... it would be this one which may need to move up by just a few
> lines.
>
> > --- /dev/null
> > +++ b/xen/include/xen/xsplice_patch.h
> > @@ -0,0 +1,59 @@
> > +/*
> > + * Copyright (C) 2016 Citrix Systems R&D Ltd.
> > + */
> > +
> > +#ifndef __XEN_XSPLICE_PATCH_H__
> > +#define __XEN_XSPLICE_PATCH_H__
> > +
> > +/*
> > + * The following definitions are to be used in patches. They are taken
> > + * from kpatch.
> > + */
> > +typedef void (*xsplice_loadcall_t)(void);
> > +typedef void (*xsplice_unloadcall_t)(void);
>
> Plain function types please.
Done.
>
> > +/* This definition is taken from Linux. */
> > +#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
> > +/*
> > + * XSPLICE_IGNORE_SECTION macro
> > + *
> > + * This macro is for ignoring sections that may change as a side effect of
> > + * another change or might be a non-bundlable section; that is one that does
> > + * not honor -ffunction-section and create a one-to-one relation from function
> > + * symbol to section.
> > + */
> > +#define XSPLICE_IGNORE_SECTION(_sec) \
> > + char *__UNIQUE_ID(xsplice_ignore_section_) __section(".xsplice.ignore.sections") = _sec;
> > +
> > +/*
> > + * XSPLICE_IGNORE_FUNCTION macro
> > + *
> > + * This macro is for ignoring functions that may change as a side effect of a
> > + * change in another function.
> > + */
> > +#define XSPLICE_IGNORE_FUNCTION(_fn) \
> > + void *__xsplice_ignore_func_##_fn __section(".xsplice.ignore.functions") = _fn;
>
> Despite mentioned in the commit message, all of the above seems
> unrelated (and unclear in this context). Even more so that - afaict -
> they're unusable as we don't seem to have any __PASTE().
/me nods. I will remove them.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-06 2:42 ` Konrad Rzeszutek Wilk
@ 2016-04-06 6:39 ` Martin Pohlack
2016-04-07 1:15 ` Jan Beulich
2016-04-07 1:11 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Martin Pohlack @ 2016-04-06 6:39 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
On 06.04.2016 04:42, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 01, 2016 at 09:50:31AM -0600, Jan Beulich wrote:
>>>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>>> From: Ross Lagerwall <ross.lagerwall@citrix.com>
>>>
>>> Add hook functions which run during patch apply and patch revert.
>>> Hook functions are used by xsplice payloads to manipulate data structures
>>> during patching, etc.
>>
>> Since the added documentation here didn't enlighten me, I've gone
>> back to the design doc, and found a single trivial mentioning of hooks.
>> No example of what they would be useful for, nothing. Unless these
>> can be shown to be needed if any recent XSA fix would be converted
>> to an xSplice patch, I'd recommend dropping this for now.
>
> I do like this for the test-case uses (and regression testing).
>
> The normal use-case is to modify structures values where we have to
> be delicate about it and can't just replace the value. As in we
> may have to recompute the value.
Agree on the default use (e.g., for XSA 91).
If we have shadow variables, we also need an unload hook to garbage
collect all the variables introduced by a hotpatch to prevent memory
leaks. Potentially, we also want to pre-reserve memory for static or
existing dynamic objects in the load-hook instead of on the fly.
For testing and debugging, various applications are possible.
In general, the hooks provide flexibility when having to deal with
unforeseen cases, but their application should be rarely required (<
10%). I would argue that we can delay them until v2, together with the
shadow variables
Martin
Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 17/28] xsplice: Add support for exception tables.
2016-04-01 16:06 ` Jan Beulich
@ 2016-04-06 14:41 ` Konrad Rzeszutek Wilk
2016-04-06 15:32 ` Andrew Cooper
2016-04-07 1:21 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-06 14:41 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
On Fri, Apr 01, 2016 at 10:06:54AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > --- a/xen/common/xsplice.c
> > +++ b/xen/common/xsplice.c
> > @@ -573,6 +573,25 @@ static int prepare_payload(struct payload *payload,
> > region->frame[i].n_bugs = sec->sec->sh_size / sizeof(struct bug_frame);
> > }
> >
> > +#ifdef CONFIG_X86
> > + sec = xsplice_elf_sec_by_name(elf, ".ex_table");
> > + if ( sec )
> > + {
> > + if ( !sec->sec->sh_size ||
> > + (sec->sec->sh_size % sizeof (struct exception_table_entry)) )
> > + {
> > + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .ex_table (exp:%lu vs %lu)!\n",
> > + XSPLICE, elf->name, sizeof (struct exception_table_entry),
> > + sec->sec->sh_size);
> > + return -EINVAL;
> > + }
> > +
> > + region->ex = (struct exception_table_entry *)sec->load_addr;
> > + region->ex_end = (struct exception_table_entry *)(sec->load_addr + sec->sec->sh_size);
> > +
> > + sort_exception_table(region->ex, region->ex_end);
> > + }
> > +#endif
>
> Nothing here is really x86-specific, so the earlier comment on the
> conditionals better going away applies here too.
But there is no sort_exception_table on ARM, nor would the sizeof work
on ARM? Or are you saying I should add an .. empty function and
structure for this?
>
> > --- a/xen/include/asm-x86/uaccess.h
> > +++ b/xen/include/asm-x86/uaccess.h
> > @@ -276,6 +276,11 @@ extern struct exception_table_entry
> > __start___pre_ex_table[];
> > extern struct exception_table_entry __stop___pre_ex_table[];
> >
> > extern unsigned long search_exception_table(unsigned long);
> > +extern unsigned long search_one_extable(const struct exception_table_entry *first,
> > + const struct exception_table_entry *last,
> > + unsigned long value);
>
> I can't seem to find a use of the outside its defining file. Why is
> this being made global?
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 17/28] xsplice: Add support for exception tables.
2016-04-06 14:41 ` Konrad Rzeszutek Wilk
@ 2016-04-06 15:32 ` Andrew Cooper
2016-04-07 1:21 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Andrew Cooper @ 2016-04-06 15:32 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Jan Beulich
Cc: Keir Fraser, mpohlack, ross.lagerwall, sasha.levin, xen-devel
On 06/04/16 15:41, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 01, 2016 at 10:06:54AM -0600, Jan Beulich wrote:
>>>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>>> --- a/xen/common/xsplice.c
>>> +++ b/xen/common/xsplice.c
>>> @@ -573,6 +573,25 @@ static int prepare_payload(struct payload *payload,
>>> region->frame[i].n_bugs = sec->sec->sh_size / sizeof(struct bug_frame);
>>> }
>>>
>>> +#ifdef CONFIG_X86
>>> + sec = xsplice_elf_sec_by_name(elf, ".ex_table");
>>> + if ( sec )
>>> + {
>>> + if ( !sec->sec->sh_size ||
>>> + (sec->sec->sh_size % sizeof (struct exception_table_entry)) )
>>> + {
>>> + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .ex_table (exp:%lu vs %lu)!\n",
>>> + XSPLICE, elf->name, sizeof (struct exception_table_entry),
>>> + sec->sec->sh_size);
>>> + return -EINVAL;
>>> + }
>>> +
>>> + region->ex = (struct exception_table_entry *)sec->load_addr;
>>> + region->ex_end = (struct exception_table_entry *)(sec->load_addr + sec->sec->sh_size);
>>> +
>>> + sort_exception_table(region->ex, region->ex_end);
>>> + }
>>> +#endif
>> Nothing here is really x86-specific, so the earlier comment on the
>> conditionals better going away applies here too.
> But there is no sort_exception_table on ARM, nor would the sizeof work
> on ARM? Or are you saying I should add an .. empty function and
> structure for this?
Given the lack of "struct exception_table_entry" entirely on ARM, would
recommend keeping the #ifdefs, as being the far cleaner option.
Longterm, ARM should gain exception table handing.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-04-04 15:00 ` Jan Beulich
2016-04-04 20:01 ` Konrad Rzeszutek Wilk
@ 2016-04-06 20:05 ` Konrad Rzeszutek Wilk
2016-04-07 1:24 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-06 20:05 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
> > --- a/xen/include/xen/version.h
> > +++ b/xen/include/xen/version.h
> > @@ -17,4 +17,7 @@ const char *xen_deny(void);
> > #include <xen/types.h>
> > int xen_build_id(const void **p, unsigned int *len);
> >
> > +#include <xen/elfstructs.h>
> > +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len);
>
> The #include is misplaced again, and I'm rather hesitant to see
> version.h gain this dependency. Couldn't this go into xen/elf.h?
Sadly no. If I remove these two includes (xen/types.h and
xen/elfstructs.h) the compile breaks. It breaks for kernel.c, console,c,
setup.c and so on - complaining about unknown type name 'Elf_Note'.
I was thinking to do:
const Elf_Note;
But that didn't work out well. I think it is tied in to the #defines..
I could make it a void pointer too and just cast it inside
xen_build_id_check to 'const Elf_Note'.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 09/28] xsplice: Add helper elf routines
2016-04-06 1:38 ` Konrad Rzeszutek Wilk
@ 2016-04-07 0:38 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 0:38 UTC (permalink / raw)
To: konrad
Cc: keir, andrew.cooper3, ian.jackson, tim, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
>>> Konrad Rzeszutek Wilk <konrad@kernel.org> 04/06/16 3:40 AM >>>
>> > +struct xsplice_elf_sym {
>> > + Elf_Sym *sym;
>>
>> const?
>
>.. this is much harder. I end up computing the values for
>these symbols and have to write to this this structure a couple of times
>(at worst).
So I've intentionally added question marks to many of these comments, as
there certainly may be reasons to better not make some of the items const.
It just generally seemed in many cases that what gets pointed to has no
reason to get altered after initial setup.
>> > + Elf_Ehdr *hdr; /* ELF file. */
>> > + struct xsplice_elf_sec *sec; /* Array of sections, allocated by us. */
>> > + struct xsplice_elf_sym *sym; /* Array of symbols , allocated by us. */
>> > + unsigned int nsym;
>> > + struct xsplice_elf_sec *symtab;/* Pointer to .symtab section - aka to sec[x]. */
>> > + struct xsplice_elf_sec *strtab;/* Pointer to .strtab section - aka to sec[y]. */
>>
>> Many times - const?
>
>I have made the symtab and strtab const, but the 'sec' and 'sym'
>I can't easily. There are many instances where I poke in the
>section (like for ELF relocations) and have to modify this.
When processing relocations shouldn't need to modify symbols, and you
also shouldn't need to modify section metadata - only section contents
itself should be altered.
>I can do some casting but it gets a bit .. messy.
One thing should be very clear: No casts should be added which cast away
constness.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-05 16:45 ` Konrad Rzeszutek Wilk
2016-04-05 17:48 ` Konrad Rzeszutek Wilk
@ 2016-04-07 0:46 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 0:46 UTC (permalink / raw)
To: konrad.wilk
Cc: keir, andrew.cooper3, mpohlack, ross.lagerwall, julien.grall,
stefano.stabellini, xen-devel, konrad, sasha.levin
>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/05/16 6:46 PM >>>
>> > + if ( mfn_array )
>> > + *mfn_array = mfn;
>> > + else
>> > + xfree(mfn);
>>
>> What's this? I certainly assumed this wouldn't be needed anymore
>> now.
>
>I still need the MFNs so I can change the page table attributes once
>I've finished copying the ELF.
>
>I can walk the virtual addresses and gather them from the PTE,
>but I figured it would be easier to have them stashed away somewhere?
Both alternatives aren't really neat, but I think exposing the MFN list via the
vmalloc interface is the uglier variant. I.e. I'd prefer doing it Linux'es way,
perhaps even having a specialized sibling to map_pages_to_xen() which
only alters attributes without changing the frame numbers.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 10/28] xsplice: Implement payload loading
2016-04-05 17:48 ` Konrad Rzeszutek Wilk
@ 2016-04-07 0:49 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 0:49 UTC (permalink / raw)
To: konrad.wilk
Cc: keir, andrew.cooper3, mpohlack, ross.lagerwall, julien.grall,
stefano.stabellini, xen-devel, konrad, sasha.levin
>>>> Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> 04/05/16 7:49 PM >>>
>On Tue, Apr 05, 2016 at 12:45:44PM -0400, Konrad Rzeszutek Wilk wrote:
>> > > +void *vm_alloc(unsigned int nr, unsigned int align)
>> > > +{
>> > > + return vm_alloc_type(nr, align, VMAP_VIRT);
>> > > +}
>> >
>> > Inline/macro wrapper?
>
>I would prefer to have this inside the common/vmap.c file as I would
>need to expose vm_alloc_type in the header file - which is really not
>to be used by users of the vmalloc API.
If you don't expose it, how would xSplice be able to make use of it? But yes,
if indeed that would become the only reason preventing something to be static,
then it probably shouldn't become an inline wrapper.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version'.
2016-04-06 2:03 ` Konrad Rzeszutek Wilk
@ 2016-04-07 1:03 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 1:03 UTC (permalink / raw)
To: konrad
Cc: keir, andrew.cooper3, mpohlack, ross.lagerwall, julien.grall,
stefano.stabellini, sasha.levin, xen-devel
>>> Konrad Rzeszutek Wilk <konrad@kernel.org> 04/06/16 4:05 AM >>>
>On Fri, Apr 01, 2016 at 07:33:54AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > --- a/xen/arch/x86/Makefile
>> > +++ b/xen/arch/x86/Makefile
>> > @@ -75,7 +75,12 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
>> > $(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
>> > ./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
>> > `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
>> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C test
>> >
>> > +install:
>> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C test install
>> > +uninstall:
>> > + $(MAKE) -f $(BASEDIR)/Rules.mk -C test uninstall
>>
>> Tests or examples should not be built by default.
>
>I can certainly make a seperate top destination called 'test' that will
>take care of this? Or should it be called 'xsplice' ? 'xsplice-test' ?
The top level one would (imo naturally) be "tests", as there could be more
than just the xSplice one(s).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces
2016-04-06 2:39 ` Konrad Rzeszutek Wilk
@ 2016-04-07 1:07 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 1:07 UTC (permalink / raw)
To: konrad
Cc: keir, andrew.cooper3, ian.jackson, tim, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
>>> Konrad Rzeszutek Wilk <konrad@kernel.org> 04/06/16 4:39 AM >>>
>On Fri, Apr 01, 2016 at 09:23:15AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > @@ -331,16 +332,17 @@ static char *pointer(char *str, char *end, const char **fmt_ptr,
>> > {
>> > unsigned long sym_size, sym_offset;
>> > char namebuf[KSYM_NAME_LEN+1];
>> > + bool_t payload = 0;
>> >
>> > /* Advance parents fmt string, as we have consumed 's' or 'S' */
>> > ++*fmt_ptr;
>> >
>> > s = symbols_lookup((unsigned long)arg, &sym_size, &sym_offset, namebuf);
>> > -
>> > - /* If the symbol is not found, fall back to printing the address */
>> > + /* If the symbol is not found, fall back to printing the address. */
>> > if ( !s )
>> > break;
>> > -
>> > + if ( strncmp(namebuf, s, KSYM_NAME_LEN) )
>> > + payload = 1;
>>
>> What is this about? A comment is absolutely needed here, the
>> more that without context "payload" is also an unclear term.
>> And then - would simply comparing the two pointers suffice?
>
>Sadly no. The namebuf is defined on the stack (and the value copied in)
>while the 's' is a pointer to the char* in the symbols.
How does one being on the stack and the other in (I assume) a string table
prevent their pointers to be compared? Iirc for the in-hypervisor symbols
symbols_lookup() simply returns the passed in namebuf, and hence
s == namebuf above. Or I must be missing something...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-06 2:42 ` Konrad Rzeszutek Wilk
2016-04-06 6:39 ` Martin Pohlack
@ 2016-04-07 1:11 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 1:11 UTC (permalink / raw)
To: konrad
Cc: keir, andrew.cooper3, mpohlack, ross.lagerwall, sasha.levin, xen-devel
>>> Konrad Rzeszutek Wilk <konrad@kernel.org> 04/06/16 4:44 AM >>>
>On Fri, Apr 01, 2016 at 09:50:31AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > From: Ross Lagerwall <ross.lagerwall@citrix.com>
>> >
>> > Add hook functions which run during patch apply and patch revert.
>> > Hook functions are used by xsplice payloads to manipulate data structures
>> > during patching, etc.
>>
>> Since the added documentation here didn't enlighten me, I've gone
>> back to the design doc, and found a single trivial mentioning of hooks.
>> No example of what they would be useful for, nothing. Unless these
>> can be shown to be needed if any recent XSA fix would be converted
>> to an xSplice patch, I'd recommend dropping this for now.
>
>I do like this for the test-case uses (and regression testing).
I don't think having infrastructure just for test cases' sake is a good idea.
>The normal use-case is to modify structures values where we have to
>be delicate about it and can't just replace the value. As in we
>may have to recompute the value.
That's the normal _theoretical_ use case afaict. Or else you would have
given an example as asked for above.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-06 6:39 ` Martin Pohlack
@ 2016-04-07 1:15 ` Jan Beulich
2016-04-08 15:57 ` Ross Lagerwall
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 1:15 UTC (permalink / raw)
To: mpohlack, konrad
Cc: keir, andrew.cooper3, mpohlack, ross.lagerwall, sasha.levin, xen-devel
>>> Martin Pohlack <mpohlack@amazon.com> 04/06/16 8:42 AM >>>
>On 06.04.2016 04:42, Konrad Rzeszutek Wilk wrote:
>> The normal use-case is to modify structures values where we have to
>> be delicate about it and can't just replace the value. As in we
>> may have to recompute the value.
>
>Agree on the default use (e.g., for XSA 91).
XSA-91 was an ARM one, i.e. would still only be a theoretical example for
the purpose of the discussion here.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 17/28] xsplice: Add support for exception tables.
2016-04-06 14:41 ` Konrad Rzeszutek Wilk
2016-04-06 15:32 ` Andrew Cooper
@ 2016-04-07 1:21 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 1:21 UTC (permalink / raw)
To: konrad
Cc: keir, andrew.cooper3, mpohlack, ross.lagerwall, sasha.levin, xen-devel
>>> Konrad Rzeszutek Wilk <konrad@kernel.org> 04/06/16 4:42 PM >>>
>On Fri, Apr 01, 2016 at 10:06:54AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > --- a/xen/common/xsplice.c
>> > +++ b/xen/common/xsplice.c
>> > @@ -573,6 +573,25 @@ static int prepare_payload(struct payload *payload,
>> > region->frame[i].n_bugs = sec->sec->sh_size / sizeof(struct bug_frame);
>> > }
>> >
>> > +#ifdef CONFIG_X86
>> > + sec = xsplice_elf_sec_by_name(elf, ".ex_table");
>> > + if ( sec )
>> > + {
>> > + if ( !sec->sec->sh_size ||
>> > + (sec->sec->sh_size % sizeof (struct exception_table_entry)) )
>> > + {
>> > + dprintk(XENLOG_DEBUG, "%s%s: Wrong size of .ex_table (exp:%lu vs %lu)!\n",
>> > + XSPLICE, elf->name, sizeof (struct exception_table_entry),
>> > + sec->sec->sh_size);
>> > + return -EINVAL;
>> > + }
>> > +
>> > + region->ex = (struct exception_table_entry *)sec->load_addr;
>> > + region->ex_end = (struct exception_table_entry *)(sec->load_addr + sec->sec->sh_size);
>> > +
>> > + sort_exception_table(region->ex, region->ex_end);
>> > + }
>> > +#endif
>>
>> Nothing here is really x86-specific, so the earlier comment on the
>> conditionals better going away applies here too.
>
>But there is no sort_exception_table on ARM, nor would the sizeof work
>on ARM? Or are you saying I should add an .. empty function and
>structure for this?
The lack of sort_exception_table() would be easy to deal with, but I indeed
overlooked the sizeof(). So I agree with you and Andrew that the conditionals
should stay, but I'd like them to be inverted (i.e. test for !ARM).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-04-06 20:05 ` Konrad Rzeszutek Wilk
@ 2016-04-07 1:24 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 1:24 UTC (permalink / raw)
To: konrad
Cc: keir, andrew.cooper3, mpohlack, ross.lagerwall, sasha.levin, xen-devel
>>> Konrad Rzeszutek Wilk <konrad@kernel.org> 04/06/16 10:05 PM >>>
>> > --- a/xen/include/xen/version.h
>> > +++ b/xen/include/xen/version.h
>> > @@ -17,4 +17,7 @@ const char *xen_deny(void);
>> > #include <xen/types.h>
>> > int xen_build_id(const void **p, unsigned int *len);
>> >
>> > +#include <xen/elfstructs.h>
>> > +int xen_build_id_check(const Elf_Note *n, const void **p, unsigned int *len);
>>
>> The #include is misplaced again, and I'm rather hesitant to see
>> version.h gain this dependency. Couldn't this go into xen/elf.h?
>
>Sadly no. If I remove these two includes (xen/types.h and
>xen/elfstructs.h) the compile breaks. It breaks for kernel.c, console,c,
>setup.c and so on - complaining about unknown type name 'Elf_Note'.
I guess there's a misunderstanding of my use of "this" here: I meant the
function declaration to get moved over. I can't see how that would cause
compilation problems.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-04 12:46 ` Jan Beulich
@ 2016-04-07 2:58 ` Konrad Rzeszutek Wilk
2016-04-08 15:49 ` Ross Lagerwall
2016-04-08 0:18 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-07 2:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > The version of ld that first implemented --build-id is v2.18.
> > Hence we check for that or later version - if older version
> > found we do not build the hypervisor with the build-id
> > (and the return code is -ENODATA for xen_build_id() call).
>
> This appears to be stale.
>
> > The EFI binary is more complicated. Having any non-recognizable
> > sections (.note, .data.note, etc) causes the boot to hang.
> > Moving the .note in the .data section makes it work. It is also
> > worth noting that the PE/COFF does not have any "comment"
> > sections to the author.
>
> I'm afraid this is too vague: What exactly is happening there? And
> is this due to binutils doing something wrong, or an issue with the
> firmware on the box you've tried? While the placement of .note is
> not really a big deal, any unusual placement needs a source
> comment attached explaining the whys, to prevent people down
> the road moving the section back into the "expected" place. But
> see also below.
I will have to dig in this more. I know I tried it on TianoCore but
that seems to have some other issues at the moment so I will
try it out on real hardware.
>
> > Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
> > symbol offsets don't changes (which means we have multiple binary
> > ids - except that the last one is the final one). Without this change,
> > the symbol table embedded in Xen are incorrect - some of the values it
> > contains are offset by the size of the included build id.
> > This obviously causes problems when resolving symbols.
>
> Would this also be a problem if you place the notes segment/section
> last in the binary?
I am not sure. Ross, you are the one who observed this?
> > +build_id.o: $(TARGET)-syms
> > + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
>
> Considering your xen.lds.S changes, won't this potentially copy quite
> a bit more than just the build ID (i.e. all notes)? This may be okay, and
> may be even intended, but then the generate file's name should
> reflect this to not misguide people.
I renamed it notes.o
>
> > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> > + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
>
> Since you put the notes into .rodata anyway, why name the
> section .note.*? Just name it .rodata.*, avoiding to mislead
> others who also think that a section's name has much of a
> meaning.
I thought that somebody during review asked for it to be called .note?
But I will dig in this next week.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-04 7:07 ` Jan Beulich
@ 2016-04-07 3:05 ` Konrad Rzeszutek Wilk
2016-04-07 15:38 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-07 3:05 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
> >> So you check for there being one such section. Is having multiple
> >> of them okay / meaningful?
> >
> > /me blinks. You can have multiple ELF sections with the same name?
> > I will double-check the spec over the weekend to see.
>
> Of course you can. Remember me telling you that using section
> names for identification is a bad idea (even if widely done that
> way)? That's precisely because section names in the spec serve
> no meaning other than making sections identifiable to the human
> eye. For certain sections there's a more or less strict convention
> on what their names should be, but that's all there is to names.
> Section types and attributes really are what describe their
> purposes.
This is going to take a bit of time to get right I am afraid.
(The checks are easy - but make sure the payload files that are generated
are doing the right thing).
>
> And even if that really was forbidden by the spec, you'd still need
> to make sure the binary meets the spec.
Yes.
> >> > +void check_for_xsplice_work(void)
> >> > +{
> >> > + /* Set at -1, so will go up to num_online_cpus - 1. */
> >> > + if ( atomic_inc_and_test(&xsplice_work.semaphore) )
> >> > + {
> >> > + struct payload *p;
> >> > + unsigned int total_cpus;
> >> > +
> >> > + p = xsplice_work.data;
> >> > + if ( !get_cpu_maps() )
> >> > + {
> >> > + printk(XENLOG_ERR "%s%s: CPU%u - unable to get cpu_maps lock!\n",
> >> > + XSPLICE, p->name, cpu);
> >> > + per_cpu(work_to_do, cpu) = 0;
> >> > + xsplice_work.data->rc = -EBUSY;
> >> > + xsplice_work.do_work = 0;
> >>
> >> On x86 such possibly simultaneous accesses may be okay, but is
> >> that universally the case? Wouldn't it better be only the monarch
> >> which updates shared data?
> >
> > Monarch? Oh you mean arch specific code path?
>
> Oh, I think you call it "master" elsewhere. IA64 terminology which
> I came to like.
>
The master CPU is the one updating it.
> >> > + /* All CPUs are waiting, now signal to disable IRQs. */
> >> > + xsplice_work.ready = 1;
> >> > + smp_wmb();
> >> > +
> >> > + atomic_inc(&xsplice_work.irq_semaphore);
> >> > + if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout, total_cpus,
> >> > + "Timed out on IRQ semaphore") )
> >>
> >> I'd prefer if the common parts of that message moved into
> >> xsplice_do_wait() - no reason to have more string literal space
> >> occupied than really needed. Also, looking back, the respective
> >> function parameter could do with a more descriptive name.
> >>
> >> And then - does it make sense to wait the perhaps full 30ms
> >> on this second step? Rendezvoused CPUs should react rather
> >> quickly to the signal to disable interrupts.
> >
> > We don't reset the timeout - the timeout is for both calls
> > to xsplice_do_wait.
>
> I understand that's the way it's right now, but that's what I'm putting
> under question. Rendezvousing CPUs is quite a bit more at risk of
> taking some time compared to having already rendezvoused CPUs
> disable their IRQs.
Yes. I could expand the timeout, but maybe have some reset (add more
timeout) once CPUs come along?
> >> > static int __init xsplice_init(void)
> >> > {
> >> > + BUILD_BUG_ON( sizeof(struct xsplice_patch_func) != 64 );
> >> > + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_addr) != 8 );
> >> > + BUILD_BUG_ON( offsetof(struct xsplice_patch_func, new_size) != 24 );
> >>
> >> What assumptions get broken if these sizes change?
> >
> > I think you mean the offsets? They can change. I added them to make sure
> > that on 32-bit hypervisor (ARM) the offsets would be the same as on 64-bit
> > hypervisor (x86).
> >
> > The size however MUST remain the same - otherwise the toolstack won't
> > produce proper payloads anymore.
>
> Well, that's a very bad thing then imo. You'd better version the
> structure instead.
Andrew reminded me that we also will have build-ids. Those by nature imply
a version. That is the payload won't ever apply against a different type
hypervisor.
But I still added a version field in the struct so when we get the
'checking the old code' we have a mechanism to select -build-id or
the newer way.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-01 13:28 ` Jan Beulich
2016-04-01 21:04 ` Konrad Rzeszutek Wilk
@ 2016-04-07 3:09 ` Konrad Rzeszutek Wilk
2016-04-07 15:43 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-07 3:09 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
> That's for an individual patch I suppose? What if REPLACE has to
> revert dozens or hundreds of patches?
I don't know. That is sometihng I need to figure out.
I also need to test this out on the 8 socket machine..
> > +void arch_xsplice_apply_jmp(struct xsplice_patch_func *func)
> > +{
> > + uint32_t val;
>
> The way it's being used below, it clearly should be int32_t.
>
> > + uint8_t *old_ptr;
> > +
> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> > +
> > + old_ptr = (uint8_t *)func->old_addr;
>
> (Considering this cast, the "old_addr" member should be
> unsigned long (or void *), not uint64_t: The latest on ARM32
> such would otherwise cause problems.)
I has to be uint8_t to make the single byte modifications. Keep
also in mind that this file is only for x86.
>
> Also - where is the verification that
> func->old_size >= PATCH_INSN_SIZE?
I made a 'arch_xsplice_verify_func' to have per-architecture check for
that.
..
> > + sec = xsplice_elf_sec_by_name(elf, names[i]);
> > + if ( !sec )
> > + {
> > + printk(XENLOG_ERR "%s%s: %s is missing!\n",
> > + XSPLICE, elf->name, names[i]);
> > + return -EINVAL;
> > + }
> > +
> > + if ( !sec->sec->sh_size )
> > + return -EINVAL;
> > + }
> > +
> > + return 0;
> > +}
>
> So you check for there being one such section. Is having multiple
> of them okay / meaningful?
I've been going back on this. I think at this point I will say no.
I am going to look at what is involved in this in later versions.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 18/28] xsplice: Add support for alternatives
2016-04-01 16:20 ` Jan Beulich
@ 2016-04-07 3:11 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-07 3:11 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
On Fri, Apr 01, 2016 at 10:20:40AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > --- a/xen/arch/x86/alternative.c
> > +++ b/xen/arch/x86/alternative.c
> > @@ -28,7 +28,7 @@
> > extern struct alt_instr __alt_instructions[], __alt_instructions_end[];
> >
> > #ifdef K8_NOP1
> > -static const unsigned char k8nops[] __initconst = {
> > +static const unsigned char k8nops[] = {
>
> Just like in Linux these init annotations should become conditional
> upon CONFIG_XSPLICE (and I realize this applies to at least the
> previous patch too).
I ended up declaring #define INIT __init and so on if CONFIG_XSPLICE
is not defined. Obviouslu they are empty if CONFIG_XSPLICE is set.
Since both alternative and exceptions use this I ended up putting
this in xsplice.h file.
..snip..
> > /* Our replacement function for xen_extra_version. */
> > const char *xen_hello_world(void)
> > {
> > + alternative(ASM_NOP1, ASM_NOP1, 1);
>
> Above you say the code is being exercised by this: How can you be
> sure that whatever feature has value 1 is actually present? The
> pending SMEP/SMAP patches add X86_FEATURE_ALWAYS for such
> a purpose.
I must have missed them. I can change it once they go in. For right now
I just changed this X86_FEATURE_NX.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-04-01 15:11 ` Jan Beulich
@ 2016-04-07 3:14 ` Konrad Rzeszutek Wilk
2016-04-07 15:46 ` Jan Beulich
[not found] ` <5707D68A.8090006@citrix.com>
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-07 3:14 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
On Fri, Apr 01, 2016 at 09:11:40AM -0600, Jan Beulich wrote:
> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> > --- a/xen/arch/x86/Makefile
> > +++ b/xen/arch/x86/Makefile
> > @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> > $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> > $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
> > - | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
> > + >$(@D)/.$(@F).0.S
> > $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> > $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> > $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
> > - | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
> > + >$(@D)/.$(@F).1.S
>
> This addition should be dependent on CONFIG_XSPLICE, not the
> least because I expect it to bloat the symbol table quite a bit. And
> then - how come this is needed here, but not in the xen.efi rule?
I added it to xen.efi rule and got:
home/konrad/xen/xen/.xen.efi.0s.S: Assembler messages:
/home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f80000543 truncated to 0x80000543
/home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f800008b2 truncated to 0x800008b2
/home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f800008b4 truncated to 0x800008b4
/home/konrad/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f800008b9 truncated to 0x800008b9
/home/konrad/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000103f truncated to 0x8000103f
/home/konrad/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001043 truncated to 0x80001043
/home/konrad/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001047 truncated to 0x80001047
/home/konrad/xen/xen/.xen.efi.0s.S:6746: Warning: value 0x100650000 truncated to 0x650000
and so on.. Not sure why. The xen.efi file boots thought?
> > + rc = xensyms_read(&symnum, &type, &addr, name);
> > + if ( rc )
> > + break;
> > +
> > + if ( !strcmp(name, symname) )
> > + {
> > + outaddr = addr;
> > + break;
> > + }
> > + } while ( name[0] != '\0' );
> > +
> > + return outaddr;
> > +}
>
> Huh - a brute force linear lookup. We've got some 7,000 symbols
> right now, and I think we can't expect that to go down.
I left it as such. I will need to redo this as the xensyms_read is not
the best for this and this will need to be redone to be much faster.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-07 3:05 ` Konrad Rzeszutek Wilk
@ 2016-04-07 15:38 ` Jan Beulich
2016-04-09 14:42 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 15:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
>>> On 07.04.16 at 05:05, <konrad.wilk@oracle.com> wrote:
>> >> > + /* All CPUs are waiting, now signal to disable IRQs. */
>> >> > + xsplice_work.ready = 1;
>> >> > + smp_wmb();
>> >> > +
>> >> > + atomic_inc(&xsplice_work.irq_semaphore);
>> >> > + if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout, total_cpus,
>> >> > + "Timed out on IRQ semaphore") )
>> >>
>> >> I'd prefer if the common parts of that message moved into
>> >> xsplice_do_wait() - no reason to have more string literal space
>> >> occupied than really needed. Also, looking back, the respective
>> >> function parameter could do with a more descriptive name.
>> >>
>> >> And then - does it make sense to wait the perhaps full 30ms
>> >> on this second step? Rendezvoused CPUs should react rather
>> >> quickly to the signal to disable interrupts.
>> >
>> > We don't reset the timeout - the timeout is for both calls
>> > to xsplice_do_wait.
>>
>> I understand that's the way it's right now, but that's what I'm putting
>> under question. Rendezvousing CPUs is quite a bit more at risk of
>> taking some time compared to having already rendezvoused CPUs
>> disable their IRQs.
>
> Yes. I could expand the timeout, but maybe have some reset (add more
> timeout) once CPUs come along?
Expand the timeout? Add more timeout? I don't understand. My
point was about shortening the timeout on the second step.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-07 3:09 ` Konrad Rzeszutek Wilk
@ 2016-04-07 15:43 ` Jan Beulich
2016-04-10 2:36 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 15:43 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
>>> On 07.04.16 at 05:09, <konrad.wilk@oracle.com> wrote:
>> > + uint8_t *old_ptr;
>> > +
>> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
>> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
>> > +
>> > + old_ptr = (uint8_t *)func->old_addr;
>>
>> (Considering this cast, the "old_addr" member should be
>> unsigned long (or void *), not uint64_t: The latest on ARM32
>> such would otherwise cause problems.)
>
> I has to be uint8_t to make the single byte modifications. Keep
> also in mind that this file is only for x86.
old_addr can't reasonably be uint8_t, so I can only assume you're
mixing up things here. (And yes, I do realize this is x86 code, but
my reference to ARM32 was only mean to say that there you'll
need to do something similar, and casting uint64_t to whatever
kind of pointer type is not going to work without compiler warning.)
>> Also - where is the verification that
>> func->old_size >= PATCH_INSN_SIZE?
>
> I made a 'arch_xsplice_verify_func' to have per-architecture check for
> that.
> ..
>> > + sec = xsplice_elf_sec_by_name(elf, names[i]);
>> > + if ( !sec )
>> > + {
>> > + printk(XENLOG_ERR "%s%s: %s is missing!\n",
>> > + XSPLICE, elf->name, names[i]);
>> > + return -EINVAL;
>> > + }
>> > +
>> > + if ( !sec->sec->sh_size )
>> > + return -EINVAL;
>> > + }
>> > +
>> > + return 0;
>> > +}
>>
>> So you check for there being one such section. Is having multiple
>> of them okay / meaningful?
>
> I've been going back on this. I think at this point I will say no.
> I am going to look at what is involved in this in later versions.
And check for there being exactly one for now, I then assume?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-04-07 3:14 ` Konrad Rzeszutek Wilk
@ 2016-04-07 15:46 ` Jan Beulich
2016-04-08 1:32 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-07 15:46 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
sasha.levin, xen-devel
>>> On 07.04.16 at 05:14, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 01, 2016 at 09:11:40AM -0600, Jan Beulich wrote:
>> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> > --- a/xen/arch/x86/Makefile
>> > +++ b/xen/arch/x86/Makefile
>> > @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
>> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>> > $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
>> > $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
>> > - | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
>> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
>> > + >$(@D)/.$(@F).0.S
>> > $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
>> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>> > $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
>> > $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
>> > - | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
>> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
>> > + >$(@D)/.$(@F).1.S
>>
>> This addition should be dependent on CONFIG_XSPLICE, not the
>> least because I expect it to bloat the symbol table quite a bit. And
>> then - how come this is needed here, but not in the xen.efi rule?
>
> I added it to xen.efi rule and got:
>
> home/konrad/xen/xen/.xen.efi.0s.S: Assembler messages:
> /home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f80000543
> truncated to 0x80000543
> /home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f800008b2
> truncated to 0x800008b2
> /home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f800008b4
> truncated to 0x800008b4
> /home/konrad/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f800008b9
> truncated to 0x800008b9
> /home/konrad/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000103f
> truncated to 0x8000103f
> /home/konrad/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001043
> truncated to 0x80001043
> /home/konrad/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001047
> truncated to 0x80001047
> /home/konrad/xen/xen/.xen.efi.0s.S:6746: Warning: value 0x100650000
> truncated to 0x650000
>
> and so on.. Not sure why. The xen.efi file boots thought?
It's the kallsyms symbol table that suffers, so the image booting
fine is not really surprising. But we'd need to understand what
specific data objects these warnings originate from - perhaps
linker generated symbols not sitting inside sections?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-04 12:46 ` Jan Beulich
2016-04-07 2:58 ` Konrad Rzeszutek Wilk
@ 2016-04-08 0:18 ` Konrad Rzeszutek Wilk
2016-04-08 1:52 ` Konrad Rzeszutek Wilk
2016-04-08 15:25 ` Jan Beulich
1 sibling, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 0:18 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
> > +build_id.o: $(TARGET)-syms
> > + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
>
> Considering your xen.lds.S changes, won't this potentially copy quite
> a bit more than just the build ID (i.e. all notes)? This may be okay, and
> may be even intended, but then the generate file's name should
> reflect this to not misguide people.
I changed it notes.o
>
> > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> > + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
>
> Since you put the notes into .rodata anyway, why name the
> section .note.*? Just name it .rodata.*, avoiding to mislead
> others who also think that a section's name has much of a
> meaning.
Way back last year:
http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01264.html
which is where the .note came about. I can put it all in .rodata
and not have it for normal ELF builds if you would like.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-04-07 15:46 ` Jan Beulich
@ 2016-04-08 1:32 ` Konrad Rzeszutek Wilk
2016-04-08 15:21 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 1:32 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
On Thu, Apr 07, 2016 at 09:46:49AM -0600, Jan Beulich wrote:
> >>> On 07.04.16 at 05:14, <konrad.wilk@oracle.com> wrote:
> > On Fri, Apr 01, 2016 at 09:11:40AM -0600, Jan Beulich wrote:
> >> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> >> > --- a/xen/arch/x86/Makefile
> >> > +++ b/xen/arch/x86/Makefile
> >> > @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> >> > $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
> >> > - | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
> >> > + >$(@D)/.$(@F).0.S
> >> > $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> >> > $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
> >> > - | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
> >> > + >$(@D)/.$(@F).1.S
> >>
> >> This addition should be dependent on CONFIG_XSPLICE, not the
> >> least because I expect it to bloat the symbol table quite a bit. And
> >> then - how come this is needed here, but not in the xen.efi rule?
> >
> > I added it to xen.efi rule and got:
> >
> > home/konrad/xen/xen/.xen.efi.0s.S: Assembler messages:
> > /home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f80000543
> > truncated to 0x80000543
> > /home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f800008b2
> > truncated to 0x800008b2
> > /home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f800008b4
> > truncated to 0x800008b4
> > /home/konrad/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f800008b9
> > truncated to 0x800008b9
> > /home/konrad/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000103f
> > truncated to 0x8000103f
> > /home/konrad/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001043
> > truncated to 0x80001043
> > /home/konrad/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001047
> > truncated to 0x80001047
> > /home/konrad/xen/xen/.xen.efi.0s.S:6746: Warning: value 0x100650000
> > truncated to 0x650000
> >
> > and so on.. Not sure why. The xen.efi file boots thought?
>
> It's the kallsyms symbol table that suffers, so the image booting
> fine is not really surprising. But we'd need to understand what
> specific data objects these warnings originate from - perhaps
> linker generated symbols not sitting inside sections?
From the .xen.efi.0s.S:
.globl symbols_offsets
ALGN
symbols_offsets:
#endif
PTR 0x544 - SYMBOLS_ORIGIN
PTR 0xa01 - SYMBOLS_ORIGIN
PTR 0xa03 - SYMBOLS_ORIGIN
PTR 0xa08 - SYMBOLS_ORIGIN
PTR 0x118e - SYMBOLS_ORIGIN
PTR 0x1192 - SYMBOLS_ORIGIN
PTR 0x1196 - SYMBOLS_ORIGIN
PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
which corresponds to:
multiboot1_header_start|0000000000000544| ? | | | |
multiboot1_header_start|0000000000000a01| ? | | | |
multiboot1_header_start|0000000000000a03| ? | | | |
multiboot1_header_start|0000000000000a08| ? | | | |
multiboot1_header_start|000000000000118e| ? | | | |
multiboot1_header_start|0000000000001192| ? | | | |
multiboot1_header_start|0000000000001196| ? | | | |
which is also found:
multiboot1_header_start|ffff82d080100008| t | | | |
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 0:18 ` Konrad Rzeszutek Wilk
@ 2016-04-08 1:52 ` Konrad Rzeszutek Wilk
2016-04-08 15:27 ` Jan Beulich
2016-04-08 15:25 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 1:52 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
On Thu, Apr 07, 2016 at 08:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
> > > +build_id.o: $(TARGET)-syms
> > > + $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
> >
> > Considering your xen.lds.S changes, won't this potentially copy quite
> > a bit more than just the build ID (i.e. all notes)? This may be okay, and
> > may be even intended, but then the generate file's name should
> > reflect this to not misguide people.
>
> I changed it notes.o
>
> >
> > > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> > > + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
> >
> > Since you put the notes into .rodata anyway, why name the
> > section .note.*? Just name it .rodata.*, avoiding to mislead
> > others who also think that a section's name has much of a
> > meaning.
>
> Way back last year:
> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01264.html
>
> which is where the .note came about. I can put it all in .rodata
> and not have it for normal ELF builds if you would like.
.rodata.notes for both ELF and EFI looks to have done the trick.
Now it is just the matter of testing it.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-04-08 1:32 ` Konrad Rzeszutek Wilk
@ 2016-04-08 15:21 ` Jan Beulich
2016-04-08 15:27 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 15:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
sasha.levin, xen-devel
>>> On 08.04.16 at 03:32, <konrad@kernel.org> wrote:
> On Thu, Apr 07, 2016 at 09:46:49AM -0600, Jan Beulich wrote:
>> >>> On 07.04.16 at 05:14, <konrad.wilk@oracle.com> wrote:
>> > On Fri, Apr 01, 2016 at 09:11:40AM -0600, Jan Beulich wrote:
>> >> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> >> > --- a/xen/arch/x86/Makefile
>> >> > +++ b/xen/arch/x86/Makefile
>> >> > @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
>> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>> >> > $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
>> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
>> >> > - | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
>> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
>> >> > + >$(@D)/.$(@F).0.S
>> >> > $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
>> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>> >> > $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
>> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
>> >> > - | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
>> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
>> >> > + >$(@D)/.$(@F).1.S
>> >>
>> >> This addition should be dependent on CONFIG_XSPLICE, not the
>> >> least because I expect it to bloat the symbol table quite a bit. And
>> >> then - how come this is needed here, but not in the xen.efi rule?
>> >
>> > I added it to xen.efi rule and got:
>> >
>> > home/konrad/xen/xen/.xen.efi.0s.S: Assembler messages:
>> > /home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f80000543
>> > truncated to 0x80000543
>> > /home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f800008b2
>> > truncated to 0x800008b2
>> > /home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f800008b4
>> > truncated to 0x800008b4
>> > /home/konrad/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f800008b9
>> > truncated to 0x800008b9
>> > /home/konrad/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000103f
>> > truncated to 0x8000103f
>> > /home/konrad/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001043
>> > truncated to 0x80001043
>> > /home/konrad/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001047
>> > truncated to 0x80001047
>> > /home/konrad/xen/xen/.xen.efi.0s.S:6746: Warning: value 0x100650000
>> > truncated to 0x650000
>> >
>> > and so on.. Not sure why. The xen.efi file boots thought?
>>
>> It's the kallsyms symbol table that suffers, so the image booting
>> fine is not really surprising. But we'd need to understand what
>> specific data objects these warnings originate from - perhaps
>> linker generated symbols not sitting inside sections?
>
> From the .xen.efi.0s.S:
> .globl symbols_offsets
> ALGN
> symbols_offsets:
> #endif
> PTR 0x544 - SYMBOLS_ORIGIN
> PTR 0xa01 - SYMBOLS_ORIGIN
> PTR 0xa03 - SYMBOLS_ORIGIN
> PTR 0xa08 - SYMBOLS_ORIGIN
> PTR 0x118e - SYMBOLS_ORIGIN
> PTR 0x1192 - SYMBOLS_ORIGIN
> PTR 0x1196 - SYMBOLS_ORIGIN
> PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
> PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
>
> which corresponds to:
> multiboot1_header_start|0000000000000544| ? | | | |
> multiboot1_header_start|0000000000000a01| ? | | | |
> multiboot1_header_start|0000000000000a03| ? | | | |
> multiboot1_header_start|0000000000000a08| ? | | | |
> multiboot1_header_start|000000000000118e| ? | | | |
> multiboot1_header_start|0000000000001192| ? | | | |
> multiboot1_header_start|0000000000001196| ? | | | |
>
> which is also found:
> multiboot1_header_start|ffff82d080100008| t | | | |
That looks like a binutils issue, associating the wrong name with
certain symbols. Depending on what binutils version you have in
use, this may be well be one of those I've fixed already.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 0:18 ` Konrad Rzeszutek Wilk
2016-04-08 1:52 ` Konrad Rzeszutek Wilk
@ 2016-04-08 15:25 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 15:25 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
>>> On 08.04.16 at 02:18, <konrad@kernel.org> wrote:
>> > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
>> > + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
>>
>> Since you put the notes into .rodata anyway, why name the
>> section .note.*? Just name it .rodata.*, avoiding to mislead
>> others who also think that a section's name has much of a
>> meaning.
>
> Way back last year:
> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01264.html
But that wasn't dealing with the EFI case at all back then.
> which is where the .note came about. I can put it all in .rodata
> and not have it for normal ELF builds if you would like.
It would, overall, look more consistent to me.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 1:52 ` Konrad Rzeszutek Wilk
@ 2016-04-08 15:27 ` Jan Beulich
2016-04-08 17:06 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 15:27 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
>>> On 08.04.16 at 03:52, <konrad@kernel.org> wrote:
> On Thu, Apr 07, 2016 at 08:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
>> >
>> > > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
>> > > + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
>> >
>> > Since you put the notes into .rodata anyway, why name the
>> > section .note.*? Just name it .rodata.*, avoiding to mislead
>> > others who also think that a section's name has much of a
>> > meaning.
>>
>> Way back last year:
>> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01264.html
>>
>> which is where the .note came about. I can put it all in .rodata
>> and not have it for normal ELF builds if you would like.
>
> .rodata.notes for both ELF and EFI looks to have done the trick.
> Now it is just the matter of testing it.
Why also for ELF? In ELF, these are ordinary notes, so imo
belong into .note or .note.*. As opposed to COFF/PE, where
the idea of notes doesn't exist.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-04-08 15:21 ` Jan Beulich
@ 2016-04-08 15:27 ` Konrad Rzeszutek Wilk
2016-04-08 15:29 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 15:27 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
sasha.levin, xen-devel
On Fri, Apr 08, 2016 at 09:21:37AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 03:32, <konrad@kernel.org> wrote:
> > On Thu, Apr 07, 2016 at 09:46:49AM -0600, Jan Beulich wrote:
> >> >>> On 07.04.16 at 05:14, <konrad.wilk@oracle.com> wrote:
> >> > On Fri, Apr 01, 2016 at 09:11:40AM -0600, Jan Beulich wrote:
> >> >> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> >> >> > --- a/xen/arch/x86/Makefile
> >> >> > +++ b/xen/arch/x86/Makefile
> >> >> > @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
> >> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> >> >> > $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
> >> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
> >> >> > - | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
> >> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
> >> >> > + >$(@D)/.$(@F).0.S
> >> >> > $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
> >> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
> >> >> > $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
> >> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
> >> >> > - | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
> >> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
> >> >> > + >$(@D)/.$(@F).1.S
> >> >>
> >> >> This addition should be dependent on CONFIG_XSPLICE, not the
> >> >> least because I expect it to bloat the symbol table quite a bit. And
> >> >> then - how come this is needed here, but not in the xen.efi rule?
> >> >
> >> > I added it to xen.efi rule and got:
> >> >
> >> > home/konrad/xen/xen/.xen.efi.0s.S: Assembler messages:
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f80000543
> >> > truncated to 0x80000543
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f800008b2
> >> > truncated to 0x800008b2
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f800008b4
> >> > truncated to 0x800008b4
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f800008b9
> >> > truncated to 0x800008b9
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000103f
> >> > truncated to 0x8000103f
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001043
> >> > truncated to 0x80001043
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001047
> >> > truncated to 0x80001047
> >> > /home/konrad/xen/xen/.xen.efi.0s.S:6746: Warning: value 0x100650000
> >> > truncated to 0x650000
> >> >
> >> > and so on.. Not sure why. The xen.efi file boots thought?
> >>
> >> It's the kallsyms symbol table that suffers, so the image booting
> >> fine is not really surprising. But we'd need to understand what
> >> specific data objects these warnings originate from - perhaps
> >> linker generated symbols not sitting inside sections?
> >
> > From the .xen.efi.0s.S:
> > .globl symbols_offsets
> > ALGN
> > symbols_offsets:
> > #endif
> > PTR 0x544 - SYMBOLS_ORIGIN
> > PTR 0xa01 - SYMBOLS_ORIGIN
> > PTR 0xa03 - SYMBOLS_ORIGIN
> > PTR 0xa08 - SYMBOLS_ORIGIN
> > PTR 0x118e - SYMBOLS_ORIGIN
> > PTR 0x1192 - SYMBOLS_ORIGIN
> > PTR 0x1196 - SYMBOLS_ORIGIN
> > PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
> > PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
> >
> > which corresponds to:
> > multiboot1_header_start|0000000000000544| ? | | | |
> > multiboot1_header_start|0000000000000a01| ? | | | |
> > multiboot1_header_start|0000000000000a03| ? | | | |
> > multiboot1_header_start|0000000000000a08| ? | | | |
> > multiboot1_header_start|000000000000118e| ? | | | |
> > multiboot1_header_start|0000000000001192| ? | | | |
> > multiboot1_header_start|0000000000001196| ? | | | |
> >
> > which is also found:
> > multiboot1_header_start|ffff82d080100008| t | | | |
>
> That looks like a binutils issue, associating the wrong name with
> certain symbols. Depending on what binutils version you have in
> use, this may be well be one of those I've fixed already.
[konrad@x230 ~]$ rpm -qa | grep binutils
binutils-2.25-9.fc22.x86_64
mingw64-binutils-2.25-1.fc22.x86_64
binutils-devel-2.25-9.fc22.x86_64
mingw-binutils-generic-2.25-1.fc22.x86_64
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
2016-04-08 15:27 ` Konrad Rzeszutek Wilk
@ 2016-04-08 15:29 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 15:29 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
sasha.levin, xen-devel
>>> On 08.04.16 at 17:27, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 08, 2016 at 09:21:37AM -0600, Jan Beulich wrote:
>> >>> On 08.04.16 at 03:32, <konrad@kernel.org> wrote:
>> > On Thu, Apr 07, 2016 at 09:46:49AM -0600, Jan Beulich wrote:
>> >> >>> On 07.04.16 at 05:14, <konrad.wilk@oracle.com> wrote:
>> >> > On Fri, Apr 01, 2016 at 09:11:40AM -0600, Jan Beulich wrote:
>> >> >> >>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> >> >> > --- a/xen/arch/x86/Makefile
>> >> >> > +++ b/xen/arch/x86/Makefile
>> >> >> > @@ -113,12 +113,14 @@ $(TARGET)-syms: prelink.o xen.lds
> $(BASEDIR)/common/symbols-dummy.o
>> >> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>> >> >> > $(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
>> >> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).0 \
>> >> >> > - | $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).0.S
>> >> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort \
>> >> >> > + >$(@D)/.$(@F).0.S
>> >> >> > $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
>> >> >> > $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
>> >> >> > $(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
>> >> >> > $(NM) -pa --format=sysv $(@D)/.$(@F).1 \
>> >> >> > - | $(BASEDIR)/tools/symbols --sysv --sort --warn-dup >$(@D)/.$(@F).1.S
>> >> >> > + | $(BASEDIR)/tools/symbols --all-symbols --sysv --sort --warn-dup \
>> >> >> > + >$(@D)/.$(@F).1.S
>> >> >>
>> >> >> This addition should be dependent on CONFIG_XSPLICE, not the
>> >> >> least because I expect it to bloat the symbol table quite a bit. And
>> >> >> then - how come this is needed here, but not in the xen.efi rule?
>> >> >
>> >> > I added it to xen.efi rule and got:
>> >> >
>> >> > home/konrad/xen/xen/.xen.efi.0s.S: Assembler messages:
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:21: Warning: value 0x7d2f80000543
>> >> > truncated to 0x80000543
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:22: Warning: value 0x7d2f800008b2
>> >> > truncated to 0x800008b2
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:23: Warning: value 0x7d2f800008b4
>> >> > truncated to 0x800008b4
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:24: Warning: value 0x7d2f800008b9
>> >> > truncated to 0x800008b9
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:25: Warning: value 0x7d2f8000103f
>> >> > truncated to 0x8000103f
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:26: Warning: value 0x7d2f80001043
>> >> > truncated to 0x80001043
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:27: Warning: value 0x7d2f80001047
>> >> > truncated to 0x80001047
>> >> > /home/konrad/xen/xen/.xen.efi.0s.S:6746: Warning: value 0x100650000
>> >> > truncated to 0x650000
>> >> >
>> >> > and so on.. Not sure why. The xen.efi file boots thought?
>> >>
>> >> It's the kallsyms symbol table that suffers, so the image booting
>> >> fine is not really surprising. But we'd need to understand what
>> >> specific data objects these warnings originate from - perhaps
>> >> linker generated symbols not sitting inside sections?
>> >
>> > From the .xen.efi.0s.S:
>> > .globl symbols_offsets
>> > ALGN
>> > symbols_offsets:
>> > #endif
>> > PTR 0x544 - SYMBOLS_ORIGIN
>> > PTR 0xa01 - SYMBOLS_ORIGIN
>> > PTR 0xa03 - SYMBOLS_ORIGIN
>> > PTR 0xa08 - SYMBOLS_ORIGIN
>> > PTR 0x118e - SYMBOLS_ORIGIN
>> > PTR 0x1192 - SYMBOLS_ORIGIN
>> > PTR 0x1196 - SYMBOLS_ORIGIN
>> > PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
>> > PTR 0xffff82d080100000 - SYMBOLS_ORIGIN
>> >
>> > which corresponds to:
>> > multiboot1_header_start|0000000000000544| ? | | | |
>> > multiboot1_header_start|0000000000000a01| ? | | | |
>> > multiboot1_header_start|0000000000000a03| ? | | | |
>> > multiboot1_header_start|0000000000000a08| ? | | | |
>> > multiboot1_header_start|000000000000118e| ? | | | |
>> > multiboot1_header_start|0000000000001192| ? | | | |
>> > multiboot1_header_start|0000000000001196| ? | | | |
>> >
>> > which is also found:
>> > multiboot1_header_start|ffff82d080100008| t | | | |
>
>>
>> That looks like a binutils issue, associating the wrong name with
>> certain symbols. Depending on what binutils version you have in
>> use, this may be well be one of those I've fixed already.
>
> [konrad@x230 ~]$ rpm -qa | grep binutils
> binutils-2.25-9.fc22.x86_64
> mingw64-binutils-2.25-1.fc22.x86_64
> binutils-devel-2.25-9.fc22.x86_64
> mingw-binutils-generic-2.25-1.fc22.x86_64
Yeah, that's surely too old (assuming it also doesn't have those
fixes backported) - iirc said changes didn't even make it into 2.26.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-07 2:58 ` Konrad Rzeszutek Wilk
@ 2016-04-08 15:49 ` Ross Lagerwall
2016-04-08 18:47 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Ross Lagerwall @ 2016-04-08 15:49 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, Julien Grall,
Stefano Stabellini, sasha.levin, xen-devel
On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
>>>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>>> The version of ld that first implemented --build-id is v2.18.
>>> Hence we check for that or later version - if older version
>>> found we do not build the hypervisor with the build-id
>>> (and the return code is -ENODATA for xen_build_id() call).
>>
>> This appears to be stale.
>>
>>> The EFI binary is more complicated. Having any non-recognizable
>>> sections (.note, .data.note, etc) causes the boot to hang.
>>> Moving the .note in the .data section makes it work. It is also
>>> worth noting that the PE/COFF does not have any "comment"
>>> sections to the author.
>>
>> I'm afraid this is too vague: What exactly is happening there? And
>> is this due to binutils doing something wrong, or an issue with the
>> firmware on the box you've tried? While the placement of .note is
>> not really a big deal, any unusual placement needs a source
>> comment attached explaining the whys, to prevent people down
>> the road moving the section back into the "expected" place. But
>> see also below.
>
> I will have to dig in this more. I know I tried it on TianoCore but
> that seems to have some other issues at the moment so I will
> try it out on real hardware.
>>
>>> Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
>>> symbol offsets don't changes (which means we have multiple binary
>>> ids - except that the last one is the final one). Without this change,
>>> the symbol table embedded in Xen are incorrect - some of the values it
>>> contains are offset by the size of the included build id.
>>> This obviously causes problems when resolving symbols.
>>
>> Would this also be a problem if you place the notes segment/section
>> last in the binary?
>
> I am not sure. Ross, you are the one who observed this?
Yes, that would probably solve the problem.
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-07 1:15 ` Jan Beulich
@ 2016-04-08 15:57 ` Ross Lagerwall
2016-04-08 17:39 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Ross Lagerwall @ 2016-04-08 15:57 UTC (permalink / raw)
To: Jan Beulich, mpohlack, konrad
Cc: keir, andrew.cooper3, mpohlack, xen-devel, sasha.levin
On 04/07/2016 02:15 AM, Jan Beulich wrote:
>>>> Martin Pohlack <mpohlack@amazon.com> 04/06/16 8:42 AM >>>
>> On 06.04.2016 04:42, Konrad Rzeszutek Wilk wrote:
>>> The normal use-case is to modify structures values where we have to
>>> be delicate about it and can't just replace the value. As in we
>>> may have to recompute the value.
>>
>> Agree on the default use (e.g., for XSA 91).
>
> XSA-91 was an ARM one, i.e. would still only be a theoretical example for
> the purpose of the discussion here.
>
> Jan
>
I've marked the following XSAs as potentially requiring hook functions
or shadow variables:
XSA-36
XSA-45
XSA-60
XSA-64
XSA-80
XSA-82
XSA-97
XSA-107
XSA-114
XSA-150
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 27/28] xsplice: Add support for shadow variables.
2016-04-06 2:26 ` Konrad Rzeszutek Wilk
@ 2016-04-08 15:58 ` Ross Lagerwall
0 siblings, 0 replies; 190+ messages in thread
From: Ross Lagerwall @ 2016-04-08 15:58 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Jan Beulich
Cc: Keir Fraser, andrew.cooper3, Ian Jackson, Tim Deegan, mpohlack,
sasha.levin, xen-devel
On 04/06/2016 03:26 AM, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 04, 2016 at 09:18:34AM -0600, Jan Beulich wrote:
>>>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>>> Shadow variables are a piece of infrastructure to be used by xsplice
>>> modules. They are used to attach a new piece of data to an existing
>>> structure in memory.
>>
>> An already known question again: Out of recent XSAs, how many
>> needed such? I.e. can#t we put this off for now?
>
> Yes I believe we can.
>
I didn't really intend for this to be submitted now, especially since it
can be included in the binary patch itself if needed. So I think
dropping it is OK.
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-04-04 20:01 ` Konrad Rzeszutek Wilk
2016-04-05 7:43 ` Jan Beulich
@ 2016-04-08 16:15 ` Ross Lagerwall
2016-04-08 17:47 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Ross Lagerwall @ 2016-04-08 16:15 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Jan Beulich
Cc: Keir Fraser, andrew.cooper3, mpohlack, sasha.levin, xen-devel
On 04/04/2016 09:01 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, Apr 04, 2016 at 09:00:00AM -0600, Jan Beulich wrote:
>>>>> On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>>> @@ -929,6 +932,33 @@ being loaded and requires an hypervisor build-id to match against.
>>> The old code allows much more flexibility and an additional guard,
>>> but is more complex to implement.
>>>
>>> +The second option which requires an build-id of the hypervisor
>>> +is implemented in the Xen Project hypervisor.
>>> +
>>> +Specifically each payload has two build-id ELF notes:
>>> + * The build-id of the payload itself (generated via --build-id).
>>> + * The build-id of the payload it depends on (extracted from the
>>> + the previous payload or hypervisor during build time).
>>> +
>>> +This means that the very first payload depends on the hypervisor
>>> +build-id.
>>
>> So this is mean to be a singly linked chain, not something with
>> branches and alike, allowing independent patches to be applied
>> solely based on the base build ID? Is such a restriction not going
>
> Correct.
>> to get in the way rather sooner than later?
>
> Here is what the design doc says:
>
> "
> ### xSplice interdependencies
>
> xSplice patches interdependencies are tricky.
>
> There are the ways this can be addressed:
> * A single large patch that subsumes and replaces all previous ones.
> Over the life-time of patching the hypervisor this large patch
> grows to accumulate all the code changes.
> * Hotpatch stack - where an mechanism exists that loads the hotpatches
> in the same order they were built in. We would need an build-id
> of the hypevisor to make sure the hot-patches are build against the
> correct build.
> * Payload containing the old code to check against that. That allows
> the hotpatches to be loaded indepedently (if they don't overlap) - or
> if the old code also containst previously patched code - even if they
> overlap.
>
> The disadvantage of the first large patch is that it can grow over
> time and not provide an bisection mechanism to identify faulty patches.
>
> The hot-patch stack puts stricts requirements on the order of the patches
> being loaded and requires an hypervisor build-id to match against.
>
> The old code allows much more flexibility and an additional guard,
> but is more complex to implement.
>
> The second option which requires an build-id of the hypervisor
> is implemented in the Xen Project hypervisor.
>
> "
>
> I was all for "old_code to check against" but that would incur quite a lot
> of implementation. The 'stacking' (suggested by Martin) is much easier
> to implement. I am hoping that in next major milestone the 'old code' checking
> can be implemented such that the admin has the choice to use both.
I don't think checking old code provides any real safety though. What if
the function I'm replacing is unchanged (so it passes the old code
check) but it calls some other function whose behavior has changed?
It's somewhat telling that the publicly available binary patches for
kSplice always use a linear stack of patches with dependency management
done in userspace, despite having old code checking. What kSplice use in
practice is exactly what is implemented here; a linear stack of patches
using some sort of identifier (build-id/uuid).
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-31 13:28 ` REST MAINTAINERS feedback requested Was:Re: " Konrad Rzeszutek Wilk
2016-03-31 13:50 ` Jan Beulich
@ 2016-04-08 16:33 ` Jan Beulich
2016-04-08 17:09 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 16:33 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
xen-devel, Daniel De Graaf, Keir Fraser, sasha.levin
>>> On 31.03.16 at 15:28, <konrad.wilk@oracle.com> wrote:
> On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
>> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
>> > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
>> >> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
>> >> > Since they're all cosmetic, if you take care of all of them, feel free
>> >> > to stick my ack on the result.
>> >>
>> >> Actually - no, please don't. While the patch is fine content wise
>> >> then from my perspective, I'm still lacking a convincing argument
>> >> of why this new hypercall is needed in the first place. If others
>> >> are convinced by the argumentation between (mostly, iirc) you
>> >> and Andrew, I'm not going to stand in the way, but I'm also not
>> >> going to approve of the code addition without being myself
>> >> convinced.
>> >
>> > Damm. I pushed the patch in yesterday in 'staging'!
>> >
>> > We can always revert them..
>> >
>> > "Others" being other maintainers I presume?
>>
>> Any one of the REST maintainers, yes.
>
> Changing the title to get their attention.
Yet nothing has happened, so I think the patch needs to be
reverted (at least for the time being).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 15:27 ` Jan Beulich
@ 2016-04-08 17:06 ` Konrad Rzeszutek Wilk
2016-04-08 17:44 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 17:06 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
On Fri, Apr 08, 2016 at 09:27:00AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 03:52, <konrad@kernel.org> wrote:
> > On Thu, Apr 07, 2016 at 08:18:27PM -0400, Konrad Rzeszutek Wilk wrote:
> >> >
> >> > > + $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
> >> > > + --rename-section=.data=.note.gnu.build-id -S $@.bin $@
> >> >
> >> > Since you put the notes into .rodata anyway, why name the
> >> > section .note.*? Just name it .rodata.*, avoiding to mislead
> >> > others who also think that a section's name has much of a
> >> > meaning.
> >>
> >> Way back last year:
> >> http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg01264.html
> >>
> >> which is where the .note came about. I can put it all in .rodata
> >> and not have it for normal ELF builds if you would like.
> >
> > .rodata.notes for both ELF and EFI looks to have done the trick.
> > Now it is just the matter of testing it.
>
> Why also for ELF? In ELF, these are ordinary notes, so imo
> belong into .note or .note.*. As opposed to COFF/PE, where
> the idea of notes doesn't exist.
The xen.lds.S will only have one #ifdef:
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 5eb825e..3b4fd15 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -31,6 +31,9 @@ OUTPUT_ARCH(i386:x86-64)
PHDRS
{
text PT_LOAD ;
+#if defined(BUILD_ID)
+ note PT_NOTE ;
+#endif
}
SECTIONS
{
@@ -96,8 +99,18 @@ SECTIONS
*(.lockprofile.data)
__lock_profile_end = .;
#endif
- _erodata = .;
} :text
+#if defined(BUILD_ID)
+ .rodata.note : {
+ . = ALIGN(4);
+ __note_gnu_build_id_start = .;
+ *(.note.gnu.build-id)
+ __note_gnu_build_id_end = .;
+ *(.note)
+ *(.note.*)
+ } :note :text
+#endif
+ _erodata = .;
#ifdef EFI
. = ALIGN(MB(2));
Instead of multiple ones.
But coming back to you:
"Since you put the notes into .rodata anyway, why name the section .note"
Perhaps you mean - why name the section .note.gnu_build-id ?
So that when xen.efi is linked with this build_id.o (in v5, now called notes.o in v6)
it can encapsulate __note_gnu_build_id_start and __note_gnu_build_id_end around
it. I could change for EFI builds the xen.lds.S to be:
*(.rodata.*)
+#if defined(BUILD_ID) && defined(EFI)
+/*
+ * No mechanism to put an PT_NOTE in the EFI file - so put
+ * it in .data section.
+ */
+ . = ALIGN(4);
+
+ __note_gnu_build_id_start = .;
+ *(.rodata.note.gnu.build-id)
+ __note_gnu_build_id_end = .;
+ *(.note)
+ *(.note.*)
+#endif
But then it differes from the change for !EFI (Which would be naturally
called .note.gnu.build-id).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 16:33 ` Jan Beulich
@ 2016-04-08 17:09 ` Konrad Rzeszutek Wilk
2016-04-08 17:13 ` Jan Beulich
2016-04-08 17:21 ` Ian Jackson
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 17:09 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
xen-devel, Daniel De Graaf, Keir Fraser, sasha.levin
On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
> >>> On 31.03.16 at 15:28, <konrad.wilk@oracle.com> wrote:
> > On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
> >> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
> >> > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
> >> >> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
> >> >> > Since they're all cosmetic, if you take care of all of them, feel free
> >> >> > to stick my ack on the result.
> >> >>
> >> >> Actually - no, please don't. While the patch is fine content wise
> >> >> then from my perspective, I'm still lacking a convincing argument
> >> >> of why this new hypercall is needed in the first place. If others
> >> >> are convinced by the argumentation between (mostly, iirc) you
> >> >> and Andrew, I'm not going to stand in the way, but I'm also not
> >> >> going to approve of the code addition without being myself
> >> >> convinced.
> >> >
> >> > Damm. I pushed the patch in yesterday in 'staging'!
> >> >
> >> > We can always revert them..
> >> >
> >> > "Others" being other maintainers I presume?
> >>
> >> Any one of the REST maintainers, yes.
> >
> > Changing the title to get their attention.
>
> Yet nothing has happened, so I think the patch needs to be
> reverted (at least for the time being).
Wait what?!
The natural consensus mechanism we use is lazy. If nobody
objects then it is Acked.
Anyhow pinged Ian Jackson on IRC.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:09 ` Konrad Rzeszutek Wilk
@ 2016-04-08 17:13 ` Jan Beulich
2016-04-08 17:21 ` Wei Liu
2016-04-08 17:21 ` Ian Jackson
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 17:13 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
xen-devel, Daniel De Graaf, Keir Fraser, sasha.levin
>>> On 08.04.16 at 19:09, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
>> >>> On 31.03.16 at 15:28, <konrad.wilk@oracle.com> wrote:
>> > On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
>> >> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
>> >> > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
>> >> >> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
>> >> >> > Since they're all cosmetic, if you take care of all of them, feel free
>> >> >> > to stick my ack on the result.
>> >> >>
>> >> >> Actually - no, please don't. While the patch is fine content wise
>> >> >> then from my perspective, I'm still lacking a convincing argument
>> >> >> of why this new hypercall is needed in the first place. If others
>> >> >> are convinced by the argumentation between (mostly, iirc) you
>> >> >> and Andrew, I'm not going to stand in the way, but I'm also not
>> >> >> going to approve of the code addition without being myself
>> >> >> convinced.
>> >> >
>> >> > Damm. I pushed the patch in yesterday in 'staging'!
>> >> >
>> >> > We can always revert them..
>> >> >
>> >> > "Others" being other maintainers I presume?
>> >>
>> >> Any one of the REST maintainers, yes.
>> >
>> > Changing the title to get their attention.
>>
>> Yet nothing has happened, so I think the patch needs to be
>> reverted (at least for the time being).
>
> Wait what?!
>
> The natural consensus mechanism we use is lazy. If nobody
> objects then it is Acked.
Since when can patches go in without any ack(s) of relevant
maintainers?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:09 ` Konrad Rzeszutek Wilk
2016-04-08 17:13 ` Jan Beulich
@ 2016-04-08 17:21 ` Ian Jackson
2016-04-08 17:41 ` Andrew Cooper
1 sibling, 1 reply; 190+ messages in thread
From: Ian Jackson @ 2016-04-08 17:21 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
xen-devel, Daniel De Graaf, Keir Fraser, sasha.levin
Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
> > Yet nothing has happened, so I think the patch needs to be
> > reverted (at least for the time being).
>
> Wait what?!
I'm sorry that I didn't understand that we were being asked for a
second opinion about this disagreement. I'm afriad that the original
email wasn't really comprehensible to me as a summary of the
disagreement.
Would someone please summarise ? Especially, since Jan is AFAICT
saying that this new hypercall is not needed, it would be helpful to
know why those who think it is needed want it.
In the meantime I think it would be best to avoid churn by leaving the
patch in tree for now. I promise that I won't let those "facts on the
ground" influence my views about whether this hypercall is needed.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:13 ` Jan Beulich
@ 2016-04-08 17:21 ` Wei Liu
2016-04-08 17:23 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Wei Liu @ 2016-04-08 17:21 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Andrew Cooper, Stefano Stabellini, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
xen-devel, Daniel De Graaf, Keir Fraser, sasha.levin
On Fri, Apr 08, 2016 at 11:13:08AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 19:09, <konrad.wilk@oracle.com> wrote:
> > On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
> >> >>> On 31.03.16 at 15:28, <konrad.wilk@oracle.com> wrote:
> >> > On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
> >> >> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
> >> >> > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
> >> >> >> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
> >> >> >> > Since they're all cosmetic, if you take care of all of them, feel free
> >> >> >> > to stick my ack on the result.
> >> >> >>
> >> >> >> Actually - no, please don't. While the patch is fine content wise
> >> >> >> then from my perspective, I'm still lacking a convincing argument
> >> >> >> of why this new hypercall is needed in the first place. If others
> >> >> >> are convinced by the argumentation between (mostly, iirc) you
> >> >> >> and Andrew, I'm not going to stand in the way, but I'm also not
> >> >> >> going to approve of the code addition without being myself
> >> >> >> convinced.
> >> >> >
> >> >> > Damm. I pushed the patch in yesterday in 'staging'!
> >> >> >
> >> >> > We can always revert them..
> >> >> >
> >> >> > "Others" being other maintainers I presume?
> >> >>
> >> >> Any one of the REST maintainers, yes.
> >> >
> >> > Changing the title to get their attention.
> >>
> >> Yet nothing has happened, so I think the patch needs to be
> >> reverted (at least for the time being).
> >
> > Wait what?!
> >
> > The natural consensus mechanism we use is lazy. If nobody
> > objects then it is Acked.
>
> Since when can patches go in without any ack(s) of relevant
> maintainers?
>
Urgh, at the risk of pointing out the obvious -- it does seem to have
your ack...
Wei.
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:21 ` Wei Liu
@ 2016-04-08 17:23 ` Konrad Rzeszutek Wilk
2016-04-08 17:27 ` Wei Liu
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 17:23 UTC (permalink / raw)
To: Wei Liu
Cc: Keir Fraser, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
Jan Beulich, xen-devel, Daniel De Graaf, sasha.levin
On Fri, Apr 08, 2016 at 06:21:27PM +0100, Wei Liu wrote:
> On Fri, Apr 08, 2016 at 11:13:08AM -0600, Jan Beulich wrote:
> > >>> On 08.04.16 at 19:09, <konrad.wilk@oracle.com> wrote:
> > > On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
> > >> >>> On 31.03.16 at 15:28, <konrad.wilk@oracle.com> wrote:
> > >> > On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
> > >> >> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
> > >> >> > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
> > >> >> >> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
> > >> >> >> > Since they're all cosmetic, if you take care of all of them, feel free
> > >> >> >> > to stick my ack on the result.
> > >> >> >>
> > >> >> >> Actually - no, please don't. While the patch is fine content wise
> > >> >> >> then from my perspective, I'm still lacking a convincing argument
> > >> >> >> of why this new hypercall is needed in the first place. If others
> > >> >> >> are convinced by the argumentation between (mostly, iirc) you
> > >> >> >> and Andrew, I'm not going to stand in the way, but I'm also not
> > >> >> >> going to approve of the code addition without being myself
> > >> >> >> convinced.
> > >> >> >
> > >> >> > Damm. I pushed the patch in yesterday in 'staging'!
> > >> >> >
> > >> >> > We can always revert them..
> > >> >> >
> > >> >> > "Others" being other maintainers I presume?
> > >> >>
> > >> >> Any one of the REST maintainers, yes.
> > >> >
> > >> > Changing the title to get their attention.
> > >>
> > >> Yet nothing has happened, so I think the patch needs to be
> > >> reverted (at least for the time being).
> > >
> > > Wait what?!
> > >
> > > The natural consensus mechanism we use is lazy. If nobody
> > > objects then it is Acked.
> >
> > Since when can patches go in without any ack(s) of relevant
> > maintainers?
> >
>
> Urgh, at the risk of pointing out the obvious -- it does seem to have
> your ack...
Which was given at night before Jan retracted it in the morning.
This feels like one of those Catch-22 :-)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-03-31 6:30 ` Jan Beulich
2016-03-31 11:43 ` Konrad Rzeszutek Wilk
@ 2016-04-08 17:24 ` George Dunlap
2016-04-08 17:34 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: George Dunlap @ 2016-04-08 17:24 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
Julien Grall, mpohlack, Ross Lagerwall, Stefano Stabellini,
xen-devel, sasha.levin, Daniel De Graaf, Keir Fraser
On Thu, Mar 31, 2016 at 7:30 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
>> Since they're all cosmetic, if you take care of all of them, feel free
>> to stick my ack on the result.
>
> Actually - no, please don't. While the patch is fine content wise
> then from my perspective, I'm still lacking a convincing argument
> of why this new hypercall is needed in the first place. If others
> are convinced by the argumentation between (mostly, iirc) you
> and Andrew, I'm not going to stand in the way, but I'm also not
> going to approve of the code addition without being myself
> convinced.
I don't see in this patch a justification for why Konrad (and/or
Andrew) think the new version is needed, nor do I see in this
particular thread why Jan thinks it's not necessary, so I don't really
know what's going on. I'm happy to give my opinion of someone wants
to catch me up.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:23 ` Konrad Rzeszutek Wilk
@ 2016-04-08 17:27 ` Wei Liu
0 siblings, 0 replies; 190+ messages in thread
From: Wei Liu @ 2016-04-08 17:27 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, ross.lagerwall, Julien Grall, Stefano Stabellini,
Jan Beulich, xen-devel, Daniel De Graaf, Keir Fraser,
sasha.levin
On Fri, Apr 08, 2016 at 01:23:23PM -0400, Konrad Rzeszutek Wilk wrote:
> On Fri, Apr 08, 2016 at 06:21:27PM +0100, Wei Liu wrote:
> > On Fri, Apr 08, 2016 at 11:13:08AM -0600, Jan Beulich wrote:
> > > >>> On 08.04.16 at 19:09, <konrad.wilk@oracle.com> wrote:
> > > > On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
> > > >> >>> On 31.03.16 at 15:28, <konrad.wilk@oracle.com> wrote:
> > > >> > On Thu, Mar 31, 2016 at 06:07:58AM -0600, Jan Beulich wrote:
> > > >> >> >>> On 31.03.16 at 13:43, <konrad@kernel.org> wrote:
> > > >> >> > On Thu, Mar 31, 2016 at 12:30:09AM -0600, Jan Beulich wrote:
> > > >> >> >> >>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
> > > >> >> >> > Since they're all cosmetic, if you take care of all of them, feel free
> > > >> >> >> > to stick my ack on the result.
> > > >> >> >>
> > > >> >> >> Actually - no, please don't. While the patch is fine content wise
> > > >> >> >> then from my perspective, I'm still lacking a convincing argument
> > > >> >> >> of why this new hypercall is needed in the first place. If others
> > > >> >> >> are convinced by the argumentation between (mostly, iirc) you
> > > >> >> >> and Andrew, I'm not going to stand in the way, but I'm also not
> > > >> >> >> going to approve of the code addition without being myself
> > > >> >> >> convinced.
> > > >> >> >
> > > >> >> > Damm. I pushed the patch in yesterday in 'staging'!
> > > >> >> >
> > > >> >> > We can always revert them..
> > > >> >> >
> > > >> >> > "Others" being other maintainers I presume?
> > > >> >>
> > > >> >> Any one of the REST maintainers, yes.
> > > >> >
> > > >> > Changing the title to get their attention.
> > > >>
> > > >> Yet nothing has happened, so I think the patch needs to be
> > > >> reverted (at least for the time being).
> > > >
> > > > Wait what?!
> > > >
> > > > The natural consensus mechanism we use is lazy. If nobody
> > > > objects then it is Acked.
> > >
> > > Since when can patches go in without any ack(s) of relevant
> > > maintainers?
> > >
> >
> > Urgh, at the risk of pointing out the obvious -- it does seem to have
> > your ack...
>
> Which was given at night before Jan retracted it in the morning.
>
> This feels like one of those Catch-22 :-)
Ah, OK then, so Jan has a point. This needs to be properly discussed and
refereed.
Wei.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:24 ` George Dunlap
@ 2016-04-08 17:34 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 17:34 UTC (permalink / raw)
To: George Dunlap
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, Ross Lagerwall, JulienGrall, Stefano Stabellini,
xen-devel, Daniel De Graaf, Keir Fraser, sasha.levin
>>> On 08.04.16 at 19:24, <george.dunlap@citrix.com> wrote:
> On Thu, Mar 31, 2016 at 7:30 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 30.03.16 at 17:43, <JBeulich@suse.com> wrote:
>>> Since they're all cosmetic, if you take care of all of them, feel free
>>> to stick my ack on the result.
>>
>> Actually - no, please don't. While the patch is fine content wise
>> then from my perspective, I'm still lacking a convincing argument
>> of why this new hypercall is needed in the first place. If others
>> are convinced by the argumentation between (mostly, iirc) you
>> and Andrew, I'm not going to stand in the way, but I'm also not
>> going to approve of the code addition without being myself
>> convinced.
>
> I don't see in this patch a justification for why Konrad (and/or
> Andrew) think the new version is needed, nor do I see in this
> particular thread why Jan thinks it's not necessary, so I don't really
> know what's going on. I'm happy to give my opinion of someone wants
> to catch me up.
Well, the hypercall is redundant with an existing one, and the
semantics needed for adding the build-id sub-op don't really
require this new hypercall either. So it not adding new
functionality, I think it simply needs to be demonstrated that
the new variant is needed, not that it's not needed.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-08 15:57 ` Ross Lagerwall
@ 2016-04-08 17:39 ` Jan Beulich
2016-04-11 8:23 ` Ross Lagerwall
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 17:39 UTC (permalink / raw)
To: Ross Lagerwall
Cc: keir, andrew.cooper3, mpohlack, mpohlack, sasha.levin, xen-devel
>>> On 08.04.16 at 17:57, <ross.lagerwall@citrix.com> wrote:
> On 04/07/2016 02:15 AM, Jan Beulich wrote:
>>>>> Martin Pohlack <mpohlack@amazon.com> 04/06/16 8:42 AM >>>
>>> On 06.04.2016 04:42, Konrad Rzeszutek Wilk wrote:
>>>> The normal use-case is to modify structures values where we have to
>>>> be delicate about it and can't just replace the value. As in we
>>>> may have to recompute the value.
>>>
>>> Agree on the default use (e.g., for XSA 91).
>>
>> XSA-91 was an ARM one, i.e. would still only be a theoretical example for
>> the purpose of the discussion here.
>
> I've marked the following XSAs as potentially requiring hook functions
> or shadow variables:
>
> XSA-36
> XSA-45
> XSA-60
> XSA-64
> XSA-80
> XSA-82
> XSA-97
> XSA-107
> XSA-114
> XSA-150
Such a raw list doesn't tell me anything, I'm afraid. Can you please
explain for at least one of them why they do need hooks (and not
just potentially)?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:21 ` Ian Jackson
@ 2016-04-08 17:41 ` Andrew Cooper
2016-04-08 17:54 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Andrew Cooper @ 2016-04-08 17:41 UTC (permalink / raw)
To: Ian Jackson, Konrad Rzeszutek Wilk
Cc: Wei Liu, Stefano Stabellini, mpohlack, ross.lagerwall,
Julien Grall, Stefano Stabellini, Jan Beulich, xen-devel,
Daniel De Graaf, Keir Fraser, sasha.levin
On 08/04/16 18:21, Ian Jackson wrote:
> Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
>> On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
>>> Yet nothing has happened, so I think the patch needs to be
>>> reverted (at least for the time being).
>> Wait what?!
> I'm sorry that I didn't understand that we were being asked for a
> second opinion about this disagreement. I'm afriad that the original
> email wasn't really comprehensible to me as a summary of the
> disagreement.
>
> Would someone please summarise ? Especially, since Jan is AFAICT
> saying that this new hypercall is not needed, it would be helpful to
> know why those who think it is needed want it.
The new hypercall is very definitely needed, which is why I requested it
during earlier revisions of the xsplice series.
The interface for the old version was sufficiently useless that build_id
can't be added to it. (Specifically, there is no ability to return
varialble length data). Also, by its design, it has some
unreasonably-short limits on extraversion and changesetinfo, both of
which could do with being longer for distros trying to encode "delta
from upstream" information.
The new hypercall has a ration interface where you don't blindly trust
that the caller passed you a pointer to a suitably-sized structure.
I am very much +10 keep to the patch.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 17:06 ` Konrad Rzeszutek Wilk
@ 2016-04-08 17:44 ` Jan Beulich
2016-04-08 19:23 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 17:44 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
>>> On 08.04.16 at 19:06, <konrad.wilk@oracle.com> wrote:
> "Since you put the notes into .rodata anyway, why name the section .note"
>
> Perhaps you mean - why name the section .note.gnu_build-id ?
Sure - .note or .note.*.
> So that when xen.efi is linked with this build_id.o (in v5, now called
> notes.o in v6)
> it can encapsulate __note_gnu_build_id_start and __note_gnu_build_id_end
> around
> it. I could change for EFI builds the xen.lds.S to be:
>
> *(.rodata.*)
> +#if defined(BUILD_ID) && defined(EFI)
> +/*
> + * No mechanism to put an PT_NOTE in the EFI file - so put
> + * it in .data section.
> + */
> + . = ALIGN(4);
> +
> + __note_gnu_build_id_start = .;
> + *(.rodata.note.gnu.build-id)
> + __note_gnu_build_id_end = .;
> + *(.note)
> + *(.note.*)
> +#endif
>
> But then it differes from the change for !EFI (Which would be naturally
> called .note.gnu.build-id).
But that looks to be the right approach, accounting for the
differences between ELF and COFF/PE. And btw., unless you did
changes elsewhere I don't think this inclusion of .note and .note.*
here would have the effect you want it to have.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 23/28] xsplice: Stacking build-id dependency checking.
2016-04-08 16:15 ` Ross Lagerwall
@ 2016-04-08 17:47 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 17:47 UTC (permalink / raw)
To: Ross Lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, sasha.levin, xen-devel
>>> On 08.04.16 at 18:15, <ross.lagerwall@citrix.com> wrote:
> On 04/04/2016 09:01 PM, Konrad Rzeszutek Wilk wrote:
>> I was all for "old_code to check against" but that would incur quite a lot
>> of implementation. The 'stacking' (suggested by Martin) is much easier
>> to implement. I am hoping that in next major milestone the 'old code' checking
>> can be implemented such that the admin has the choice to use both.
>
> I don't think checking old code provides any real safety though. What if
> the function I'm replacing is unchanged (so it passes the old code
> check) but it calls some other function whose behavior has changed?
That's identical to an entirely bad patch imo.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:41 ` Andrew Cooper
@ 2016-04-08 17:54 ` Jan Beulich
2016-04-11 10:50 ` Ian Jackson
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 17:54 UTC (permalink / raw)
To: Andrew Cooper
Cc: Wei Liu, StefanoStabellini, Ian Jackson, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
>>> On 08.04.16 at 19:41, <andrew.cooper3@citrix.com> wrote:
> On 08/04/16 18:21, Ian Jackson wrote:
>> Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested
> Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall
> mirroring XENVER_ but sane."):
>>> On Fri, Apr 08, 2016 at 10:33:33AM -0600, Jan Beulich wrote:
>>>> Yet nothing has happened, so I think the patch needs to be
>>>> reverted (at least for the time being).
>>> Wait what?!
>> I'm sorry that I didn't understand that we were being asked for a
>> second opinion about this disagreement. I'm afriad that the original
>> email wasn't really comprehensible to me as a summary of the
>> disagreement.
>>
>> Would someone please summarise ? Especially, since Jan is AFAICT
>> saying that this new hypercall is not needed, it would be helpful to
>> know why those who think it is needed want it.
>
> The new hypercall is very definitely needed, which is why I requested it
> during earlier revisions of the xsplice series.
>
> The interface for the old version was sufficiently useless that build_id
> can't be added to it. (Specifically, there is no ability to return
> varialble length data).
This is simply not true: The hypercall being passed a void handle,
everything can be arranged for without introducing a new
hypercall.
> Also, by its design, it has some
> unreasonably-short limits on extraversion and changesetinfo, both of
> which could do with being longer for distros trying to encode "delta
> from upstream" information.
>
> The new hypercall has a ration interface where you don't blindly trust
> that the caller passed you a pointer to a suitably-sized structure.
While the new one is indeed slightly neater, that's not sufficient
for such redundancy imo. That's the whole reason for withdrawing
my ack _without_ making it an explicit NAK.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 15:49 ` Ross Lagerwall
@ 2016-04-08 18:47 ` Konrad Rzeszutek Wilk
2016-04-08 18:54 ` Andrew Cooper
2016-04-08 19:54 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 18:47 UTC (permalink / raw)
To: Ross Lagerwall
Cc: Keir Fraser, andrew.cooper3, mpohlack, Julien Grall,
Stefano Stabellini, Jan Beulich, sasha.levin, xen-devel
On Fri, Apr 08, 2016 at 04:49:00PM +0100, Ross Lagerwall wrote:
> On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote:
> >On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
> >>>>>On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
> >>>The version of ld that first implemented --build-id is v2.18.
> >>>Hence we check for that or later version - if older version
> >>>found we do not build the hypervisor with the build-id
> >>>(and the return code is -ENODATA for xen_build_id() call).
> >>
> >>This appears to be stale.
> >>
> >>>The EFI binary is more complicated. Having any non-recognizable
> >>>sections (.note, .data.note, etc) causes the boot to hang.
> >>>Moving the .note in the .data section makes it work. It is also
> >>>worth noting that the PE/COFF does not have any "comment"
> >>>sections to the author.
> >>
> >>I'm afraid this is too vague: What exactly is happening there? And
> >>is this due to binutils doing something wrong, or an issue with the
> >>firmware on the box you've tried? While the placement of .note is
> >>not really a big deal, any unusual placement needs a source
> >>comment attached explaining the whys, to prevent people down
> >>the road moving the section back into the "expected" place. But
> >>see also below.
> >
> >I will have to dig in this more. I know I tried it on TianoCore but
> >that seems to have some other issues at the moment so I will
> >try it out on real hardware.
> >>
> >>>Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
> >>>symbol offsets don't changes (which means we have multiple binary
> >>>ids - except that the last one is the final one). Without this change,
> >>>the symbol table embedded in Xen are incorrect - some of the values it
> >>>contains are offset by the size of the included build id.
> >>>This obviously causes problems when resolving symbols.
> >>
> >>Would this also be a problem if you place the notes segment/section
> >>last in the binary?
> >
> >I am not sure. Ross, you are the one who observed this?
>
> Yes, that would probably solve the problem.
Sadly no. I stuck the .note right before .bss section and I got:
relink.o: In function `symbols_expand_symbol':
/home/konrad/xen/xen/common/symbols.c:47: undefined reference to `symbols_names'
/home/konrad/xen/xen/common/symbols.c:47:(.text+0x30f40): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `symbols_names'
/home/konrad/xen/xen/common/symbols.c:58: undefined reference to `symbols_token_table'
/home/konrad/xen/xen/common/symbols.c:58:(.text+0x30f6e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `symbols_token_table'
>
> --
> Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 18:47 ` Konrad Rzeszutek Wilk
@ 2016-04-08 18:54 ` Andrew Cooper
2016-04-08 19:54 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Andrew Cooper @ 2016-04-08 18:54 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, Ross Lagerwall
Cc: Keir Fraser, mpohlack, Julien Grall, Stefano Stabellini,
Jan Beulich, xen-devel, sasha.levin
>>>>> Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
>>>>> symbol offsets don't changes (which means we have multiple binary
>>>>> ids - except that the last one is the final one). Without this change,
>>>>> the symbol table embedded in Xen are incorrect - some of the values it
>>>>> contains are offset by the size of the included build id.
>>>>> This obviously causes problems when resolving symbols.
>>>> Would this also be a problem if you place the notes segment/section
>>>> last in the binary?
>>> I am not sure. Ross, you are the one who observed this?
>> Yes, that would probably solve the problem.
> Sadly no. I stuck the .note right before .bss section and I got:
>
> relink.o: In function `symbols_expand_symbol':
> /home/konrad/xen/xen/common/symbols.c:47: undefined reference to `symbols_names'
> /home/konrad/xen/xen/common/symbols.c:47:(.text+0x30f40): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `symbols_names'
> /home/konrad/xen/xen/common/symbols.c:58: undefined reference to `symbols_token_table'
> /home/konrad/xen/xen/common/symbols.c:58:(.text+0x30f6e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `symbols_token_table'
Ah yes - our symbol table generation also plays the same trick...
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 17:44 ` Jan Beulich
@ 2016-04-08 19:23 ` Konrad Rzeszutek Wilk
2016-04-08 19:39 ` Konrad Rzeszutek Wilk
2016-04-08 20:14 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 19:23 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 19:06, <konrad.wilk@oracle.com> wrote:
> > "Since you put the notes into .rodata anyway, why name the section .note"
> >
> > Perhaps you mean - why name the section .note.gnu_build-id ?
>
> Sure - .note or .note.*.
>
> > So that when xen.efi is linked with this build_id.o (in v5, now called
> > notes.o in v6)
> > it can encapsulate __note_gnu_build_id_start and __note_gnu_build_id_end
> > around
> > it. I could change for EFI builds the xen.lds.S to be:
> >
> > *(.rodata.*)
> > +#if defined(BUILD_ID) && defined(EFI)
> > +/*
> > + * No mechanism to put an PT_NOTE in the EFI file - so put
> > + * it in .data section.
> > + */
> > + . = ALIGN(4);
> > +
> > + __note_gnu_build_id_start = .;
> > + *(.rodata.note.gnu.build-id)
> > + __note_gnu_build_id_end = .;
> > + *(.note)
> > + *(.note.*)
> > +#endif
> >
> > But then it differes from the change for !EFI (Which would be naturally
> > called .note.gnu.build-id).
>
> But that looks to be the right approach, accounting for the
> differences between ELF and COFF/PE. And btw., unless you did
> changes elsewhere I don't think this inclusion of .note and .note.*
> here would have the effect you want it to have.
We don't really have any other .note, which is good.
I tried to feed the linker a notes.o file with .rodata.note
and have the efi.lds.S ingest it:
__note_gnu_build_id_start = .;
*(.rodata.note)
__note_gnu_build_id_end = .;
But it ignored it (no data, and __note_gnu_build_id_start == __note_gnu_build_id_end)
If I left the name as .note or *(.note.*) it was OK.
Here is what I came up with. Going to test it shortly
From ff61823cef437fb8a69903b3ff14b0d06ccf743b Mon Sep 17 00:00:00 2001
From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed, 6 Apr 2016 22:05:06 -0400
Subject: [PATCH] build_id: Provide ld-embedded build-ids
This patch enables the Elf to be built with the build-id
and provide in the Xen hypervisor the code to extract it.
The man-page for ld --build-id says it is:
"Request the creation of a ".note.gnu.build-id" ELF note
section or a ".build-id" COFF section. The contents of the
note are unique bits identifying this linked file. style can be
"uuid" to use 128 random bits, "sha1" to use a 160-bit SHA1 hash
on the normative parts of the output contents, ..."
One can also retrieve the value of the build-id by doing
'readelf -n xen-syms'.
For EFI builds we re-use the same build-id that the xen-syms
was built with.
The version of ld that first implemented --build-id is v2.18.
We check for to see if the linker supports the --build-id
parameter and if so use it.
For x86 we have two binaries - the xen-syms and the xen - an
smaller version with lots of sections removed. To make it possible
for readelf -n xen we also modify mkelf32 and xen.lds.S to include
the PT_NOTE ELF section.
The EFI binary is more complicated. We only build one type of
binary and expanding the amount of sections the EFI binary has to
include an .note one is pointless - as there is no concept of
PT_NOTE. The best we can do is move the .note in the .rodata section.
Further development wise should move it to .buildid section
so that DataDirectory debug data nor CodeView can view it.
(The author has no clue what those are).
Note that in earlier patches the linker script had:
__note_gnu_build_id_start = .;
*(.rodata.note.gnu.build-id)
__note_gnu_build_id_end = .;
*(.note)
*(.note.*)
Which meant you could have different ELF notes _outside_ the
__note_gnu_build_id_end. However for EFI builds we take the whole
.note* section and jam it in the EFI to be between
__note_gnu_build_id_start and __note_gnu_build_id_end.
To not make EFI be the odd-man out all the buids will ingest
the same type. This means if we had extra ELF Notes we have to
careful that the very first one is the --build-id (otherwise
xen_build_init will fail).
Note that we do call --binary-id=sha1 on all linker invocations.
We have to do to enforce that the symbol offsets don't changes
(the side effect is that we we would have multiple binary ids -
except that the last one is the final one).
Without this working the symbol table embedded in Xen ends
up incorrect - some of the values it contains would be offset by the
size of the included build id.
This obviously causes problems when resolving symbols.
Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Martin Pohlack <mpohlack@amazon.de>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
---
Cc: Stefano Stabellini <stefano.stabellini@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
v1: Rebase it on Martin's initial patch
v2: Move it to XENVER hypercall
v3: Fix EFI building (Ross's fix)
Don't use the third argument for length.
Use new structure for XENVER_build_id with variable buf.
Include Ross's fix.
Include detection of bin-utils for build-id support, add
probing for size, and return -EPERM for XSM denied calls.
Build xen_build_id under ARM, required adding ELFSIZE in proper file.
Rebase on top XSM version class.
v4:
Include the build-id .note in the xen ELF binary.
s/build_id/build_id_linker/
For EFI build, moved the --build-id values in .data section
Rebase on staging.
Split patch in two. Always do --build-id call. Include the .note in
.rodata. USe const void * and ssize_t
Use -S to make build_id.o and objcopy differently (Andrew suggested)
v5: Put back the #ifdef LOCK_PROFILE on ARM. (Bad change). Move the _erodata
around. s/ssize_t/unsigned int/
v6: Redid it per Jan's review.
v7: Move build-id note in .rodata.note for EFI builds only.
Move build-id note in .rodata for EFI builds only. Retain
it in .note. Change name of object file used by EFI builds to notes.o
---
---
Config.mk | 11 ++++
xen/arch/arm/Makefile | 2 +-
xen/arch/arm/xen.lds.S | 16 +++++-
xen/arch/x86/Makefile | 30 +++++++++--
xen/arch/x86/boot/mkelf32.c | 129 +++++++++++++++++++++++++++++++++++++++-----
xen/arch/x86/efi/Makefile | 2 +-
xen/arch/x86/xen.lds.S | 24 +++++++++
xen/common/version.c | 51 ++++++++++++++++++
xen/include/xen/version.h | 1 +
9 files changed, 243 insertions(+), 23 deletions(-)
diff --git a/Config.mk b/Config.mk
index 79eb2bd..db70638 100644
--- a/Config.mk
+++ b/Config.mk
@@ -126,6 +126,17 @@ endef
check-$(gcc) = $(call cc-ver-check,CC,0x040100,"Xen requires at least gcc-4.1")
$(eval $(check-y))
+ld-ver-build-id = $(shell $(1) --build-id 2>&1 | \
+ grep -q unrecognized && echo n || echo y)
+
+export XEN_HAS_BUILD_ID ?= n
+ifeq ($(call ld-ver-build-id,$(LD)),n)
+build_id_linker :=
+else
+CFLAGS += -DBUILD_ID
+build_id_linker := --build-id=sha1
+endif
+
# as-insn: Check whether assembler supports an instruction.
# Usage: cflags-y += $(call as-insn "insn",option-yes,option-no)
as-insn = $(if $(shell echo 'void _(void) { asm volatile ( $(2) ); }' \
diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
index bbd190e..d3489bd 100644
--- a/xen/arch/arm/Makefile
+++ b/xen/arch/arm/Makefile
@@ -92,7 +92,7 @@ $(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols --sysv --sort >$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/arm/xen.lds.S b/xen/arch/arm/xen.lds.S
index 9909595..a5e635d 100644
--- a/xen/arch/arm/xen.lds.S
+++ b/xen/arch/arm/xen.lds.S
@@ -22,6 +22,9 @@ OUTPUT_ARCH(FORMAT)
PHDRS
{
text PT_LOAD /* XXX should be AT ( XEN_PHYS_START ) */ ;
+#if defined(BUILD_ID)
+ note PT_NOTE ;
+#endif
}
SECTIONS
{
@@ -57,10 +60,19 @@ SECTIONS
*(.lockprofile.data)
__lock_profile_end = .;
#endif
-
- _erodata = .; /* End of read-only data */
} :text
+#if defined(BUILD_ID)
+ . = ALIGN(4);
+ .note : {
+ __note_gnu_build_id_start = .;
+ *(.note)
+ *(.note.*)
+ __note_gnu_build_id_end = .;
+ } :note :text
+#endif
+ _erodata = .; /* End of read-only data */
+
.data : { /* Data */
. = ALIGN(PAGE_SIZE);
*(.data.page_aligned)
diff --git a/xen/arch/x86/Makefile b/xen/arch/x86/Makefile
index 08a7b68..727e012 100644
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -72,6 +72,12 @@ efi-y := $(shell if [ ! -r $(BASEDIR)/include/xen/compile.h -o \
-O $(BASEDIR)/include/xen/compile.h ]; then \
echo '$(TARGET).efi'; fi)
+ifneq ($(build_id_linker),)
+num_phdrs = --notes
+else
+num_phdrs =
+endif
+
ifdef CONFIG_XSPLICE
all_symbols = --all-symbols
else
@@ -80,7 +86,8 @@ endif
$(TARGET): $(TARGET)-syms $(efi-y) boot/mkelf32
./boot/mkelf32 $(TARGET)-syms $(TARGET) 0x100000 \
- `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'`
+ `$(NM) -nr $(TARGET)-syms | head -n 1 | sed -e 's/^\([^ ]*\).*/0x\1/'` \
+ $(num_phdrs)
.PHONY: test
test:
@@ -114,22 +121,28 @@ $(BASEDIR)/common/symbols-dummy.o:
$(MAKE) -f $(BASEDIR)/Rules.mk -C $(BASEDIR)/common symbols-dummy.o
$(TARGET)-syms: prelink.o xen.lds $(BASEDIR)/common/symbols-dummy.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(BASEDIR)/common/symbols-dummy.o -o $(@D)/.$(@F).0
$(NM) -pa --format=sysv $(@D)/.$(@F).0 \
| $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort \
>$(@D)/.$(@F).0.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).0.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).0.o -o $(@D)/.$(@F).1
$(NM) -pa --format=sysv $(@D)/.$(@F).1 \
| $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort --warn-dup \
>$(@D)/.$(@F).1.S
$(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1.o
- $(LD) $(LDFLAGS) -T xen.lds -N prelink.o \
+ $(LD) $(LDFLAGS) -T xen.lds -N prelink.o $(build_id_linker) \
$(@D)/.$(@F).1.o -o $@
rm -f $(@D)/.$(@F).[0-9]*
+notes.o: $(TARGET)-syms
+ $(OBJCOPY) -O binary --only-section=.note $(BASEDIR)/xen-syms $@.bin
+ $(OBJCOPY) -I binary -O elf64-x86-64 -B i386:x86-64 \
+ --rename-section=.data=.note -S $@.bin $@
+ rm -f $@.bin
+
EFI_LDFLAGS = $(patsubst -m%,-mi386pep,$(LDFLAGS)) --subsystem=10
EFI_LDFLAGS += --image-base=$(1) --stack=0,0 --heap=0,0 --strip-debug
EFI_LDFLAGS += --section-alignment=0x200000 --file-alignment=0x20
@@ -142,6 +155,13 @@ $(TARGET).efi: VIRT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A VIR
$(TARGET).efi: ALT_BASE = 0x$(shell $(NM) efi/relocs-dummy.o | sed -n 's, A ALT_START$$,,p')
# Don't use $(wildcard ...) here - at least make 3.80 expands this too early!
$(TARGET).efi: guard = $(if $(shell echo efi/dis* | grep disabled),:)
+ifneq ($(build_id_linker),)
+$(TARGET).efi: notes.o
+notes_file := notes.o
+else
+notes_file :=
+endif
+
$(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbols-dummy.o efi/mkreloc
$(foreach base, $(VIRT_BASE) $(ALT_BASE), \
$(guard) $(LD) $(call EFI_LDFLAGS,$(base)) -T efi.lds -N $< efi/relocs-dummy.o \
@@ -158,7 +178,7 @@ $(TARGET).efi: prelink-efi.o efi.lds efi/relocs-dummy.o $(BASEDIR)/common/symbol
| $(guard) $(BASEDIR)/tools/symbols $(all_symbols) --sysv --sort >$(@D)/.$(@F).1s.S
$(guard) $(MAKE) -f $(BASEDIR)/Rules.mk $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o
$(guard) $(LD) $(call EFI_LDFLAGS,$(VIRT_BASE)) -T efi.lds -N $< \
- $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o -o $@
+ $(@D)/.$(@F).1r.o $(@D)/.$(@F).1s.o $(notes_file) -o $@
if $(guard) false; then rm -f $@; echo 'EFI support disabled'; fi
rm -f $(@D)/.$(@F).[0-9]*
diff --git a/xen/arch/x86/boot/mkelf32.c b/xen/arch/x86/boot/mkelf32.c
index 993a7ee..fce1716 100644
--- a/xen/arch/x86/boot/mkelf32.c
+++ b/xen/arch/x86/boot/mkelf32.c
@@ -45,9 +45,9 @@ static Elf32_Ehdr out_ehdr = {
0, /* e_flags */
sizeof(Elf32_Ehdr), /* e_ehsize */
sizeof(Elf32_Phdr), /* e_phentsize */
- 1, /* e_phnum */
+ 1, /* modify based on num_phdrs */ /* e_phnum */
sizeof(Elf32_Shdr), /* e_shentsize */
- 3, /* e_shnum */
+ 3, /* modify based on num_phdrs */ /* e_shnum */
2 /* e_shstrndx */
};
@@ -61,8 +61,20 @@ static Elf32_Phdr out_phdr = {
PF_R|PF_W|PF_X, /* p_flags */
64 /* p_align */
};
+static Elf32_Phdr note_phdr = {
+ PT_NOTE, /* p_type */
+ DYNAMICALLY_FILLED, /* p_offset */
+ DYNAMICALLY_FILLED, /* p_vaddr */
+ DYNAMICALLY_FILLED, /* p_paddr */
+ DYNAMICALLY_FILLED, /* p_filesz */
+ DYNAMICALLY_FILLED, /* p_memsz */
+ PF_R, /* p_flags */
+ 4 /* p_align */
+};
static u8 out_shstrtab[] = "\0.text\0.shstrtab";
+/* If num_phdrs >= 2, we need to tack the .note. */
+static u8 out_shstrtab_extra[] = ".note\0";
static Elf32_Shdr out_shdr[] = {
{ 0 },
@@ -90,6 +102,23 @@ static Elf32_Shdr out_shdr[] = {
}
};
+/*
+ * The 17 points to the '.note' in the out_shstrtab and out_shstrtab_extra
+ * laid out in the file.
+ */
+static Elf32_Shdr out_shdr_note = {
+ 17, /* sh_name */
+ SHT_NOTE, /* sh_type */
+ 0, /* sh_flags */
+ DYNAMICALLY_FILLED, /* sh_addr */
+ DYNAMICALLY_FILLED, /* sh_offset */
+ DYNAMICALLY_FILLED, /* sh_size */
+ 0, /* sh_link */
+ 0, /* sh_info */
+ 4, /* sh_addralign */
+ 0 /* sh_entsize */
+};
+
/* Some system header files define these macros and pollute our namespace. */
#undef swap16
#undef swap32
@@ -228,21 +257,22 @@ static void do_read(int fd, void *data, int len)
int main(int argc, char **argv)
{
u64 final_exec_addr;
- u32 loadbase, dat_siz, mem_siz;
+ u32 loadbase, dat_siz, mem_siz, note_base, note_sz, offset;
char *inimage, *outimage;
int infd, outfd;
char buffer[1024];
int bytes, todo, i;
+ int num_phdrs = 1;
Elf32_Ehdr in32_ehdr;
Elf64_Ehdr in64_ehdr;
Elf64_Phdr in64_phdr;
- if ( argc != 5 )
+ if ( argc < 5 )
{
fprintf(stderr, "Usage: mkelf32 <in-image> <out-image> "
- "<load-base> <final-exec-addr>\n");
+ "<load-base> <final-exec-addr> <number of program headers> [--notes]\n");
return 1;
}
@@ -250,6 +280,8 @@ int main(int argc, char **argv)
outimage = argv[2];
loadbase = strtoul(argv[3], NULL, 16);
final_exec_addr = strtoull(argv[4], NULL, 16);
+ if ( argv[5] && (!strcmp(argv[5], "--notes")) )
+ num_phdrs = 2;
infd = open(inimage, O_RDONLY);
if ( infd == -1 )
@@ -285,11 +317,10 @@ int main(int argc, char **argv)
(int)in64_ehdr.e_phentsize, (int)sizeof(in64_phdr));
return 1;
}
-
- if ( in64_ehdr.e_phnum != 1 )
+ if ( in64_ehdr.e_phnum != num_phdrs )
{
- fprintf(stderr, "Expect precisly 1 program header; found %d.\n",
- (int)in64_ehdr.e_phnum);
+ fprintf(stderr, "Expect precisly %d program header; found %d.\n",
+ num_phdrs, (int)in64_ehdr.e_phnum);
return 1;
}
@@ -304,6 +335,32 @@ int main(int argc, char **argv)
/*mem_siz = (u32)in64_phdr.p_memsz;*/
mem_siz = (u32)(final_exec_addr - in64_phdr.p_vaddr);
+ note_sz = note_base = offset = 0;
+ if ( num_phdrs > 1 )
+ {
+ offset = in64_phdr.p_offset;
+ note_base = in64_phdr.p_vaddr;
+
+ (void)lseek(infd, in64_ehdr.e_phoff+sizeof(in64_phdr), SEEK_SET);
+ do_read(infd, &in64_phdr, sizeof(in64_phdr));
+ endianadjust_phdr64(&in64_phdr);
+
+ (void)lseek(infd, offset, SEEK_SET);
+
+ note_sz = in64_phdr.p_memsz;
+ note_base = in64_phdr.p_vaddr - note_base;
+
+ if ( in64_phdr.p_offset > dat_siz || offset > in64_phdr.p_offset )
+ {
+ fprintf(stderr, "Expected .note section within .text section!\n" \
+ "Offset %ld not within %d!\n",
+ in64_phdr.p_offset, dat_siz);
+ return 1;
+ }
+ /* Gets us the absolute offset within the .text section. */
+ offset = in64_phdr.p_offset - offset;
+ }
+
/*
* End the image on a page boundary. This gets round alignment bugs
* in the boot- or chain-loader (e.g., kexec on the XenoBoot CD).
@@ -322,6 +379,31 @@ int main(int argc, char **argv)
out_shdr[1].sh_size = dat_siz;
out_shdr[2].sh_offset = RAW_OFFSET + dat_siz + sizeof(out_shdr);
+ if ( num_phdrs > 1 )
+ {
+ /* We have two of them! */
+ out_ehdr.e_phnum = num_phdrs;
+ /* Extra .note section. */
+ out_ehdr.e_shnum++;
+
+ /* Fill out the PT_NOTE program header. */
+ note_phdr.p_vaddr = note_base;
+ note_phdr.p_paddr = note_base;
+ note_phdr.p_filesz = note_sz;
+ note_phdr.p_memsz = note_sz;
+ note_phdr.p_offset = offset;
+
+ /* Tack on the .note\0 */
+ out_shdr[2].sh_size += sizeof(out_shstrtab_extra);
+ /* And move it past the .note section. */
+ out_shdr[2].sh_offset += sizeof(out_shdr_note);
+
+ /* Fill out the .note section. */
+ out_shdr_note.sh_size = note_sz;
+ out_shdr_note.sh_addr = note_base;
+ out_shdr_note.sh_offset = RAW_OFFSET + offset;
+ }
+
outfd = open(outimage, O_WRONLY|O_CREAT|O_TRUNC, 0775);
if ( outfd == -1 )
{
@@ -335,8 +417,14 @@ int main(int argc, char **argv)
endianadjust_phdr32(&out_phdr);
do_write(outfd, &out_phdr, sizeof(out_phdr));
-
- if ( (bytes = RAW_OFFSET - sizeof(out_ehdr) - sizeof(out_phdr)) < 0 )
+
+ if ( num_phdrs > 1 )
+ {
+ endianadjust_phdr32(¬e_phdr);
+ do_write(outfd, ¬e_phdr, sizeof(note_phdr));
+ }
+
+ if ( (bytes = RAW_OFFSET - sizeof(out_ehdr) - (num_phdrs * sizeof(out_phdr)) ) < 0 )
{
fprintf(stderr, "Header overflow.\n");
return 1;
@@ -355,9 +443,22 @@ int main(int argc, char **argv)
endianadjust_shdr32(&out_shdr[i]);
do_write(outfd, &out_shdr[0], sizeof(out_shdr));
- do_write(outfd, out_shstrtab, sizeof(out_shstrtab));
- do_write(outfd, buffer, 4-((sizeof(out_shstrtab)+dat_siz)&3));
-
+ if ( num_phdrs > 1 )
+ {
+ endianadjust_shdr32(&out_shdr_note);
+ /* Append the .note section. */
+ do_write(outfd, &out_shdr_note, sizeof(out_shdr_note));
+ /* The normal strings - .text\0.. */
+ do_write(outfd, out_shstrtab, sizeof(out_shstrtab));
+ /* Our .note */
+ do_write(outfd, out_shstrtab_extra, sizeof(out_shstrtab_extra));
+ do_write(outfd, buffer, 4-((sizeof(out_shstrtab)+sizeof(out_shstrtab_extra)+dat_siz)&3));
+ }
+ else
+ {
+ do_write(outfd, out_shstrtab, sizeof(out_shstrtab));
+ do_write(outfd, buffer, 4-((sizeof(out_shstrtab)+dat_siz)&3));
+ }
close(infd);
close(outfd);
diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
index 5099430..a6dae4c 100644
--- a/xen/arch/x86/efi/Makefile
+++ b/xen/arch/x86/efi/Makefile
@@ -6,7 +6,7 @@ create = test -e $(1) || touch -t 199901010000 $(1)
efi := y$(shell rm -f disabled)
efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c check.c 2>disabled && echo y))
-efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 2>disabled && echo y))
+efi := $(if $(efi),$(shell $(LD_EFI) -mi386pep --subsystem=10 -o check.efi check.o 2>disabled && echo y))
efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); $(call create,runtime.o)))
extra-$(efi) += boot.init.o relocs-dummy.o runtime.o compat.o
diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
index 5eb825e..87297d0 100644
--- a/xen/arch/x86/xen.lds.S
+++ b/xen/arch/x86/xen.lds.S
@@ -31,6 +31,9 @@ OUTPUT_ARCH(i386:x86-64)
PHDRS
{
text PT_LOAD ;
+#if defined(BUILD_ID) && !defined(EFI)
+ note PT_NOTE ;
+#endif
}
SECTIONS
{
@@ -79,6 +82,17 @@ SECTIONS
*(.rodata)
*(.rodata.*)
+#if defined(BUILD_ID) && defined(EFI)
+/*
+ * No mechanism to put an PT_NOTE in the EFI file - so put
+ * it in .rodata section. (notes.o supplies us with .note).
+ */
+ . = ALIGN(4);
+ __note_gnu_build_id_start = .;
+ *(.note)
+ *(.note.*)
+ __note_gnu_build_id_end = .;
+#endif
. = ALIGN(8);
/* Exception table */
__start___ex_table = .;
@@ -99,6 +113,16 @@ SECTIONS
_erodata = .;
} :text
+#if defined(BUILD_ID) && !defined(EFI)
+ . = ALIGN(4);
+ .note : {
+ __note_gnu_build_id_start = .;
+ *(.note)
+ *(.note.*)
+ __note_gnu_build_id_end = .;
+ } :note :text
+#endif
+
#ifdef EFI
. = ALIGN(MB(2));
#else
diff --git a/xen/common/version.c b/xen/common/version.c
index fc9bf42..33a930a 100644
--- a/xen/common/version.c
+++ b/xen/common/version.c
@@ -1,4 +1,9 @@
#include <xen/compile.h>
+#include <xen/init.h>
+#include <xen/errno.h>
+#include <xen/string.h>
+#include <xen/types.h>
+#include <xen/elf.h>
#include <xen/version.h>
const char *xen_compile_date(void)
@@ -61,6 +66,52 @@ const char *xen_deny(void)
return "<denied>";
}
+static const void *build_id_p;
+static unsigned int build_id_len;
+
+int xen_build_id(const void **p, unsigned int *len)
+{
+ if ( !build_id_len )
+ return -ENODATA;
+
+ *len = build_id_len;
+ *p = build_id_p;
+
+ return 0;
+}
+
+#ifdef BUILD_ID
+#define NT_GNU_BUILD_ID 3
+/* Defined in linker script. */
+extern const Elf_Note __note_gnu_build_id_start[], __note_gnu_build_id_end[];
+
+static int __init xen_build_init(void)
+{
+ const Elf_Note *n = __note_gnu_build_id_start;
+
+ /* --build-id invoked with wrong parameters. */
+ if ( __note_gnu_build_id_end <= &n[0] )
+ return -ENODATA;
+
+ /* Check for full Note header. */
+ if ( &n[1] > __note_gnu_build_id_end )
+ return -ENODATA;;
+
+ /* Check if we really have a build-id. */
+ if ( NT_GNU_BUILD_ID != n->type )
+ return -ENODATA;
+
+ /* Sanity check, name should be "GNU" for ld-generated build-id. */
+ if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 )
+ return -ENODATA;
+
+ build_id_len = n->descsz;
+ build_id_p = ELFNOTE_DESC(n);
+
+ return 0;
+}
+__initcall(xen_build_init);
+#endif
/*
* Local variables:
* mode: C
diff --git a/xen/include/xen/version.h b/xen/include/xen/version.h
index 2015c0b..400160f 100644
--- a/xen/include/xen/version.h
+++ b/xen/include/xen/version.h
@@ -13,5 +13,6 @@ const char *xen_extra_version(void);
const char *xen_changeset(void);
const char *xen_banner(void);
const char *xen_deny(void);
+int xen_build_id(const void **p, unsigned int *len);
#endif /* __XEN_VERSION_H__ */
--
2.4.3
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply related [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 19:23 ` Konrad Rzeszutek Wilk
@ 2016-04-08 19:39 ` Konrad Rzeszutek Wilk
2016-04-08 20:14 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 19:39 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
> diff --git a/xen/arch/x86/efi/Makefile b/xen/arch/x86/efi/Makefile
> index 5099430..a6dae4c 100644
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -6,7 +6,7 @@ create = test -e $(1) || touch -t 199901010000 $(1)
>
> efi := y$(shell rm -f disabled)
> efi := $(if $(efi),$(shell $(CC) $(filter-out $(CFLAGS-y) .%.d,$(CFLAGS)) -c check.c 2>disabled && echo y))
> -efi := $(if $(efi),$(shell $(LD) -mi386pep --subsystem=10 -o check.efi check.o 2>disabled && echo y))
> +efi := $(if $(efi),$(shell $(LD_EFI) -mi386pep --subsystem=10 -o check.efi check.o 2>disabled && echo y))
> efi := $(if $(efi),$(shell rm disabled)y,$(shell $(call create,boot.init.o); $(call create,runtime.o)))
>
Ignore this chunk pls. Sneaked in while I was compile testing it.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 18:47 ` Konrad Rzeszutek Wilk
2016-04-08 18:54 ` Andrew Cooper
@ 2016-04-08 19:54 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 19:54 UTC (permalink / raw)
To: Ross Lagerwall, Konrad Rzeszutek Wilk
Cc: Keir Fraser, andrew.cooper3, mpohlack, Julien Grall,
Stefano Stabellini, sasha.levin, xen-devel
>>> On 08.04.16 at 20:47, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 08, 2016 at 04:49:00PM +0100, Ross Lagerwall wrote:
>> On 04/07/2016 03:58 AM, Konrad Rzeszutek Wilk wrote:
>> >On Mon, Apr 04, 2016 at 06:46:24AM -0600, Jan Beulich wrote:
>> >>>>>On 24.03.16 at 21:00, <konrad.wilk@oracle.com> wrote:
>> >>>The version of ld that first implemented --build-id is v2.18.
>> >>>Hence we check for that or later version - if older version
>> >>>found we do not build the hypervisor with the build-id
>> >>>(and the return code is -ENODATA for xen_build_id() call).
>> >>
>> >>This appears to be stale.
>> >>
>> >>>The EFI binary is more complicated. Having any non-recognizable
>> >>>sections (.note, .data.note, etc) causes the boot to hang.
>> >>>Moving the .note in the .data section makes it work. It is also
>> >>>worth noting that the PE/COFF does not have any "comment"
>> >>>sections to the author.
>> >>
>> >>I'm afraid this is too vague: What exactly is happening there? And
>> >>is this due to binutils doing something wrong, or an issue with the
>> >>firmware on the box you've tried? While the placement of .note is
>> >>not really a big deal, any unusual placement needs a source
>> >>comment attached explaining the whys, to prevent people down
>> >>the road moving the section back into the "expected" place. But
>> >>see also below.
>> >
>> >I will have to dig in this more. I know I tried it on TianoCore but
>> >that seems to have some other issues at the moment so I will
>> >try it out on real hardware.
>> >>
>> >>>Lastly, we MUST call --binary-id=sha1 on all linker invocation so that
>> >>>symbol offsets don't changes (which means we have multiple binary
>> >>>ids - except that the last one is the final one). Without this change,
>> >>>the symbol table embedded in Xen are incorrect - some of the values it
>> >>>contains are offset by the size of the included build id.
>> >>>This obviously causes problems when resolving symbols.
>> >>
>> >>Would this also be a problem if you place the notes segment/section
>> >>last in the binary?
>> >
>> >I am not sure. Ross, you are the one who observed this?
>>
>> Yes, that would probably solve the problem.
>
> Sadly no. I stuck the .note right before .bss section and I got:
>
> relink.o: In function `symbols_expand_symbol':
> /home/konrad/xen/xen/common/symbols.c:47: undefined reference to
> `symbols_names'
> /home/konrad/xen/xen/common/symbols.c:47:(.text+0x30f40): relocation
> truncated to fit: R_X86_64_PC32 against undefined symbol `symbols_names'
> /home/konrad/xen/xen/common/symbols.c:58: undefined reference to
> `symbols_token_table'
> /home/konrad/xen/xen/common/symbols.c:58:(.text+0x30f6e): relocation
> truncated to fit: R_X86_64_PC32 against undefined symbol
> `symbols_token_table'
Well, "before the .bss section" != "last in the binary", but since
we prefer it to be part of r/o data anyway, I guess always
passing the option is reasonable.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 19:23 ` Konrad Rzeszutek Wilk
2016-04-08 19:39 ` Konrad Rzeszutek Wilk
@ 2016-04-08 20:14 ` Jan Beulich
2016-04-08 20:50 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 20:14 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
>>> On 08.04.16 at 21:23, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote:
>> >>> On 08.04.16 at 19:06, <konrad.wilk@oracle.com> wrote:
>> > So that when xen.efi is linked with this build_id.o (in v5, now called
>> > notes.o in v6)
>> > it can encapsulate __note_gnu_build_id_start and __note_gnu_build_id_end
>> > around
>> > it. I could change for EFI builds the xen.lds.S to be:
>> >
>> > *(.rodata.*)
>> > +#if defined(BUILD_ID) && defined(EFI)
>> > +/*
>> > + * No mechanism to put an PT_NOTE in the EFI file - so put
>> > + * it in .data section.
>> > + */
>> > + . = ALIGN(4);
>> > +
>> > + __note_gnu_build_id_start = .;
>> > + *(.rodata.note.gnu.build-id)
>> > + __note_gnu_build_id_end = .;
>> > + *(.note)
>> > + *(.note.*)
>> > +#endif
>> >
>> > But then it differes from the change for !EFI (Which would be naturally
>> > called .note.gnu.build-id).
>>
>> But that looks to be the right approach, accounting for the
>> differences between ELF and COFF/PE. And btw., unless you did
>> changes elsewhere I don't think this inclusion of .note and .note.*
>> here would have the effect you want it to have.
>
> We don't really have any other .note, which is good.
>
> I tried to feed the linker a notes.o file with .rodata.note
> and have the efi.lds.S ingest it:
>
> __note_gnu_build_id_start = .;
> *(.rodata.note)
> __note_gnu_build_id_end = .;
>
> But it ignored it (no data, and __note_gnu_build_id_start ==
> __note_gnu_build_id_end)
I don't think it ignored it - it merely got put in a place you didn't want
it to be: The earlier *(.rodata.*) consumes it afaict. So perhaps you
want to move the notes between .text and .rodata?
> @@ -57,10 +60,19 @@ SECTIONS
> *(.lockprofile.data)
> __lock_profile_end = .;
> #endif
> -
> - _erodata = .; /* End of read-only data */
> } :text
>
> +#if defined(BUILD_ID)
> + . = ALIGN(4);
> + .note : {
> + __note_gnu_build_id_start = .;
> + *(.note)
> + *(.note.*)
> + __note_gnu_build_id_end = .;
> + } :note :text
> +#endif
That can't be right: What if any other .note or .note.* section
appears for whatever reason? There may be distro specific
.note.* sections issued by the compiler...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 20:14 ` Jan Beulich
@ 2016-04-08 20:50 ` Konrad Rzeszutek Wilk
2016-04-08 21:11 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 20:50 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 21:23, <konrad.wilk@oracle.com> wrote:
> > On Fri, Apr 08, 2016 at 11:44:54AM -0600, Jan Beulich wrote:
> >> >>> On 08.04.16 at 19:06, <konrad.wilk@oracle.com> wrote:
> >> > So that when xen.efi is linked with this build_id.o (in v5, now called
> >> > notes.o in v6)
> >> > it can encapsulate __note_gnu_build_id_start and __note_gnu_build_id_end
> >> > around
> >> > it. I could change for EFI builds the xen.lds.S to be:
> >> >
> >> > *(.rodata.*)
> >> > +#if defined(BUILD_ID) && defined(EFI)
> >> > +/*
> >> > + * No mechanism to put an PT_NOTE in the EFI file - so put
> >> > + * it in .data section.
> >> > + */
> >> > + . = ALIGN(4);
> >> > +
> >> > + __note_gnu_build_id_start = .;
> >> > + *(.rodata.note.gnu.build-id)
> >> > + __note_gnu_build_id_end = .;
> >> > + *(.note)
> >> > + *(.note.*)
> >> > +#endif
> >> >
> >> > But then it differes from the change for !EFI (Which would be naturally
> >> > called .note.gnu.build-id).
> >>
> >> But that looks to be the right approach, accounting for the
> >> differences between ELF and COFF/PE. And btw., unless you did
> >> changes elsewhere I don't think this inclusion of .note and .note.*
> >> here would have the effect you want it to have.
> >
> > We don't really have any other .note, which is good.
> >
> > I tried to feed the linker a notes.o file with .rodata.note
> > and have the efi.lds.S ingest it:
> >
> > __note_gnu_build_id_start = .;
> > *(.rodata.note)
> > __note_gnu_build_id_end = .;
> >
> > But it ignored it (no data, and __note_gnu_build_id_start ==
> > __note_gnu_build_id_end)
>
> I don't think it ignored it - it merely got put in a place you didn't want
> it to be: The earlier *(.rodata.*) consumes it afaict. So perhaps you
Aaah, could very well! Let me try that.
> want to move the notes between .text and .rodata?
>
> > @@ -57,10 +60,19 @@ SECTIONS
> > *(.lockprofile.data)
> > __lock_profile_end = .;
> > #endif
> > -
> > - _erodata = .; /* End of read-only data */
> > } :text
> >
> > +#if defined(BUILD_ID)
> > + . = ALIGN(4);
> > + .note : {
> > + __note_gnu_build_id_start = .;
> > + *(.note)
> > + *(.note.*)
> > + __note_gnu_build_id_end = .;
> > + } :note :text
> > +#endif
>
> That can't be right: What if any other .note or .note.* section
> appears for whatever reason? There may be distro specific
> .note.* sections issued by the compiler...
OK, it is all OK on ELF and on ARM build. But on EFI? The two
objcopy calls squash the contents of the .note section in the notes.o
Which means we can include distro specific in EFI (but no in ELF).
The only good solution I can think of is to make the .note section
on ELF builds to be:
.note : {
__note_gnu_build_id_start = .;
*(.note.gnu.build-id)
__note_gnu_build_id_end = .;
} :note :text
And that will guarantee that the .note section will only have the
build-id when ingested by EFI.
And other .notes will be effectively ignored by the xen.lds linker script.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 20:50 ` Konrad Rzeszutek Wilk
@ 2016-04-08 21:11 ` Jan Beulich
2016-04-08 21:15 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-08 21:11 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
>>> On 08.04.16 at 22:50, <konrad.wilk@oracle.com> wrote:
> On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
>> >>> On 08.04.16 at 21:23, <konrad.wilk@oracle.com> wrote:
>> > @@ -57,10 +60,19 @@ SECTIONS
>> > *(.lockprofile.data)
>> > __lock_profile_end = .;
>> > #endif
>> > -
>> > - _erodata = .; /* End of read-only data */
>> > } :text
>> >
>> > +#if defined(BUILD_ID)
>> > + . = ALIGN(4);
>> > + .note : {
>> > + __note_gnu_build_id_start = .;
>> > + *(.note)
>> > + *(.note.*)
>> > + __note_gnu_build_id_end = .;
>> > + } :note :text
>> > +#endif
>>
>> That can't be right: What if any other .note or .note.* section
>> appears for whatever reason? There may be distro specific
>> .note.* sections issued by the compiler...
>
> OK, it is all OK on ELF and on ARM build. But on EFI? The two
> objcopy calls squash the contents of the .note section in the notes.o
> Which means we can include distro specific in EFI (but no in ELF).
>
> The only good solution I can think of is to make the .note section
> on ELF builds to be:
>
> .note : {
> __note_gnu_build_id_start = .;
> *(.note.gnu.build-id)
> __note_gnu_build_id_end = .;
> } :note :text
>
> And that will guarantee that the .note section will only have the
> build-id when ingested by EFI.
>
> And other .notes will be effectively ignored by the xen.lds linker script.
Yes, that's one of the possible routes to go. The other would seem
to be to name the section .note.gnu.build-id instead of just .note.
But that second option can equally well be implemented by whoever
needs a second kind of note propagated in the final image.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 19/28] build_id: Provide ld-embedded build-ids
2016-04-08 21:11 ` Jan Beulich
@ 2016-04-08 21:15 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-08 21:15 UTC (permalink / raw)
To: Jan Beulich
Cc: Keir Fraser, ross.lagerwall, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, sasha.levin, xen-devel
On Fri, Apr 08, 2016 at 03:11:17PM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 22:50, <konrad.wilk@oracle.com> wrote:
> > On Fri, Apr 08, 2016 at 02:14:22PM -0600, Jan Beulich wrote:
> >> >>> On 08.04.16 at 21:23, <konrad.wilk@oracle.com> wrote:
> >> > @@ -57,10 +60,19 @@ SECTIONS
> >> > *(.lockprofile.data)
> >> > __lock_profile_end = .;
> >> > #endif
> >> > -
> >> > - _erodata = .; /* End of read-only data */
> >> > } :text
> >> >
> >> > +#if defined(BUILD_ID)
> >> > + . = ALIGN(4);
> >> > + .note : {
> >> > + __note_gnu_build_id_start = .;
> >> > + *(.note)
> >> > + *(.note.*)
> >> > + __note_gnu_build_id_end = .;
> >> > + } :note :text
> >> > +#endif
> >>
> >> That can't be right: What if any other .note or .note.* section
> >> appears for whatever reason? There may be distro specific
> >> .note.* sections issued by the compiler...
> >
> > OK, it is all OK on ELF and on ARM build. But on EFI? The two
> > objcopy calls squash the contents of the .note section in the notes.o
> > Which means we can include distro specific in EFI (but no in ELF).
> >
> > The only good solution I can think of is to make the .note section
> > on ELF builds to be:
> >
> > .note : {
> > __note_gnu_build_id_start = .;
> > *(.note.gnu.build-id)
> > __note_gnu_build_id_end = .;
> > } :note :text
> >
> > And that will guarantee that the .note section will only have the
> > build-id when ingested by EFI.
> >
> > And other .notes will be effectively ignored by the xen.lds linker script.
>
> Yes, that's one of the possible routes to go. The other would seem
> to be to name the section .note.gnu.build-id instead of just .note.
Hehe.
> But that second option can equally well be implemented by whoever
> needs a second kind of note propagated in the final image.
/me nods.
OK, so .note.gnu.build-id is what I am going with.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-07 15:38 ` Jan Beulich
@ 2016-04-09 14:42 ` Konrad Rzeszutek Wilk
2016-04-11 15:38 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-09 14:42 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
On Thu, Apr 07, 2016 at 09:38:53AM -0600, Jan Beulich wrote:
> >>> On 07.04.16 at 05:05, <konrad.wilk@oracle.com> wrote:
> >> >> > + /* All CPUs are waiting, now signal to disable IRQs. */
> >> >> > + xsplice_work.ready = 1;
> >> >> > + smp_wmb();
> >> >> > +
> >> >> > + atomic_inc(&xsplice_work.irq_semaphore);
> >> >> > + if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout, total_cpus,
> >> >> > + "Timed out on IRQ semaphore") )
> >> >>
> >> >> I'd prefer if the common parts of that message moved into
> >> >> xsplice_do_wait() - no reason to have more string literal space
> >> >> occupied than really needed. Also, looking back, the respective
> >> >> function parameter could do with a more descriptive name.
> >> >>
> >> >> And then - does it make sense to wait the perhaps full 30ms
> >> >> on this second step? Rendezvoused CPUs should react rather
> >> >> quickly to the signal to disable interrupts.
> >> >
> >> > We don't reset the timeout - the timeout is for both calls
> >> > to xsplice_do_wait.
> >>
> >> I understand that's the way it's right now, but that's what I'm putting
> >> under question. Rendezvousing CPUs is quite a bit more at risk of
> >> taking some time compared to having already rendezvoused CPUs
> >> disable their IRQs.
> >
> > Yes. I could expand the timeout, but maybe have some reset (add more
> > timeout) once CPUs come along?
>
> Expand the timeout? Add more timeout? I don't understand. My
> point was about shortening the timeout on the second step.
By how much?
The clock (timeout) starts ticking the moment the schedule_work
is called - to quiten all the CPUs. Adding an acceleration once
they have passed the #1 stage is modifying the semantics of the
timeout ("well, it was 30ms, but once it goes over phase #1 it
is shorten by half (or is it a quarter?").
Should we expose both timeouts to the sysctl so that the user can
customize the acceleration ratio?
Perhaps we can fiddle with this later?
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-07 15:43 ` Jan Beulich
@ 2016-04-10 2:36 ` Konrad Rzeszutek Wilk
2016-04-10 2:45 ` Konrad Rzeszutek Wilk
2016-04-10 19:47 ` Is: ARM maintainers advice ..Was:Re: " Konrad Rzeszutek Wilk
0 siblings, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-10 2:36 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
> >>> On 07.04.16 at 05:09, <konrad.wilk@oracle.com> wrote:
> >> > + uint8_t *old_ptr;
> >> > +
> >> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> >> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> >> > +
> >> > + old_ptr = (uint8_t *)func->old_addr;
> >>
> >> (Considering this cast, the "old_addr" member should be
> >> unsigned long (or void *), not uint64_t: The latest on ARM32
> >> such would otherwise cause problems.)
> >
> > I has to be uint8_t to make the single byte modifications. Keep
> > also in mind that this file is only for x86.
>
> old_addr can't reasonably be uint8_t, so I can only assume you're
> mixing up things here. (And yes, I do realize this is x86 code, but
> my reference to ARM32 was only mean to say that there you'll
> need to do something similar, and casting uint64_t to whatever
> kind of pointer type is not going to work without compiler warning.)
Way back .. when we spoke about the .xsplice.funcs structure
you recommended to make the types be either uintXX specific
or Elf types. I choose Elf types but then we realized that
ARM32 hypervisor would be involved which of course would have
a different size of the structure. So I went with uintXXX
to save a bit of headache (specifically those BUILD_BUG_ON
checks).
I can't see making the old_addr be unsigned long or void *,
which means going back to Elf types. And for ARM32 I will
have to deal with a different structure size.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-10 2:36 ` Konrad Rzeszutek Wilk
@ 2016-04-10 2:45 ` Konrad Rzeszutek Wilk
2016-04-11 15:41 ` Jan Beulich
2016-04-10 19:47 ` Is: ARM maintainers advice ..Was:Re: " Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-10 2:45 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
On Sat, Apr 09, 2016 at 10:36:00PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
> > >>> On 07.04.16 at 05:09, <konrad.wilk@oracle.com> wrote:
> > >> > + uint8_t *old_ptr;
> > >> > +
> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> > >> > +
> > >> > + old_ptr = (uint8_t *)func->old_addr;
> > >>
> > >> (Considering this cast, the "old_addr" member should be
> > >> unsigned long (or void *), not uint64_t: The latest on ARM32
> > >> such would otherwise cause problems.)
> > >
> > > I has to be uint8_t to make the single byte modifications. Keep
> > > also in mind that this file is only for x86.
> >
> > old_addr can't reasonably be uint8_t, so I can only assume you're
> > mixing up things here. (And yes, I do realize this is x86 code, but
> > my reference to ARM32 was only mean to say that there you'll
> > need to do something similar, and casting uint64_t to whatever
> > kind of pointer type is not going to work without compiler warning.)
>
> Way back .. when we spoke about the .xsplice.funcs structure
> you recommended to make the types be either uintXX specific
> or Elf types. I choose Elf types but then we realized that
> ARM32 hypervisor would be involved which of course would have
> a different size of the structure. So I went with uintXXX
> to save a bit of headache (specifically those BUILD_BUG_ON
> checks).
>
> I can't see making the old_addr be unsigned long or void *,
> which means going back to Elf types. And for ARM32 I will
> have to deal with a different structure size.
Oh gosh, that is going to be problem with our headers as
I would be now exposing the 'xsplice_patch_func' structure
in a public header which would depend on Elf_X types.
And we do not expose those. Moving the whole elfstructs.h
to public directory is a bit .. harsh.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-10 2:36 ` Konrad Rzeszutek Wilk
2016-04-10 2:45 ` Konrad Rzeszutek Wilk
@ 2016-04-10 19:47 ` Konrad Rzeszutek Wilk
2016-04-10 20:58 ` Stefano Stabellini
2016-04-11 15:44 ` Jan Beulich
1 sibling, 2 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-10 19:47 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, sstabellini
Cc: Kevin Tian, Keir Fraser, Jan Beulich, Jun Nakajima,
andrew.cooper3, mpohlack, ross.lagerwall, Julien Grall,
Stefano Stabellini, Suravee Suthikulpanit, sasha.levin,
xen-devel, Boris Ostrovsky
On Sat, Apr 09, 2016 at 10:36:02PM -0400, Konrad Rzeszutek Wilk wrote:
> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
> > >>> On 07.04.16 at 05:09, <konrad.wilk@oracle.com> wrote:
> > >> > + uint8_t *old_ptr;
> > >> > +
> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> > >> > +
> > >> > + old_ptr = (uint8_t *)func->old_addr;
> > >>
> > >> (Considering this cast, the "old_addr" member should be
> > >> unsigned long (or void *), not uint64_t: The latest on ARM32
> > >> such would otherwise cause problems.)
> > >
> > > I has to be uint8_t to make the single byte modifications. Keep
> > > also in mind that this file is only for x86.
> >
> > old_addr can't reasonably be uint8_t, so I can only assume you're
> > mixing up things here. (And yes, I do realize this is x86 code, but
> > my reference to ARM32 was only mean to say that there you'll
> > need to do something similar, and casting uint64_t to whatever
> > kind of pointer type is not going to work without compiler warning.)
>
> Way back .. when we spoke about the .xsplice.funcs structure
> you recommended to make the types be either uintXX specific
> or Elf types. I choose Elf types but then we realized that
> ARM32 hypervisor would be involved which of course would have
> a different size of the structure. So I went with uintXXX
> to save a bit of headache (specifically those BUILD_BUG_ON
> checks).
>
> I can't see making the old_addr be unsigned long or void *,
> which means going back to Elf types. And for ARM32 I will
> have to deal with a different structure size.
CC-ing Stefano and Julien here to advise. I ended up
exposing the ABI part in sysctl.h (and design document as):
#define XSPLICE_PAYLOAD_VERSION 1
/*
* .xsplice.funcs structure layout defined in the `Payload format`
* section in the xSplice design document.
*
* The size should be exactly 64 bytes.
*/
struct xsplice_patch_func {
const char *name; /* Name of function to be patched. */
uint64_t new_addr;
uint64_t old_addr; /* Can be zero and name will be looked up. */
uint32_t new_size;
uint32_t old_size;
uint8_t version; /* MUST be XSPLICE_PAYLOAD_VERSION. */
uint8_t pad[31]; /* MUST be zero filled. */
};
typedef struct xsplice_patch_func xsplice_patch_func_t;
Which looks nice.
When the ELF file is loaded we load it as this structure:
[x86]
#ifndef CONFIG_ARM
struct xsplice_patch_func_internal {
const char *name;
void *new_addr;
void *old_addr;
uint32_t new_size;
uint32_t old_size;
uint8_t version;
union {
uint8_t undo[8];
uint8_t pad[31];
} u;
};
#else
[ARM]
struct xsplice_patch_func_internal {
const char *name;
uint32_t _pad0;
void *new_addr;
uint32_t _pad1;
void *old_addr;
uint32_t _pad2;
uint32_t new_size;
uint32_t old_size;
uint8_t version;
union {
uint8_t pad[31];
} u;
};
#endif
That allows the size and offsets to be the same. I checked under ARM32
builds:
struct xsplice_patch_func_internal {
const char * name; /* 0 4 */
uint32_t _pad0; /* 4 4 */
void * new_addr; /* 8 4 */
uint32_t _pad1; /* 12 4 */
void * old_addr; /* 16 4 */
uint32_t _pad2; /* 20 4 */
uint32_t new_size; /* 24 4 */
uint32_t old_size; /* 28 4 */
uint8_t version; /* 32 1 */
union {
uint8_t pad[31]; /* 31 */
} u; /* 33 31 */
/* --- cacheline 1 boundary (64 bytes) --- */
/* size: 64, cachelines: 1, members: 10 */
};
So it all looks correct. (and I can cast the old_addr to uint8_t).
Naturally we can expand the pad[] to hold whatever is needed
when implementing xSplice under ARM
However I would appreciate advise from ARM folks if I made some
wrong assumptions..
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-10 19:47 ` Is: ARM maintainers advice ..Was:Re: " Konrad Rzeszutek Wilk
@ 2016-04-10 20:58 ` Stefano Stabellini
2016-04-11 15:44 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Stefano Stabellini @ 2016-04-10 20:58 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kevin Tian, sstabellini, Keir Fraser, Jan Beulich,
ross.lagerwall, Jun Nakajima, andrew.cooper3, mpohlack,
Julien Grall, Stefano Stabellini, Suravee Suthikulpanit,
sasha.levin, xen-devel, Boris Ostrovsky
On Sun, 10 Apr 2016, Konrad Rzeszutek Wilk wrote:
> On Sat, Apr 09, 2016 at 10:36:02PM -0400, Konrad Rzeszutek Wilk wrote:
> > On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
> > > >>> On 07.04.16 at 05:09, <konrad.wilk@oracle.com> wrote:
> > > >> > + uint8_t *old_ptr;
> > > >> > +
> > > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> > > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> > > >> > +
> > > >> > + old_ptr = (uint8_t *)func->old_addr;
> > > >>
> > > >> (Considering this cast, the "old_addr" member should be
> > > >> unsigned long (or void *), not uint64_t: The latest on ARM32
> > > >> such would otherwise cause problems.)
> > > >
> > > > I has to be uint8_t to make the single byte modifications. Keep
> > > > also in mind that this file is only for x86.
> > >
> > > old_addr can't reasonably be uint8_t, so I can only assume you're
> > > mixing up things here. (And yes, I do realize this is x86 code, but
> > > my reference to ARM32 was only mean to say that there you'll
> > > need to do something similar, and casting uint64_t to whatever
> > > kind of pointer type is not going to work without compiler warning.)
> >
> > Way back .. when we spoke about the .xsplice.funcs structure
> > you recommended to make the types be either uintXX specific
> > or Elf types. I choose Elf types but then we realized that
> > ARM32 hypervisor would be involved which of course would have
> > a different size of the structure. So I went with uintXXX
> > to save a bit of headache (specifically those BUILD_BUG_ON
> > checks).
> >
> > I can't see making the old_addr be unsigned long or void *,
> > which means going back to Elf types. And for ARM32 I will
> > have to deal with a different structure size.
>
> CC-ing Stefano and Julien here to advise. I ended up
> exposing the ABI part in sysctl.h (and design document as):
>
>
> #define XSPLICE_PAYLOAD_VERSION 1
> /*
> * .xsplice.funcs structure layout defined in the `Payload format`
> * section in the xSplice design document.
> *
> * The size should be exactly 64 bytes.
> */
> struct xsplice_patch_func {
> const char *name; /* Name of function to be patched. */
> uint64_t new_addr;
> uint64_t old_addr; /* Can be zero and name will be looked up. */
> uint32_t new_size;
> uint32_t old_size;
> uint8_t version; /* MUST be XSPLICE_PAYLOAD_VERSION. */
> uint8_t pad[31]; /* MUST be zero filled. */
> };
> typedef struct xsplice_patch_func xsplice_patch_func_t;
>
> Which looks nice.
>
> When the ELF file is loaded we load it as this structure:
>
> [x86]
> #ifndef CONFIG_ARM
> struct xsplice_patch_func_internal {
> const char *name;
> void *new_addr;
> void *old_addr;
> uint32_t new_size;
> uint32_t old_size;
> uint8_t version;
> union {
> uint8_t undo[8];
> uint8_t pad[31];
> } u;
> };
> #else
> [ARM]
> struct xsplice_patch_func_internal {
> const char *name;
> uint32_t _pad0;
> void *new_addr;
> uint32_t _pad1;
> void *old_addr;
> uint32_t _pad2;
> uint32_t new_size;
> uint32_t old_size;
> uint8_t version;
> union {
> uint8_t pad[31];
> } u;
> };
> #endif
>
> That allows the size and offsets to be the same. I checked under ARM32
> builds:
>
>
> struct xsplice_patch_func_internal {
> const char * name; /* 0 4 */
> uint32_t _pad0; /* 4 4 */
> void * new_addr; /* 8 4 */
> uint32_t _pad1; /* 12 4 */
> void * old_addr; /* 16 4 */
> uint32_t _pad2; /* 20 4 */
> uint32_t new_size; /* 24 4 */
> uint32_t old_size; /* 28 4 */
> uint8_t version; /* 32 1 */
> union {
> uint8_t pad[31]; /* 31 */
> } u; /* 33 31 */
> /* --- cacheline 1 boundary (64 bytes) --- */
>
> /* size: 64, cachelines: 1, members: 10 */
> };
>
> So it all looks correct. (and I can cast the old_addr to uint8_t).
> Naturally we can expand the pad[] to hold whatever is needed
> when implementing xSplice under ARM
>
> However I would appreciate advise from ARM folks if I made some
> wrong assumptions..
It looks good. I take that ARM64 will be like x86. In that case, instead
of #ifdef'ing x86 or ARM, I would #ifdef BITS_PER_LONG or POINTER_ALIGN.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address.
[not found] ` <5707FA8B02000078000E6178@prv-mh.provo.novell.com>
@ 2016-04-11 8:07 ` Ross Lagerwall
0 siblings, 0 replies; 190+ messages in thread
From: Ross Lagerwall @ 2016-04-11 8:07 UTC (permalink / raw)
To: Jan Beulich; +Cc: mpohlack, xen-devel, sasha.levin, andrew.cooper3
On 04/08/2016 06:38 PM, Jan Beulich wrote:
> (Did you drop all Cc-s for a reason?)
No. Re-adding CCs.
>
>>>> On 08.04.16 at 18:04, <ross.lagerwall@citrix.com> wrote:
>> On 04/01/2016 04:11 PM, Jan Beulich wrote:
>>>> + nsyms = 0;
>>>> + strtab_len = 0;
>>>> + for ( i = 1; i < elf->nsym; i++ )
>>>> + {
>>>> + if ( is_core_symbol(elf, elf->sym + i) )
>>>> + {
>>>> + symtab[nsyms].name = strtab + strtab_len;
>>>> + symtab[nsyms].size = elf->sym[i].sym->st_size;
>>>> + symtab[nsyms].value = elf->sym[i].sym->st_value;
>>>> + symtab[nsyms].new_symbol = 0; /* To be checked below. */
>>>> + strtab_len += strlcpy(strtab + strtab_len, elf->sym[i].name,
>>>> + KSYM_NAME_LEN) + 1;
>>>> + nsyms++;
>>>> + }
>>>> + }
>>>> +
>>>> + for ( i = 0; i < nsyms; i++ )
>>>> + {
>>>> + bool_t found = 0;
>>>> +
>>>> + for ( j = 0; j < payload->nfuncs; j++ )
>>>> + {
>>>> + if ( symtab[i].value == payload->funcs[j].new_addr )
>>>> + {
>>>> + found = 1;
>>>> + break;
>>>> + }
>>>> + }
>>>> +
>>>> + if ( !found )
>>>> + {
>>>> + if ( xsplice_symbols_lookup_by_name(symtab[i].name) )
>>>> + {
>>>> + printk(XENLOG_ERR "%s%s: duplicate new symbol: %s\n",
>>>> + XSPLICE, elf->name, symtab[i].name);
>>>> + xfree(symtab);
>>>> + xfree(strtab);
>>>> + return -EEXIST;
>>>> + }
>>>> + symtab[i].new_symbol = 1;
>>>> + dprintk(XENLOG_DEBUG, "%s%s: new symbol %s\n",
>>>> + XSPLICE, elf->name, symtab[i].name);
>>>> + }
>>>> + else
>>>> + {
>>>> + dprintk(XENLOG_DEBUG, "%s%s: overriding symbol %s\n",
>>>> + XSPLICE, elf->name, symtab[i].name);
>>>
>>> Since you don't do anything here - how is this an override of some
>>> sort?
>>
>> The binary patch that is being loaded is overriding a hypervisor symbol
>> or a symbol introduced in a previous patch. i.e. you're replacing the
>> old function with a different one. Binary patches can also introduce
>> completely new functions (just above).
>
> So you mean to say that in symbol lookup, patches take priority
> over the core binary? Once we get rid of linear ordering of
> patches, how would this yield deterministic results?
>
Yes. If a patch replaces some functions in the hypervisor, then when
performing a symbol lookup you'd want to get the address of the function
currently in use, which is the one from the patch. If the linear
ordering restriction were removed, then the symbol lookup would simply
need to be updated so that it still gets the address of the function
currently in use (however that is determined).
There's also a different type of symbol lookup in the xsplice code:
looking up the address of the symbol to be replaced. In this case, it is
the original symbol thatr needs to be returned. This prevents having a
chain of jumps if a function is patched multiple times.
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-08 17:39 ` Jan Beulich
@ 2016-04-11 8:23 ` Ross Lagerwall
2016-04-22 13:33 ` Jan Beulich
2016-04-22 13:58 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Ross Lagerwall @ 2016-04-11 8:23 UTC (permalink / raw)
To: Jan Beulich
Cc: keir, andrew.cooper3, mpohlack, mpohlack, sasha.levin, xen-devel
On 04/08/2016 06:39 PM, Jan Beulich wrote:
>>>> On 08.04.16 at 17:57, <ross.lagerwall@citrix.com> wrote:
>> On 04/07/2016 02:15 AM, Jan Beulich wrote:
>>>>>> Martin Pohlack <mpohlack@amazon.com> 04/06/16 8:42 AM >>>
>>>> On 06.04.2016 04:42, Konrad Rzeszutek Wilk wrote:
>>>>> The normal use-case is to modify structures values where we have to
>>>>> be delicate about it and can't just replace the value. As in we
>>>>> may have to recompute the value.
>>>>
>>>> Agree on the default use (e.g., for XSA 91).
>>>
>>> XSA-91 was an ARM one, i.e. would still only be a theoretical example for
>>> the purpose of the discussion here.
>>
>> I've marked the following XSAs as potentially requiring hook functions
>> or shadow variables:
>>
>> XSA-36
>> XSA-45
>> XSA-60
>> XSA-64
>> XSA-80
>> XSA-82
>> XSA-97
>> XSA-107
>> XSA-114
>> XSA-150
>
> Such a raw list doesn't tell me anything, I'm afraid. Can you please
> explain for at least one of them why they do need hooks (and not
> just potentially)?
>
Some examples:
XSA-80: In addition to patching the code, a hook function is needed to
set iommu_dont_flush_iotlb back to 0.
XSA-82: The original patch applies to an __init function. Instead, use a
hook function to update the MSR.
Of course, it requires someone with decent knowledge of the code area &
source patch to determine exactly what needs to be done. But any patch
which touches initialization code (__init or otherwise) or changes the
layout or content of data (structs or static/global data) will either
need the source patch to be rewritten and/or the use of hook
functions/shadow variables. The XSAs I've listed above fall into this
category.
--
Ross Lagerwall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-08 17:54 ` Jan Beulich
@ 2016-04-11 10:50 ` Ian Jackson
2016-04-11 13:56 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Ian Jackson @ 2016-04-11 10:50 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> On 08.04.16 at 19:41, <andrew.cooper3@citrix.com> wrote:
> > The interface for the old version was sufficiently useless that build_id
> > can't be added to it. (Specifically, there is no ability to return
> > varialble length data).
>
> This is simply not true: The hypercall being passed a void handle,
> everything can be arranged for without introducing a new
> hypercall.
I'm trying to understand what your alternative suggestion is. Could
you please be more explicit ?
I'm reading xen/include/public/version.h. (Sadly it doesn't have the
API doc markup.) AFAICT there is a XENVER_xxxx sub-op namespace which
permits extensions to the XENVER hypercall.
But does that permit the caller to specify their buffer size ?
> > The new hypercall has a ration interface where you don't blindly trust
> > that the caller passed you a pointer to a suitably-sized structure.
Ie I think ^ this is for me a key question.
> While the new one is indeed slightly neater, that's not sufficient
> for such redundancy imo. That's the whole reason for withdrawing
> my ack _without_ making it an explicit NAK.
I don't think I would be content with simply adding a new sub-op with
bigger fixed-length fields.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 10:50 ` Ian Jackson
@ 2016-04-11 13:56 ` Konrad Rzeszutek Wilk
2016-04-11 14:22 ` Ian Jackson
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-11 13:56 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
xen-devel, Daniel De Graaf, KeirFraser, sasha.levin
On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> > On 08.04.16 at 19:41, <andrew.cooper3@citrix.com> wrote:
> > > The interface for the old version was sufficiently useless that build_id
> > > can't be added to it. (Specifically, there is no ability to return
> > > varialble length data).
> >
> > This is simply not true: The hypercall being passed a void handle,
> > everything can be arranged for without introducing a new
> > hypercall.
>
> I'm trying to understand what your alternative suggestion is. Could
> you please be more explicit ?
>
> I'm reading xen/include/public/version.h. (Sadly it doesn't have the
> API doc markup.) AFAICT there is a XENVER_xxxx sub-op namespace which
> permits extensions to the XENVER hypercall.
>
> But does that permit the caller to specify their buffer size ?
Only via the sub-op parameters itself. As in you cannot expand the
amount of parameters the XENVER_hypercall can do (which is two - subops
number and the pointer to arguments).
>
> > > The new hypercall has a ration interface where you don't blindly trust
> > > that the caller passed you a pointer to a suitably-sized structure.
>
> Ie I think ^ this is for me a key question.
>
> > While the new one is indeed slightly neater, that's not sufficient
> > for such redundancy imo. That's the whole reason for withdrawing
> > my ack _without_ making it an explicit NAK.
>
> I don't think I would be content with simply adding a new sub-op with
> bigger fixed-length fields.
It was variable-ish.
The new-subop (xsplice.v3) ended up 'lets-try-this-size' subop. Meaning:
/* Return value is the number of bytes written, or XEN_Exx on error.
* Calling with empty parameter returns the size of build_id. */
#define XENVER_build_id 10
struct xen_build_id {
uint32_t len; /* IN: size of buf[]. */
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
unsigned char buf[];
#elif defined(__GNUC__)
unsigned char buf[1]; /* OUT: Variable length buffer with build_id. */
#endif
};
When constructing this in libxl we could do:
xen_build_id_t *build_id;
ret= xc_version(ctx->xch, XENVER_build_id, NULL);
if ( ret != -ENOSYS && ret > 0 )
build_id = libxl__zalloc(gc, ret + sizeof(*build_id));
build_id->len = info->pagesize - sizeof(*build_id);
ret= xc_version(ctx->xch, XENVER_build_id, build_id);
.. parse it...
}
For the default case, ret would be 20, which meant the structure had
to be 24 bytes. 4 bytes were for 'len' (which had the value of 20)
and the rest inside the build_id were to be filled with the hypervisor.
For glory details:
http://xenbits.xen.org/gitweb/?p=people/konradwilk/xen.git;a=commitdiff;h=63681414ede6e38c1910077d7a225e0d67f0ff2e;hp=37efc2ac64b9ecf0cd49fb65aa7c7659467c9318
and
http://xenbits.xen.org/gitweb/?p=people/konradwilk/xen.git;a=commitdiff;h=176c63f3c0db430c70c28fe81cb8d039ae459c66;hp=63681414ede6e38c1910077d7a225e0d67f0ff2e
(albeit we first tried with the default 1020 bytes we have on the stack).
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 13:56 ` Konrad Rzeszutek Wilk
@ 2016-04-11 14:22 ` Ian Jackson
2016-04-11 15:48 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Ian Jackson @ 2016-04-11 14:22 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
xen-devel, Daniel De Graaf, KeirFraser, sasha.levin
Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
> > I don't think I would be content with simply adding a new sub-op with
> > bigger fixed-length fields.
>
> It was variable-ish.
...
> /* Return value is the number of bytes written, or XEN_Exx on error.
> * Calling with empty parameter returns the size of build_id. */
...
> #define XENVER_build_id 10
> struct xen_build_id {
> uint32_t len; /* IN: size of buf[]. */
> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
> unsigned char buf[];
This is pretty ugly but tolerable.
The comment introducing the new HYPERCALL_version_op mentions some
other differences with HYPERCALL_xen_version, which seem to suggest
other deficiencies in the latter. Those deficiencies, together with
the ugliness of the above, would tend to suggest to me that a cleaner
new interface is warranted.
But to an extent some of this conversation seems to be on matters of
taste.
Jan, what is the downside of introducing a new hypercall ?
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-09 14:42 ` Konrad Rzeszutek Wilk
@ 2016-04-11 15:38 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 15:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
>>> On 09.04.16 at 16:42, <konrad@kernel.org> wrote:
> On Thu, Apr 07, 2016 at 09:38:53AM -0600, Jan Beulich wrote:
>> >>> On 07.04.16 at 05:05, <konrad.wilk@oracle.com> wrote:
>> >> >> > + /* All CPUs are waiting, now signal to disable IRQs. */
>> >> >> > + xsplice_work.ready = 1;
>> >> >> > + smp_wmb();
>> >> >> > +
>> >> >> > + atomic_inc(&xsplice_work.irq_semaphore);
>> >> >> > + if ( !xsplice_do_wait(&xsplice_work.irq_semaphore, timeout,
> total_cpus,
>> >> >> > + "Timed out on IRQ semaphore") )
>> >> >>
>> >> >> I'd prefer if the common parts of that message moved into
>> >> >> xsplice_do_wait() - no reason to have more string literal space
>> >> >> occupied than really needed. Also, looking back, the respective
>> >> >> function parameter could do with a more descriptive name.
>> >> >>
>> >> >> And then - does it make sense to wait the perhaps full 30ms
>> >> >> on this second step? Rendezvoused CPUs should react rather
>> >> >> quickly to the signal to disable interrupts.
>> >> >
>> >> > We don't reset the timeout - the timeout is for both calls
>> >> > to xsplice_do_wait.
>> >>
>> >> I understand that's the way it's right now, but that's what I'm putting
>> >> under question. Rendezvousing CPUs is quite a bit more at risk of
>> >> taking some time compared to having already rendezvoused CPUs
>> >> disable their IRQs.
>> >
>> > Yes. I could expand the timeout, but maybe have some reset (add more
>> > timeout) once CPUs come along?
>>
>> Expand the timeout? Add more timeout? I don't understand. My
>> point was about shortening the timeout on the second step.
>
> By how much?
1ms would seem more than enough to me at a first glance.
> The clock (timeout) starts ticking the moment the schedule_work
> is called - to quiten all the CPUs. Adding an acceleration once
> they have passed the #1 stage is modifying the semantics of the
> timeout ("well, it was 30ms, but once it goes over phase #1 it
> is shorten by half (or is it a quarter?").
>
> Should we expose both timeouts to the sysctl so that the user can
> customize the acceleration ratio?
>
> Perhaps we can fiddle with this later?
Sure. It was just a thought, not an immediate requirement.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-10 2:45 ` Konrad Rzeszutek Wilk
@ 2016-04-11 15:41 ` Jan Beulich
2016-04-11 23:29 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 15:41 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
>>> On 10.04.16 at 04:45, <konrad@kernel.org> wrote:
> On Sat, Apr 09, 2016 at 10:36:00PM -0400, Konrad Rzeszutek Wilk wrote:
>> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
>> > >>> On 07.04.16 at 05:09, <konrad.wilk@oracle.com> wrote:
>> > >> > + uint8_t *old_ptr;
>> > >> > +
>> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
>> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
>> > >> > +
>> > >> > + old_ptr = (uint8_t *)func->old_addr;
>> > >>
>> > >> (Considering this cast, the "old_addr" member should be
>> > >> unsigned long (or void *), not uint64_t: The latest on ARM32
>> > >> such would otherwise cause problems.)
>> > >
>> > > I has to be uint8_t to make the single byte modifications. Keep
>> > > also in mind that this file is only for x86.
>> >
>> > old_addr can't reasonably be uint8_t, so I can only assume you're
>> > mixing up things here. (And yes, I do realize this is x86 code, but
>> > my reference to ARM32 was only mean to say that there you'll
>> > need to do something similar, and casting uint64_t to whatever
>> > kind of pointer type is not going to work without compiler warning.)
>>
>> Way back .. when we spoke about the .xsplice.funcs structure
>> you recommended to make the types be either uintXX specific
>> or Elf types. I choose Elf types but then we realized that
>> ARM32 hypervisor would be involved which of course would have
>> a different size of the structure. So I went with uintXXX
>> to save a bit of headache (specifically those BUILD_BUG_ON
>> checks).
>>
>> I can't see making the old_addr be unsigned long or void *,
>> which means going back to Elf types. And for ARM32 I will
>> have to deal with a different structure size.
>
> Oh gosh, that is going to be problem with our headers as
> I would be now exposing the 'xsplice_patch_func' structure
> in a public header which would depend on Elf_X types.
So how about uintptr_t? Not exactly the thing we do in public
headers already, but at least a possibility. Or else maybe
xen_ulong_t, albeit on ARM32 that again won't cast well to
pointer types.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-10 19:47 ` Is: ARM maintainers advice ..Was:Re: " Konrad Rzeszutek Wilk
2016-04-10 20:58 ` Stefano Stabellini
@ 2016-04-11 15:44 ` Jan Beulich
2016-04-11 15:50 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 15:44 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk, sstabellini, Konrad Rzeszutek Wilk
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, sasha.levin, xen-devel, Boris Ostrovsky
>>> On 10.04.16 at 21:47, <konrad.wilk@oracle.com> wrote:
> That allows the size and offsets to be the same. I checked under ARM32
> builds:
>
>
> struct xsplice_patch_func_internal {
> const char * name; /* 0 4 */
> uint32_t _pad0; /* 4 4 */
> void * new_addr; /* 8 4 */
> uint32_t _pad1; /* 12 4 */
> void * old_addr; /* 16 4 */
> uint32_t _pad2; /* 20 4 */
> uint32_t new_size; /* 24 4 */
> uint32_t old_size; /* 28 4 */
> uint8_t version; /* 32 1 */
> union {
> uint8_t pad[31]; /* 31 */
> } u; /* 33 31 */
> /* --- cacheline 1 boundary (64 bytes) --- */
>
> /* size: 64, cachelines: 1, members: 10 */
> };
>
> So it all looks correct. (and I can cast the old_addr to uint8_t).
> Naturally we can expand the pad[] to hold whatever is needed
> when implementing xSplice under ARM
I still don't get: Why is it so important for this structure to have
the same size and layout across architectures?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 14:22 ` Ian Jackson
@ 2016-04-11 15:48 ` Jan Beulich
2016-04-11 16:25 ` Ian Jackson
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 15:48 UTC (permalink / raw)
To: Ian Jackson, Konrad Rzeszutek Wilk
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
>>> On 11.04.16 at 16:22, <Ian.Jackson@eu.citrix.com> wrote:
> Konrad Rzeszutek Wilk writes ("Re: REST MAINTAINERS feedback requested
> Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall
> mirroring XENVER_ but sane."):
>> On Mon, Apr 11, 2016 at 11:50:25AM +0100, Ian Jackson wrote:
>> > I don't think I would be content with simply adding a new sub-op with
>> > bigger fixed-length fields.
>>
>> It was variable-ish.
> ...
>> /* Return value is the number of bytes written, or XEN_Exx on error.
>> * Calling with empty parameter returns the size of build_id. */
> ...
>> #define XENVER_build_id 10
>> struct xen_build_id {
>> uint32_t len; /* IN: size of buf[]. */
>> #if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L
>> unsigned char buf[];
>
> This is pretty ugly but tolerable.
>
> The comment introducing the new HYPERCALL_version_op mentions some
> other differences with HYPERCALL_xen_version, which seem to suggest
> other deficiencies in the latter. Those deficiencies, together with
> the ugliness of the above, would tend to suggest to me that a cleaner
> new interface is warranted.
>
> But to an extent some of this conversation seems to be on matters of
> taste.
Agreed.
> Jan, what is the downside of introducing a new hypercall ?
Duplicate code effectively doing the same thing.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-11 15:44 ` Jan Beulich
@ 2016-04-11 15:50 ` Konrad Rzeszutek Wilk
2016-04-11 16:05 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-11 15:50 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, sstabellini, Keir Fraser, Jun Nakajima,
ross.lagerwall, andrew.cooper3, mpohlack, Julien Grall,
Stefano Stabellini, Suravee Suthikulpanit, sasha.levin,
xen-devel, Boris Ostrovsky
On Mon, Apr 11, 2016 at 09:44:55AM -0600, Jan Beulich wrote:
> >>> On 10.04.16 at 21:47, <konrad.wilk@oracle.com> wrote:
> > That allows the size and offsets to be the same. I checked under ARM32
> > builds:
> >
> >
> > struct xsplice_patch_func_internal {
> > const char * name; /* 0 4 */
> > uint32_t _pad0; /* 4 4 */
> > void * new_addr; /* 8 4 */
> > uint32_t _pad1; /* 12 4 */
> > void * old_addr; /* 16 4 */
> > uint32_t _pad2; /* 20 4 */
> > uint32_t new_size; /* 24 4 */
> > uint32_t old_size; /* 28 4 */
> > uint8_t version; /* 32 1 */
> > union {
> > uint8_t pad[31]; /* 31 */
> > } u; /* 33 31 */
> > /* --- cacheline 1 boundary (64 bytes) --- */
> >
> > /* size: 64, cachelines: 1, members: 10 */
> > };
> >
> > So it all looks correct. (and I can cast the old_addr to uint8_t).
> > Naturally we can expand the pad[] to hold whatever is needed
> > when implementing xSplice under ARM
>
> I still don't get: Why is it so important for this structure to have
> the same size and layout across architectures?
I have a very bad taste from the blkif.h struct request where the structure
size is 112 or 108 depending on the 32 vs 64.
Having the same offsets for variables should make it easier for the
tools to generate the payload much simpler without having to worry
about the sizes or offset. Also it means that the common code BUILT_IN_BUG
can be generic across ARM and x86.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: Is: ARM maintainers advice ..Was:Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-11 15:50 ` Konrad Rzeszutek Wilk
@ 2016-04-11 16:05 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 16:05 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Kevin Tian, sstabellini, Keir Fraser, Jun Nakajima,
andrew.cooper3, mpohlack, ross.lagerwall, Julien Grall,
Stefano Stabellini, Suravee Suthikulpanit, sasha.levin,
xen-devel, Boris Ostrovsky
>>> On 11.04.16 at 17:50, <konrad.wilk@oracle.com> wrote:
> On Mon, Apr 11, 2016 at 09:44:55AM -0600, Jan Beulich wrote:
>> >>> On 10.04.16 at 21:47, <konrad.wilk@oracle.com> wrote:
>> > That allows the size and offsets to be the same. I checked under ARM32
>> > builds:
>> >
>> >
>> > struct xsplice_patch_func_internal {
>> > const char * name; /* 0 4 */
>> > uint32_t _pad0; /* 4 4 */
>> > void * new_addr; /* 8 4 */
>> > uint32_t _pad1; /* 12 4 */
>> > void * old_addr; /* 16 4 */
>> > uint32_t _pad2; /* 20 4 */
>> > uint32_t new_size; /* 24 4 */
>> > uint32_t old_size; /* 28 4 */
>> > uint8_t version; /* 32 1 */
>> > union {
>> > uint8_t pad[31]; /* 31 */
>> > } u; /* 33 31 */
>> > /* --- cacheline 1 boundary (64 bytes) --- */
>> >
>> > /* size: 64, cachelines: 1, members: 10 */
>> > };
>> >
>> > So it all looks correct. (and I can cast the old_addr to uint8_t).
>> > Naturally we can expand the pad[] to hold whatever is needed
>> > when implementing xSplice under ARM
>>
>> I still don't get: Why is it so important for this structure to have
>> the same size and layout across architectures?
>
> I have a very bad taste from the blkif.h struct request where the structure
> size is 112 or 108 depending on the 32 vs 64.
The two have very little - if anything - in common imo.
> Having the same offsets for variables should make it easier for the
> tools to generate the payload much simpler without having to worry
> about the sizes or offset. Also it means that the common code BUILT_IN_BUG
> can be generic across ARM and x86.
None of this seems overly hard to retain even when the structure
size wasn't consistent - just that you couldn't use a literal 64 anymore,
for example.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 15:48 ` Jan Beulich
@ 2016-04-11 16:25 ` Ian Jackson
2016-04-11 16:53 ` Konrad Rzeszutek Wilk
2016-04-11 17:00 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Ian Jackson @ 2016-04-11 16:25 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Andrew Cooper, StefanoStabellini, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> On 11.04.16 at 16:22, <Ian.Jackson@eu.citrix.com> wrote:
> > But to an extent some of this conversation seems to be on matters of
> > taste.
>
> Agreed.
>
> > Jan, what is the downside of introducing a new hypercall ?
>
> Duplicate code effectively doing the same thing.
I agree that duplication is bad, all other things being equal.
But any improvement from an old API to a new one necessarily involves
providing a dual facility during a transition period.
I don't see an explicit deprecation in the patch that is in tree, but
it seems to me to be intended (and, perhaps, implied). Certainly if
we are going to permit these strings etc. to be bigger than fits in
the old hypercall, the old hypercall needs to be deprecated on the
grounds that it can provide incomplete or inaccurate information.
Does this way of looking at it help ?
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 16:25 ` Ian Jackson
@ 2016-04-11 16:53 ` Konrad Rzeszutek Wilk
2016-04-11 17:06 ` Jan Beulich
2016-04-11 17:00 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-11 16:53 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
xen-devel, Daniel De Graaf, KeirFraser, sasha.levin
On Mon, Apr 11, 2016 at 05:25:04PM +0100, Ian Jackson wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> > On 11.04.16 at 16:22, <Ian.Jackson@eu.citrix.com> wrote:
> > > But to an extent some of this conversation seems to be on matters of
> > > taste.
> >
> > Agreed.
> >
> > > Jan, what is the downside of introducing a new hypercall ?
> >
> > Duplicate code effectively doing the same thing.
>
> I agree that duplication is bad, all other things being equal.
>
> But any improvement from an old API to a new one necessarily involves
> providing a dual facility during a transition period.
>
> I don't see an explicit deprecation in the patch that is in tree, but
> it seems to me to be intended (and, perhaps, implied). Certainly if
I tried it at some point by adding the suffix 'compat' to it.
The compat layer did not like the extra compat string and all kinds of
compilation issues arose. I put it on the backburner.
> we are going to permit these strings etc. to be bigger than fits in
> the old hypercall, the old hypercall needs to be deprecated on the
> grounds that it can provide incomplete or inaccurate information.
The build-id in Config.mk is set to use sha1. Which produces 20 bytes.
You (or anybody else) can modify Config.mk to modify --build-id
as per man ld (there is an uuid or md5 or):
"0xhexstring" to use a chosen bit string specified as an even number of hexadecimal
digits ("-" and ":" characters between digit pairs are ignored)."
which does not impose any limits. Albeit 2967 characters of 0xdeadbeef is all I seem to be able
jam on the line. Weird. Anyhow:
build_id : deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeef0000deadbeefdeadbeef0000deadbeef0000deadbeef0000dead
is possible.
>
> Does this way of looking at it help ?
>
> Thanks,
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 16:25 ` Ian Jackson
2016-04-11 16:53 ` Konrad Rzeszutek Wilk
@ 2016-04-11 17:00 ` Jan Beulich
2016-04-11 17:13 ` Ian Jackson
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 17:00 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
>>> On 11.04.16 at 18:25, <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 16:22, <Ian.Jackson@eu.citrix.com> wrote:
>> > But to an extent some of this conversation seems to be on matters of
>> > taste.
>>
>> Agreed.
>>
>> > Jan, what is the downside of introducing a new hypercall ?
>>
>> Duplicate code effectively doing the same thing.
>
> I agree that duplication is bad, all other things being equal.
>
> But any improvement from an old API to a new one necessarily involves
> providing a dual facility during a transition period.
Except that, at least for most sub-ops, the new one doesn't really
provide much advantage, and hence dealing with the lack of size
for those sub-ops where it matters within the existing hypercall
(perhaps by adding one or two new sub-ops) would limit duplication
quite a bit.
> I don't see an explicit deprecation in the patch that is in tree, but
> it seems to me to be intended (and, perhaps, implied). Certainly if
> we are going to permit these strings etc. to be bigger than fits in
> the old hypercall, the old hypercall needs to be deprecated on the
> grounds that it can provide incomplete or inaccurate information.
>
> Does this way of looking at it help ?
If that means you approve of the introduction of the new hypercall,
yes. After all the goal of this whole discussion is to determine
whether another maintainer is willing to provide a replacement ack
for the withdrawn one.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 16:53 ` Konrad Rzeszutek Wilk
@ 2016-04-11 17:06 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 17:06 UTC (permalink / raw)
To: Ian Jackson, Konrad Rzeszutek Wilk
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
>>> On 11.04.16 at 18:53, <konrad.wilk@oracle.com> wrote:
> On Mon, Apr 11, 2016 at 05:25:04PM +0100, Ian Jackson wrote:
>> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
>> Certainly if
>> we are going to permit these strings etc. to be bigger than fits in
>> the old hypercall, the old hypercall needs to be deprecated on the
>> grounds that it can provide incomplete or inaccurate information.
>
> The build-id in Config.mk is set to use sha1. Which produces 20 bytes.
> You (or anybody else) can modify Config.mk to modify --build-id
> as per man ld (there is an uuid or md5 or):
>
> "0xhexstring" to use a chosen bit string specified as an even number of
> hexadecimal
> digits ("-" and ":" characters between digit pairs are ignored)."
>
> which does not impose any limits.
This has nothing to do with the discussion here, imo. The new
build-id sub-op can, as said numerous times before, easily have
a buffer length communicated.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 17:00 ` Jan Beulich
@ 2016-04-11 17:13 ` Ian Jackson
2016-04-11 17:34 ` Jan Beulich
2016-04-11 17:46 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: Ian Jackson @ 2016-04-11 17:13 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re: [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> On 11.04.16 at 18:25, <Ian.Jackson@eu.citrix.com> wrote:
> > But any improvement from an old API to a new one necessarily involves
> > providing a dual facility during a transition period.
>
> Except that, at least for most sub-ops, the new one doesn't really
> provide much advantage, and hence dealing with the lack of size
> for those sub-ops where it matters within the existing hypercall
> (perhaps by adding one or two new sub-ops) would limit duplication
> quite a bit.
ISTM that the lower duplication (which in principle is an advantage
which will be time limited if we are ever able to completely remove
teh old hypercall) comes with the cost of (in the long term) increased
mess in this particular subop.
Is that right ? Obviously this cost is not very significant. But
maybe the duplication isn't that significant either. I was kind of
expecting to find stronger arguments on both sides in this
discussion...
Andrew, can you please confirm what you think of Jan's suggestion to
instead add a new sub-op where the sub-op structure contains a
guest-provided length field ? Are there other reasons to want to
introduce a new hypercall ?
> > I don't see an explicit deprecation in the patch that is in tree, but
> > it seems to me to be intended (and, perhaps, implied). Certainly if
> > we are going to permit these strings etc. to be bigger than fits in
> > the old hypercall, the old hypercall needs to be deprecated on the
> > grounds that it can provide incomplete or inaccurate information.
> >
> > Does this way of looking at it help ?
>
> If that means you approve of the introduction of the new hypercall,
> yes. After all the goal of this whole discussion is to determine
> whether another maintainer is willing to provide a replacement ack
> for the withdrawn one.
Err. Well, I am still asking questions. When I said "does that help"
I was meaning something like "does that help bring you closer to
agreement with Andrew". But I don't want to focus on procedure here.
If we're going to have the argument over this bike shed I'd like to
figure out what colour I myself prefer :-). But I need to know what
the reasons are behind people's preferences.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 17:13 ` Ian Jackson
@ 2016-04-11 17:34 ` Jan Beulich
2016-04-11 17:46 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 17:34 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
>>> On 11.04.16 at 19:13, <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 18:25, <Ian.Jackson@eu.citrix.com> wrote:
>> > But any improvement from an old API to a new one necessarily involves
>> > providing a dual facility during a transition period.
>>
>> Except that, at least for most sub-ops, the new one doesn't really
>> provide much advantage, and hence dealing with the lack of size
>> for those sub-ops where it matters within the existing hypercall
>> (perhaps by adding one or two new sub-ops) would limit duplication
>> quite a bit.
>
> ISTM that the lower duplication (which in principle is an advantage
> which will be time limited if we are ever able to completely remove
> teh old hypercall) comes with the cost of (in the long term) increased
> mess in this particular subop.
We cannot, ever, remove a not toolstack limited hypercall completely
(or if, then only by Kconfig option so that people knowing none of the
guests they care about use such deprecated ones).
>> > I don't see an explicit deprecation in the patch that is in tree, but
>> > it seems to me to be intended (and, perhaps, implied). Certainly if
>> > we are going to permit these strings etc. to be bigger than fits in
>> > the old hypercall, the old hypercall needs to be deprecated on the
>> > grounds that it can provide incomplete or inaccurate information.
>> >
>> > Does this way of looking at it help ?
>>
>> If that means you approve of the introduction of the new hypercall,
>> yes. After all the goal of this whole discussion is to determine
>> whether another maintainer is willing to provide a replacement ack
>> for the withdrawn one.
>
> Err. Well, I am still asking questions. When I said "does that help"
> I was meaning something like "does that help bring you closer to
> agreement with Andrew". But I don't want to focus on procedure here.
Oh, well, in that case the answer is "no". Bike shed issue or not,
having to maintain two pieces of code with similar functionality is
undesirable. And it's not like we didn't have any XSA for that
(apparently trivial) piece of code already.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 17:13 ` Ian Jackson
2016-04-11 17:34 ` Jan Beulich
@ 2016-04-11 17:46 ` Jan Beulich
2016-04-12 9:58 ` George Dunlap
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-11 17:46 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini, xen-devel,
Daniel De Graaf, KeirFraser, sasha.levin
>>> On 11.04.16 at 19:13, <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: REST MAINTAINERS feedback requested Was:Re:
> [Xen-devel] [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring
> XENVER_ but sane."):
>> On 11.04.16 at 18:25, <Ian.Jackson@eu.citrix.com> wrote:
>> > But any improvement from an old API to a new one necessarily involves
>> > providing a dual facility during a transition period.
>>
>> Except that, at least for most sub-ops, the new one doesn't really
>> provide much advantage, and hence dealing with the lack of size
>> for those sub-ops where it matters within the existing hypercall
>> (perhaps by adding one or two new sub-ops) would limit duplication
>> quite a bit.
>
> ISTM that the lower duplication (which in principle is an advantage
> which will be time limited if we are ever able to completely remove
> teh old hypercall) comes with the cost of (in the long term) increased
> mess in this particular subop.
>
> Is that right ? Obviously this cost is not very significant. But
> maybe the duplication isn't that significant either. I was kind of
> expecting to find stronger arguments on both sides in this
> discussion...
If, btw, the cost of having to read the length argument from guest
memory was deemed undesirable, we'd certainly have the option
of specifying it to be passed through, say, the high half of the
current "cmd" parameter.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches.
2016-04-11 15:41 ` Jan Beulich
@ 2016-04-11 23:29 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-11 23:29 UTC (permalink / raw)
To: Jan Beulich
Cc: Kevin Tian, Keir Fraser, Jun Nakajima, andrew.cooper3, mpohlack,
ross.lagerwall, Julien Grall, Stefano Stabellini,
Suravee Suthikulpanit, xen-devel, sasha.levin, Boris Ostrovsky
[-- Attachment #1.1: Type: text/plain, Size: 2362 bytes --]
On Apr 11, 2016 11:41 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 10.04.16 at 04:45, <konrad@kernel.org> wrote:
> > On Sat, Apr 09, 2016 at 10:36:00PM -0400, Konrad Rzeszutek Wilk wrote:
> >> On Thu, Apr 07, 2016 at 09:43:38AM -0600, Jan Beulich wrote:
> >> > >>> On 07.04.16 at 05:09, <konrad.wilk@oracle.com> wrote:
> >> > >> > + uint8_t *old_ptr;
> >> > >> > +
> >> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE > sizeof(func->undo));
> >> > >> > + BUILD_BUG_ON(PATCH_INSN_SIZE != (1 + sizeof val));
> >> > >> > +
> >> > >> > + old_ptr = (uint8_t *)func->old_addr;
> >> > >>
> >> > >> (Considering this cast, the "old_addr" member should be
> >> > >> unsigned long (or void *), not uint64_t: The latest on ARM32
> >> > >> such would otherwise cause problems.)
> >> > >
> >> > > I has to be uint8_t to make the single byte modifications. Keep
> >> > > also in mind that this file is only for x86.
> >> >
> >> > old_addr can't reasonably be uint8_t, so I can only assume you're
> >> > mixing up things here. (And yes, I do realize this is x86 code, but
> >> > my reference to ARM32 was only mean to say that there you'll
> >> > need to do something similar, and casting uint64_t to whatever
> >> > kind of pointer type is not going to work without compiler warning.)
> >>
> >> Way back .. when we spoke about the .xsplice.funcs structure
> >> you recommended to make the types be either uintXX specific
> >> or Elf types. I choose Elf types but then we realized that
> >> ARM32 hypervisor would be involved which of course would have
> >> a different size of the structure. So I went with uintXXX
> >> to save a bit of headache (specifically those BUILD_BUG_ON
> >> checks).
> >>
> >> I can't see making the old_addr be unsigned long or void *,
> >> which means going back to Elf types. And for ARM32 I will
> >> have to deal with a different structure size.
> >
> > Oh gosh, that is going to be problem with our headers as
> > I would be now exposing the 'xsplice_patch_func' structure
> > in a public header which would depend on Elf_X types.
>
> So how about uintptr_t? Not exactly the thing we do in public
> headers already, but at least a possibility. Or else maybe
> xen_ulong_t, albeit on ARM32 that again won't cast well to
> pointer types.
I ended up (see v7 patches) making it uint64_t in public and in the private
void*.
>
> Jan
>
[-- Attachment #1.2: Type: text/html, Size: 3388 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-11 17:46 ` Jan Beulich
@ 2016-04-12 9:58 ` George Dunlap
2016-04-12 13:56 ` Konrad Rzeszutek Wilk
2016-04-12 15:17 ` Jan Beulich
0 siblings, 2 replies; 190+ messages in thread
From: George Dunlap @ 2016-04-12 9:58 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, Ian Jackson, mpohlack,
Ross Lagerwall, Julien Grall, Stefano Stabellini, sasha.levin,
xen-devel, Daniel De Graaf, KeirFraser
On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich <JBeulich@suse.com> wrote:
[snip]
>> ISTM that the lower duplication (which in principle is an advantage
>> which will be time limited if we are ever able to completely remove
>> teh old hypercall) comes with the cost of (in the long term) increased
>> mess in this particular subop.
>
> We cannot, ever, remove a not toolstack limited hypercall completely
> (or if, then only by Kconfig option so that people knowing none of the
> guests they care about use such deprecated ones).
We need to keep the hypercall around and functioning for ABI
compatibility, but we could at least remove it from the public headers
and point people to using the new one instead. (Discussion about the
merit of this idea below.)
[snip]
>> ISTM that the lower duplication (which in principle is an advantage
>> which will be time limited if we are ever able to completely remove
>> teh old hypercall) comes with the cost of (in the long term) increased
>> mess in this particular subop.
>>
>> Is that right ? Obviously this cost is not very significant. But
>> maybe the duplication isn't that significant either. I was kind of
>> expecting to find stronger arguments on both sides in this
>> discussion...
>
> If, btw, the cost of having to read the length argument from guest
> memory was deemed undesirable, we'd certainly have the option
> of specifying it to be passed through, say, the high half of the
> current "cmd" parameter.
OK, so here are the options I see:
1. Use the existing hypercall with the existing call semantics for
build-id -- i.e., require the caller to have a large but fixed-length
buffer (maybe 1024 or 2048).
2. Use the existing hypercall but wedge in different calling semantics
for the build-id subop. We could have just that subop pay attention
to an extra argument as a length, for example, and return an error if
the length is too short. Or we could make essentially a flag that
asks, "How much space if I were to execute this subop for real?"
3. We could use a new hypercall only for new functionality, with the
proposed new semantics. This would at minimum be build-id, but
probably also extraversion, compileinfo, changeset, maybe
capabilities_info.
4. Have the new hypercall replace the old hypercall. The new
hypercall will duplicate all the functionality of the old hypercall.
Deprecate the hypercall for a release or two, then remove it from the
public headers (although keep the code, because we need to maintain
backwards compatibility).
Honestly I still don't quite understand what the problem is with #1 --
if build-id is mainly meant to be a UUID or a hash of the build to
make sure that you're applying the right hotfix (please correct me if
I'm wrong here -- I haven't had time to actually follow the patch
series), 256 bytes should be enough for a properly hashed build, and
2048 should be more than enough. Requiring the caller to have a
2048-byte buffer before calling doesn't really seem like that much of
a hardship to me. Basically:
a. It's nicer to have arbitrary-length strings (2-4), but reasonably
large fixed-length ones aren't awful (1)
b. It's nicer for hypercall consumers to have a single hypercall with
consistent semantics (1,4), but having two hypercalls (3) or a single
one with inconsistent semantics (2) aren't that bad either.
c. It's nicer for hypervisor maintainers to have a single place to
support any given bit of functionality (1-3), but having a slightly
duplicated functionality that only has to be supported in an ABI
backwards-compatible manner isn't that bad either (4).
This does seem to me an awful lot like a bike shed. :-) All of the
options (1-4) seem perfectly fine to me. FWIW my preferred color
would probably be 1 because it's the easiest and least inconsistent
with the current state of things. My least favorite would be 3,
because although each individual piece of information is only in one
place, the path to get there is duplicated; both the kernel developer
and the hypervisor developer are forced to continue to deal with both.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 9:58 ` George Dunlap
@ 2016-04-12 13:56 ` Konrad Rzeszutek Wilk
2016-04-12 14:38 ` George Dunlap
2016-04-12 15:17 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-12 13:56 UTC (permalink / raw)
To: George Dunlap
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, Ian Jackson, mpohlack,
Ross Lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
xen-devel, sasha.levin, Daniel De Graaf, KeirFraser
On Tue, Apr 12, 2016 at 10:58:09AM +0100, George Dunlap wrote:
> On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich <JBeulich@suse.com> wrote:
> [snip]
> >> ISTM that the lower duplication (which in principle is an advantage
> >> which will be time limited if we are ever able to completely remove
> >> teh old hypercall) comes with the cost of (in the long term) increased
> >> mess in this particular subop.
> >
> > We cannot, ever, remove a not toolstack limited hypercall completely
> > (or if, then only by Kconfig option so that people knowing none of the
> > guests they care about use such deprecated ones).
>
> We need to keep the hypercall around and functioning for ABI
> compatibility, but we could at least remove it from the public headers
> and point people to using the new one instead. (Discussion about the
> merit of this idea below.)
>
> [snip]
> >> ISTM that the lower duplication (which in principle is an advantage
> >> which will be time limited if we are ever able to completely remove
> >> teh old hypercall) comes with the cost of (in the long term) increased
> >> mess in this particular subop.
> >>
> >> Is that right ? Obviously this cost is not very significant. But
> >> maybe the duplication isn't that significant either. I was kind of
> >> expecting to find stronger arguments on both sides in this
> >> discussion...
> >
> > If, btw, the cost of having to read the length argument from guest
> > memory was deemed undesirable, we'd certainly have the option
> > of specifying it to be passed through, say, the high half of the
> > current "cmd" parameter.
>
> OK, so here are the options I see:
>
> 1. Use the existing hypercall with the existing call semantics for
> build-id -- i.e., require the caller to have a large but fixed-length
> buffer (maybe 1024 or 2048).
>
> 2. Use the existing hypercall but wedge in different calling semantics
> for the build-id subop. We could have just that subop pay attention
> to an extra argument as a length, for example, and return an error if
> the length is too short. Or we could make essentially a flag that
> asks, "How much space if I were to execute this subop for real?"
You can't wedge in the extra argument. Tried that an Jan pointed out
that we clobber it (specifically we clobber any non-used arguments).
>
> 3. We could use a new hypercall only for new functionality, with the
> proposed new semantics. This would at minimum be build-id, but
> probably also extraversion, compileinfo, changeset, maybe
> capabilities_info.
>
> 4. Have the new hypercall replace the old hypercall. The new
> hypercall will duplicate all the functionality of the old hypercall.
> Deprecate the hypercall for a release or two, then remove it from the
> public headers (although keep the code, because we need to maintain
> backwards compatibility).
5). Stick the build-id in the xsplice sysctl. Or just in the sysctl.
>
> Honestly I still don't quite understand what the problem is with #1 --
> if build-id is mainly meant to be a UUID or a hash of the build to
> make sure that you're applying the right hotfix (please correct me if
> I'm wrong here -- I haven't had time to actually follow the patch
> series), 256 bytes should be enough for a properly hashed build, and
> 2048 should be more than enough. Requiring the caller to have a
> 2048-byte buffer before calling doesn't really seem like that much of
> a hardship to me. Basically:
>
> a. It's nicer to have arbitrary-length strings (2-4), but reasonably
> large fixed-length ones aren't awful (1)
>
> b. It's nicer for hypercall consumers to have a single hypercall with
> consistent semantics (1,4), but having two hypercalls (3) or a single
> one with inconsistent semantics (2) aren't that bad either.
>
> c. It's nicer for hypervisor maintainers to have a single place to
> support any given bit of functionality (1-3), but having a slightly
> duplicated functionality that only has to be supported in an ABI
> backwards-compatible manner isn't that bad either (4).
>
> This does seem to me an awful lot like a bike shed. :-) All of the
This is really past bike shedding - all the bikes shed have been
already built (for all those options).
> options (1-4) seem perfectly fine to me. FWIW my preferred color
> would probably be 1 because it's the easiest and least inconsistent
> with the current state of things. My least favorite would be 3,
> because although each individual piece of information is only in one
> place, the path to get there is duplicated; both the kernel developer
> and the hypervisor developer are forced to continue to deal with both.
>
The state is that 1-3 have been Nacked by Andrew, 4 has been
Nacked by Jan. And 5) (the original way) was way way back Nacked
as well.
I believe this conversation is to break a tie-breaker between maintainers.
(See http://www.xenproject.org/governance.html, Refereeing).
That is any of the REST maintainers or Project Leads will override the
Nack/Acks. Granted, Jan, me, and Andrew are excluded as we are most
certainly not neutral. That means Ian, Tim, and Keir.
And then we all can go to the pub.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 13:56 ` Konrad Rzeszutek Wilk
@ 2016-04-12 14:38 ` George Dunlap
2016-04-12 15:00 ` Konrad Rzeszutek Wilk
` (2 more replies)
0 siblings, 3 replies; 190+ messages in thread
From: George Dunlap @ 2016-04-12 14:38 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, Ian Jackson, mpohlack,
Ross Lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
sasha.levin, xen-devel, Daniel De Graaf, KeirFraser
On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>> 3. We could use a new hypercall only for new functionality, with the
>> proposed new semantics. This would at minimum be build-id, but
>> probably also extraversion, compileinfo, changeset, maybe
>> capabilities_info.
>>
>> 4. Have the new hypercall replace the old hypercall. The new
>> hypercall will duplicate all the functionality of the old hypercall.
>> Deprecate the hypercall for a release or two, then remove it from the
>> public headers (although keep the code, because we need to maintain
>> backwards compatibility).
>
> 5). Stick the build-id in the xsplice sysctl. Or just in the sysctl.
Which is somewhat similar to #3, except that instead of being in its
own hypercall, it's with a bunch of other related functionality. I'd
be OK with that color too; it's not a great color but I think it's
better than 3. :-)
>> This does seem to me an awful lot like a bike shed. :-) All of the
>
> This is really past bike shedding - all the bikes shed have been
> already built (for all those options).
You mean, the shed already has 3 layers of paint, a layer of
wallpaper, and a layer of plastic siding? :-)
>> options (1-4) seem perfectly fine to me. FWIW my preferred color
>> would probably be 1 because it's the easiest and least inconsistent
>> with the current state of things. My least favorite would be 3,
>> because although each individual piece of information is only in one
>> place, the path to get there is duplicated; both the kernel developer
>> and the hypervisor developer are forced to continue to deal with both.
>>
>
>
> The state is that 1-3 have been Nacked by Andrew, 4 has been
> Nacked by Jan. And 5) (the original way) was way way back Nacked
> as well.
There's a difference between "I think this other way is better" and "I
am absolutely opposed to this".
Well we know which option Andy prefers, but are there other options
that Andy is not absolutely opposed to? And we don't know anything
about which option Jan prefers at all, except that it's not #4.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 14:38 ` George Dunlap
@ 2016-04-12 15:00 ` Konrad Rzeszutek Wilk
2016-04-12 15:26 ` Ian Jackson
2016-04-12 15:31 ` Jan Beulich
2 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-12 15:00 UTC (permalink / raw)
To: George Dunlap
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, Ian Jackson, mpohlack,
Ross Lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
sasha.levin, xen-devel, Daniel De Graaf, KeirFraser
On Tue, Apr 12, 2016 at 03:38:31PM +0100, George Dunlap wrote:
> On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> >> 3. We could use a new hypercall only for new functionality, with the
> >> proposed new semantics. This would at minimum be build-id, but
> >> probably also extraversion, compileinfo, changeset, maybe
> >> capabilities_info.
> >>
> >> 4. Have the new hypercall replace the old hypercall. The new
> >> hypercall will duplicate all the functionality of the old hypercall.
> >> Deprecate the hypercall for a release or two, then remove it from the
> >> public headers (although keep the code, because we need to maintain
> >> backwards compatibility).
> >
> > 5). Stick the build-id in the xsplice sysctl. Or just in the sysctl.
>
> Which is somewhat similar to #3, except that instead of being in its
> own hypercall, it's with a bunch of other related functionality. I'd
> be OK with that color too; it's not a great color but I think it's
> better than 3. :-)
>
> >> This does seem to me an awful lot like a bike shed. :-) All of the
> >
> > This is really past bike shedding - all the bikes shed have been
> > already built (for all those options).
>
> You mean, the shed already has 3 layers of paint, a layer of
> wallpaper, and a layer of plastic siding? :-)
<laughs>
Yes. Very much so!
>
> >> options (1-4) seem perfectly fine to me. FWIW my preferred color
> >> would probably be 1 because it's the easiest and least inconsistent
> >> with the current state of things. My least favorite would be 3,
> >> because although each individual piece of information is only in one
> >> place, the path to get there is duplicated; both the kernel developer
> >> and the hypervisor developer are forced to continue to deal with both.
> >>
> >
> >
> > The state is that 1-3 have been Nacked by Andrew, 4 has been
> > Nacked by Jan. And 5) (the original way) was way way back Nacked
> > as well.
>
> There's a difference between "I think this other way is better" and "I
> am absolutely opposed to this".
>
> Well we know which option Andy prefers, but are there other options
> that Andy is not absolutely opposed to? And we don't know anything
> about which option Jan prefers at all, except that it's not #4.
/me nods. Thank you for pointing that out.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 9:58 ` George Dunlap
2016-04-12 13:56 ` Konrad Rzeszutek Wilk
@ 2016-04-12 15:17 ` Jan Beulich
2016-04-12 15:28 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-12 15:17 UTC (permalink / raw)
To: konrad.wilk, dunlapg
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, Ian.Jackson,
mpohlack, ross.lagerwall, julien.grall, stefano.stabellini,
sasha.levin, xen-devel, dgdegra, keir
>>> George Dunlap <dunlapg@umich.edu> 04/12/16 11:58 AM >>>
>On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>> ISTM that the lower duplication (which in principle is an advantage
>>> which will be time limited if we are ever able to completely remove
>>> teh old hypercall) comes with the cost of (in the long term) increased
>>> mess in this particular subop.
>>
>> We cannot, ever, remove a not toolstack limited hypercall completely
>> (or if, then only by Kconfig option so that people knowing none of the
>> guests they care about use such deprecated ones).
>
>We need to keep the hypercall around and functioning for ABI
>compatibility, but we could at least remove it from the public headers
>and point people to using the new one instead. (Discussion about the
>merit of this idea below.)
Please don't forget that guests use this to be deprecated hypercall as one of the
cheapest possible ways to call into the hypervisor just to get events delivered.
I'm afraid the new hypercall would mean (slightly) more overhead. In fact I'm
afraid the addition of the XSM call to the old one already had some of this effect
namely when XSM is enabled: Konrad - was this considered when you added
that?
>OK, so here are the options I see:
>
>1. Use the existing hypercall with the existing call semantics for
>build-id -- i.e., require the caller to have a large but fixed-length
>buffer (maybe 1024 or 2048).
I think it was explained even on this thread that a fixed size may indeed not
be suitable here.
>2. Use the existing hypercall but wedge in different calling semantics
>for the build-id subop. We could have just that subop pay attention
>to an extra argument as a length, for example, and return an error if
>the length is too short. Or we could make essentially a flag that
>asks, "How much space if I were to execute this subop for real?"
A suitable variant of this is what I've been arguing for.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 14:38 ` George Dunlap
2016-04-12 15:00 ` Konrad Rzeszutek Wilk
@ 2016-04-12 15:26 ` Ian Jackson
2016-04-13 4:21 ` Jan Beulich
2016-04-12 15:31 ` Jan Beulich
2 siblings, 1 reply; 190+ messages in thread
From: Ian Jackson @ 2016-04-12 15:26 UTC (permalink / raw)
To: George Dunlap
Cc: Wei Liu, StefanoStabellini, Andrew Cooper, mpohlack,
Ross Lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
sasha.levin, xen-devel, Daniel De Graaf, KeirFraser
George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> Well we know which option Andy prefers, but are there other options
> that Andy is not absolutely opposed to? And we don't know anything
> about which option Jan prefers at all, except that it's not #4.
Let me go a bit further than George.
It's clear that there are various options, most of which are
tolerable. Buit if I'm trying to help referee a disagreement between
Andrew and Jan I would prefer to be choosing between Andrew's
preferred answer and Jan's preferred answer.
Jan: AFAICT it's clear that you would still like the current patch
reverted. Can you please say what, if anything, you would like to
replace it with ?
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 15:17 ` Jan Beulich
@ 2016-04-12 15:28 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-12 15:28 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, dunlapg,
Ian.Jackson, mpohlack, ross.lagerwall, julien.grall,
stefano.stabellini, sasha.levin, xen-devel, dgdegra, keir
On Tue, Apr 12, 2016 at 09:17:29AM -0600, Jan Beulich wrote:
> >>> George Dunlap <dunlapg@umich.edu> 04/12/16 11:58 AM >>>
> >On Mon, Apr 11, 2016 at 6:46 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>> ISTM that the lower duplication (which in principle is an advantage
> >>> which will be time limited if we are ever able to completely remove
> >>> teh old hypercall) comes with the cost of (in the long term) increased
> >>> mess in this particular subop.
> >>
> >> We cannot, ever, remove a not toolstack limited hypercall completely
> >> (or if, then only by Kconfig option so that people knowing none of the
> >> guests they care about use such deprecated ones).
> >
> >We need to keep the hypercall around and functioning for ABI
> >compatibility, but we could at least remove it from the public headers
> >and point people to using the new one instead. (Discussion about the
> >merit of this idea below.)
>
> Please don't forget that guests use this to be deprecated hypercall as one of the
> cheapest possible ways to call into the hypervisor just to get events delivered.
> I'm afraid the new hypercall would mean (slightly) more overhead. In fact I'm
> afraid the addition of the XSM call to the old one already had some of this effect
> namely when XSM is enabled: Konrad - was this considered when you added
> that?
Yes, and I raised it up as well :-)
However, now that we dropped the XSM checks for some of the sub-ops,
it is pointless to do the XSM checks for them (they just do
function functions calls that end up with return 0).
I can most certainly add back the mask of flags - so only specific sub-ops
go through the XSM check. Let me write a patch for this and send it
out for review shortly.
>
> >OK, so here are the options I see:
> >
> >1. Use the existing hypercall with the existing call semantics for
> >build-id -- i.e., require the caller to have a large but fixed-length
> >buffer (maybe 1024 or 2048).
>
> I think it was explained even on this thread that a fixed size may indeed not
> be suitable here.
>
> >2. Use the existing hypercall but wedge in different calling semantics
> >for the build-id subop. We could have just that subop pay attention
> >to an extra argument as a length, for example, and return an error if
> >the length is too short. Or we could make essentially a flag that
> >asks, "How much space if I were to execute this subop for real?"
>
> A suitable variant of this is what I've been arguing for.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 14:38 ` George Dunlap
2016-04-12 15:00 ` Konrad Rzeszutek Wilk
2016-04-12 15:26 ` Ian Jackson
@ 2016-04-12 15:31 ` Jan Beulich
2 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-12 15:31 UTC (permalink / raw)
To: konrad.wilk, dunlapg
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, Ian.Jackson,
mpohlack, ross.lagerwall, julien.grall, stefano.stabellini,
sasha.levin, xen-devel, dgdegra, keir
>>> George Dunlap <dunlapg@umich.edu> 04/12/16 4:38 PM >>>
>On Tue, Apr 12, 2016 at 2:56 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
>> options (1-4) seem perfectly fine to me. FWIW my preferred color
>> would probably be 1 because it's the easiest and least inconsistent
>> with the current state of things. My least favorite would be 3,
>> because although each individual piece of information is only in one
>> place, the path to get there is duplicated; both the kernel developer
>> and the hypervisor developer are forced to continue to deal with both.
>
> The state is that 1-3 have been Nacked by Andrew, 4 has been
> Nacked by Jan. And 5) (the original way) was way way back Nacked
> as well.
No, I only withdrew my ack. Hence an ack from another REST maintainer
would suffice for it to stay in as it is now.
>There's a difference between "I think this other way is better" and "I
>am absolutely opposed to this".
>
>Well we know which option Andy prefers, but are there other options
>that Andy is not absolutely opposed to? And we don't know anything
>about which option Jan prefers at all, except that it's not #4.
As said in another reply - a suitable variant of 2.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-12 15:26 ` Ian Jackson
@ 2016-04-13 4:21 ` Jan Beulich
2016-04-13 16:07 ` Ian Jackson
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-13 4:21 UTC (permalink / raw)
To: Ian.Jackson, dunlapg
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, mpohlack,
ross.lagerwall, julien.grall, stefano.stabellini, sasha.levin,
xen-devel, dgdegra, keir
>>> Ian Jackson <Ian.Jackson@eu.citrix.com> 04/12/16 6:47 PM >>>
>George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ >but sane."):
>> Well we know which option Andy prefers, but are there other options
>> that Andy is not absolutely opposed to? And we don't know anything
>> about which option Jan prefers at all, except that it's not #4.
>
>Let me go a bit further than George.
>
>It's clear that there are various options, most of which are
>tolerable. Buit if I'm trying to help referee a disagreement between
>Andrew and Jan I would prefer to be choosing between Andrew's
>preferred answer and Jan's preferred answer.
>
>Jan: AFAICT it's clear that you would still like the current patch
>reverted. Can you please say what, if anything, you would like to
>replace it with ?
That patch doesn't need replacing by anything. It's the follow-up patch adding
support to retrieve the build-id which would need a replacement, and several
options have been put on the table. As mentioned before, I'd prefer the variant
of the new sub-op getting added to the existing version hypercall, with the
needed length argument passed either via a structure element, with the
structure pointed to by the 2nd hypercall argument, or with the high bits of
the first hypercall argument re-purposed to allow (and for this sub-op require)
holding a length. Which of these two sub-options is chosen I don't really care
much.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-13 4:21 ` Jan Beulich
@ 2016-04-13 16:07 ` Ian Jackson
2016-04-14 15:13 ` George Dunlap
0 siblings, 1 reply; 190+ messages in thread
From: Ian Jackson @ 2016-04-13 16:07 UTC (permalink / raw)
To: Jan Beulich
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, dunlapg, mpohlack,
ross.lagerwall, julien.grall, stefano.stabellini, sasha.levin,
xen-devel, dgdegra, keir
Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> George Dunlap <dunlapg@umich.edu> 04/12/16 11:58 AM >>>
> >2. Use the existing hypercall but wedge in different calling semantics
> >for the build-id subop. We could have just that subop pay attention
> >to an extra argument as a length, for example, and return an error if
> >the length is too short. Or we could make essentially a flag that
> >asks, "How much space if I were to execute this subop for real?"
>
> A suitable variant of this is what I've been arguing for.
Earlier I wrote:
It's clear that there are various options, most of which are
tolerable. Buit if I'm trying to help referee a disagreement between
Andrew and Jan I would prefer to be choosing between Andrew's
preferred answer and Jan's preferred answer.
So as I see it we have two options actually seriously proposed:
Andrew's new hypercall, and Jan's additional argument (in the struct,
seems to be what Jan is mainly suggesting).
The new hypercall is neater but more new code - and involves a
deprecation plan; the additional argument is more messy but less
duplication.
I think either of these options is tolerable. I don't see the need to
look further.
Frankly, I find the choice difficult. But the bikeshed has to be
painted /some/ colour and we should make these decisions in a sensible
way and that means I and George (who've been called on to help decide)
need to put forward an opinion.
On balance I think I prefer Jan's suggestion, mostly on the grounds
that in case of dispute, disagreement, or uncertainty, it is (all
other things being equal) better to make smaller changes. And if this
hypercall becomes _too_ much of a mess we can always replace it later
along the lines that Andrew suggests.
I look forward to hearing from George.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-13 16:07 ` Ian Jackson
@ 2016-04-14 15:13 ` George Dunlap
2016-04-14 15:59 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: George Dunlap @ 2016-04-14 15:13 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, mpohlack,
Ross Lagerwall, Julien Grall, Stefano Stabellini, Jan Beulich,
sasha.levin, xen-devel, Daniel De Graaf, Keir Fraser
On Wed, Apr 13, 2016 at 5:07 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
>> George Dunlap <dunlapg@umich.edu> 04/12/16 11:58 AM >>>
>> >2. Use the existing hypercall but wedge in different calling semantics
>> >for the build-id subop. We could have just that subop pay attention
>> >to an extra argument as a length, for example, and return an error if
>> >the length is too short. Or we could make essentially a flag that
>> >asks, "How much space if I were to execute this subop for real?"
>>
>> A suitable variant of this is what I've been arguing for.
>
> Earlier I wrote:
>
> It's clear that there are various options, most of which are
> tolerable. Buit if I'm trying to help referee a disagreement between
> Andrew and Jan I would prefer to be choosing between Andrew's
> preferred answer and Jan's preferred answer.
>
> So as I see it we have two options actually seriously proposed:
> Andrew's new hypercall, and Jan's additional argument (in the struct,
> seems to be what Jan is mainly suggesting).
>
> The new hypercall is neater but more new code - and involves a
> deprecation plan; the additional argument is more messy but less
> duplication.
>
> I think either of these options is tolerable. I don't see the need to
> look further.
>
> Frankly, I find the choice difficult. But the bikeshed has to be
> painted /some/ colour and we should make these decisions in a sensible
> way and that means I and George (who've been called on to help decide)
> need to put forward an opinion.
>
> On balance I think I prefer Jan's suggestion, mostly on the grounds
> that in case of dispute, disagreement, or uncertainty, it is (all
> other things being equal) better to make smaller changes. And if this
> hypercall becomes _too_ much of a mess we can always replace it later
> along the lines that Andrew suggests.
I'm a bit torn here. I think on the whole, I agree with Ian's
approach that if there is disagreement, then the more conservative
approach should be taken. And if we were discussing an uncommitted
patch about which no consensus had been reached, I would second his
suggestion.
On the other hand, I think there's a bit of a faulty interpretation of
the procedure here. Jan reviewed the patch thoroughly and then acked
it; on the basis of that, Konrad legitimately checked it in. After it
was checked in Jan said, "I've changed my mind and withdraw my Ack";
and the assumption of the subsequent conversation was that an ack
*can* be withdrawn after it has been legitimately checked in, and that
if no other Ack is supplied, then it must be reverted.
I don't think that's a correct interpretation of the rules. Reviewers
in general, and maintainers in particular, should make reasonably sure
that they mean the Ack before they give it; and if they change their
mind after it has been legitimately checked in, then it's now up to
them to make the change they want to see according to the regular
procedure. That is, if Jan wants it reverted, he needs to post a
patch reverting it and get Acks from the appropriate maintainers; and
the discussion needs to be around Jan's reversion being accepted, not
about Konrad's original patch continuing to be accepted. (Obvious
exceptions can be made in the case of emergencies like build
breakages.)
Normally it's best to try to come to agreement instead of falling back
to rule lawyering; and in any case it's always easier to talk about
the rules when we're not trying to sort out a specific situation. But
since we've failed to reach a genuine agreement, in this case I think
the rule lawyering is probably a legitimate way to resolve the issue.
Thoughts?
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-14 15:13 ` George Dunlap
@ 2016-04-14 15:59 ` Jan Beulich
2016-04-14 16:19 ` George Dunlap
0 siblings, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-14 15:59 UTC (permalink / raw)
To: george.dunlap, Ian.Jackson
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, mpohlack,
ross.lagerwall, julien.grall, stefano.stabellini, sasha.levin,
xen-devel, dgdegra, keir
>>> George Dunlap <george.dunlap@citrix.com> 04/14/16 5:16 PM >>>
>On the other hand, I think there's a bit of a faulty interpretation of
>the procedure here. Jan reviewed the patch thoroughly and then acked
>it; on the basis of that, Konrad legitimately checked it in. After it
>was checked in Jan said, "I've changed my mind and withdraw my Ack";
>and the assumption of the subsequent conversation was that an ack
>*can* be withdrawn after it has been legitimately checked in, and that
>if no other Ack is supplied, then it must be reverted.
>
>I don't think that's a correct interpretation of the rules. Reviewers
>in general, and maintainers in particular, should make reasonably sure
>that they mean the Ack before they give it; and if they change their
>mind after it has been legitimately checked in, then it's now up to
>them to make the change they want to see according to the regular
>procedure. That is, if Jan wants it reverted, he needs to post a
>patch reverting it and get Acks from the appropriate maintainers; and
>the discussion needs to be around Jan's reversion being accepted, not
>about Konrad's original patch continuing to be accepted. (Obvious
>exceptions can be made in the case of emergencies like build
>breakages.)
Fundamentally I agree, but I think there's more to this than just following
a set of rules. For example, please don't forget the time pressure due to
the (at that time) rapidly approaching freeze date. And then, mistakes
happen, and so I made a mistake here by sending the ack a few hours too
early.
What is really hard to understand to me is why it is so difficult to just
get a refereeing opinion on the actual interface change. IMO we don't
really need to discuss rules and processes, the question is as simple
as "Do we want/need this new interface?"
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-14 15:59 ` Jan Beulich
@ 2016-04-14 16:19 ` George Dunlap
2016-04-14 17:01 ` Jan Beulich
0 siblings, 1 reply; 190+ messages in thread
From: George Dunlap @ 2016-04-14 16:19 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, Ross Lagerwall, Julien Grall, Stefano Stabellini,
xen-devel, sasha.levin, Daniel De Graaf, Keir Fraser
On Thu, Apr 14, 2016 at 4:59 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>>> George Dunlap <george.dunlap@citrix.com> 04/14/16 5:16 PM >>>
>>On the other hand, I think there's a bit of a faulty interpretation of
>>the procedure here. Jan reviewed the patch thoroughly and then acked
>>it; on the basis of that, Konrad legitimately checked it in. After it
>>was checked in Jan said, "I've changed my mind and withdraw my Ack";
>>and the assumption of the subsequent conversation was that an ack
>>*can* be withdrawn after it has been legitimately checked in, and that
>>if no other Ack is supplied, then it must be reverted.
>>
>>I don't think that's a correct interpretation of the rules. Reviewers
>>in general, and maintainers in particular, should make reasonably sure
>>that they mean the Ack before they give it; and if they change their
>>mind after it has been legitimately checked in, then it's now up to
>>them to make the change they want to see according to the regular
>>procedure. That is, if Jan wants it reverted, he needs to post a
>>patch reverting it and get Acks from the appropriate maintainers; and
>>the discussion needs to be around Jan's reversion being accepted, not
>>about Konrad's original patch continuing to be accepted. (Obvious
>>exceptions can be made in the case of emergencies like build
>>breakages.)
>
> Fundamentally I agree, but I think there's more to this than just following
> a set of rules. For example, please don't forget the time pressure due to
> the (at that time) rapidly approaching freeze date. And then, mistakes
> happen, and so I made a mistake here by sending the ack a few hours too
> early.
Sure, mistakes happen; but I hope it's not being to controversial to
say that in general, the procedure should be arranged such that the
person who makes the mistake is the one who has to do deal with the
most consequences from the mistake, not the people around him. I
mean, if you asked a bartender for a bottle of beer, and after he'd
already opened it you said, "Oh sorry, I actually wanted a cider", it
would be fair enough for the bartender to ask you to pay for the beer,
rather than eating it*, wouldn't it? :-)
> What is really hard to understand to me is why it is so difficult to just
> get a refereeing opinion on the actual interface change. IMO we don't
> really need to discuss rules and processes, the question is as simple
> as "Do we want/need this new interface?"
Well Ian and I have already given our opinions -- Ian thinks moving to
a clean interface and deprecating the old one is in general a good
thing, and doesn't look too painful in this case. I don't really see
a problem with using a large fixed size, but I don't fundamentally see
a problem with moving to a new clean interface either. Given that
Andy has a strong aversion to the way things are, if you had only a
mild distaste rather than a strong objection to the new hypercall, it
would probably make sense to go with the new hypercall.
If you do have a strong objection, then maybe we could try to convince
Andy to accept adding subops with different calling semantics to the
existing hypercall. But I would still think the burden of persuasion
is primarily on you.
-George
* In this context "eating" something means just accepting the loss of
the thing yourself. For instance, if you bought two tickets to a
concert but couldn't convince anyone to go with you, you'd say you had
to "eat the other ticket". Here it means the bartender throws the
beer away and accepts the loss himself.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-14 16:19 ` George Dunlap
@ 2016-04-14 17:01 ` Jan Beulich
2016-04-14 18:11 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages] Ian Jackson
2016-04-15 11:23 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane George Dunlap
0 siblings, 2 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-14 17:01 UTC (permalink / raw)
To: george.dunlap
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, Ian.Jackson,
mpohlack, ross.lagerwall, julien.grall, stefano.stabellini,
sasha.levin, xen-devel, dgdegra, keir
>>> George Dunlap <george.dunlap@citrix.com> 04/14/16 6:20 PM >>>
>On Thu, Apr 14, 2016 at 4:59 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>>>> George Dunlap <george.dunlap@citrix.com> 04/14/16 5:16 PM >>>
>>>On the other hand, I think there's a bit of a faulty interpretation of
>>>the procedure here. Jan reviewed the patch thoroughly and then acked
>>>it; on the basis of that, Konrad legitimately checked it in. After it
>>>was checked in Jan said, "I've changed my mind and withdraw my Ack";
>>>and the assumption of the subsequent conversation was that an ack
>>>*can* be withdrawn after it has been legitimately checked in, and that
>>>if no other Ack is supplied, then it must be reverted.
>>>
>>>I don't think that's a correct interpretation of the rules. Reviewers
>>>in general, and maintainers in particular, should make reasonably sure
>>>that they mean the Ack before they give it; and if they change their
>>>mind after it has been legitimately checked in, then it's now up to
>>>them to make the change they want to see according to the regular
>>>procedure. That is, if Jan wants it reverted, he needs to post a
>>>patch reverting it and get Acks from the appropriate maintainers; and
>>>the discussion needs to be around Jan's reversion being accepted, not
>>>about Konrad's original patch continuing to be accepted. (Obvious
>>>exceptions can be made in the case of emergencies like build
>>>breakages.)
>>
>> Fundamentally I agree, but I think there's more to this than just following
>> a set of rules. For example, please don't forget the time pressure due to
>> the (at that time) rapidly approaching freeze date. And then, mistakes
>> happen, and so I made a mistake here by sending the ack a few hours too
>> early.
>
>Sure, mistakes happen; but I hope it's not being to controversial to
>say that in general, the procedure should be arranged such that the
>person who makes the mistake is the one who has to do deal with the
>most consequences from the mistake, not the people around him. I
>mean, if you asked a bartender for a bottle of beer, and after he'd
>already opened it you said, "Oh sorry, I actually wanted a cider", it
>would be fair enough for the bartender to ask you to pay for the beer,
>rather than eating it*, wouldn't it? :-)
Sure. And I think that's what I've done. I suggested to revert the thing,
collecting opinions either direction. I just didn't post a revert patch, as I
think that makes little sense - a revert is a mechanical operation, which
doesn't need people looking at the actual patch.
>Well Ian and I have already given our opinions -- Ian thinks moving to
>a clean interface and deprecating the old one is in general a good
>thing, and doesn't look too painful in this case. I don't really see
>a problem with using a large fixed size, but I don't fundamentally see
>a problem with moving to a new clean interface either. Given that
>Andy has a strong aversion to the way things are, if you had only a
>mild distaste rather than a strong objection to the new hypercall, it
>would probably make sense to go with the new hypercall.
>
>If you do have a strong objection, then maybe we could try to convince
>Andy to accept adding subops with different calling semantics to the
>existing hypercall. But I would still think the burden of persuasion
>is primarily on you.
I do not have a strong objection, or else I would have converted my ack
into a nak instead of just withdrawing it. I just dislike the duplication, and
hence I'm not happy with me now being the one having approved it to go
in. Hence the request for a replacement ack (or whatever else referee
decision).
And btw., considering that Konrad has already posted a revert patch,
and I have ack-ed that one, this could now go in right away (and the
discussion could either be settled or start over).
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages]
2016-04-14 17:01 ` Jan Beulich
@ 2016-04-14 18:11 ` Ian Jackson
2016-04-14 19:22 ` Konrad Rzeszutek Wilk
2016-04-17 7:23 ` Jan Beulich
2016-04-15 11:23 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane George Dunlap
1 sibling, 2 replies; 190+ messages in thread
From: Ian Jackson @ 2016-04-14 18:11 UTC (permalink / raw)
To: Jan Beulich, George Dunlap
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, mpohlack,
Ross Lagerwall, Julien Grall, Stefano Stabellini, sasha.levin,
xen-devel, Daniel De Graaf, Keir Fraser
George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> On the other hand, I think there's a bit of a faulty interpretation of
> the procedure here. Jan reviewed the patch thoroughly and then acked
> it; on the basis of that, Konrad legitimately checked it in. After it
> was checked in Jan said, "I've changed my mind and withdraw my Ack";
> and the assumption of the subsequent conversation was that an ack
> *can* be withdrawn after it has been legitimately checked in, and that
> if no other Ack is supplied, then it must be reverted.
>
> I don't think that's a correct interpretation of the rules. Reviewers
> in general, and maintainers in particular, should make reasonably sure
> that they mean the Ack before they give it; and if they change their
> mind after it has been legitimately checked in, then it's now up to
> them to make the change they want to see according to the regular
> procedure.
For the record, I agree completely with George here. I was expecting
that the next step would be to for Jan to post patches to revert the
extra hypercall and replace it with something else.
Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:
> And btw., considering that Konrad has already posted a revert patch,
> and I have ack-ed that one, this could now go in right away (and the
> discussion could either be settled or start over).
I don't see that patch you describe in my inbox, but maybe I have
missed it.
If that reversion is proposed, following a request for a 2nd/3rd
opinion from me and George, and given the discussion so far, I think
that patch ought to have been CC'd to me and George.
I don't think it would be appropriate to commit a revert except as
part of a series which introduces an replacement way of providing the
needed functionality - at least, enough functionality that in practice
a plausibly long build-id can be retrieved.
If you want the original reverted, I think it is up to you, Jan, to
provide (or procure) such a replacement.
Thanks,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages]
2016-04-14 18:11 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages] Ian Jackson
@ 2016-04-14 19:22 ` Konrad Rzeszutek Wilk
2016-04-17 7:23 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-14 19:22 UTC (permalink / raw)
To: Ian Jackson
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, George Dunlap,
mpohlack, Ross Lagerwall, Julien Grall, Stefano Stabellini,
Jan Beulich, sasha.levin, xen-devel, Daniel De Graaf,
Keir Fraser
On Thu, Apr 14, 2016 at 07:11:46PM +0100, Ian Jackson wrote:
> George Dunlap writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane."):
> > On the other hand, I think there's a bit of a faulty interpretation of
> > the procedure here. Jan reviewed the patch thoroughly and then acked
> > it; on the basis of that, Konrad legitimately checked it in. After it
> > was checked in Jan said, "I've changed my mind and withdraw my Ack";
> > and the assumption of the subsequent conversation was that an ack
> > *can* be withdrawn after it has been legitimately checked in, and that
> > if no other Ack is supplied, then it must be reverted.
> >
> > I don't think that's a correct interpretation of the rules. Reviewers
> > in general, and maintainers in particular, should make reasonably sure
> > that they mean the Ack before they give it; and if they change their
> > mind after it has been legitimately checked in, then it's now up to
> > them to make the change they want to see according to the regular
> > procedure.
>
> For the record, I agree completely with George here. I was expecting
> that the next step would be to for Jan to post patches to revert the
> extra hypercall and replace it with something else.
>
> Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:
> > And btw., considering that Konrad has already posted a revert patch,
> > and I have ack-ed that one, this could now go in right away (and the
> > discussion could either be settled or start over).
>
> I don't see that patch you describe in my inbox, but maybe I have
> missed it.
It is part of my series. This is the revert (there are two of them)
http://lists.xen.org/archives/html/xen-devel/2016-04/msg01913.html
http://lists.xen.org/archives/html/xen-devel/2016-04/msg01926.html
And then these two patches add build-id using the XENVER hypercall:
http://lists.xen.org/archives/html/xen-devel/2016-04/msg01923.html
http://lists.xen.org/archives/html/xen-devel/2016-04/msg01902.html
>
> If that reversion is proposed, following a request for a 2nd/3rd
> opinion from me and George, and given the discussion so far, I think
> that patch ought to have been CC'd to me and George.
Argh, I probably missed you and George on them. My apologies!
>
> I don't think it would be appropriate to commit a revert except as
> part of a series which introduces an replacement way of providing the
> needed functionality - at least, enough functionality that in practice
> a plausibly long build-id can be retrieved.
>
> If you want the original reverted, I think it is up to you, Jan, to
> provide (or procure) such a replacement.
>
> Thanks,
> Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-14 17:01 ` Jan Beulich
2016-04-14 18:11 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages] Ian Jackson
@ 2016-04-15 11:23 ` George Dunlap
2016-04-17 7:52 ` Jan Beulich
1 sibling, 1 reply; 190+ messages in thread
From: George Dunlap @ 2016-04-15 11:23 UTC (permalink / raw)
To: Jan Beulich
Cc: Wei Liu, Stefano Stabellini, Andrew Cooper, Ian Jackson,
mpohlack, Ross Lagerwall, Julien Grall, Stefano Stabellini,
xen-devel, sasha.levin, Daniel De Graaf, Keir Fraser
On Thu, Apr 14, 2016 at 6:01 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>Sure, mistakes happen; but I hope it's not being to controversial to
>>say that in general, the procedure should be arranged such that the
>>person who makes the mistake is the one who has to do deal with the
>>most consequences from the mistake, not the people around him. I
>>mean, if you asked a bartender for a bottle of beer, and after he'd
>>already opened it you said, "Oh sorry, I actually wanted a cider", it
>>would be fair enough for the bartender to ask you to pay for the beer,
>>rather than eating it*, wouldn't it? :-)
>
> Sure. And I think that's what I've done. I suggested to revert the thing,
> collecting opinions either direction. I just didn't post a revert patch, as I
> think that makes little sense - a revert is a mechanical operation, which
> doesn't need people looking at the actual patch.
You don't need people to review the content of the actual patch, but
it provides a standardized way to have a discussion about the patch,
and it makes it clear what the procedure is for having it applied.
You don't need any technical code review for adding or removing
maintainers either, but we ask people to send patches to the
MAINTAINERS file anyway, because it provides a structured way to have
an open discussion and make a decision.
When Konrad asked for further input on the patch and then didn't get
any in a few days, you responded, "It looks like it will have to be
reverted then." As I've said, I think that's the wrong way round --
it's not that the commit is reverted unless someone else acks it; it's
that the commit stays unless someone acks your reversion. If you had
posted a patch (probably RFC) requesting to revert the change in favor
of a different one, then it would have been more obvious that the
burden was on you to get the reversion Acked, rather than on Konrad to
get the existing commit re-acked.
>>Well Ian and I have already given our opinions -- Ian thinks moving to
>>a clean interface and deprecating the old one is in general a good
>>thing, and doesn't look too painful in this case. I don't really see
>>a problem with using a large fixed size, but I don't fundamentally see
>>a problem with moving to a new clean interface either. Given that
>>Andy has a strong aversion to the way things are, if you had only a
>>mild distaste rather than a strong objection to the new hypercall, it
>>would probably make sense to go with the new hypercall.
>>
>>If you do have a strong objection, then maybe we could try to convince
>>Andy to accept adding subops with different calling semantics to the
>>existing hypercall. But I would still think the burden of persuasion
>>is primarily on you.
>
> I do not have a strong objection, or else I would have converted my ack
> into a nak instead of just withdrawing it. I just dislike the duplication, and
> hence I'm not happy with me now being the one having approved it to go
> in. Hence the request for a replacement ack (or whatever else referee
> decision).
Well this makes it sound like you're saying that you were asking us to
save you from having to appear to have approved of a patch that you
didn't like. Which doesn't sound very nice. :-)
But I wonder if something slightly different is going on. Forgive me
for trying to guess at motivations here, but I think it may be
helpful. I'm often in the situation where my gut objects to a patch
that other coders I respect think is fine; and often a few years down
the road, I look back and agree that it's fine as well. In other
words, I know that sometimes my own objections turn out to be
unreasonable; and that in any case, working with other people you
sometimes have to compromise. But on the other hand, I've also had
the experience of giving in and accepting patches that later I regret,
or that other people come back and say, "This was a terrible idea, you
should have stood up for it more."
So in the moment -- particularly, as you say, under time pressure --
how do you determine if objecting to the patch is being unreasonable
and obstructive, or if assenting to the patch is failing your duty as
a maintainer to prevent bad code, and is a decision you'll regret
later?
Was it perhaps actually the case that your internal reasoning was
along the lines of, "Actually, adding a new hypercall seems like a bad
idea. But since Andrew strongly disagrees, maybe I'm being
unreasonable. Or, maybe it really is a bad idea and he's being
unreasonable. Why don't I ask the REST maintainers to look at it; if
they Ack it, then I'm probably being too conservative; if they don't,
then I'm probably justified in objecting to it"?
If so, we should probably find a better way for maintainers to ask for
additional feedback in those situations. :-) I'd certainly appreciate
that at times.
If that's not the case, and you genuinely only have a mild dislike for
the hypercall, then there are a couple of things to say about that.
The first is that given the circumstances, it seems to me that giving
the Ack was not only reasonable, but the right thing to do. An Ack
doesn't mean, "I think this is a good idea", but it means "Given all
considerations, I think this should be in the tree." And given that
Andrew had strong objections to the other solutions, and you only had
a distaste for this one, this is obviously the solution to choose.
Acking a patch on the basis that you don't really like it but it's the
best compromise with the other maintainers is perfectly reasonable.
Secondly, I can certainly see that you might be a bit embarrased
about having your name on a patch you dislike, but... well, you did in
fact approve it going in. :-) Maybe that was because you were in
haste, and you regret it, but that's an accurate record of what
happened. Stand up and take responsibility for your actions. :-)
> And btw., considering that Konrad has already posted a revert patch,
> and I have ack-ed that one, this could now go in right away (and the
> discussion could either be settled or start over).
Yes, unless someone objects to that patch then we have a clear way
forward, and we're just discussing principles for future reference at
this point.
-George
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages]
2016-04-14 18:11 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages] Ian Jackson
2016-04-14 19:22 ` Konrad Rzeszutek Wilk
@ 2016-04-17 7:23 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-17 7:23 UTC (permalink / raw)
To: george.dunlap, Ian.Jackson
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, mpohlack,
ross.lagerwall, julien.grall, stefano.stabellini, sasha.levin,
xen-devel, dgdegra, keir
>>> Ian Jackson <Ian.Jackson@eu.citrix.com> 04/14/16 8:12 PM >>>
>Jan Beulich writes ("Re: [Xen-devel] REST MAINTAINERS feedback requested Was:
>> And btw., considering that Konrad has already posted a revert patch,
>> and I have ack-ed that one, this could now go in right away (and the
>> discussion could either be settled or start over).
>
>I don't see that patch you describe in my inbox, but maybe I have
>missed it.
Patches 1 and 2 of the most recent v8.1 series.
>If that reversion is proposed, following a request for a 2nd/3rd
>opinion from me and George, and given the discussion so far, I think
>that patch ought to have been CC'd to me and George.
>
>I don't think it would be appropriate to commit a revert except as
>part of a series which introduces an replacement way of providing the
>needed functionality - at least, enough functionality that in practice
>a plausibly long build-id can be retrieved.
For one, the revert wouldn't revert that functionality, as that didn't even go
in yet.
>If you want the original reverted, I think it is up to you, Jan, to
>provide (or procure) such a replacement.
And with that (albeit not just because of it not being in yet at all), I don't see
why this would be the case. I think there's some general disagreement here,
which with the hackathon around the corner we probably should just get
sorted out in person there.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane.
2016-04-15 11:23 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane George Dunlap
@ 2016-04-17 7:52 ` Jan Beulich
0 siblings, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-17 7:52 UTC (permalink / raw)
To: george.dunlap
Cc: wei.liu2, stefano.stabellini, andrew.cooper3, Ian.Jackson,
mpohlack, ross.lagerwall, julien.grall, stefano.stabellini,
sasha.levin, xen-devel, dgdegra, keir
>>> George Dunlap <george.dunlap@citrix.com> 04/15/16 1:23 PM >>>
>On Thu, Apr 14, 2016 at 6:01 PM, Jan Beulich <jbeulich@suse.com> wrote:
>>>Sure, mistakes happen; but I hope it's not being to controversial to
>>>say that in general, the procedure should be arranged such that the
>>>person who makes the mistake is the one who has to do deal with the
>>>most consequences from the mistake, not the people around him. I
>>>mean, if you asked a bartender for a bottle of beer, and after he'd
>>>already opened it you said, "Oh sorry, I actually wanted a cider", it
>>>would be fair enough for the bartender to ask you to pay for the beer,
>>>rather than eating it*, wouldn't it? :-)
>>
>> Sure. And I think that's what I've done.
To be fair, I think this was too broad a statement: I had indeed asked Konrad
to collect the replacement ack. Yet on second thought I really can't see
what's wrong with withdraing an ack - just like a patch can be withdrawn, that
should be possible for an ack too. And if the patch has already gone in, no
matter whether the patch itself or the ack got withdrawn, the patch imo should
then be reverted. I agree that's not something spelled out anywhere, so my
opinion here is based on solely general considerations of mine.
>When Konrad asked for further input on the patch and then didn't get
>any in a few days, you responded, "It looks like it will have to be
>reverted then." As I've said, I think that's the wrong way round --
>it's not that the commit is reverted unless someone else acks it; it's
>that the commit stays unless someone acks your reversion. If you had
>posted a patch (probably RFC) requesting to revert the change in favor
>of a different one, then it would have been more obvious that the
>burden was on you to get the reversion Acked, rather than on Konrad to
>get the existing commit re-acked.
I agree on the process aspect (albeit among the few cases where things
needed reverting, I think there was a non-negligible amount of such where
the revert was requested quite informally), but that's relatively moot with me
not agreeing on the premises it builds upon.
>>>Well Ian and I have already given our opinions -- Ian thinks moving to
>>>a clean interface and deprecating the old one is in general a good
>>>thing, and doesn't look too painful in this case. I don't really see
>>>a problem with using a large fixed size, but I don't fundamentally see
>>>a problem with moving to a new clean interface either. Given that
>>>Andy has a strong aversion to the way things are, if you had only a
>>>mild distaste rather than a strong objection to the new hypercall, it
>>>would probably make sense to go with the new hypercall.
>>>
>>>If you do have a strong objection, then maybe we could try to convince
>>>Andy to accept adding subops with different calling semantics to the
>>>existing hypercall. But I would still think the burden of persuasion
>>>is primarily on you.
>>
>> I do not have a strong objection, or else I would have converted my ack
>> into a nak instead of just withdrawing it. I just dislike the duplication, and
>> hence I'm not happy with me now being the one having approved it to go
>> in. Hence the request for a replacement ack (or whatever else referee
>> decision).
>
>Well this makes it sound like you're saying that you were asking us to
>save you from having to appear to have approved of a patch that you
>didn't like. Which doesn't sound very nice. :-)
I'm sorry if it's being understood that way. My intention really was to avoid
the revert in case a replacement ack can be obtained. Otherwise, following
my way of thinking outlined above, the patch should have been reverted
right away. Yet I seem to be the only one here thinking this way...
>But I wonder if something slightly different is going on. Forgive me
>for trying to guess at motivations here, but I think it may be
>helpful. I'm often in the situation where my gut objects to a patch
>that other coders I respect think is fine; and often a few years down
>the road, I look back and agree that it's fine as well. In other
>words, I know that sometimes my own objections turn out to be
>unreasonable; and that in any case, working with other people you
>sometimes have to compromise. But on the other hand, I've also had
>the experience of giving in and accepting patches that later I regret,
>or that other people come back and say, "This was a terrible idea, you
>should have stood up for it more."
>
>So in the moment -- particularly, as you say, under time pressure --
>how do you determine if objecting to the patch is being unreasonable
>and obstructive, or if assenting to the patch is failing your duty as
>a maintainer to prevent bad code, and is a decision you'll regret
>later?
>
>Was it perhaps actually the case that your internal reasoning was
>along the lines of, "Actually, adding a new hypercall seems like a bad
>idea. But since Andrew strongly disagrees, maybe I'm being
>unreasonable. Or, maybe it really is a bad idea and he's being
>unreasonable. Why don't I ask the REST maintainers to look at it; if
>they Ack it, then I'm probably being too conservative; if they don't,
>then I'm probably justified in objecting to it"?
Well, not really. My main problem here (and not just here) is that often
I end up reviewing patches for being done correctly, but ignore the question
of "Do we need this in the first place?" This has happened to me more
often earlier on, but it continues to happen from time to time, like on this
occasion.
>If so, we should probably find a better way for maintainers to ask for
>additional feedback in those situations. :-) I'd certainly appreciate
>that at times.
Well, the main problem I'm seeing here that the current set of REST
maintainers makes it very hard to get _any_ kind of feedback without
explicitly asking and pinging for it. I sincerely hope that this will change
with the pending committership and maintainership adjustments. My
general understanding here is that it shouldn't be really necessary to
explicitly ask for a second opinion - after all maintainers get Cc-ed on
patches for the reason of seeking their input. And the question of
replacing an existing public interface with a slightly different new one,
even more so with no obvious route of deprecating the old one, is
something that any one of the REST maintainers should really have
an opinion on imo.
>If that's not the case, and you genuinely only have a mild dislike for
>the hypercall, then there are a couple of things to say about that.
>The first is that given the circumstances, it seems to me that giving
>the Ack was not only reasonable, but the right thing to do. An Ack
>doesn't mean, "I think this is a good idea", but it means "Given all
>considerations, I think this should be in the tree." And given that
>Andrew had strong objections to the other solutions, and you only had
>a distaste for this one, this is obviously the solution to choose.
>Acking a patch on the basis that you don't really like it but it's the
>best compromise with the other maintainers is perfectly reasonable.
Taking a strictly formal perspective, there was no disagreement between
maintainers, since I've been the only one of those currently named under
REST involved in the discussion. Which is part of the problem, as said
above. And Andrew's strong objection was, in my view, based on not very
convincing arguments. Hence I couldn't really see myself making a
reasonable compromise here.
>Secondly, I can certainly see that you might be a bit embarrased
>about having your name on a patch you dislike, but... well, you did in
>fact approve it going in. :-) Maybe that was because you were in
>haste, and you regret it, but that's an accurate record of what
>happened. Stand up and take responsibility for your actions. :-)
Which is why - see above - I didn't revert it right away.
>> And btw., considering that Konrad has already posted a revert patch,
>> and I have ack-ed that one, this could now go in right away (and the
>> discussion could either be settled or start over).
>
>Yes, unless someone objects to that patch then we have a clear way
>forward, and we're just discussing principles for future reference at
>this point.
Agreed. As said in reply to Ian - perhaps worth taking some time at the
hackathon.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-11 8:23 ` Ross Lagerwall
@ 2016-04-22 13:33 ` Jan Beulich
2016-04-22 13:58 ` Jan Beulich
1 sibling, 0 replies; 190+ messages in thread
From: Jan Beulich @ 2016-04-22 13:33 UTC (permalink / raw)
To: Ross Lagerwall
Cc: keir, andrew.cooper3, mpohlack, mpohlack, sasha.levin, xen-devel
>>> On 11.04.16 at 10:23, <ross.lagerwall@citrix.com> wrote:
> Some examples:
> XSA-80: In addition to patching the code, a hook function is needed to
> set iommu_dont_flush_iotlb back to 0.
I don't think this is an issue that can be reasonably life patched:
Doing so would likely lead to the false impression that everything
is fine after the patching, which it isn't as you don't know what
other flushing didn't happen as needed, and hence what else is
in a broken state at the point of patching.
> XSA-82: The original patch applies to an __init function. Instead, use a
> hook function to update the MSR.
__devinit == <nothing> (i.e. != __init)
The right way to deal with MSR value changes post boot imo is
to run a utility from Dom0 user mode which fiddles with the MSR
on all CPUs. No need for a patch to also deal with machine state.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-11 8:23 ` Ross Lagerwall
2016-04-22 13:33 ` Jan Beulich
@ 2016-04-22 13:58 ` Jan Beulich
2016-04-22 17:32 ` Konrad Rzeszutek Wilk
1 sibling, 1 reply; 190+ messages in thread
From: Jan Beulich @ 2016-04-22 13:58 UTC (permalink / raw)
To: Ross Lagerwall
Cc: keir, andrew.cooper3, mpohlack, mpohlack, sasha.levin, xen-devel
>>> On 11.04.16 at 10:23, <ross.lagerwall@citrix.com> wrote:
> On 04/08/2016 06:39 PM, Jan Beulich wrote:
>>>>> On 08.04.16 at 17:57, <ross.lagerwall@citrix.com> wrote:
>>> I've marked the following XSAs as potentially requiring hook functions
>>> or shadow variables:
>>>
>>> XSA-36
Again an example that I don't think can be live patched: The ACPI
tables the parsing of which gets adjusted may not be available
anymore at the time of patching.
>>> XSA-45
Hmm, this one is adding a field to struct vcpu, which by itself
already makes it very difficult to deal with this correctly in a
patch. But yes, to construct such a beast (if that's possible at
all), I can see how either or both of the above could be useful
here.
>>> XSA-60
While the field additions could be dealt with here, this again is
so complex a change that I personally wouldn't dare to
recommend using a live patch for this, even if someone managed
to create one.
>>> XSA-64
I don't think this can be fixed for any guests already started, as
it doesn't look like simply going and zapping the mis-initialized L4
entries would actually be correct in all cases.
>>> XSA-97
A field addition to an existing structure again - see above.
>>> XSA-107
Yes, this indeed could be dealt with in a hook (but I can also see
ways to deal with this without).
>>> XSA-114
Hmm, yes, if you really manage to enumerate all r/w locks in
the system, this could be dealt with in a hook too.
>>> XSA-150
Growing a structure again, so see above.
Overall I think that all of the cited examples are such which already
don't really lend themselves to live patching. Hence I think we're
going to be fine without these extra two pieces for the initial round,
taking into consideration just those cases where live patching is
reasonable to do.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
* Re: [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case
2016-04-22 13:58 ` Jan Beulich
@ 2016-04-22 17:32 ` Konrad Rzeszutek Wilk
0 siblings, 0 replies; 190+ messages in thread
From: Konrad Rzeszutek Wilk @ 2016-04-22 17:32 UTC (permalink / raw)
To: Jan Beulich
Cc: keir, andrew.cooper3, mpohlack, mpohlack, Ross Lagerwall,
sasha.levin, xen-devel
> Overall I think that all of the cited examples are such which already
> don't really lend themselves to live patching. Hence I think we're
> going to be fine without these extra two pieces for the initial round,
/me nods.
> taking into consideration just those cases where live patching is
> reasonable to do.
I've dropped them from my v1 patchset.
>
> Jan
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 190+ messages in thread
end of thread, other threads:[~2016-04-22 17:32 UTC | newest]
Thread overview: 190+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-24 20:00 [PATCH v5] xSplice v1 design and implementation Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane Konrad Rzeszutek Wilk
2016-03-24 20:22 ` Andrew Cooper
2016-03-24 21:07 ` Konrad Rzeszutek Wilk
2016-03-24 21:30 ` Konrad Rzeszutek Wilk
2016-03-30 15:43 ` Jan Beulich
2016-03-31 6:30 ` Jan Beulich
2016-03-31 11:43 ` Konrad Rzeszutek Wilk
2016-03-31 12:07 ` Jan Beulich
2016-03-31 13:28 ` REST MAINTAINERS feedback requested Was:Re: " Konrad Rzeszutek Wilk
2016-03-31 13:50 ` Jan Beulich
2016-04-08 16:33 ` Jan Beulich
2016-04-08 17:09 ` Konrad Rzeszutek Wilk
2016-04-08 17:13 ` Jan Beulich
2016-04-08 17:21 ` Wei Liu
2016-04-08 17:23 ` Konrad Rzeszutek Wilk
2016-04-08 17:27 ` Wei Liu
2016-04-08 17:21 ` Ian Jackson
2016-04-08 17:41 ` Andrew Cooper
2016-04-08 17:54 ` Jan Beulich
2016-04-11 10:50 ` Ian Jackson
2016-04-11 13:56 ` Konrad Rzeszutek Wilk
2016-04-11 14:22 ` Ian Jackson
2016-04-11 15:48 ` Jan Beulich
2016-04-11 16:25 ` Ian Jackson
2016-04-11 16:53 ` Konrad Rzeszutek Wilk
2016-04-11 17:06 ` Jan Beulich
2016-04-11 17:00 ` Jan Beulich
2016-04-11 17:13 ` Ian Jackson
2016-04-11 17:34 ` Jan Beulich
2016-04-11 17:46 ` Jan Beulich
2016-04-12 9:58 ` George Dunlap
2016-04-12 13:56 ` Konrad Rzeszutek Wilk
2016-04-12 14:38 ` George Dunlap
2016-04-12 15:00 ` Konrad Rzeszutek Wilk
2016-04-12 15:26 ` Ian Jackson
2016-04-13 4:21 ` Jan Beulich
2016-04-13 16:07 ` Ian Jackson
2016-04-14 15:13 ` George Dunlap
2016-04-14 15:59 ` Jan Beulich
2016-04-14 16:19 ` George Dunlap
2016-04-14 17:01 ` Jan Beulich
2016-04-14 18:11 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane. [and 1 more messages] Ian Jackson
2016-04-14 19:22 ` Konrad Rzeszutek Wilk
2016-04-17 7:23 ` Jan Beulich
2016-04-15 11:23 ` REST MAINTAINERS feedback requested Was:Re: [PATCH v5 01/28] HYPERCALL_version_op. New hypercall mirroring XENVER_ but sane George Dunlap
2016-04-17 7:52 ` Jan Beulich
2016-04-12 15:31 ` Jan Beulich
2016-04-12 15:17 ` Jan Beulich
2016-04-12 15:28 ` Konrad Rzeszutek Wilk
2016-04-08 17:24 ` George Dunlap
2016-04-08 17:34 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 02/28] libxc/libxl/python/xenstat/ocaml: Use new XEN_VERSION hypercall Konrad Rzeszutek Wilk
2016-03-24 21:24 ` Wei Liu
2016-03-25 13:21 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 03/28] arm/x86: Use struct virtual_region to do bug, symbol, and (x86) exception tables lookup Konrad Rzeszutek Wilk
2016-03-30 16:09 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 04/28] vmap: Add vmalloc_cb and vfree_cb Konrad Rzeszutek Wilk
2016-03-30 16:24 ` Jan Beulich
2016-03-30 16:44 ` Konrad Rzeszutek Wilk
2016-03-31 6:46 ` Jan Beulich
2016-03-31 11:49 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 05/28] xsplice: Design document Konrad Rzeszutek Wilk
2016-03-29 9:36 ` Jan Beulich
2016-03-29 20:46 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 06/28] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
2016-03-31 9:45 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 07/28] libxc: Implementation of XEN_XSPLICE_op in libxc Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 08/28] xen-xsplice: Tool to manipulate xsplice payloads Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 09/28] xsplice: Add helper elf routines Konrad Rzeszutek Wilk
2016-03-31 12:03 ` Jan Beulich
2016-04-06 1:38 ` Konrad Rzeszutek Wilk
2016-04-07 0:38 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 10/28] xsplice: Implement payload loading Konrad Rzeszutek Wilk
2016-03-31 13:45 ` Jan Beulich
2016-03-31 21:26 ` Konrad Rzeszutek Wilk
2016-04-01 9:18 ` Jan Beulich
2016-04-04 19:44 ` Konrad Rzeszutek Wilk
2016-04-05 1:57 ` Konrad Rzeszutek Wilk
2016-04-05 7:34 ` Jan Beulich
2016-04-05 15:50 ` Konrad Rzeszutek Wilk
2016-04-05 16:15 ` Jan Beulich
2016-04-05 16:45 ` Konrad Rzeszutek Wilk
2016-04-05 17:48 ` Konrad Rzeszutek Wilk
2016-04-07 0:49 ` Jan Beulich
2016-04-07 0:46 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 11/28] xsplice: Implement support for applying/reverting/replacing patches Konrad Rzeszutek Wilk
2016-04-01 13:28 ` Jan Beulich
2016-04-01 21:04 ` Konrad Rzeszutek Wilk
2016-04-04 7:07 ` Jan Beulich
2016-04-07 3:05 ` Konrad Rzeszutek Wilk
2016-04-07 15:38 ` Jan Beulich
2016-04-09 14:42 ` Konrad Rzeszutek Wilk
2016-04-11 15:38 ` Jan Beulich
2016-04-07 3:09 ` Konrad Rzeszutek Wilk
2016-04-07 15:43 ` Jan Beulich
2016-04-10 2:36 ` Konrad Rzeszutek Wilk
2016-04-10 2:45 ` Konrad Rzeszutek Wilk
2016-04-11 15:41 ` Jan Beulich
2016-04-11 23:29 ` Konrad Rzeszutek Wilk
2016-04-10 19:47 ` Is: ARM maintainers advice ..Was:Re: " Konrad Rzeszutek Wilk
2016-04-10 20:58 ` Stefano Stabellini
2016-04-11 15:44 ` Jan Beulich
2016-04-11 15:50 ` Konrad Rzeszutek Wilk
2016-04-11 16:05 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 12/28] x86/xen_hello_world.xsplice: Test payload for patching 'xen_extra_version' Konrad Rzeszutek Wilk
2016-04-01 13:33 ` Jan Beulich
2016-04-06 2:03 ` Konrad Rzeszutek Wilk
2016-04-07 1:03 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 13/28] xsplice, symbols: Implement symbol name resolution on address Konrad Rzeszutek Wilk
2016-04-01 15:11 ` Jan Beulich
2016-04-07 3:14 ` Konrad Rzeszutek Wilk
2016-04-07 15:46 ` Jan Beulich
2016-04-08 1:32 ` Konrad Rzeszutek Wilk
2016-04-08 15:21 ` Jan Beulich
2016-04-08 15:27 ` Konrad Rzeszutek Wilk
2016-04-08 15:29 ` Jan Beulich
[not found] ` <5707D68A.8090006@citrix.com>
[not found] ` <5707FA8B02000078000E6178@prv-mh.provo.novell.com>
2016-04-11 8:07 ` Ross Lagerwall
2016-03-24 20:00 ` [PATCH v5 14/28] x86, xsplice: Print payload's symbol name and payload name in backtraces Konrad Rzeszutek Wilk
2016-04-01 15:23 ` Jan Beulich
2016-04-06 2:39 ` Konrad Rzeszutek Wilk
2016-04-07 1:07 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 15/28] xsplice: Add .xsplice.hooks functions and test-case Konrad Rzeszutek Wilk
2016-04-01 15:50 ` Jan Beulich
2016-04-06 2:42 ` Konrad Rzeszutek Wilk
2016-04-06 6:39 ` Martin Pohlack
2016-04-07 1:15 ` Jan Beulich
2016-04-08 15:57 ` Ross Lagerwall
2016-04-08 17:39 ` Jan Beulich
2016-04-11 8:23 ` Ross Lagerwall
2016-04-22 13:33 ` Jan Beulich
2016-04-22 13:58 ` Jan Beulich
2016-04-22 17:32 ` Konrad Rzeszutek Wilk
2016-04-07 1:11 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 16/28] xsplice: Add support for bug frames Konrad Rzeszutek Wilk
2016-04-01 16:00 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 17/28] xsplice: Add support for exception tables Konrad Rzeszutek Wilk
2016-04-01 16:06 ` Jan Beulich
2016-04-06 14:41 ` Konrad Rzeszutek Wilk
2016-04-06 15:32 ` Andrew Cooper
2016-04-07 1:21 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 18/28] xsplice: Add support for alternatives Konrad Rzeszutek Wilk
2016-04-01 16:20 ` Jan Beulich
2016-04-07 3:11 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 19/28] build_id: Provide ld-embedded build-ids Konrad Rzeszutek Wilk
2016-04-04 12:46 ` Jan Beulich
2016-04-07 2:58 ` Konrad Rzeszutek Wilk
2016-04-08 15:49 ` Ross Lagerwall
2016-04-08 18:47 ` Konrad Rzeszutek Wilk
2016-04-08 18:54 ` Andrew Cooper
2016-04-08 19:54 ` Jan Beulich
2016-04-08 0:18 ` Konrad Rzeszutek Wilk
2016-04-08 1:52 ` Konrad Rzeszutek Wilk
2016-04-08 15:27 ` Jan Beulich
2016-04-08 17:06 ` Konrad Rzeszutek Wilk
2016-04-08 17:44 ` Jan Beulich
2016-04-08 19:23 ` Konrad Rzeszutek Wilk
2016-04-08 19:39 ` Konrad Rzeszutek Wilk
2016-04-08 20:14 ` Jan Beulich
2016-04-08 20:50 ` Konrad Rzeszutek Wilk
2016-04-08 21:11 ` Jan Beulich
2016-04-08 21:15 ` Konrad Rzeszutek Wilk
2016-04-08 15:25 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 20/28] HYPERCALL_version_op: Add VERSION_build_id to retrieve build-id Konrad Rzeszutek Wilk
2016-03-25 16:26 ` Daniel De Graaf
2016-04-04 13:35 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 21/28] libxl: info: Display build_id of the hypervisor using XEN_VERSION_build_id Konrad Rzeszutek Wilk
2016-03-25 13:25 ` Konrad Rzeszutek Wilk
2016-03-25 15:27 ` Wei Liu
2016-03-24 20:00 ` [PATCH v5 22/28] xsplice: Print build_id in keyhandler and on bootup Konrad Rzeszutek Wilk
2016-04-04 13:38 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 23/28] xsplice: Stacking build-id dependency checking Konrad Rzeszutek Wilk
2016-04-04 15:00 ` Jan Beulich
2016-04-04 20:01 ` Konrad Rzeszutek Wilk
2016-04-05 7:43 ` Jan Beulich
2016-04-08 16:15 ` Ross Lagerwall
2016-04-08 17:47 ` Jan Beulich
2016-04-06 20:05 ` Konrad Rzeszutek Wilk
2016-04-07 1:24 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 24/28] xsplice/xen_replace_world: Test-case for XSPLICE_ACTION_REPLACE Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 25/28] xsplice: Print dependency and payloads build_id in the keyhandler Konrad Rzeszutek Wilk
2016-04-04 15:03 ` Jan Beulich
2016-03-24 20:00 ` [PATCH v5 26/28] xsplice: Prevent duplicate payloads from being loaded Konrad Rzeszutek Wilk
2016-04-04 15:06 ` Jan Beulich
2016-04-04 19:52 ` Konrad Rzeszutek Wilk
2016-03-24 20:00 ` [PATCH v5 27/28] xsplice: Add support for shadow variables Konrad Rzeszutek Wilk
2016-04-04 15:18 ` Jan Beulich
2016-04-06 2:26 ` Konrad Rzeszutek Wilk
2016-04-08 15:58 ` Ross Lagerwall
2016-03-24 20:00 ` [PATCH v5 28/28] MAINTAINERS/xsplice: Add myself and Ross as the maintainers Konrad Rzeszutek Wilk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).