The inventory based testing for create-diff-object was introduced at a
time when create-diff-object only needed the two object files to operate.
Now, it requires vmlinux as well. This makes the inventory testing (a
unit testing framework for create-diff-object) obsolete and difficult to
update in it's current form.
This commit removes the inventory test framework.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This commit introduces functionality to verify the location of symbols
used in both the patch and dynrelas sections. It adds significant
protection from mismatches between the base and running kernels.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Right now the matching criteria for the NULL sym is type LOCAL and shndx
UNDEF. Unfortunately, that would also match any new LOCAL symbol
added to the symbol table with uninit'd sym.* fields i.e. the upcoming
__kpatch_strings and .kpatch.strings symbols.
Change the matching criteria to be symbols that have a zero-length name;
a property unique to the NULL sym.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
kpatch_migrate_included_symbols() is called from
kpatch_reorder_symbols() now, not kpatch_migrate_included_elements().
The difference is the kpatch_reorder_symbols() is operating on the
output kpatch_elf structure, and thus all symbols are by definition
included.
Remove the check and rename the function since it is redundant.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This fixes the weird ld errors we've been seeing lately.
According to the "ELF-64 Object File Format" spec, the symtab sh_info
field should contain "Index of first non-local symbol (i.e., number of
local symbols)".
Right now, reindexing of the included sections and symbols is done
when they migrate to the output kpatch_elf structure. However, due
to recently added features, the section and symbol list is not
final at this point, leading to constant tracking of the indexes for
addition sections and symbols added after this point. Additionally,
symbols have to be in a particular order, adding to the complexity.
This commit delays the reindexing and symbol reordering until the
section and symbol lists are finalized, removing the need to
track indexes and placeholders in the symbol list.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Since we only ever have one cache at a time, move the kernel source from
~/.kpatch/$(uname -r)/src to ~/.kpatch/src. This allows ccache to work
between kernel version changes, making it less painful to build for
multiple kernels. The cache's kernel version is stored in
~/.kpatch/version.
The user-installed vs system-installed dichotomy is confusing. Let's
just have "installed". RPM-installed modules can just call "kpatch
install" in their post-install step.
Because create-diff-object is a one-shot program (not a long lived
process) we haven't really bothered with cleaning up and freeing any
allocated memory. However, freeing data when it passes out of the
logical scope does have debugging benefits.
This commit adds two new functions for tearing down and freeing the
primary struct kpatch_elf data structures. The idea is the if a stale
pointer still references the old data structure that has passed out of
the logical scope, an issue will be more immediately apparent (i.e. NULL
references).
Signed-off-by: Seth Jennings <sjenning@redhat.com>
We rebuild the rela section data buffer in kpatch_create_rela_section()
just to rebuild it again later in kpatch_rebuild_rela_section_data()
before writing the output ELF file.
This commit removes the redundant rebuild while retaining the update
for the section header data.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This adds dynamic linking support for the patch modules. It is the
first step toward supporting patching module code and relocatable
kernels.
Rela entries that reference non-included local and non-exported global
symbols are converted to "dynrelas". These dynrelas are relocations
that are done by the core module, not the kernel module linker. This
allows the core module to apply offsets to the base addresses found
in the base vmlinux or module.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Conflicts:
kpatch-build/kpatch-build
In preparation for dynamic symbol linking, the symbol lookup logic
is going to move into create-diff-obj anyway. We might as well
minimize the code duplication and pull this into create-diff-obj.
This avoids having to re-parse the ELF file modify it in-place.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
Conflicts:
kpatch-build/kpatch-build
Right now, there is a case where a symbol is included but not its
section. This is the case when the symbol is a rela dependency of
another section by the symbol section (the object or function) has not
changed. When we migrate the included symbols over to the output kelf
structure however, these symbols are still referencing their old
non-included section via their sec fields. This is a bug.
This commit adds code to the symbol migration to test whether the
symbol's section was also included. If so, it updates the symbol's
section index. If not it sets the section index to UNDEF and its sec
field to NULL.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
There's at least one case in the kernel (ddebug_proc_show) where the
compiled instructions are affected by the source file path given to gcc.
Which means that compiling the kernel with O= will result in many of the
function addresses changing. This causes a mismatch between the locally
compiled vmlinux and the original vmlinux, which is very dangerous,
since we need the addresses to be correct.
The easy fix is just to use the original vmlinux for all the function
addresses.
Other potential ways to fix it which we might want to consider in the
future:
- use a combination of the old System.map and the new vmlinux to find
the addresses. The function ordering should be the same. For
non-duplicate symbols, use System.map. For duplicate symbols, use
vmlinux to find what order the symbol comes in. e.g. the 2nd
occurrence of foo() in System.map. It adds a little complexity to the
lookup code, but seems safe and wouldn't require the kernel debuginfo
package. However, this may not help us for patching modules.
- do something similar at runtime, i.e. use kallsyms_lookup_name for
non-dups and kallsyms_on_each_symbol for dups, and look for the nth
occurrence of the symbol (value of n is decided at build time). This
has the complexity of the previous option but it's done at runtime
rather than build time, so... why? Doing it at build time is better.
- compile the kernel in place. This basically means no more caching
because recompiling with --function-sections causes everything to be
recompiled again. This is bad for kpatch developers' SSDs...
We merged PR #186 a little too hastily. It seg faults with the new
parainstructions-section.patch in the integration test suite. Reverting
it for now until we get it figured out.
This reverts commit e1177e3a03.
This reverts commit 880e271841.
This reverts commit 2de5f6cbfb.
This reverts commit 38b7ac74ad.
This reverts commit 108cd9f95e.
One of the tests is now failing:
ERROR: smp-locks-section: kpatch replace failed
I suspect the issue is the vmlinux mismatch problem. Fix for that
coming soon.
The kpatch_regenerate_* functions use a local list_head to construct the
new list. While the local list_head is copied to the sec->relas after
it is built, the neighboring nodes in the list are not updated, leading
to list corruption.
This commit uses list_replace() which updates the neighbor nodes properly.
Regression introduced by PR #1175d36dd1.
Fixes#185.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
This adds dynamic linking support for the patch modules. It is the
first step toward supporting patching module code and relocatable
kernels.
Rela entries that reference non-included local and non-exported global
symbols are converted to "dynrelas". These dynrelas are relocations
that are done by the core module, not the kernel module linker. This
allows the core module to apply offsets to the base addresses found
in the base vmlinux or module.
Signed-off-by: Seth Jennings <sjenning@redhat.com>
