Support patching objects that have duplicated function names. This feature was
introduced upstream in Linux v4.5.
This patch appends the symbol position to the symbol structure when
lookup_local_symbol is called. This pos variable is then used when creating the
funcs and dynrelas sections. Finally, incorporate sympos into the livepatch
patch hook only if the kernel version is greater than v4.5. In other cases the
older format is used.
Fixes: #493
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
The uncorrelation logic is incomplete. For bundled symbols, in addition
to uncorrelating the sections, it should also uncorrelate the section
symbols and any rela sections.
Similarly the correlation logic needs to correlate section symbols. (It
already correlates rela sections.)
If a kernel SRPM is used to get the kernel sources, the target kernel
version is determined from the name of the SRPM.
One cannot obtain the target kernel version this way if the source tree
is used instead of an SRPM, so let us extract that information from
vmlinux.
Signed-off-by: Evgenii Shatokhin <eshatokhin@odin.com>
This fix is an addition to 9fedd0d283 "kpatch-build: fix
gcc_version_check".
On some systems, the GCC version stored in vmlinux may have the
following format:
(GNU) 4.8.3 20140911 (Red Hat 4.8.3-9)
while GCC returns
(GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)
As a result, binary patches cannot be built, although the compiler is
the same.
gcc_version_check() now takes this into account.
Signed-off-by: Evgenii Shatokhin <eshatokhin@odin.com>
Deal with a special case where gcc needs a pointer to the address at the end of
a data section.
This is usually used with a compare instruction to determine when to end a
loop. The code doesn't actually dereference the pointer so this is "normal"
and we just replace the section reference with a reference to the last symbol
in the section.
Note that this only catches the issue when it happens at the end of a section.
It can also happen in the middle of a section. In that case, the wrong symbol
will be associated with the reference. But that's ok because:
1) This situation only occurs when gcc is trying to get the address of the
symbol, not the contents of its data; and
2) Because kpatch doesn't allow data sections to change, &(var1+sizeof(var1))
will always be the same as &var2.
Fixes: #553
Refine the static local variable handling again. This builds on a
previous patch by Zhou Chengming.
This fixes the following bugs reported by Zhou:
1. xxx.123 ---> xxx.123 (previous correlation by coincidence)
xxx.256 ---> xxx.256 (previous correlation by coincidence)
But real xxx.123 ---> xxx.256
In this case, the code doesn't work. Because when find patched_sym for
xxx.123, the xxx.256 in patched_object hasn't been de-correlated.
2. old-object | new-object
func1 | func1
xxx.123 | xxx.123 (inline)
func2 | func2
xxx.256 | xxx.256
xxx.123 | xxx.123 (inline)
When find patched_sym for xxx.123, first find xxx.123 in func1 of new-object,
But then find xxx.256 in func2 of new-object.
So I think should not iterate the base-sections, when find one, just go out to next symbol.
Both of these problems can be fixed by splitting the code up into
multiple passes:
1. uncorrelate all static locals
2. correlate all static locals
3. ensure each static local is referenced by all the same sections in
both objects
4. print warning on any new static locals
Fixes: #545
Before this patch, kpatch_build dependends on bash version >4.0
that support declare -A. This patch remove this dependency by
replacing dict(declare -A) with array.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
When find kobj, it should use 'cat changed_objs' to get the changed
objects, in order to process the following object format:
a/b/c/../../object.o. If using patched dir to get changed object,
the object will be a/object.o, but it is a/b/c/../../object.o in
*.cmd file.
This patch also fix the find_parent_obj that change the format
'a/b/c/../../object.o' to 'a/object.o' in deep find, otherwise
it will fail with "two parent matches for *.o".
Signed-off-by: Li Bin <huawei.libin@huawei.com>
readelf -wi may output trailing spaces in the lines with section names
('alt_instr', etc.). The regexps should take this into account,
otherwise kpatch-build may fail with error:
"can't find special struct size"
This script works on other distros and can target source linux directories.
Adjust comments to match this.
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Rewrite the static local variable correlation logic. The algorithm now
traverses all the static locals in the original object rather than the
patched object, ensuring that each symbol in the original object has a
twin. It adds a new restriction that static local variables can't be
removed.
This adds support for the following:
- Multiple static locals with the same name in the same function
- Two separate static locals which happen to have the same numbered
suffix
- Static locals which are referenced by data sections
- CSWTCH and other static locals which are sometimes unused due to
sharing of their data sections
Fixes: #514
It turns out this is a more general issue which exists for more than
just CSWTCH symbols. The new static local handling code will handle it.
This reverts commit fd0c1bbe9c888c4a2b6684bba0bddb0f463caac8.
create-diff-object now checks if the original functions have fentry calls.
If an original function to be affected by the patch does not have the
fentry call, it cannot be patched. Error is reported in that case.
kpatch_create_mcount_sections() now also takes into account if a changed
or a new function has fentry call. If it does, mcount record is
generated for it as before. If a changed or a new function has no fentry
call, it is not an error in this case.
All this fixes the following issues.
1. If an original function has no fentry call (e.g. a "notrace" function)
but the patched function has it, the original function can not be
patched, but it would only be detected when applying the patch.
2. kpatch_create_mcount_sections() crashed if a patched function had no
relocation at all.
I observed such crashes when experimenting with a modified version of
the patch "tcp_cubic: better follow cubic curve after idle period" in
CentOS 7 x64.
Besides that, for a function with the first instruction starting with
0x0f, it would be incorrectly detemined that the function had fentry call.
The first bytes of the function would be overwritten in that case.
3. create-diff-object output an error if a new (an added) function had
no fentry call. This restriction is not necessary.
v2:
* Moved the check for fentry calls after the call to
kpatch_compare_correlated_elements() and before info about the original
ELF file is destroyed. The original symbols are now checked there (via
sym->twin) rather than the patched ones.
* Removed an excessive error check.
Signed-off-by: Evgenii Shatokhin <eshatokhin@odin.com>
Build artifacts are stored in $CACHEDIR/tmp instead of /tmp. This includes
files such as the build log and the temp directories used to build the patch.
In addition, allow $CACHEDIR to be set as an environment variable.
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Hard-coding the special section group sizes is unreliable. Instead,
determine them dynamically by finding the related struct definitions in
the DWARF metadata.
Fixes#517.
Fixes#523.
-ffunction-sections and -fdata-sections are needed when building the
original and the patched kernels.
It is not necessary, however, to use these options when building a
patch module itself, its functions and data are OK in the sections they
are.
Let us remove these options from KCGLAGS after the kernels have been
built.
If a source RPM is used to obtain the kernel sources, kpatch-build
executes rpmdev-setuptree to prepare ~/rpmbuild directory tree, installs
the source RPM there. Then it calls 'rpmbuild -bp' to prepare the
kernel source tree.
All this, however, may clobber the existing contents of ~/rpmbuild,
which is very inconvenient if one uses rpmbuild to build other packages.
To avoid that, I could not find a better way than to specify a fake home
directory (~/.kpatch/tempsrc) for that portion of kpatch-build. It seems,
neither rpmdev-setuptree nor rpm have appropriate options for that.
I put the affected commands into a subshell so that the changes in $HOME
could not propagate to other parts of kpatch-build.
If kpatch core module is packaged in an RPM and the package is installed,
the likely location of the module and its symvers file is
/lib/modules/<kernel_version>/extra/kpatch/.
kpatch-build checks this location too now when looking for the .symvers
file. This is convenient for distributing the Kpatch tools as RPMs and
the like.
Signed-off-by: Evgenii Shatokhin <eshatokhin@odin.com>
Before this fix, kpatch-build looked for Module.symvers for the core
module built for the currently running kernel. So, if one tried to build
a patch module for a kernel, different from the current one, an error
would occur. This patch fixed the problem.
Signed-off-by: Evgenii Shatokhin <eshatokhin@odin.com>
