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.
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.
Right now, the makefile has one target, create-diff-object, which
contains all the source/headers as one long list and all the source
files compiled in one command to make create-diff-object.
This doesn't scale well and doesn't accurately portray the dependencies
of each object that contribute to the final binary.
This commit renames create-diff-object.c to main.c so that it can be
compiled and linked seperately and cleanly in Make and autogenerates
dependencies for each .o. This should make it easier to add additional
object files, or refactor the very large main.o into seperate object
file, later.
Combine all the patch modules into a single kpatch-COMBINED.ko for a
much quicker test which still gives 95% or so of the coverage compared
to the full test suite. Use "make quick" for use this new option.
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
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.
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>
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>
This is a basic integration test framework for kpatch, which tests
building, loading, and unloading patches, as well as any other related
custom tests.
The kpatch-test script looks for test input files in the
tests/integration directory. It expects certain file naming
conventions:
- foo.patch - patch that should build successfully
- bar-FAIL.patch - patch that should fail to build
- foo-LOADED.test - executable which tests whether the foo.patch module
is loaded. It will be used to test that loading/unloading the patch
module works as expected.
Any other *.test files will be executed after all the patch modules have
been built from the *.patch files. They can be used for more custom
tests above and beyond the simple loading and unloading tests.
I just have one test here, but many more to come eventually. I'm
constantly doing manual testing of patches and am planning on automating
them with this framework.
Build and install the kpatch core module with make and make install,
rather than building it every time with kpatch build.
The only downside to this approach is that the user has to make and make
install kpatch every time they get a new kernel. But this is only
temporary, until the kpatch module is delivered in an RPM.
The end-to-end patching works. From object analysis to generation to
runtime patching. It's still missing the scripting piece that will only
take a patch and kernel source dir as input.
Jessica Yu
Seth Jennings
Josh Poimboeuf