profile
viewpoint
Josh Poimboeuf jpoimboe Red Hat Paducah, KY

issue commentdynup/kpatch

Need to document callback best practices

Can maybe also document how to add/remove sysfs files to existing dirs?

jpoimboe

comment created time in 13 hours

issue commentdynup/kpatch

Need to document callback best practices

Also may need to mention other things discussed like how globals are harmful though I did open another issue for that.

jpoimboe

comment created time in 14 hours

issue openeddynup/kpatch

Need to document callback best practices

Need to document the callback best practices which we defined while working on the IFU and TAA patches. Not sure whether it belongs in the author guide or in the kernel callback docs. Maybe both.

created time in 14 hours

push eventdynup/kpatch

Julien Thierry

commit sha e4b6e1ff6e3587e3d80b353089fc030dc72972fa

doc: Update broken hyperlink Referenced kernel documentation has moved from txt file to rst. Update the hyperlink to point to the correct file. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Josh Poimboeuf

commit sha ea348164f6a15b9134053c4895cf75afd720e366

Merge pull request #1058 from julien-thierry/doc-link-fix doc: Update broken hyperlink

view details

push time in 7 days

PR merged dynup/kpatch

doc: Update broken hyperlink

Referenced kernel documentation has moved from txt file to rst. Update the hyperlink to point to the correct file.

Signed-off-by: Julien Thierry jthierry@redhat.com

+1 -1

0 comment

1 changed file

julien-thierry

pr closed time in 7 days

issue openeddynup/kpatch

Storing state in global variables considered harmful

If a patch stores state in a global variable, and then the patch is later replaced with a newer cumulative patch, the global variable in the new patch will be distinct from the variable in the original patch, and thus won't have the original state. This is dangerous and needs to be prevented. Instead a shadow variable should be used to store global state.

Ideally the best option would be to report an error (or at least a warning) if non-rodata data is added to a patch. I'm not sure if there would be any false positive warnings. It needs to be investigated.

created time in 13 days

Pull request review commentdynup/kpatch

dynrela cleanups

  struct kpatch_symbol { 	unsigned long src;-	unsigned long pos;+	unsigned long sympos;

Good point. I also don't have a strong feeling either way but I might prefer to leave it as 'sympos' despite the redundancy, because that's what we call the value upstream.

jpoimboe

comment created time in 17 days

Pull request review commentdynup/kpatch

dynrela cleanups

 static void kpatch_create_patches_sections(struct kpatch_elf *kelf,  	/* count patched functions */ 	nr = 0;-	list_for_each_entry(sym, &kelf->symbols, list)-		if (sym->type == STT_FUNC && sym->status == CHANGED && !sym->parent)-			nr++;+	list_for_each_entry(sym, &kelf->symbols, list) {+		if (sym->type != STT_FUNC || sym->status != CHANGED ||+		    sym->parent)+			continue;+		nr++;

In isolation I would agree, but the benefit is that this makes the condition identical to the 2nd loop's conditional, so the reader can verify the conditions are the same and 'nr' is valid.

jpoimboe

comment created time in 19 days

create barnchjpoimboe/kpatch

branch : klp-arch-removal

created branch time in 19 days

PR opened dynup/kpatch

dynrela cleanups

Some long overdue cleanups to the dynrela and lookup code. In theory this should be no functional change.

+362 -368

0 comment

6 changed files

pr created time in 19 days

push eventjpoimboe/kpatch

Julien Thierry

commit sha 770f5292253d6c6150b2a1757072a4731687f908

kpatch-elf: Ensure stale references are not used When freeing a kpatch_elf, another object might have symbols and sections twined with elements that are getting freed. Clear the twin references, so if they are used after the object they reference is freed, the program will crash. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha 49a9adaf743d1cb6f32f453cb70db7185fb22c48

create-diff-object: Correlate objects related to a section at once Elements from the original object and the patched object can be correlated using their mangled names. In case an elements (section or symbol) could be matched with more than one object through mangling, make sure all elements related to a section are correlated with the corresponding elements of the twin section. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha e49e3a59c2204b3f3783f1cc2797062bd20cfe92

create-diff-object: Rename elements getting correlated Change 935f1998752b ('create-diff-object: simplify mangled function correlation') simplified the way symbols are correlated and got rid of symbol section renaming. As a result a symbol/section can now have a CHANGED status, being correlated to an element that doesn't have the exact same name. This will cause lookups to the original object fail when creating the new patch object. So lets bring back the symbol/section renaming, but only once they have actually been correlated. Fixes: 935f1998752b ('create-diff-object: simplify mangled function correlation') Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha 852bad5e8d4c453f98423d0ba7533db62d462659

create-diff-object: Use new helpers for static local correlation Simplify static local variable correlation and renaming code by using the newly introduced helpers for section and symbol correlation. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha 54553c062227fc291e576fc26ce2c65badcac4eb

test/unit: Update unit test submodule Include test for mangled symbol modification. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

julien-thierry

commit sha b53e4e3f44b9062a7cc63f0f3dd90f5bd257775d

Merge pull request #1048 from julien-thierry/correlation-rename-fixes Correlation rename fixes

view details

Josh Poimboeuf

commit sha 5534103a6cbab383773c48ccb36f46f6634c1167

create-diff-object: reduce indentation in kpatch_create_patches_sections() Reverse the if condition and use a 'continue' statement to reduce indentation and improve readability. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 6a1767ce00c105b4f1e6eac9763a8540e4b57bec

lookup: remove unused testing code This testing code is no longer used. Remove it. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha ec72bd6388032f3c3d284a03a2fd073eef64cf84

lookup: rename 'value' -> 'addr' Rename 'value' to 'addr' to more accurately describe it. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha e522917752b657b7d7b2794ab3485503ca6fcedb

lookup: rename 'pos' to 'sympos' To more accurately describe its purpose. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 1c141675c8853d489db6be785501dc85c24dd673

lookup: convert lookup functions to return bool IMO, the code is easier to follow if these functions return bool. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 9eef74d982c52971c11f02f3c794a32b37211c39

lookup: add 'objname' to lookup table and lookup results This will be needed for the upcoming dynrela refactoring. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 487900dc12d45a78216748de54f96475a94dd643

lookup: add duplicate symbol checks Add checks for duplicate symbols, and refactor the logic slightly. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 2e41f281339e0216a91f0c0488919deff599403b

create-diff-object: rename lookup 'result' -> 'symbol' Improve readability by renaming the lookup "result" variables to "symbol". Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 2bfae851eff1189a8e5f7e77ca067a4d4037a552

create-diff-object: refactor dynrela conversion The dynrela (aka .klp.rela) conversion logic is notoriously complex and fragile. Simplify it and improve the comments. This is mainly a cosmetic change. In theory it shouldn't change functionality or break anything. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

push time in 19 days

push eventjpoimboe/kpatch

Jessica Yu

commit sha 3d6ea904e8b0fa735625d4c59adede6683bc579f

log: include error.h Usage of error() requires error.h

view details

Jessica Yu

commit sha 6e430624099e736fc4c7aaa508e3572c9f71ad85

kpatch-elf: add livepatch related Elf constants

view details

Jessica Yu

commit sha 2c3c44fec2d37902d82b09ae6023caecd1f2bebf

kpatch-elf: add kpatch_reindex_elements() and kpatch_rebuild_rela_section_data() Move functions kpatch_reindex_elements() and kpatch_rebuild_rela_section_data() from create-diff-object.c to kpatch-elf.c. These functions will be used to rebuild kpatch elf data in create-klp-module and create-kpatch-module, i.e. during the second "phase" of kpatch-build.

view details

Jessica Yu

commit sha 91909e92734e2356c07e6b860baf5772b0a0824f

kpatch-elf: ensure SHN_LIVEPATCH syms don't get set to SHN_UNDEF when reindexing elements

view details

Jessica Yu

commit sha a3108de96aa68d930c9e2a1a4a37acbd47ff43bb

kpatch-elf: fix null dereference when sym->sec is NULL Make sure sym->sec is not NULL before checking for its rela section (sym->sec->rela). This fixes a case where an object may have STT_FUNC symbols whose the sections (sym->sec) were not selected for inclusion (or are located in another object) and hence these symbols do not have sym->sec set. This corner case only recently popped up after reusing kpatch_elf_open() on objects that have been outputted by create-diff-object (and these objects only contain the necessary sections needed for the patch module). This will also automatically exclude livepatch symbols from the check, because they do not have sections associated with them (i.e., sym->sec is NULL). We do not have to check for fentry calls for klp (SHN_LIVEPATCH) symbols, because [1] they do not have sections associated with them, [2] they are not the target functions to be patched, and [3] they are technically just placeholder symbols for symbol resolution in livepatch.

view details

Jessica Yu

commit sha dac26b8cb2f1b4012ec1018944749c2366267ada

kpatch-elf: for rela sections, find base section by index rather than name If there exist multiple sections with the same name (which can happen when using the --unique option with ld, which will be used to keep multiple (per-object) .parainstructions and .altinstructions sections separate), find_section_by_name() will only return the first section name match, which leads to incorrect base section assignments for rela sections. Fix this by using the sh_info field of the rela section to find its base section instead, which contains the index of the section to which the relocation applies.

view details

Jessica Yu

commit sha 52e2ad66cae900a18fdbd7540a7e8751c7262f69

kpatch-elf: add kpatch_remove_and_free_section() Add kpatch_remove_and_free_section(), which, given a section name, removes and frees all matching sections from the passed in kpatch_elf.

view details

Jessica Yu

commit sha b6a15f3dd6bbf85bcff8691115f0249a6f6a2d99

create-diff-object: rename 'name' variable to 'objname' 'name' isn't very descriptive, rename it to 'objname' to avoid confusion

view details

Jessica Yu

commit sha 58de46cb9e5357405c9fb731b1ed15aff408c4df

lookup: parse Module.symvers in lookup_open() Have lookup_open() also parse Module.symvers and add the resulting symbols and their objnames to the lookup table. This code was essentially cherry-picked from Josh Poimboeuf's lookup code found here: https://github.com/jpoimboe/kpatch/commit/8cdca59c8844505bcf40b59b5c5050b03e974fea That patch was modified to fix a bug in obj_read() (calling elf_end() without strdup'ing the symbol name strings, which was causing null dereferences) and to fix up the module name after reading it from Module.symvers (replacing '-' with '_' and stripping the path prefixes). Also, add lookup_exported_symbol_objname(), which looks up the objname of an exported symbol by making use of the objname information obtained from Module.symvers.

view details

Jessica Yu

commit sha 87643703a75746e03c6942f7ecc722113fa21783

create-diff-object: create .kpatch.relocations and .kpatch.symbols sections Instead of creating dynrela sections, have create-diff-object create intermediate sections .kpatch.relocations and .kpatch.symbols which can then be used to build (depending on kernel version) either dynrela sections or klp rela/klp arch sections + klp symbols in a later phase of kpatch-build.

view details

Jessica Yu

commit sha 42902d0fccd8a4889b5923aeff622681851ad68c

create-diff-object: create intermediate .kpatch.arch section In addition to .kpatch.relocations and .kpatch.symbols, have create-diff-object create an .kpatch.arch section. This section can be used to create .klp.arch. sections that are required for klp modules built for versions >= 4.9. Each entry in the .kpatch.arch section represents an arch-specific section (.altinstructions or .parainstructions) and contains a pointer to the arch-specific section itself (see kpatch_arch struct member 'sec') and a pointer to the objname string (see kpatch_arch struct member 'objname'). This is enough information to be able to build .klp.arch. sections in a later phase of kpatch-build.

view details

Jessica Yu

commit sha 900d28fe752396154da038356c95126d048223de

kpatch-elf: add find_rela_by_offset() Add find_rela_by_offset(), which, given a relocation section and offset, will return the rela struct with the matching offset.

view details

Jessica Yu

commit sha 09d2af5cb44417a89066b44360b774133df6e232

create-klp-module: add new program that creates patch modules that have klp elements Add a new program, create-klp-module, that, given a built module (.ko), will create a patch module with klp rela sections, klp arch sections, and klp symbols.

view details

Jessica Yu

commit sha 0cc693ba36ac0f8292926bb7d912ef2b74fe33dc

create-kpatch-module: add new program that creates kpatch modules Add new program create-kpatch-module, that, given an intermediate object outputted by create-diff-object, outputs an object (.o) that contains the .kpatch.dynrelas section required by kpatch.

view details

Jessica Yu

commit sha 355996e366c0adc78faf12846dbe8241f0c39dd5

livepatch-patch-hook: ensure compatibility with kernels < 4.7 and >= 4.7 Use dynrelas when kernel version is < 4.7 and klp relas otherwise.

view details

Jessica Yu

commit sha b1cdc83d574d3eaa01d47f1649cc91829b8e2b79

kpatch-build: build dynrelas or klp relas depending on kernel version Introduce a second phase in the kpatch-build process that creates kpatch modules or livepatch modules that use the new klp rela sections depending on the kernel version being worked on. This change uses the two new programs to either create a patch module that uses dynrelas (create-kpatch-module) or a patch module that uses klp rela and arch sections + klp symbols marked with the correct Elf flags (create-klp-module). For klp patch modules, the --unique flag for ld is needed to prevent .parainstructions and .altinstructions sections from different objects from being merged, as arch_klp_init_object_loaded() applies these sections per-object.

view details

Josh Poimboeuf

commit sha ac899455ab750fefb0f1aabed548f74c1580b841

create-diff-object: convert global symbols to local As reported in PR #658, when patching an exported function which is used by the patch module init code, the init code will incorrectly link to the patched version of the function and will call the patched function before its relocations have been applied. For example, when patching __kmalloc(), I see: # insmod kpatch-kmalloc.ko kpatch_kmalloc: module is marked as livepatch module, but livepatch support is disabled kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle kernel paging request at ffffc90001d03c58 IP: 0xffffc90001d03c58 PGD 7c8b4067 PUD 7c8b5067 PMD 755f7067 PTE 800000007ad03163 Oops: 0011 [#1] PREEMPT SMP Modules linked in: kpatch_kmalloc(OE+) kpatch(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack cfg80211 rfkill ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic ppdev crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel snd_hda_intel virtio_balloon snd_hda_codec snd_hwdep serio_raw virtio_console snd_hda_core parport_pc parport snd_pcm virtio_net snd_timer snd i2c_piix4 soundcore virtio_blk qxl drm_kms_helper ttm drm virtio_pci virtio_ring virtio ata_generic pata_acpi CPU: 1 PID: 1042 Comm: insmod Tainted: G OE 4.10.0-rc5 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.1-1.fc24 04/01/2014 task: ffff88007560d480 task.stack: ffffc90001d00000 RIP: 0010:0xffffc90001d03c58 RSP: 0018:ffffc90001d03c50 EFLAGS: 00010286 RAX: 0000000000000004 RBX: 0000000000000008 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 00000000014080c0 RDI: 0000000000000008 RBP: ffff88007ad00058 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 0000000000000001 R12: 00000000fffffff4 R13: ffffffffa0394ef0 R14: 0000000000000000 R15: ffffc90001d03ea8 FS: 00007f9689d74700(0000) GS:ffff88007d000000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffc90001d03c58 CR3: 000000007af1d000 CR4: 00000000001406e0 Call Trace: ? kzalloc.constprop.6+0xe/0x10 [kpatch_kmalloc] ? patch_init+0xa6/0x1000 [kpatch_kmalloc] ? 0xffffffffa0399000 ? do_one_initcall+0x52/0x1b0 ? do_init_module+0x27/0x1fa ? rcu_read_lock_sched_held+0x4a/0x80 ? kmem_cache_alloc_trace+0x28a/0x2f0 ? do_init_module+0x5f/0x1fa ? load_module+0x2446/0x2b90 ? __symbol_put+0x90/0x90 ? vfs_read+0x137/0x180 ? SYSC_finit_module+0xdf/0x110 ? SyS_finit_module+0xe/0x10 ? entry_SYSCALL_64_fastpath+0x1f/0xc2 Code: c9 ff ff 10 00 00 00 00 00 00 00 86 02 01 00 00 00 00 00 50 3c d0 01 00 c9 ff ff 18 00 00 00 00 00 00 00 b4 33 39 a0 ff ff ff ff <a0> 3c d0 01 00 c9 ff ff a6 90 39 a0 ff ff ff ff 00 00 00 00 00 RIP: 0xffffc90001d03c58 RSP: ffffc90001d03c50 CR2: ffffc90001d03c58

view details

Jessica Yu

commit sha d4f9da349434729bf84643ec33396630fe893b65

Merge pull request #661 from jpoimboe/convert-global-to-local create-diff-object: convert global symbols to local

view details

Jessica Yu

commit sha 43f8683cd721127f186206181cc01b458a4866a5

kpatch-build: rename kpatch-tmp.ko to tmp.ko Rename kpatch-tmp.ko to tmp.ko, since create-klp-module will run into issues if we happen to have a patch named tmp.patch

view details

Jessica Yu

commit sha b0f5ded2b0bc1f58efc00a130eea633f04a2ad63

kpatch-intermediate.h: fix comments

view details

push time in 20 days

pull request commentdynup/kpatch

create-diff-object: process debug sections last

This was found via code inspection, so I don't really have a unit test for it.

jpoimboe

comment created time in 20 days

PR opened dynup/kpatch

create-diff-object: process debug sections last

Process the debug sections only after all the other inclusion logic has finished, since it makes decisions based on what else has already been included.

Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com

+1 -1

0 comment

1 changed file

pr created time in 20 days

create barnchjpoimboe/kpatch

branch : process-debug-sections-last

created branch time in 20 days

pull request commentdynup/kpatch

Static local reworks

A unit test (or tests) for this PR would be good too.

julien-thierry

comment created time in 20 days

Pull request review commentdynup/kpatch

Static local reworks

 static void kpatch_bundle_symbols(struct kpatch_elf *kelf) 	} } +static void kpatch_add_child_symbol(struct symbol *parent, struct symbol *child)+{+	parent->nb_children++;+	parent->children = realloc(parent->children,+				   sizeof(*parent->children) * parent->nb_children);+	if (!parent->children)+		ERROR("failed to add child %s to symbol %s", child->name,+		      parent->name);+	child->parent = parent;+	parent->children[parent->nb_children - 1] = child;+}+

Instead of a dynamic array, how about a linked list? That's what the rest of the code does and I think it would be a little cleaner.

julien-thierry

comment created time in 20 days

Pull request review commentdynup/kpatch

Static local reworks

 static void kpatch_mark_ignored_sections_same(struct kpatch_elf *kelf) 			sym->status = SAME; } +static void kpatch_mark_ignored_children_same(struct symbol *sym)+{+	int i;++	for (i = 0; i < sym->nb_children; ++i) {+		sym->children[i]->status = SAME;+		kpatch_mark_ignored_children_same(sym->children[i]);

Why? Can there be grandchildren?

julien-thierry

comment created time in 20 days

Pull request review commentdynup/kpatch

Static local reworks

 static int kpatch_line_macro_change_only(struct section *sec) } #endif +static bool kpatch_changed_child_needs_parent_profiling(struct symbol *sym)+{+	int i;++	for (i = 0; i < sym->nb_children; i++) {+		if (sym->children[i]->has_func_profiling)+			continue;+		if (sym->children[i]->sec->status == CHANGED ||+		    kpatch_changed_child_needs_parent_profiling(sym->children[i]))+			return true;

Why the recursive call? Isn't the for loop already doing this check for all the siblings?

julien-thierry

comment created time in 20 days

Pull request review commentdynup/kpatch

Static local reworks

 static void kpatch_detect_child_functions(struct kpatch_elf *kelf) 	struct symbol *sym;  	list_for_each_entry(sym, &kelf->symbols, list) {-		char *coldstr;+		struct symbol *parent;+		char *childstr;+		char *pname; -		coldstr = strstr(sym->name, ".cold.");-		if (coldstr != NULL) {-			char *pname;+		if (sym->type != STT_FUNC)+			continue; -			pname = strndup(sym->name, coldstr - sym->name);-			if (!pname)-				ERROR("strndup");+		childstr = strstr(sym->name, ".cold.");+		if (!childstr) {+			childstr = strstr(sym->name, ".part.");+			if (!childstr)+				continue;+		} -			sym->parent = find_symbol_by_name(&kelf->symbols, pname);-			free(pname);+		pname = strndup(sym->name, childstr - sym->name);+		if (!pname)+			ERROR("strndup"); -			if (!sym->parent)-				ERROR("failed to find parent function for %s", sym->name);+		parent = find_symbol_by_name(&kelf->symbols, pname);+		free(pname); -			sym->parent->child = sym;+		if (!parent) {+			/* ".part." symbols don't always have parents */+			if (sym->has_func_profiling)+				continue;+			ERROR("failed to find parent function for %s",+			      sym->name);

Is this really an error? Not every ".part." function has a parent and not every function has func profiling, so presumably not every ".part" function has func profiling?

julien-thierry

comment created time in 20 days

Pull request review commentdynup/kpatch

Static local reworks

 static int kpatch_line_macro_change_only(struct section *sec) } #endif +static bool kpatch_changed_child_needs_parent_profiling(struct symbol *sym)

It might be helpful to add a comment somewhere explaining that .cold children don't have fentry but that .part children often do.

BTW, the terms 'parent' and 'child' in this context have always bothered me because they're so ambigious. What do you think? Any ideas for better naming? Superfunction/subfunction?

julien-thierry

comment created time in 20 days

pull request commentdynup/kpatch

kpatch-build: Make local static twining stricter

Thanks. We want the unit tests to be as comprehensive as possible. I think some overlap between unit tests and integration tests is ok.

julien-thierry

comment created time in 20 days

pull request commentdynup/kpatch

kpatch-build: Make local static twining stricter

Looks good. Would it be possible to create a unit test for this one?

julien-thierry

comment created time in 20 days

pull request commentdynup/kpatch

Correlation rename fixes

@julien-thierry once the test PR is merged, you can rebase this PR to update the test/unit/objs ref to reference the new test PR. Then feel free to merge this one.

julien-thierry

comment created time in 21 days

pull request commentdynup/kpatch-unit-test-objs

Add test for mangled symbol modification

And with that change, feel free to merge this PR.

julien-thierry

comment created time in 21 days

pull request commentdynup/kpatch-unit-test-objs

Add test for mangled symbol modification

@julien-thierry for newer unit tests we've also been including the issue name in the file name. In this case I don't think there's an issue opened for it, but you can instead use the pr #. So maybe mangled-symbol-modification-issue-1048.

julien-thierry

comment created time in 21 days

push eventjpoimboe/kpatch

Josh Poimboeuf

commit sha 21d2f3803fb1835b14834c47949b4fbcfc35e638

fix

view details

push time in 22 days

push eventjpoimboe/kpatch

Josh Poimboeuf

commit sha 0ef451214f825317e8a4fbe15a401ca2a960705e

fix

view details

push time in 22 days

push eventjpoimboe/kpatch

Julien Thierry

commit sha e59355c2b74375bbc29b8991abc1d427b40d89e3

test/integration: Make multiple.test cleanup after itself If an error occurs while loading a module or one of the tests, multiple.test will exit leaving the working modules loaded. This leaves the system in an unwanted state and causes the test that previously pass to fail (succeeding before being loaded for multiple.test's point of view). Cleanup the loaded modules before exiting due to errors. Also take this opportunity to factorize the test for the different distros. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha 58eead5a16fa557d966820040c2ffc5b3ce3b7a5

kpatch: Fix all module unloading Some versions of Linux livepatching require patches to be unloaded in the opposite order than the order they were loaded. Currently kpatch simply goes through the list of sysfs livepatch directories and tries to disable them one by one. This makes the following fail: $ kpatch load a.ko $ kpatch load b.ko $ kpatch unload --all kpatch: failed to unload module b Since kpatch is not bound to a version of Linux, cater for those version that do not support random unloading order, even for patches that do not depend on one another. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha c9a4e09b459772e250ce03c53fbb2628aa617fe9

test/integration: Fix kpatch-test module unloading The unload_all() function in kpatch-test script is out dated and does not unload patches loaded through livepatching. Luckily, "kpatch unload --all" should support both kpatch unloading kpatch patches and livepatch patches. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha a02842fb693b92e943a8bfad55b676646dfd3c05

kpatch-elf: Free sections in elf teardown Currently, only rela section get freed. This seems like a simple scope mistake. Free all sections regardless of their nature in kpatch_elf_teardown() Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Artem Savkov

commit sha 3a1a73f08cdb4f13e010e220f26c408d8b5125d1

Make symvers reading code more flexible. Kernel commit cb9b55d21fe0 modpost: add support for symbol namespaces adds a new namespace column to Module.symvers file which can be blank. fscanf is no longer a viable solution to parse that. Switch to the way scripts/mod/modpost.c handles this and try to support both versions with and without namespace column. Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Josh Poimboeuf

commit sha eec99f0923869a0046fa7bdb2dc328aa89c3bc69

Merge pull request #1046 from julien-thierry/unload-fixes Unload fixes

view details

Josh Poimboeuf

commit sha c9519b6a1411e06117ffd476502a8d2d0b799bda

Merge pull request #1050 from julien-thierry/elf-teardown-free-sec kpatch-elf: Free sections in elf teardown

view details

Josh Poimboeuf

commit sha e0bd024c18f1273cd5617cd37aad4e110145943f

Merge pull request #1052 from sm00th/symvers Make symvers reading code more flexible.

view details

Josh Poimboeuf

commit sha 5eac3184e5e1c2d8ca6ae1ac7f84c7d916bbcb89

create-diff-object: update dynrela and toc_rela comments These are complicated topics. Try to clarify the comments as much as possible. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 330541d08eb4e37024ec0193f7aa5149898043aa

create-diff-object: refactor may_need_dynrela() To make the code clearer, move more of the dynrela decision making to earlier, in may_need_dynrela(). Ideally we could make all the decisions in may_need_dynrela(), and then rename it to need_dynrela(), but this is a good start. The rest of the decisions are dependent on the lookup table. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha bbae0324d7f8e7bce904581953a23ae6c2497d1c

create-diff-object: process debug sections last Process the debug sections only after all the other inclusion logic has finished, since it makes decisions based on what else has already been included. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha e8034843854b0f2f76ca08587023ac9314ffe307

create-diff-object: reduce indentation in kpatch_create_patches_sections() Reverse the if condition and use a 'continue' statement to reduce indentation and improve readability. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 5433fc279c98082737a67c417dfde52f9667d3ef

lookup: remove unused testing code This testing code is no longer used. Remove it. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 2022440d3fd566bd91a943089e1e6343cc0221b0

lookup: rename 'value' -> 'addr' Rename 'value' to 'addr' to more accurately describe it. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 89952d6bb46b640fa3f0d3e9ef998237b51a60c4

lookup: rename 'pos' to 'sympos' To more accurately describe its purpose. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 2a63bec03dbfaf90332a9ff5dea9d8c4a3bc80c9

lookup: convert lookup functions to return bool The code is easier to follow if these functions return bool. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 412d8aec481e90b9624810379cb915077259cc4f

todo

view details

Josh Poimboeuf

commit sha 1e587bc4660681b2c03f9cd7088c437df3f91f63

todo

view details

Josh Poimboeuf

commit sha c935b2ab1676719aa4c6050d2a30249f5d4a5f56

rewrite dynrela logic

view details

Josh Poimboeuf

commit sha dedd63542a458c9f3077b7fae9c0d9a98eaca317

fixes

view details

push time in 22 days

push eventjpoimboe/kpatch

Josh Poimboeuf

commit sha d6874d2e7f0710b53c5a7b5b7fc0cea33186121b

fixes

view details

Josh Poimboeuf

commit sha bfc7ed192dc876c2a6871e1df8b44b41526c50c2

remove .klp.arch sections

view details

Josh Poimboeuf

commit sha a0505d958901828d065d9fbce21aa13ff260b26f

allow jump tables, enforce rules

view details

push time in 22 days

push eventjpoimboe/kpatch

Artem Savkov

commit sha e790d59bec1a03170f371d0ba0e14cb54a814941

create-diff-object: name arguments Use named variables instead of cmdline argument indexes so that it is easier to read create-diff-object.c. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Artem Savkov

commit sha 3aa5abb8072c2e198a3e5dbb84502823d830b8cc

kpatch-build: use symbol table instead of kobject create-diff-object doesn't really need the full kernel object file as input. All it requires is a symbol table. Switch to using "eu-readelf -s"'s output instead of object files. This will enable us to cover more cases in unit tests. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Joe Lawrence

commit sha de10550faeec030366d240e4035a871ea345fa9f

create-klp-module: group .kpatch.symbols with like-scope From Oracle's Linker and Libraries Guide [1]: "The symbols in a symbol table are written in the following order ... The global symbols immediately follow the local symbols in the symbol table. The first global symbol is identified by the symbol table sh_info value. Local and global symbols are always kept separate in this manner, and cannot be mixed together." [1] https://docs.oracle.com/cd/E19120-01/open.solaris/819-0690/chapter6-79797/index.html Fixes #854. Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>

view details

Josh Poimboeuf

commit sha a3ee36944811278f06ce26df71a7609fd2a3a9a5

livepatch-patch-hook: add RHEL immediate check The 'immediate' flag removal is going to be backported to RHEL 7. Adjust the check accordingly. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Artem Savkov

commit sha 8927b575097342100c2622489b3d2ce5a079247e

create-diff-object: ignore .cold.* suffixes in is_bundleable() While building a gcc-consprop patch from integration tests gcc8 would place a __timekeeping_inject_sleeptime.constprop.18.cold.27 symbol into .text.unlikely.__timekeeping_inject_sleeptime.constprop.18 section. Because section name doesn't have the '.cold.27' suffix this symbol fails is_bundleable() check while still being bundleable and later exits early in kpatch_rename_mangled_functions() without renaming the corresponding patched function. All of this results in a create-diff-object errror: ERROR: timekeeping.o: symbol changed sections: __timekeeping_inject_sleeptime.constprop.18.cold.27 /home/asavkov/dev/kpatch/kpatch-build/create-diff-object: unreconcilable difference Fix by ignoring .cold.* name suffix in is_bundleable() for.text.unlikely sections. Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Josh Poimboeuf

commit sha 7023c239b15247e299e86744e217d4474768ca14

create-diff-object: don't convert .TOC. references to dynrelas When I made a patch to the nfsd module on a ppc64le system with a RHEL 7 based kernel, livepatch prevented the target module from loading with: livepatch: symbol '.TOC.' not found in symbol table References to this symbol are treated specially by the kernel module loader, so references to it should never be converted to dynrelas. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Kamalesh Babulal

commit sha 3ba9a145e9a2ad30b9f579c13850d6f0c085e91f

gcc-plugin: Include additional header for GCC 8 plugin compilation fails on GCC 8: In file included from gcc-plugins/gcc-common.h:100, from gcc-plugins/ppc64le-plugin.c:1: /usr/lib/gcc/powerpc64le-linux-gnu/8/plugin/include/attribs.h: In function ‘tree_node* canonicalize_attr_name(tree)’: /usr/lib/gcc/powerpc64le-linux-gnu/8/plugin/include/attribs.h:118:11: error: ‘get_identifier_with_length’ was not declared in this scope return get_identifier_with_length (s + 2, l - 4); ^~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/lib/gcc/powerpc64le-linux-gnu/8/plugin/include/attribs.h:118:11: note: suggested alternative: ‘get_attr_min_length’ return get_identifier_with_length (s + 2, l - 4); ^~~~~~~~~~~~~~~~~~~~~~~~~~ get_attr_min_length Makefile:34: recipe for target 'gcc-plugins/ppc64le-plugin.so' failed get_identifier_with_length() is defined under stringpool.h, include this header file for GCC 8, before including attribs.h Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>

view details

Joe Lawrence

commit sha c2f6d4d0fb21bf855bfbaf29c3d109cb8c59e63c

Merge pull request #860 from jpoimboe/rhel-immediate livepatch-patch-hook: add RHEL immediate check

view details

Josh Poimboeuf

commit sha 5736f18d83c87579e94e5ff2dafc85a521280b9d

test/unit: run submodule command from base git directory This fixes the following error with an older version of git (1.8.3.1): make -C test/unit make[1]: Entering directory `/root/kpatch/test/unit' git submodule update --init --rebase You need to run this command from the toplevel of the working tree. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Artem Savkov

commit sha 019c02983009ce418ee525b7665634c068c60e49

Add .cold. to mangled functions check gcc8 introduces ".cold." optimization symbols that have arbitrary trainling numbers in their names just like ".isra." and others. Add ".cold." to a condition in kpatch_rename_mangled_functions() Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Joe Lawrence

commit sha b387dffab6f6f0a84a60c36e9540938a18f4140e

Merge pull request #863 from jpoimboe/unit-submodule-root-dir test/unit: run submodule command from base git directory

view details

Joe Lawrence

commit sha 9d0a2105ef5c53bfce2720e1066abd1feb8b2b92

Merge pull request #861 from kamalesh-babulal/gcc_plugin gcc-plugin: Include additional header for GCC 8

view details

Joe Lawrence

commit sha a879d1f3ea0f5783fde4c1af2fa9bb1264b41ce3

Merge pull request #859 from jpoimboe/ppc-TOC create-diff-object: don't convert .TOC. references to dynrelas

view details

Joe Lawrence

commit sha ace1e2cbf603ce028112069ba0df64cdba92f61d

Merge pull request #849 from sm00th/cdo-symtab create-diff-object symtab

view details

Joe Lawrence

commit sha 27accf46ee26a81e4ebae94a9d8121adcd535bb4

Merge pull request #857 from joe-lawrence/local-symbols create-klp-module: group .kpatch.symbols with like-scope

view details

Artem Savkov

commit sha 355927287d87de14bcb30fc35cf73c95ff63c08a

livepatch-patch-hook: fix non-rhel builds Preprocessor doesn't stop unwinding macroses in #if clauses if one of the conditions is false resulting in the following error when trying to build on non-rhel system: patch/livepatch-patch-hook.c:53:48: error: missing binary operator before token "(" RHEL_RELEASE_CODE <= RHEL_RELEASE_VERSION(7, 5)) Fix by using 2 levels of #ifs instead of &&. The same way HAVE_CALLBACKS does. Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Artem Savkov

commit sha 6c58f09cc759972f66623942081b371a63586073

test/unit: update objects to include cold testcase Update unit test objects subrepo to include x86_64 gcc-constprop-cold testcase. Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Josh Poimboeuf

commit sha a7c413d4e97fce8cab8efaf99e1b58792138442f

Merge pull request #856 from sm00th/unlikely-cold create-diff-object: ignore .cold.* suffixes in is_bundleable()

view details

Joe Lawrence

commit sha 74392002de84f048ce5bf7afab6180d800bdbdfc

Merge pull request #864 from sm00th/rhel-immediate-fix livepatch-patch-hook: fix non-rhel builds

view details

Joe Lawrence

commit sha 7646c68b595e52c1c2dac272bc30b9cfc031f656

testing: kpatch-build should set all module names Since c0105ea46774 ("kpatch-build: set default module prefix accordingly") kpatch-build has automatically named resulting patch modules with a "kpatch-" or "livepatch-" prefix (depending on its type). To avoid naming confusion, have kpatch-test name all of its patch modules with a "test-" prefix. Fixes #867. Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>

view details

push time in 22 days

Pull request review commentdynup/kpatch

Correlation rename fixes

 static void kpatch_correlate_static_local_variables(struct kpatch_elf *base, 				ERROR("sections %s and %s aren't correlated for symbol %s", 				      sym->sec->name, patched_sym->sec->name, sym->name); -			log_debug("renaming and correlating static local %s to %s\n",-				  patched_sym->name, sym->name);--			patched_sym->name = strdup(sym->name);-			sym->twin = patched_sym;-			patched_sym->twin = sym;--			/* set initial status, might change */-			sym->status = patched_sym->status = SAME;+			kpatch_correlate_static_local(sym, patched_sym);  			if (bundled) {-				sym->sec->twin = patched_sym->sec;-				patched_sym->sec->twin = sym->sec;+				kpatch_correlate_section(sym->sec, patched_sym->sec);+				kpatch_correlate_symbol(sym->sec->secsym, patched_sym->sec->secsym); -				sym->sec->secsym->twin = patched_sym->sec->secsym;-				patched_sym->sec->secsym->twin = sym->sec->secsym;--				if (sym->sec->rela && patched_sym->sec->rela) {-					sym->sec->rela->twin = patched_sym->sec->rela;-					patched_sym->sec->rela->twin = sym->sec->rela;-				}+				if (sym->sec->rela && patched_sym->sec->rela)+					kpatch_correlate_section(sym->sec->rela, patched_sym->sec->rela);

This is all quite similar to what kpatch_process_section_correlation() does... could it all be replaced with

if (bundled) {
        kpatch_correlate_section(sym->sec, patched_sym->sec);
        kpatch_process_section_correlation(sym->sec);
}

?

And for that matter I wonder if it would be better to have kpatch_correlate_section() automatically do all the work in kpatch_process_section_correlation()? Then kpatch_correlate_section() could call a lower-level __kpatch_correlate_section() version which doesn't do that extra work. So kpatch_correlate_section() would be a higher-level interface which just does the right thing, and then this could just be

if (bundled)
        kpatch_correlate_section(sym->sec, patched_sym->sec);

And similarly kpatch_correlate_sections() wouldn't need to call kpatch_process_section_correlation().

julien-thierry

comment created time in 23 days

issue commentdynup/kpatch

Static Local Variable: missing reference to it...

I'm working on improving jump label / static key support this week, I suspect it will solve this problem.

CentUser

comment created time in 24 days

push eventdynup/kpatch

Artem Savkov

commit sha 3a1a73f08cdb4f13e010e220f26c408d8b5125d1

Make symvers reading code more flexible. Kernel commit cb9b55d21fe0 modpost: add support for symbol namespaces adds a new namespace column to Module.symvers file which can be blank. fscanf is no longer a viable solution to parse that. Switch to the way scripts/mod/modpost.c handles this and try to support both versions with and without namespace column. Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Josh Poimboeuf

commit sha e0bd024c18f1273cd5617cd37aad4e110145943f

Merge pull request #1052 from sm00th/symvers Make symvers reading code more flexible.

view details

push time in 24 days

PR merged dynup/kpatch

Make symvers reading code more flexible.

Kernel commit cb9b55d21fe0 modpost: add support for symbol namespaces adds a new namespace column to Module.symvers file which can be blank. fscanf is no longer a viable solution to parse that. Switch to the way scripts/mod/modpost.c handles this and try to support both versions with and without namespace column.

+35 -6

1 comment

1 changed file

sm00th

pr closed time in 24 days

push eventdynup/kpatch

Julien Thierry

commit sha a02842fb693b92e943a8bfad55b676646dfd3c05

kpatch-elf: Free sections in elf teardown Currently, only rela section get freed. This seems like a simple scope mistake. Free all sections regardless of their nature in kpatch_elf_teardown() Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Josh Poimboeuf

commit sha c9519b6a1411e06117ffd476502a8d2d0b799bda

Merge pull request #1050 from julien-thierry/elf-teardown-free-sec kpatch-elf: Free sections in elf teardown

view details

push time in 24 days

PR merged dynup/kpatch

Reviewers
kpatch-elf: Free sections in elf teardown

Currently, only rela section get freed. This seems like a simple scope mistake.

Free all sections regardless of their nature in kpatch_elf_teardown()

Signed-off-by: Julien Thierry jthierry@redhat.com

+2 -2

0 comment

1 changed file

julien-thierry

pr closed time in 24 days

Pull request review commentdynup/kpatch

Correlation rename fixes

 static void kpatch_correlate_static_local_variables(struct kpatch_elf *base, 				ERROR("sections %s and %s aren't correlated for symbol %s", 				      sym->sec->name, patched_sym->sec->name, sym->name); -			log_debug("renaming and correlating static local %s to %s\n",-				  patched_sym->name, sym->name);--			patched_sym->name = strdup(sym->name);-			sym->twin = patched_sym;-			patched_sym->twin = sym;+			CORRELATE_ELEMENTS(sym, patched_sym, "static local");

Here you might as well call a kpatch_correlate_static_local_variable() wrapper which hides the ugly macro, similar to the other two helpers.

julien-thierry

comment created time in 24 days

Pull request review commentdynup/kpatch

Correlation rename fixes

 static void kpatch_correlate_static_local_variables(struct kpatch_elf *base, 				ERROR("sections %s and %s aren't correlated for symbol %s", 				      sym->sec->name, patched_sym->sec->name, sym->name); -			log_debug("renaming and correlating static local %s to %s\n",-				  patched_sym->name, sym->name);--			patched_sym->name = strdup(sym->name);-			sym->twin = patched_sym;-			patched_sym->twin = sym;+			CORRELATE_ELEMENTS(sym, patched_sym, "static local");  			/* set initial status, might change */ 			sym->status = patched_sym->status = SAME;

I think this is no longer needed since CORRELATE_ELEMENTS does this?

julien-thierry

comment created time in 24 days

Pull request review commentdynup/kpatch

Correlation rename fixes

 static void kpatch_compare_symbols(struct list_head *symlist) 	} } +#define CORRELATE_ELEMENTS(_e1_, _e2_, kindstr)			\+do {								\+	typeof(_e1_) e1 = (_e1_);				\+	typeof(_e2_) e2 = (_e2_);				\+	e1->twin = e2;						\+	e2->twin = e1;						\+	/* set initial status, might change */			\+	e1->status = e2->status = SAME;				\+	if (strcmp(e1->name, e2->name)) {			\+		/* Rename mangled element */			\+		log_debug("renaming %s %s to %s\n",		\+			  kindstr, e2->name, e1->name);		\+		e2->name = strdup(e1->name);			\+	}							\+} while (0)++#define UNCORRELATE_ELEMENT(_elem_)				\+do {								\+	typeof(_elem_) elem = (_elem_);				\+	if (elem->twin->orig_name != elem->twin->name) {	\+		free(elem->twin->name);				\+		elem->twin->name = elem->twin->orig_name;	\+	}							\+	elem->twin->twin = NULL;				\+	elem->twin = NULL;					\+	if (elem->orig_name != elem->name) {			\+		free(elem->name);				\+		elem->name = elem->orig_name;			\+	}							\+} while (0)++static void make_correlated_sections(struct section *sec1, struct section *sec2)+{+	CORRELATE_ELEMENTS(sec1, sec2, "section");+}++static void make_correlated_symbols(struct symbol *sym1, struct symbol *sym2)+{+	CORRELATE_ELEMENTS(sym1, sym2, "symbol");+}

Naming suggestions: make_correlated_sections() almost makes it sound like it's creating a section - how about renaming to kpatch_correlate_section()? That also gives it a name analagous to its caller kpatch_correlate_sections(). And a similar comment for make_correlated_symbols().

And that would also imply a CORRELATE_ELEMENTS -> CORRELATE_ELEMENT rename for consistency - yes, it's correlating two elements, but depending on one's perspective they might be considered the same element :-)

julien-thierry

comment created time in 24 days

push eventdynup/kpatch

Julien Thierry

commit sha e59355c2b74375bbc29b8991abc1d427b40d89e3

test/integration: Make multiple.test cleanup after itself If an error occurs while loading a module or one of the tests, multiple.test will exit leaving the working modules loaded. This leaves the system in an unwanted state and causes the test that previously pass to fail (succeeding before being loaded for multiple.test's point of view). Cleanup the loaded modules before exiting due to errors. Also take this opportunity to factorize the test for the different distros. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha 58eead5a16fa557d966820040c2ffc5b3ce3b7a5

kpatch: Fix all module unloading Some versions of Linux livepatching require patches to be unloaded in the opposite order than the order they were loaded. Currently kpatch simply goes through the list of sysfs livepatch directories and tries to disable them one by one. This makes the following fail: $ kpatch load a.ko $ kpatch load b.ko $ kpatch unload --all kpatch: failed to unload module b Since kpatch is not bound to a version of Linux, cater for those version that do not support random unloading order, even for patches that do not depend on one another. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha c9a4e09b459772e250ce03c53fbb2628aa617fe9

test/integration: Fix kpatch-test module unloading The unload_all() function in kpatch-test script is out dated and does not unload patches loaded through livepatching. Luckily, "kpatch unload --all" should support both kpatch unloading kpatch patches and livepatch patches. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Josh Poimboeuf

commit sha eec99f0923869a0046fa7bdb2dc328aa89c3bc69

Merge pull request #1046 from julien-thierry/unload-fixes Unload fixes

view details

push time in 24 days

PR merged dynup/kpatch

Reviewers
Unload fixes

Couple of fixes for missing/failing module unloading found while running kpatch testsuite.

+133 -428

0 comment

10 changed files

julien-thierry

pr closed time in 24 days

Pull request review commentdynup/kpatch

Author guide updates

 correleating constprop subfunctions created by the optimization: ``` The current workaround for this issue to add `__attribute__((noclone))` to offending functions.++Sibling calls+-------------++If function A() calls function B() at the end of A() and both return similar+data-types, GCC may deem them "sibling calls" and apply a tail call+optimization in which A() restores the stack to is callee state before setting+up B()'s arguments and jumping to B().++This may be an issue for kpatches on PowerPC which modify only A() or B() and+the function call crosses a kernel module boundary: the sibling call+optimization has changed expected calling conventions and (un)patched code may+not be similarly modified.++Commit [8b952bd77130](https://github.com/dynup/kpatch/commit/8b952bd77130)+("create-diff-object/ppc64le: Don't allow sibling calls") contains an+excellent example and description of this problem with annotated disassembly.++Adding `__attribute__((optimize("-fno-optimize-sibling-calls")))` instructs+GCC to turn off the optimization for the given function.

Reading this, it's not clear how the user should know they've hit this issue in the first place. It should probably mention the error message:

			ERROR("Found an unsupported sibling call at %s()+0x%lx.  Add __attribute__((optimize(\"-fno-optimize-sibling-calls\"))) to %s() definition.",
joe-lawrence

comment created time in 24 days

Pull request review commentdynup/kpatch

Author guide updates

 if (static_key_true(&key1)) /* supported */ if (static_key_enabled(&key1)) ```++Constant propagation symbol changes+-----------------------------------++GCC's constant propagation optimizations may result in kpatch-build+errors like: `ERROR: timekeeping.o: symbol changed sections: .text.timekeeping_update.constprop.9`++This is currently tracked as issue+[#935](https://github.com/dynup/kpatch/issues/935) "duplicate" mangled+fuctions.  In that case, readelf revealed that kpatch-build wasn't+correleating constprop subfunctions created by the optimization:+```+# eu-readelf -s orig/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.9+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.8+# eu-readelf -s patched/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.10+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.9+```+The current workaround for this issue to add `__attribute__((noclone))`+to offending functions.

I think this issue was fixed in #1043. Should this commit be dropped?

joe-lawrence

comment created time in 24 days

PR closed dynup/kpatch

create-diff-object: Add ppc64le mcount support

Add the __mcount_loc section on ppc64le. It has pointers to all the mcount calls. This will enable the ftrace hook to be used for patched functions.

We have also been seeing a mysterious ppc64le livepatch bug where r2 (TOC pointer) gets intermittently corrupted. My only theory is that the call to _mcount is doing that somehow. Now that call will be replaced with a NOP when the patch module is loaded.

Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com

+58 -28

2 comments

1 changed file

jpoimboe

pr closed time in 24 days

issue commentdynup/kpatch

uname enhancement

Not to say that we shouldn't do it, just that we should be cautious in deciding to do it.

joe-lawrence

comment created time in 2 months

issue commentdynup/kpatch

uname enhancement

* An "effective kernel version" may be confusing to a user if it only includes a subset of the patches of said kernel version.

This is the part that bothers me the most. It seems like setting an "effective kernel version", when in fact it would be missing most of the patches from the corresponding real kernel, is actively misleading.

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 A shadow PID variable is allocated in `do_fork()`: it is associated with the current `struct task_struct *p` value, given a string lookup key of "newpid", sized accordingly, and allocated as per `GFP_KERNEL` flag rules. -`kpatch_shadow_alloc` returns a pointer to the shadow variable, so we can+`klp_shadow_get_or_alloc()` returns a pointer to the shadow variable, so we can

Ah, that makes sense now. I guess the correct fix would be to use klp_shadow_free_all() in a post-unload callback? If so it might be worth adding that to the real integration patches as well for proper test coverage.

joe-lawrence

comment created time in 2 months

pull request commentdynup/kpatch

create-diff-object: simplify mangled function correlation

This PR is now in shape for merging, once reviews are done.

jpoimboe

comment created time in 2 months

push eventjpoimboe/kpatch

Josh Poimboeuf

commit sha 935f1998752b050365993b05c7c44b64ee79c6c6

create-diff-object: simplify mangled function correlation The RHEL powerpc kernel is compiled with -O3, which triggers some "interesting" new optimizations. One of them, which seems to be relatively common, is the replacing of a function with two separate "constprop" functions. Previously we only ever saw a single constprop clone, so we just renamed the patched version of the function to match the original version. Now that we can have two such clones, that no longer makes sense. Instead of renaming functions, just improve the correlation logic such that they can be correlated despite having slightly different symbol names. The first clone in the original object is correlated with the first clone in the patched object; the second clone is correlated with the second clone; and so on. This assumes that the order of the symbols and sections doesn't change, which seems to be a reasonable assumption based on past experience with the compiler. Otherwise it will just unnecessarily mark the cloned constprop functions as changed, which is annoying but harmless, and noticeable by a human anyway. Fixes #935. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

push time in 2 months

push eventdynup/kpatch-unit-test-objs

Josh Poimboeuf

commit sha 26b94a97bb093b8a236f243fc9f434f0053c6002

Add test for the powerpc "double constprop" issue This is a test for dynup/kpatch#935. The following patch was used with a RHEL7.8-based kernel: diff -Nupr src.orig/kernel/time/timekeeping.c src/kernel/time/timekeeping.c --- src.orig/kernel/time/timekeeping.c 2017-09-22 15:27:21.602055778 -0400 +++ src/kernel/time/timekeeping.c 2017-09-22 15:27:27.522080292 -0400 @@ -877,6 +877,9 @@ void do_gettimeofday(struct timeval *tv) { struct timespec64 now; + if (!tv) + return; + getnstimeofday64(&now); tv->tv_sec = now.tv_sec; tv->tv_usec = now.tv_nsec/1000; Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha a5fd47f575552ef989b6b14de84460de5ce0b4ea

Merge pull request #18 from jpoimboe/double-constprop Add test for the powerpc "double constprop" issue

view details

push time in 2 months

PR merged dynup/kpatch-unit-test-objs

Add test for the powerpc "double constprop" issue

This is a test for dynup/kpatch#935. The following patch was used with a RHEL7.8-based kernel:

diff -Nupr src.orig/kernel/time/timekeeping.c src/kernel/time/timekeeping.c --- src.orig/kernel/time/timekeeping.c 2017-09-22 15:27:21.602055778 -0400 +++ src/kernel/time/timekeeping.c 2017-09-22 15:27:27.522080292 -0400 @@ -877,6 +877,9 @@ void do_gettimeofday(struct timeval *tv) { struct timespec64 now;

  • if (!tv)
  •   return;
    
  • getnstimeofday64(&now); tv->tv_sec = now.tv_sec; tv->tv_usec = now.tv_nsec/1000;

Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com

+4 -0

0 comment

3 changed files

jpoimboe

pr closed time in 2 months

pull request commentdynup/kpatch

create-diff-object: simplify mangled function correlation

I think it is a normal submodule workflow. If we merge test-obj PR right now it won't affect the main repo since the submodule pointer will still use old commit-id, we can then add a commit updating the pointer to this PR so once it is merged we'll have both the test and accompanying changes. No races anywhere.

Right, of course.... Not sure how I managed to forget that. I'll go ahead and merge the test PR now.

jpoimboe

comment created time in 2 months

pull request commentdynup/kpatch

create-diff-object: simplify mangled function correlation

I think it's a bit of a chicken-egg problem, but we can merge the test PR immediately before rebasing this commit with the updated test-objs pointer and then merging this PR.

jpoimboe

comment created time in 2 months

push eventjpoimboe/kpatch

Josh Poimboeuf

commit sha 3b832d382b5bdae2eb51073631861bf5cedae51a

create-diff-object: simplify mangled function correlation The RHEL powerpc kernel is compiled with -O3, which triggers some "interesting" new optimizations. One of them, which seems to be relatively common, is the replacing of a function with two separate "constprop" functions. Previously we only ever saw a single constprop clone, so we just renamed the patched version of the function to match the original version. Now that we can have two such clones, that no longer makes sense. Instead of renaming functions, just improve the correlation logic such that they can be correlated despite having slightly different symbol names. The first clone in the original object is correlated with the first clone in the patched object; the second clone is correlated with the second clone; and so on. This assumes that the order of the symbols and sections doesn't change, which seems to be a reasonable assumption based on past experience with the compiler. Otherwise it will just unnecessarily mark the cloned constprop functions as changed, which is annoying but harmless, and noticeable by a human anyway. Fixes #935. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

push time in 2 months

PR opened dynup/kpatch-unit-test-objs

Add test for the powerpc "double constprop" issue

This is a test for dynup/kpatch#935. The following patch was used with a RHEL7.8-based kernel:

diff -Nupr src.orig/kernel/time/timekeeping.c src/kernel/time/timekeeping.c --- src.orig/kernel/time/timekeeping.c 2017-09-22 15:27:21.602055778 -0400 +++ src/kernel/time/timekeeping.c 2017-09-22 15:27:27.522080292 -0400 @@ -877,6 +877,9 @@ void do_gettimeofday(struct timeval *tv) { struct timespec64 now;

  • if (!tv)
  •   return;
    
  • getnstimeofday64(&now); tv->tv_sec = now.tv_sec; tv->tv_usec = now.tv_nsec/1000;

Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com

+4 -0

0 comment

3 changed files

pr created time in 2 months

create barnchjpoimboe/kpatch-unit-test-objs

branch : double-constprop

created branch time in 2 months

pull request commentdynup/kpatch

create-diff-object: simplify mangled function correlation

I will add a powerpc unit test for this hopefully tomorrow.

jpoimboe

comment created time in 2 months

PR opened dynup/kpatch

create-diff-object: simplify mangled function correlation

The RHEL powerpc kernel is compiled with -O3, which triggers some "interesting" new optimizations. One of them, which seems to be relatively common, is the replacing of a function with two separate "constprop" functions.

Previously we only ever saw a single constprop clone, so we just renamed the patched version of the function to match the original version. Now that we can have two such clones, that no longer makes sense.

Instead of renaming functions, just improve the correlation logic such that they can be correlated despite having slightly different symbol names. The first clone in the original object is correlated with the first clone in the patched object; the second clone is correlated with the second clone; and so on.

This assumes that the order of the symbols and sections doesn't change, which seems to be a reasonable assumption based on past experience with the compiler. Otherwise it will just unnecessarily mark the cloned constprop functions as changed, which is annoying but harmless, and noticeable by a human anyway.

Fixes #935.

Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com

+5 -80

0 comment

1 changed file

pr created time in 2 months

create barnchjpoimboe/kpatch

branch : double-constprop

created branch time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 structure can be used by patched code to handle both new (post-patch) and existing (pre-patch) instances.  (This example is trimmed to highlight this use-case. Boilerplate code is also-required to allocate/free a shadow variable called "reqs_active_v2" whenever a-new `struct kioctx` is created/released. No values are ever assigned to the-shadow variable.)+required to allocate/free a shadow variable with enum ID SV_REQS_ACTIVE_V2

If it makes it more readable, why not go with the longer version? The extra characters are free. KLP_SV and KPS_ are cryptic, and ID_ doesn't make clear that it's a kpatch-specific id.

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 For example, a `pr_warn_once()` can be replaced with: 		pr_warn("..."); 	} ```++inline implies notrace+----------------------++The linux kernel defines its own version of "inline" in+include/linux/compiler_types.h which includes "notrace" as well:++```+#if !defined(CONFIG_OPTIMIZE_INLINING)+#define inline inline __attribute__((__always_inline__)) __gnu_inline \+        __inline_maybe_unused notrace+#else+#define inline inline                                    __gnu_inline \+        __inline_maybe_unused notrace+#endif+```++With the implicit "notrace", use of "inline" in patch sources may lead+to kpatch-build errors like the following:++1. `__tcp_mtu_to_mss()` is marked as inline:++```+net/ipv4/tcp_output.c:++/* Calculate MSS not accounting any TCP options.  */+static inline int __tcp_mtu_to_mss(struct sock *sk, int pmtu)+{+```++2. the compiler decides not to inline it and keeps it in its own+   function-section.  Then kpatch-build notices that it doesn't have an+   fentry/mcount call:++```+% kpatch-build ...++tcp_output.o: function __tcp_mtu_to_mss has no fentry/mcount call, unable to patch+```++3. a peek at the generated code:++```+Disassembly of section .text.__tcp_mtu_to_mss:++0000000000000000 <__tcp_mtu_to_mss>:+   0:   48 8b 87 60 05 00 00    mov    0x560(%rdi),%rax+   7:   0f b7 50 30             movzwl 0x30(%rax),%edx+   b:   0f b7 40 32             movzwl 0x32(%rax),%eax+   f:   29 d6                   sub    %edx,%esi+  11:   83 ee 14                sub    $0x14,%esi+  ...+```++This could be a little confusing since one might have expected to see+changes to all of `__tcp_mtu_to_mss()` callers (ie, it was inlined as+requested).  In this case, a simple workaround is to provide a new,+non-inlined copy of `__tcp_mtu_to_mss()` and then update all its callers+to use it.++Jump labels+-----------++When modifying a function that contains a jump label, kpatch-build may+return an error like: `ERROR: oom_kill.o: kpatch_regenerate_special_section: 2109: Found a jump label at out_of_memory()+0x10a, using key cpusets_enabled_key.  Jump labels aren't currently supported.  Use static_key_enabled() instead.`++This is due to a limitation in the kernel to process static key+livepatch relocations (resolved by late-module patching).  Older+versions of kpatch-build may have reported successfully building +kpatch module, but issue+[#931](https://github.com/dynup/kpatch/issues/931) revealed potentially+dangerous behavior if the static key value had been modified from its+compiled default.++The current workaround is to remove the jump label by explictly checking+the static key:++```+/* unsupported */+if (static_key_true(&key1))++/* supported */+if (static_key_enabled(&key1))+```++Constant propagation symbol changes+-----------------------------------++GCC's constant propagation optimizations may result in kpatch-build+errors like: `ERROR: timekeeping.o: symbol changed sections: .text.timekeeping_update.constprop.9`++This is currently tracked as issue+[#935](https://github.com/dynup/kpatch/issues/935) "duplicate" mangled+fuctions.  In that case, readelf revealed that kpatch-build wasn't+correleating constprop subfunctions created by the optimization:+```+# eu-readelf -s orig/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.9+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.8+# eu-readelf -s patched/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.10+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.9+```+The current workaround for this issue to add `__attribute__((noclone))`+to offending functions.++Sibling calls+-------------++If function A() calls function B() and they share a common function+signature, GCC may deem them "sibling calls" and apply a tail call

The signatures don't need to match because for sibling calls, A() restores the stack to its callee's state, and then sets up B()'s args appropriately before jumping to B().

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 A shadow PID variable is allocated in `do_fork()`: it is associated with the current `struct task_struct *p` value, given a string lookup key of "newpid", sized accordingly, and allocated as per `GFP_KERNEL` flag rules. -`kpatch_shadow_alloc` returns a pointer to the shadow variable, so we can+`klp_shadow_get_or_alloc()` returns a pointer to the shadow variable, so we can

How would klp_shadow_get_or_alloc() be more straightforward here? In do_fork() there shouldn't be an existing shadow struct for it, right?

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

test/integration: Rebase to RHEL 8.0

 static void kpatch_bundle_symbols(struct kpatch_elf *kelf) 	} } +static void kpatch_add_child_symbol(struct symbol *parent, struct symbol *child)+{+	parent->nb_children++;+	parent->children = realloc(parent->children,+				   sizeof(*parent->children) * parent->nb_children);+	child->parent = parent;+	parent->children[parent->nb_children - 1] = child;+}+ /*  * During optimization gcc may move unlikely execution branches into *.cold- * subfunctions. kpatch_detect_child_functions detects such subfunctions and+ * subfunctions. Some functions can also be split into multiple *.part+ * functions.+ * kpatch_detect_child_functions detects such subfunctions and

Since we don't have a CI running these yet, I think I'd suggest doing the integration tests first, in one PR. That way the other fixes can refer to them.

kamalesh-babulal

comment created time in 2 months

Pull request review commentdynup/kpatch

test/integration: Rebase to RHEL 8.0

 static void kpatch_bundle_symbols(struct kpatch_elf *kelf) 	} } +static void kpatch_add_child_symbol(struct symbol *parent, struct symbol *child)+{+	parent->nb_children++;+	parent->children = realloc(parent->children,+				   sizeof(*parent->children) * parent->nb_children);+	child->parent = parent;+	parent->children[parent->nb_children - 1] = child;+}+ /*  * During optimization gcc may move unlikely execution branches into *.cold- * subfunctions. kpatch_detect_child_functions detects such subfunctions and+ * subfunctions. Some functions can also be split into multiple *.part+ * functions.+ * kpatch_detect_child_functions detects such subfunctions and

Ah... I think I had a fundamental misunderstanding of this optimization. Looking at gcc/ipa-split.c in the GCC source confirms that. I had been thinking this was more like the constprop and isra optimizations.

So I take back my original comment! It's very similar to the .cold optimization and I think the parent/child relationship makes sense after all.

kamalesh-babulal

comment created time in 2 months

Pull request review commentdynup/kpatch

kmod: don't build module for kernels >=v5.2

 # make rules KPATCH_BUILD ?= /lib/modules/$(shell uname -r)/build KERNELRELEASE := $(lastword $(subst /, , $(dir $(patsubst %/,%,$(KPATCH_BUILD)))))+VERCODE := $(shell awk '/LINUX_VERSION_CODE/{print $$NF}' $(KPATCH_BUILD)/include/generated/uapi/linux/version.h) THISDIR := $(abspath $(dir $(lastword $(MAKEFILE_LIST))))  ifeq ($(wildcard $(KPATCH_BUILD)),) $(error $(KPATCH_BUILD) doesn\'t exist.  Try installing the kernel-devel-$(KERNELRELEASE) RPM or linux-headers-$(KERNELRELEASE) DEB.) endif +ifeq ($(shell if [ $(VERCODE) -lt 328192 ];then echo "y";fi),y) KPATCH_MAKE = $(MAKE) -C $(KPATCH_BUILD) M=$(THISDIR)  kpatch.ko: core.c 	$(KPATCH_MAKE) kpatch.ko  all: kpatch.ko+else+all:+$(info !!! Starting at v5.2, needed stacktrace routines are no longer available; not building kmod)

When running make from the top-level dir, I see this message twice because it does a clean first.

yhcote

comment created time in 2 months

pull request commentdynup/kpatch

kmod: don't build module for kernels >=v5.2

* I wonder if it would be better to just remove the support module entirely?  I would think the various kpatch-build kernel `CONFIG_` checks would indirectly enforce a minimum kernel version (and not worry about distro releases complicating the version code logic).  It's code that we're bringing along, but not  testing any longer... @jpoimboe thoughts?

I'd love to rip kpatch.ko out entirely, but I think it still has some users for older kernels, like @euspectre if I'm not mistaken.

yhcote

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 A shadow PID variable is allocated in `do_fork()`: it is associated with the current `struct task_struct *p` value, given a string lookup key of "newpid", sized accordingly, and allocated as per `GFP_KERNEL` flag rules. -`kpatch_shadow_alloc` returns a pointer to the shadow variable, so we can+`klp_shadow_get_or_alloc()` returns a pointer to the shadow variable, so we can dereference and make assignments as usual.  In this patch chunk, the shadow `newpid` is allocated then assigned to a rolling `ctr` counter value: ```+@@ -1797,6 +1798,13 @@ long do_fork(unsigned long clone_flags,+ 	if (!IS_ERR(p)) {+ 		struct completion vfork;+ 		struct pid *pid; +		int *newpid; +		static int ctr = 0; +-+		newpid = kpatch_shadow_alloc(p, "newpid", sizeof(*newpid),-+					     GFP_KERNEL);++		newpid = klp_shadow_get_or_alloc(p, 0, sizeof(*newpid), GFP_KERNEL,

Maybe have #define KPATCH_SHADOW_NEWPID 0 somewhere (or enum) and use that instead? Perhaps along with a comment that the value needs to be globally unique.

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 the spinlock:  		return NULL;    	spin_lock_init(&sta->lock);-+	ps_lock = kpatch_shadow_alloc(sta, "ps_lock", sizeof(*ps_lock), gfp);++	ps_lock = klp_shadow_alloc(sta, PS_LOCK, sizeof(*ps_lock), gfp,

Similar comment here for PS_LOCK

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 structure can be used by patched code to handle both new (post-patch) and existing (pre-patch) instances.  (This example is trimmed to highlight this use-case. Boilerplate code is also-required to allocate/free a shadow variable called "reqs_active_v2" whenever a-new `struct kioctx` is created/released. No values are ever assigned to the-shadow variable.)+required to allocate/free a shadow variable with enum ID SV_REQS_ACTIVE_V2

I had to do a double take at the SV_ prefix, maybe give it a KPATCH_SHADOW prefix instead? Also it might be clearer to define it somewhere in the code.

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 A shadow PID variable is allocated in `do_fork()`: it is associated with the current `struct task_struct *p` value, given a string lookup key of "newpid", sized accordingly, and allocated as per `GFP_KERNEL` flag rules. -`kpatch_shadow_alloc` returns a pointer to the shadow variable, so we can+`klp_shadow_get_or_alloc()` returns a pointer to the shadow variable, so we can dereference and make assignments as usual.  In this patch chunk, the shadow `newpid` is allocated then assigned to a rolling `ctr` counter value: ```+@@ -1797,6 +1798,13 @@ long do_fork(unsigned long clone_flags,+ 	if (!IS_ERR(p)) {+ 		struct completion vfork;+ 		struct pid *pid; +		int *newpid; +		static int ctr = 0; +-+		newpid = kpatch_shadow_alloc(p, "newpid", sizeof(*newpid),-+					     GFP_KERNEL);++		newpid = klp_shadow_get_or_alloc(p, 0, sizeof(*newpid), GFP_KERNEL,

Same question

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 A shadow PID variable is allocated in `do_fork()`: it is associated with the current `struct task_struct *p` value, given a string lookup key of "newpid", sized accordingly, and allocated as per `GFP_KERNEL` flag rules. -`kpatch_shadow_alloc` returns a pointer to the shadow variable, so we can+`klp_shadow_get_or_alloc()` returns a pointer to the shadow variable, so we can

Shouldn't this be klp_shadow_alloc()?

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 static void kpatch_post_unpatch_tcp_send_challenge_ack(patch_object *obj) +KPATCH_POST_UNPATCH_CALLBACK(kpatch_post_unpatch_tcp_send_challenge_ack); ``` -Don't forget to protect access to the data as needed. Please note that-spinlocks and mutexes / sleeping locks can't be used from stop_machine-context. Also note the pre-patch callback return code will be ignored by the-kernel's module notifier, so it does not affect the target module or livepatch-module status. This means:--* Pre-patch callbacks to loaded objects (vmlinux, loaded kernel modules) are-  run from stop_machine(), so they may only inspect lock state (i.e.-  spin_is_locked(), mutex_is_locked()) and optionally return -EBUSY to prevent-  patching.--* Post-patch, pre-unpatch, and post-unpatch callbacks to loaded objects are-  also run from stop_machine(), so the same locking context applies.  No-  return status is supported.--* Deferred pre-patch callbacks to newly loading objects do not run from-  stop_machine(), so they may spin or schedule, i.e. spin_lock(),-  mutex_lock()).  Return status is ignored.--* Post-patch, pre-unpatch, and post-unpatch callbacks to unloading objects are-  also *not* run from stop_machine(), so they may spin or sleep.  No return-  status is supported.--Unfortunately there is no simple, all-case-inclusive kpatch callback-implementation that handles data structures and mutual exclusion.--A few workarounds:--1. If a given lock/mutex is held and released by the same set of functions-(that is, functions that take a lock/mutex always release it before-returning), a trivial change to those functions can re-purpose kpatch's-activeness safety check to avoid patching when the lock/mutex may be held.-This assumes that all lock/mutex holders can be patched.+Don't forget to protect access to the data as needed. Spinlocks and mutexes /+sleeping locks **may be used** (this is a change of behavior from when kpatch+relied on the kpatch.ko support module and `stop_machine()` context.) -2. If it can be assured that all patch targets will be loaded before the-kpatch patch module, pre-patch callbacks may return -EBUSY if the lock/mutex-is held to block the patching.+Also note the pre-patch callback return code will be ignored by the kernel's+module notifier, so it does not affect the target module or livepatch module+status.

It will, however, prevent the patch from being enabled.

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 For example, a `pr_warn_once()` can be replaced with: 		pr_warn("..."); 	} ```++inline implies notrace+----------------------++The linux kernel defines its own version of "inline" in+include/linux/compiler_types.h which includes "notrace" as well:++```+#if !defined(CONFIG_OPTIMIZE_INLINING)+#define inline inline __attribute__((__always_inline__)) __gnu_inline \+        __inline_maybe_unused notrace+#else+#define inline inline                                    __gnu_inline \+        __inline_maybe_unused notrace+#endif+```++With the implicit "notrace", use of "inline" in patch sources may lead+to kpatch-build errors like the following:++1. `__tcp_mtu_to_mss()` is marked as inline:++```+net/ipv4/tcp_output.c:++/* Calculate MSS not accounting any TCP options.  */+static inline int __tcp_mtu_to_mss(struct sock *sk, int pmtu)+{+```++2. the compiler decides not to inline it and keeps it in its own+   function-section.  Then kpatch-build notices that it doesn't have an+   fentry/mcount call:++```+% kpatch-build ...++tcp_output.o: function __tcp_mtu_to_mss has no fentry/mcount call, unable to patch+```++3. a peek at the generated code:++```+Disassembly of section .text.__tcp_mtu_to_mss:++0000000000000000 <__tcp_mtu_to_mss>:+   0:   48 8b 87 60 05 00 00    mov    0x560(%rdi),%rax+   7:   0f b7 50 30             movzwl 0x30(%rax),%edx+   b:   0f b7 40 32             movzwl 0x32(%rax),%eax+   f:   29 d6                   sub    %edx,%esi+  11:   83 ee 14                sub    $0x14,%esi+  ...+```++This could be a little confusing since one might have expected to see+changes to all of `__tcp_mtu_to_mss()` callers (ie, it was inlined as+requested).  In this case, a simple workaround is to provide a new,+non-inlined copy of `__tcp_mtu_to_mss()` and then update all its callers+to use it.++Jump labels+-----------++When modifying a function that contains a jump label, kpatch-build may+return an error like: `ERROR: oom_kill.o: kpatch_regenerate_special_section: 2109: Found a jump label at out_of_memory()+0x10a, using key cpusets_enabled_key.  Jump labels aren't currently supported.  Use static_key_enabled() instead.`++This is due to a limitation in the kernel to process static key+livepatch relocations (resolved by late-module patching).  Older+versions of kpatch-build may have reported successfully building +kpatch module, but issue+[#931](https://github.com/dynup/kpatch/issues/931) revealed potentially+dangerous behavior if the static key value had been modified from its+compiled default.++The current workaround is to remove the jump label by explictly checking+the static key:++```+/* unsupported */+if (static_key_true(&key1))++/* supported */+if (static_key_enabled(&key1))+```++Constant propagation symbol changes+-----------------------------------++GCC's constant propagation optimizations may result in kpatch-build+errors like: `ERROR: timekeeping.o: symbol changed sections: .text.timekeeping_update.constprop.9`++This is currently tracked as issue+[#935](https://github.com/dynup/kpatch/issues/935) "duplicate" mangled+fuctions.  In that case, readelf revealed that kpatch-build wasn't+correleating constprop subfunctions created by the optimization:+```+# eu-readelf -s orig/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.9+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.8+# eu-readelf -s patched/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.10+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.9+```+The current workaround for this issue to add `__attribute__((noclone))`+to offending functions.++Sibling calls+-------------++If function A() calls function B() and they share a common function+signature, GCC may deem them "sibling calls" and apply a tail call+optimization in which the call to B() avoids the overhead of an ordinary+function call.  This may be an issue for kpatches which only A() or B():

which only patch A() or B()?

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 For example, a `pr_warn_once()` can be replaced with: 		pr_warn("..."); 	} ```++inline implies notrace+----------------------++The linux kernel defines its own version of "inline" in+include/linux/compiler_types.h which includes "notrace" as well:++```+#if !defined(CONFIG_OPTIMIZE_INLINING)+#define inline inline __attribute__((__always_inline__)) __gnu_inline \+        __inline_maybe_unused notrace+#else+#define inline inline                                    __gnu_inline \+        __inline_maybe_unused notrace+#endif+```++With the implicit "notrace", use of "inline" in patch sources may lead+to kpatch-build errors like the following:++1. `__tcp_mtu_to_mss()` is marked as inline:++```+net/ipv4/tcp_output.c:++/* Calculate MSS not accounting any TCP options.  */+static inline int __tcp_mtu_to_mss(struct sock *sk, int pmtu)+{+```++2. the compiler decides not to inline it and keeps it in its own+   function-section.  Then kpatch-build notices that it doesn't have an+   fentry/mcount call:++```+% kpatch-build ...++tcp_output.o: function __tcp_mtu_to_mss has no fentry/mcount call, unable to patch+```++3. a peek at the generated code:++```+Disassembly of section .text.__tcp_mtu_to_mss:++0000000000000000 <__tcp_mtu_to_mss>:+   0:   48 8b 87 60 05 00 00    mov    0x560(%rdi),%rax+   7:   0f b7 50 30             movzwl 0x30(%rax),%edx+   b:   0f b7 40 32             movzwl 0x32(%rax),%eax+   f:   29 d6                   sub    %edx,%esi+  11:   83 ee 14                sub    $0x14,%esi+  ...+```++This could be a little confusing since one might have expected to see+changes to all of `__tcp_mtu_to_mss()` callers (ie, it was inlined as+requested).  In this case, a simple workaround is to provide a new,+non-inlined copy of `__tcp_mtu_to_mss()` and then update all its callers+to use it.++Jump labels+-----------++When modifying a function that contains a jump label, kpatch-build may+return an error like: `ERROR: oom_kill.o: kpatch_regenerate_special_section: 2109: Found a jump label at out_of_memory()+0x10a, using key cpusets_enabled_key.  Jump labels aren't currently supported.  Use static_key_enabled() instead.`++This is due to a limitation in the kernel to process static key+livepatch relocations (resolved by late-module patching).  Older+versions of kpatch-build may have reported successfully building +kpatch module, but issue+[#931](https://github.com/dynup/kpatch/issues/931) revealed potentially+dangerous behavior if the static key value had been modified from its+compiled default.++The current workaround is to remove the jump label by explictly checking+the static key:++```+/* unsupported */+if (static_key_true(&key1))++/* supported */+if (static_key_enabled(&key1))+```++Constant propagation symbol changes+-----------------------------------++GCC's constant propagation optimizations may result in kpatch-build+errors like: `ERROR: timekeeping.o: symbol changed sections: .text.timekeeping_update.constprop.9`++This is currently tracked as issue+[#935](https://github.com/dynup/kpatch/issues/935) "duplicate" mangled+fuctions.  In that case, readelf revealed that kpatch-build wasn't+correleating constprop subfunctions created by the optimization:+```+# eu-readelf -s orig/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.9+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.8+# eu-readelf -s patched/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.10+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.9+```+The current workaround for this issue to add `__attribute__((noclone))`+to offending functions.++Sibling calls+-------------++If function A() calls function B() and they share a common function+signature, GCC may deem them "sibling calls" and apply a tail call+optimization in which the call to B() avoids the overhead of an ordinary+function call.  This may be an issue for kpatches which only A() or B():

It might also be worth mentioning somewhere that this is only an issue when the sibling call crosses a kernel module boundary, and only on powerpc.

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 For example, a `pr_warn_once()` can be replaced with: 		pr_warn("..."); 	} ```++inline implies notrace+----------------------++The linux kernel defines its own version of "inline" in+include/linux/compiler_types.h which includes "notrace" as well:++```+#if !defined(CONFIG_OPTIMIZE_INLINING)+#define inline inline __attribute__((__always_inline__)) __gnu_inline \+        __inline_maybe_unused notrace+#else+#define inline inline                                    __gnu_inline \+        __inline_maybe_unused notrace+#endif+```++With the implicit "notrace", use of "inline" in patch sources may lead+to kpatch-build errors like the following:++1. `__tcp_mtu_to_mss()` is marked as inline:++```+net/ipv4/tcp_output.c:++/* Calculate MSS not accounting any TCP options.  */+static inline int __tcp_mtu_to_mss(struct sock *sk, int pmtu)+{+```++2. the compiler decides not to inline it and keeps it in its own+   function-section.  Then kpatch-build notices that it doesn't have an+   fentry/mcount call:++```+% kpatch-build ...++tcp_output.o: function __tcp_mtu_to_mss has no fentry/mcount call, unable to patch+```++3. a peek at the generated code:++```+Disassembly of section .text.__tcp_mtu_to_mss:++0000000000000000 <__tcp_mtu_to_mss>:+   0:   48 8b 87 60 05 00 00    mov    0x560(%rdi),%rax+   7:   0f b7 50 30             movzwl 0x30(%rax),%edx+   b:   0f b7 40 32             movzwl 0x32(%rax),%eax+   f:   29 d6                   sub    %edx,%esi+  11:   83 ee 14                sub    $0x14,%esi+  ...+```++This could be a little confusing since one might have expected to see+changes to all of `__tcp_mtu_to_mss()` callers (ie, it was inlined as+requested).  In this case, a simple workaround is to provide a new,+non-inlined copy of `__tcp_mtu_to_mss()` and then update all its callers+to use it.++Jump labels+-----------++When modifying a function that contains a jump label, kpatch-build may+return an error like: `ERROR: oom_kill.o: kpatch_regenerate_special_section: 2109: Found a jump label at out_of_memory()+0x10a, using key cpusets_enabled_key.  Jump labels aren't currently supported.  Use static_key_enabled() instead.`++This is due to a limitation in the kernel to process static key+livepatch relocations (resolved by late-module patching).  Older+versions of kpatch-build may have reported successfully building +kpatch module, but issue+[#931](https://github.com/dynup/kpatch/issues/931) revealed potentially+dangerous behavior if the static key value had been modified from its+compiled default.++The current workaround is to remove the jump label by explictly checking+the static key:++```+/* unsupported */+if (static_key_true(&key1))++/* supported */+if (static_key_enabled(&key1))+```++Constant propagation symbol changes+-----------------------------------++GCC's constant propagation optimizations may result in kpatch-build+errors like: `ERROR: timekeeping.o: symbol changed sections: .text.timekeeping_update.constprop.9`++This is currently tracked as issue+[#935](https://github.com/dynup/kpatch/issues/935) "duplicate" mangled+fuctions.  In that case, readelf revealed that kpatch-build wasn't+correleating constprop subfunctions created by the optimization:+```+# eu-readelf -s orig/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.9+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.8+# eu-readelf -s patched/kernel/time/timekeeping.o  | grep timekeeping_update+  137: 0000000000000000    552 FUNC    LOCAL  DEFAULT       48 timekeeping_update.constprop.10+  138: 0000000000000000    568 FUNC    LOCAL  DEFAULT       50 timekeeping_update.constprop.9+```+The current workaround for this issue to add `__attribute__((noclone))`+to offending functions.++Sibling calls+-------------++If function A() calls function B() and they share a common function+signature, GCC may deem them "sibling calls" and apply a tail call

A shared function signature isn't necessarily required. The return values need to be compatible, and the call to B() is usually done at the end of A(). But it's complicated... might be easiest to just not describe the preconditions in the first place :-)

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

Author guide updates

 For example, a `pr_warn_once()` can be replaced with: 		pr_warn("..."); 	} ```++inline implies notrace+----------------------++The linux kernel defines its own version of "inline" in+include/linux/compiler_types.h which includes "notrace" as well:++```+#if !defined(CONFIG_OPTIMIZE_INLINING)+#define inline inline __attribute__((__always_inline__)) __gnu_inline \+        __inline_maybe_unused notrace+#else+#define inline inline                                    __gnu_inline \+        __inline_maybe_unused notrace+#endif+```++With the implicit "notrace", use of "inline" in patch sources may lead+to kpatch-build errors like the following:++1. `__tcp_mtu_to_mss()` is marked as inline:++```+net/ipv4/tcp_output.c:++/* Calculate MSS not accounting any TCP options.  */+static inline int __tcp_mtu_to_mss(struct sock *sk, int pmtu)+{+```++2. the compiler decides not to inline it and keeps it in its own+   function-section.  Then kpatch-build notices that it doesn't have an+   fentry/mcount call:++```+% kpatch-build ...++tcp_output.o: function __tcp_mtu_to_mss has no fentry/mcount call, unable to patch+```++3. a peek at the generated code:++```+Disassembly of section .text.__tcp_mtu_to_mss:++0000000000000000 <__tcp_mtu_to_mss>:+   0:   48 8b 87 60 05 00 00    mov    0x560(%rdi),%rax+   7:   0f b7 50 30             movzwl 0x30(%rax),%edx+   b:   0f b7 40 32             movzwl 0x32(%rax),%eax+   f:   29 d6                   sub    %edx,%esi+  11:   83 ee 14                sub    $0x14,%esi+  ...+```++This could be a little confusing since one might have expected to see+changes to all of `__tcp_mtu_to_mss()` callers (ie, it was inlined as+requested).  In this case, a simple workaround is to provide a new,+non-inlined copy of `__tcp_mtu_to_mss()` and then update all its callers+to use it.

Alternatively you could change it to __always_inline.

joe-lawrence

comment created time in 2 months

Pull request review commentdynup/kpatch

test/integration: Rebase to RHEL 8.0

 static void kpatch_bundle_symbols(struct kpatch_elf *kelf) 	} } +static void kpatch_add_child_symbol(struct symbol *parent, struct symbol *child)+{+	parent->nb_children++;+	parent->children = realloc(parent->children,+				   sizeof(*parent->children) * parent->nb_children);+	child->parent = parent;+	parent->children[parent->nb_children - 1] = child;+}+ /*  * During optimization gcc may move unlikely execution branches into *.cold- * subfunctions. kpatch_detect_child_functions detects such subfunctions and+ * subfunctions. Some functions can also be split into multiple *.part+ * functions.+ * kpatch_detect_child_functions detects such subfunctions and

Hm. Does the patched audit_log_end() also reference the "lock" static local variable? IIRC, "part" functions are clones of the originals. So it seems like audit_log_end() should also reference the static local, unless I'm missing something.

kamalesh-babulal

comment created time in 2 months

Pull request review commentdynup/kpatch

test/integration: Rebase to RHEL 8.0

 static void kpatch_bundle_symbols(struct kpatch_elf *kelf) 	} } +static void kpatch_add_child_symbol(struct symbol *parent, struct symbol *child)+{+	parent->nb_children++;+	parent->children = realloc(parent->children,+				   sizeof(*parent->children) * parent->nb_children);+	child->parent = parent;+	parent->children[parent->nb_children - 1] = child;+}+ /*  * During optimization gcc may move unlikely execution branches into *.cold- * subfunctions. kpatch_detect_child_functions detects such subfunctions and+ * subfunctions. Some functions can also be split into multiple *.part+ * functions.+ * kpatch_detect_child_functions detects such subfunctions and

I'm not sure a ".part" function can be considered a "child". In the context of this code, a child (or subfunction) means that it's a ".cold" extension of the parent function, where the parent function can branch to the child subfunction.

But in the case of ".part", I believe it's an optimized clone of the original function. But otherwise the functions have no relation -- i.e. they are independent and the parent doesn't branch to the clone.

Or maybe I'm misunderstanding. Was there a patch which showed this behavior?

kamalesh-babulal

comment created time in 2 months

push eventdynup/kpatch

chenzefeng

commit sha e9755413ed58c8d40b615552e84ff9c5e80acc57

kpatch-build: use whole word filename matching in find_parent_obj() Building a kpatch for a module with this Makefile: The Makefile is as follow: obj-m += m_hello.o m_hello-y = hello.o default: $(MAKE) -C /lib/modules/4.4.21-69-default/build M=$(shell pwd) modules clean: $(MAKE) -C /lib/modules/4.4.21-69-default/build M=$(shell pwd) clean results in kpatch-build "ERROR: two parent matches for hello.o". The problem is that find_parent_obj() looks for filenames like so: % grep -l hello.o ./.*.cmd | grep -Fv hello.o .m_hello.ko.cmd .m_hello.o.cmd where .m_hello.ko.cmd is the parant for m_hello.o, and .m_hello.o.cmd is the parant for hello.o, but because the "hello.o" is a substring of "m_hello.o", it will cause "m_hello.o" to be matched for the "hello.o" as well. Fix this by using grep's -w|--word-regexp option to force it to match whole words instead of substrings. Signed-off-by: chenzefeng <chenzefeng2@huawei.com>

view details

Josh Poimboeuf

commit sha 683289206bed3ee9296406da4ec58b881c408507

Merge pull request #1038 from wwheart/master kpatch-build: fix two parent matches error

view details

push time in 2 months

PR merged dynup/kpatch

kpatch-build: fix two parent matches error

when I make a patch for a module, cause the error as follow: ERROR: two parent matches for hello.o. Check /tmp/kpatch-build.log for more details.

The Makefile is as follow: obj-m += m_hello.o m_hello-y = hello.o default: $(MAKE) -C /lib/modules/4.4.21-69-default/build M=$(shell pwd) modules clean: $(MAKE) -C /lib/modules/4.4.21-69-default/build M=$(shell pwd) clean

and than cmd "grep -l hello.o ./.*.cmd | grep -Fv hello.o" would get two parant .m_hello.ko.cmd .m_hello.o.cmd but the ".m_hello.ko.cmd" is the parant for "m_hello.o", and ".m_hello.o.cmd" is the parant for "hello.o".

because the "hello.o" is a substring of "m_hello.o", which will cause the "m_hello.o" matched for the "hello.o".

Signed-off-by: chenzefeng chenzefeng2@huawei.com

+7 -7

3 comments

1 changed file

wwheart

pr closed time in 2 months

push eventdynup/kpatch

Julien Thierry

commit sha 50476c94cc9549ea9b421b3e2a5638ffe1a2e5a9

create-diff-object: Check ELF headers earlier There is no point inspecting through the symbols of the ELF files (original and patched) when the ELF headers do not meet requirements. Check ELF headers as soon as the files are mapped. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha bd4fae25f90659bf39bab2e7614f4fd3015af9ff

create-diff-object: Add const to unmodified rela_insn arguments rela_insn() only retrieves information about an instruction and does not modify sections or relocations. Add const to make this explicit. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Julien Thierry

commit sha 878bac379f2a1393446e8e01bebc0952620c16aa

create-diff-object: Simplify relocation processing If the symbol associated with a relocation does not have a section set, nothing is done for that relocation. Skip iterating through all the symbols of the ELF file in such a case. Signed-off-by: Julien Thierry <jthierry@redhat.com>

view details

Josh Poimboeuf

commit sha c175d8697c7aa8e155a86c3cd917da6b1a912427

Merge pull request #1039 from julien-thierry/misc-cleanups Misc cleanups

view details

push time in 2 months

PR merged dynup/kpatch

Misc cleanups

Some suggestion of cleanups I stumbled upon while trying to understand the code.

+8 -8

0 comment

1 changed file

julien-thierry

pr closed time in 2 months

push eventdynup/kpatch

Artem Savkov

commit sha 52d4936e728629ebb725de37574cbeed231dbcd5

integration/rhel-*: fix multiple.test When these from internal depths of Red Hat upstream paths changed and now we are one level deeper in directory tree. The issue probably also exist in rhel8.0 rebase pr #993. Signed-off-by: Artem Savkov <asavkov@redhat.com>

view details

Josh Poimboeuf

commit sha d131d43656b191d6b47772591c306dc9a4c68852

Merge pull request #1040 from sm00th/multiple_test integration/rhel-*: fix multiple.test

view details

push time in 2 months

PR merged dynup/kpatch

integration/rhel-*: fix multiple.test

When these from internal depths of Red Hat upstream paths changed and now we are one level deeper in directory tree.

The issue probably also exist in rhel8.0 rebase pr #993.

+4 -4

1 comment

4 changed files

sm00th

pr closed time in 2 months

issue commentClangBuiltLinux/linux

missing symbol for section .text, .init.text, .ref.text

@nickdesaulniers I think it just means that the section symbols associated with those sections are missing. It's not necessarily a bug, I'd need to see the .o file to know more.

tpimh

comment created time in 2 months

push eventdynup/kpatch

Josh Poimboeuf

commit sha 2499eb2bdcd0652c5138effecf2bed3aac90a3d7

Revert "create-diff-object: Check for *_fixup sections changes" We are seeing the following error on a real world patch: unsupported reference to special section __barrier_nospec_fixup The kpatch commit bb444c2168d1 ("create-diff-object: Check for *_fixup sections changes") created this error because we were trying to be future proof. However, that may have been overly paranoid, as it doesn't seem likely that those fixup sections will need relocations anytime soon, because the replacement instructions are manually generated in code. And anyway that "future proof" commit breaks the present. Also we decided at LPC that we are going to remove .klp.arch sections anyway, so once that happens we will be fully future-proof anyway. This reverts commit bb444c2168d17ba7a67a2329ea7ed6f9b37b45cc. Fixes #974. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

Josh Poimboeuf

commit sha 0b000cb87d88ea9dd5983ea3effb7b7e5326abc1

Merge pull request #1037 from jpoimboe/ppc64le-remove-unsupported-check Revert "create-diff-object: Check for *_fixup sections changes"

view details

push time in 2 months

PR merged dynup/kpatch

Revert "create-diff-object: Check for *_fixup sections changes"

We are seeing the following error on a real world patch:

unsupported reference to special section __barrier_nospec_fixup

The kpatch commit bb444c2168d1 ("create-diff-object: Check for *_fixup sections changes") created this error because we were trying to be future proof. However, that may have been overly paranoid, as it doesn't seem likely that those fixup sections will need relocations anytime soon, because the replacement instructions are manually generated in code. And anyway that "future proof" commit breaks the present.

Also we decided at LPC that we are going to remove .klp.arch sections anyway, so once that happens we will be fully future-proof anyway.

This reverts commit bb444c2168d17ba7a67a2329ea7ed6f9b37b45cc.

Fixes #974.

Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com

+0 -9

0 comment

1 changed file

jpoimboe

pr closed time in 2 months

issue closeddynup/kpatch

powerpc: support alternatives (aka feature fixups)

As mentioned in #963, I think we have two gaps in powerpc support related to alternatives ("feature fixups"):

  1. kpatch-build doesn't create .klp.arch sections
  2. the kernel powerpc arch livepatch code doesn't read .klp.arch sections

At least in theory this means that if any of the feature fixup sections refers to a patched function, and the alternative original code has klp relas associated with it, code corruption may occur when the klp relas clobber the copied alternative replacement code, thinking that it's the alternative original code.

Phase 1 fix:

  • For kernel versions which don't have livepatch-specific powerpc code (currently all kernel versions), kpatch-build needs to assert an error if it detects that one of the following sections refers to a patched function: __ftr_fixup, __mmu_ftr_fixup, __fw_ftr_fixup.

Phase 2 fix:

  • The upstream kernel needs a powerpc implementation of arch_klp_init_object_loaded().
  • kpatch-build needs to create klp.arch sections for powerpc for those kernel versions, instead of the phase 1 error

Phase 3 fix:

  • Convince upstream that loading patches for modules which haven't been loaded yet is still a bad idea. The easiest solution is just to modprobe all target modules before loading the patch.
  • Remove all these .klp section hacks

closed time in 2 months

jpoimboe

push eventdynup/kpatch

Artem Savkov

commit sha aabdf9c9c929dbaf43705a1211941f687297b3cf

Fix parent matches for kernels newer than 5.3 Somewhere starting with 5.3 (probably with 9f69a496f100 "kbuild: split out *.mod out of {single,multi}-used-m rules", but that is not confirmed) .mod and correcponding .mod.cmd files started showing up during module builds throwing off kpatch-build's find_parent_obj() func. Filter out any files ending with .mod.cmd as they are definitely not the parent. Signed-off-by: Artem Savkov <artem.savkov@gmail.com>

view details

Josh Poimboeuf

commit sha 7a9fc1fbc8e912a697a619581d320cb09c91b774

Merge pull request #1036 from sm00th/mod_cmd Fix parent matches for kernels newer than 5.3

view details

push time in 2 months

PR merged dynup/kpatch

Fix parent matches for kernels newer than 5.3

Somewhere starting with 5.3 (probably with 9f69a496f100 "kbuild: split out *.mod out of {single,multi}-used-m rules", but that is not confirmed) .mod and correcponding .mod.cmd files started showing up during module builds throwing off kpatch-build's find_parent_obj() func.

Filter out any files ending with .mod.cmd as they are definitely not the parent.

+14 -6

0 comment

1 changed file

sm00th

pr closed time in 2 months

PR opened dynup/kpatch

Revert "create-diff-object: Check for *_fixup sections changes"

We are seeing the following error on a real world patch:

unsupported reference to special section __barrier_nospec_fixup

The kpatch commit bb444c2168d1 ("create-diff-object: Check for *_fixup sections changes") created this error because we were trying to be future proof. However, that may have been overly paranoid, as it doesn't seem likely that those fixup sections will need relocations anytime soon, because the replacement instructions are manually generated in code. And anyway that "future proof" commit breaks the present.

Also we decided at LPC that we are going to remove .klp.arch sections anyway, so once that happens we will be fully future-proof anyway.

This reverts commit bb444c2168d17ba7a67a2329ea7ed6f9b37b45cc.

Fixes #974.

Signed-off-by: Josh Poimboeuf jpoimboe@redhat.com

+0 -9

0 comment

1 changed file

pr created time in 2 months

push eventjpoimboe/kpatch

Josh Poimboeuf

commit sha 2499eb2bdcd0652c5138effecf2bed3aac90a3d7

Revert "create-diff-object: Check for *_fixup sections changes" We are seeing the following error on a real world patch: unsupported reference to special section __barrier_nospec_fixup The kpatch commit bb444c2168d1 ("create-diff-object: Check for *_fixup sections changes") created this error because we were trying to be future proof. However, that may have been overly paranoid, as it doesn't seem likely that those fixup sections will need relocations anytime soon, because the replacement instructions are manually generated in code. And anyway that "future proof" commit breaks the present. Also we decided at LPC that we are going to remove .klp.arch sections anyway, so once that happens we will be fully future-proof anyway. This reverts commit bb444c2168d17ba7a67a2329ea7ed6f9b37b45cc. Fixes #974. Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

view details

push time in 2 months

create barnchjpoimboe/kpatch

branch : ppc64le-remove-unsupported-check

created branch time in 2 months

issue commentdynup/kpatch

powerpc: support alternatives (aka feature fixups)

And going through them manually, none of them appear to rely on relocations.

So this appears to be a false alarm. I think we are safe. And we can probably get by without .klp.arch sections on powerpc. (@kamalesh-babulal I can't remember if we talked about this previously)

But to be future-proof we should at least detect the usage of those sections in a patched function and error out in kpatch-build.

I now disagree with my past self here. We have a recent patch which shows:

unsupported reference to special section __barrier_nospec_fixup

There's no real reason to enforce this, since as I said above, "we are safe". And also we will eventually be getting rid of .klp.arch sections anyway, as discussed at LPC. I will post a patch to remove 'unsupported' for these sections.

jpoimboe

comment created time in 2 months

startedSUSE/klp-ccp

started time in 3 months

Pull request review commentdynup/kpatch

kpatch-build: Check if /etc/os-release exists

 fi [[ -z "$TARGETS" ]] && TARGETS="vmlinux modules"  # Don't check external file.-# shellcheck disable=SC1091-source /etc/os-release+# shellcheck disable=SC1090+[ -f "$RELEASE_FILE" ] && source "$RELEASE_FILE"

style nit: we use double brackets everywhere

wipawel

comment created time in 3 months

pull request commentdynup/kpatch

kpatch-build: sanity check patched filenames

As far as removing the checks in kpatch-gcc, I don't think we can do that as this commit only checks direct changes to those source files. A header file change could slip through and still modify an end object file, so I think kpatch-gcc needs to keep its checks intact.

Agreed

joe-lawrence

comment created time in 3 months

pull request commentdynup/kpatch

kpatch-build: sanity check patched filenames

Not that I can think of, but you might want to look at all the files that are ignored by kpatch-gcc. For example, it ignores lib/ files. That check can probably be removed now? There might be others as well.

joe-lawrence

comment created time in 3 months

Pull request review commentdynup/kpatch

test/integration: add an ability to check specific repo/commit

 #!/bin/bash  KPATCH_SLOW=0+KPATCH_GIT=${KPATCH_GIT:-https://github.com/dynup/kpatch.git}+KPATCH_REV=${KPATCH_REV:-HEAD} LOGDIR="/vagrant/logs"  usage() {   echo "usage: $(basename "${0}") [options]" >&2-  echo "-h, --help This message" >&2-  echo "-s, --slow Run all of the tests" >&2+  echo "-h, --help      This message" >&2+  echo "-s, --slow      Run all of the tests" >&2+  echo "-g, --git       Git url to clone from" >&2+  echo "-r, --revision  Revision to use (HEAD by default)" >&2 } -options="$(getopt -o s -l "slow" -- "$@")" || "getopt failed"+options="$(getopt -o "shg:r:" -l "slow,help,git:,revision:" -- "$@")" || "getopt failed"  eval set -- "${options}"  while [[ $# -gt 0 ]]; do   case "$1" in     -s|--slow)       KPATCH_SLOW=1+      shift+      ;;+    -g|--git)+      KPATCH_GIT="${2}"+      shift 2+      ;;+    -r|--revision)+      KPATCH_REV="${2}"+      shift 2       ;;     -h|--help)       usage       exit 0       ;;+    --)+      shift+      break+      ;;   esac-  shift done -git clone https://github.com/dynup/kpatch.git || exit 1+git clone "${KPATCH_GIT}" || exit 1  cd kpatch || exit 1 +git reset --hard "${KPATCH_REV}" || exit 1

Ah, right. Though since it's run in a VM and it's a fresh clone I guess there shouldn't be any local changes anyway? I guess either way works.

sm00th

comment created time in 3 months

more