When pruning entries from the fixup table, update the offsets in
.rela__ex_table otherwise the relas might point to the wrong fixup entry
or even out of the .fixup section.
Fixes#615.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
If $SRCDIR was a git repo, we leave the repo with a dirty index even after
reversing the patch during cleanup. This gets picked up by
scripts/setlocalversion and consequently subsequent kpatch-builds using the
same $SRCDIR end up with a '+' sign appended to the version string. Fix
this by properly refreshing the index during cleanup.
Source RPMs for recent Fedora kernels have a '.git' subdirectory, which
causes '+' to be appended to the module version magic, causing the
module to fail to load:
kpatch_readdir: version magic '4.8.6-201.fc24.x86_64+ SMP mod_unload ' should be '4.8.6-201.fc24.x86_64 SMP mod_unload '
Add a switch to kpatch-build that provides an opt-out to the cleanup
portion of the script. This can be handy when debugging $TEMPDIR or
$RPMTOPDIR contents, as well as inspecting the patched source code
itself.
The user's environment might have TEMPDIR exported. If so, then kpatch-build
dies with a bogus "invalid ancestor" error. If you turn those bogus errors into
warnings, then the script goes on to incorrectly put into the generated .ko file
every single function that was compiled in the *original* kernel build, thereby
producing an immense .ko file with more than 64k sections that the linux kernel
cannot load. This fix makes sure that TEMPDIR is unexported on the build of the
original kernel. Actually, this fix uses a separate KPATCH_GCC_TEMPDIR variable,
so that if the kernel build is interrupted, the cleanup function in the kpatch-kbuild
script will still have TEMPDIR set correctly.
Signed-off-by: Martin Carroll <martin.carroll@alcatel-lucent.com>
This fixes the detection of WARN_ON_ONCE, WARN_ONCE, and WARN_TAINT_ONCE
on Linux 4.6 and newer.
The signature for those macros changed with upstream Linux commit
dfbf2897d004 ("bug: set warn variable before calling WARN()").
Fixes#602.
Since is_bundleable() is only called once by kpatch_create_symbol_list(),
and no other kpatch-build tool will need to call this function, we can
simply make it static and local to kpatch-elf.c
Introduce a common kpatch elf api by moving all functions and struct
declarations related to manipulating kpatch_elf objects from
create-diff-object to kpatch-elf.{h,c}. Move logging macros to a separate
file log.h, and have kpatch-elf.h include it. These changes will generalize
the kpatch-elf and logging api and make it available to other kpatch-build
tools.
Including the .altinstr_replacement section by itself and without
.altinstructions doesn't make sense, as it only serves as a memory area to
hold replacement instructions to be copied over when alternatives are
applied. Don't include .altinstr_replacement unconditionally and only
include it when .altinstructions is also marked as included.
While the officially supported distributions all have
CONFIG_DEBUG_KERNEL enabled, this is not true for some other
distributions.
This option is necessary when kpatch-build retrieves the
SPECIAL_VARS using readelf command.
Signed-off-by: Quey-Liang Kao <s101062801@m101.nthu.edu.tw>
kpatch-build currently requires Module.symvers for the Kpatch core
module unconditionally and fails if it is not found. This does not allow
using kpatch-build to prepare livepatch-based patches.
This patch fixes the problem.
Signed-off-by: Evgenii Shatokhin <eshatokhin@virtuozzo.com>
Process the patch name correctly that only concern the fuffix with
.patch or .diff. Otherwise if the patch name is not end with .patch
or .diff but has it as substring, the fuffix will be removed
unreasonably.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
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 fd0c1bbe9c.
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>
Before this patch, if changed function is weak symbol, it is not
be allowed to create live patch, and it will trigger the following
error:
/usr/local/libexec/kpatch/create-diff-object: ERROR: ***.o:
kpatch_create_patches_sections: 2294: lookup_global_symbol ***
And if the changed function reference the weak symbol, when loading
the patch module will trigger the following error:
module kpatch-***: overflow in relocation type *** val 0
insmod: can't insert 'kpatch-***.ko': invalid module format
This patch fix it and add support for patching weak function.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
kpatch_verify_patchability can detect the change of .bss or .data or
.init section, but it must be processed before verify num_changed.
Otherwise, for example, if only .init section changed, it will fail
with 'no changed functions were found', but not 'unsupported section
change(s)'.
With this patch,
for .init section: .init section will not a bundled section, so if
the section changed, not sync the function status, kpatch_verify_patchability
will give 'changed section <secname> not selected for inclusion' and
'unsupported section change(s)' error.
for .bss/.data section: kpatch_verify_patchability will ensure not
including .data or .bss section, otherwise it will give 'data section
<secname> selected for inclusion' and 'unsupported section change(s)'
error.
Signed-off-by: Li Bin <huawei.libin@huawei.com>
If a static variable is a pointer, it has rela section.
Example:
static int *p = &a;
changed to:
static int *p = &b;
so its rela section has changed.
Then this change of data should be found and report error.
But if we don't correlate its rela section, we won't
find this change.
Signed-off-by: Zhou ChengMing <zhouchengming1@outlook.com>
kpatch-build was failing on centos7 with
mv: cannot stat '/home/vagrant/rpmbuild/BUILD/kernel-*/linux-3.10.0-229.el7.x86_64': No such file or directory
in the error log. This was due to the actual directory being named
linux-3.10.0-229.el7.centos.x86_64. This patch avoids this failure by
adding a wildcard before the arch.
Signed-off-by: Louis Taylor <louis@kragniz.eu>
Bash doesn't correctly format the version string which causes the source
package to not be downloaded correctly.
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
The current WARN detection logic catches the majority of cases, but
there are still a lot of outliers which it doesn't catch (thanks, gcc).
I looked at a much larger sample of WARN calls and came up with a more
generic algorithm.
The _rs variable is used for printk ratelimiting, similar to __warned,
which makes it a logical candidate to be "special": don't correlate it,
yet don't mark a function as changed just because it references it.
When patching a kernel module, if we can't find a needed dynrela symbol,
we currently assume it's exported. However, it's also possible that
it's provided by another .o in the patch module. Add support for that.
Fixes#445.
Currently unbundled section references are only replaced if the start of
the symbol is referenced. It's also useful to support replacement of
references which point to inside the symbol.
Improve the static local variable correlation logic, for the case where
a static local is used by multiple functions. For each usage of the
variable, look for a corresponding usage in the base object. If we find
at least one matching usage, consider it a twin.
Allow static locals to be used by two functions. This is possible if
the static's containing function is inlined. We only need to find one
of them to do the correlation.
