[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8.1 24/27] xsplice: Stacking build-id dependency checking.
>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 04/14/16 12:03 AM >>> >+.PHONY: note.o >+note.o: >+ $(OBJCOPY) -O binary --only-section=.note.gnu.build-id >$(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 Same note as on the earlier patch regarding an interrupted build here ... >+.PHONY: hello_world_note.o >+hello_world_note.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 ... and here. Thinking about it a second time, wouldn't that then also require entries in .gitignore? >$(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 note.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_note.o >+ $(LD) $(LDFLAGS) $(build_id_linker) -r -o $(XSPLICE_BYE) \ >+ xen_bye_world_func.o xen_bye_world.o hello_world_note.o Coming back to the remark on the much earlier patch: The latest here it should become pretty clear that this explicit invocation of make is getting unwieldy. >--- /dev/null >+++ b/xen/arch/x86/test/xen_bye_world.c Any comments previously given on its "hello" sibling would likely apply here too. >--- a/xen/common/version.c >+++ b/xen/common/version.c >@@ -84,9 +84,38 @@ int xen_build_id(const void **p, unsigned int *len) >/* 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, unsigned int n_sz, >+ const void **p, unsigned int *len) >+{ >+ /* Check if we really have a build-id. */ >+ if ( NT_GNU_BUILD_ID != n->type ) >+ return -ENODATA; >+ >+ if ( n->namesz >= n_sz ) >+ return -EINVAL; >+ >+ if ( n->descsz >= n_sz ) >+ return -EINVAL; >+ >+ if ( n->namesz + n->descsz >= n_sz ) >+ return -EINVAL; These three checks could be done by two ones, and for one more correctly: First check that the addition doesn't overflow, and then do the latter check. But then it looks like the addition should also include sizeof(*n) (and then use > instead of >=)? >+ /* Sanity check, name should be "GNU" for ld-generated build-id. */ >+ if ( strncmp(ELFNOTE_NAME(n), "GNU", n->namesz) != 0 ) >+ return -ENODATA; So if namesz is 3, this will (I think wrongly) pass as it seems. >@@ -96,18 +125,9 @@ static int __init xen_build_init(void) >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); >+ sz = (size_t)__note_gnu_build_id_end - (size_t)&n[0]; Why &n[0] instead of just n? >@@ -441,6 +452,7 @@ static int prepare_payload(struct payload *payload, >unsigned int i; >struct xsplice_patch_func_internal *f; >struct virtual_region *region; >+ Elf_Note *n; const >@@ -1252,6 +1343,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); const >@@ -1260,6 +1363,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, list_empty(&applied_list)); !!list_empty() Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |