On Fri, Oct 14, 2016 at 04:21:59PM +0300, Evgenii Shatokhin wrote: > Hi, > > It might be not a problem in Kpatch itself but perhaps you could give an > advice on how to deal with it. > > I hit a strange problem when experimenting with the patches for > CVE-2015-7872 and CVE-2016-5696 for the kernel 3.10.0-327.4.4 in CentOS. > > To build the binary patch for these, I used the same GCC as was used for the > kernel, GCC 4.8.3 20140911 (Red Hat 4.8.3-9). > > The following error was reported by kpatch-build: > > /usr/libexec/kpatch/create-diff-object: ERROR: gc.o: > kpatch_create_dynamic_rela_sections: 2659: lookup_local_symbol > graveyard.20319 (gc.c) needed for .text.key_gc_unused_keys.constprop.1 > > The kernel has such symbol but with a different numeric suffix: > $ readelf -sW ./vmlinux | grep -F graveyard. > 24328: ffffffff819df280 16 OBJECT LOCAL DEFAULT 15 graveyard.20316 > > I cannot say why the same GCC behaved differently in these cases. > > I can change lookup_local_symbol() so that it would ignore such suffixes for > variables (but not for the functions) when matching the names. This is not > enough however, because the dynrela for that symbol still refers to > graveyard.20319 and the binary patch fails to load as a result. > > The problem has not shown up for other kernels so far, only for > 3.10.0-327.4.4. > > Any ideas?
Hi Evgenii, gcc added the suffix to the graveyard variable because it's a static local variable, which is very similar to a global variable, except its scope is local to the function. So it's possible for there to be several of these variables with the same name in the same file, or even in the same function. The .20316 suffix is its gcc object number, which can change even if you patch completely unrelated code. It's always added to static local variables to distinguish them for other static locals which might have the same name. In general, dealing with static local variables properly is hard, and has been a real problem area for kpatch-build. We have plans to rewrite the static local handling code (yet again). For some background, see: https://github.com/dynup/kpatch/issues/545 Anyway, I don't know what specific issue you're seeing, but feel free to open a github issue for it. -- Josh _______________________________________________ kpatch mailing list kpatch@redhat.com https://www.redhat.com/mailman/listinfo/kpatch
