Hi,
On 27.08.2021 01:34, Peter Swain wrote:
We have a new userspace live-patch creation tool, LLpatch, paralleling
kpatch-build, but without requiring its arch-specific code for ELF
analysis and manipulation.
We considered extending kpatch-build to a new target architecture
(arm64), cluttering its code with details of another architecture’s
quirky instruction sequences & relocation modes, and suspected there
might be a better way.
The LLVM suite already knows these details, and offers llvm-diff, for
comparing generated code at the LLVM-IR (internal representation)
level, which has access to much more of the code’s _intent_ than
kpatch’s create-diff-object is able to infer from ELF-level
differences.
Interesting.
LLpatch requires a pre-built kernel tree ("repository"), right?
Does that mean that the kernel should be built with clang first?
Or, perhaps, clang is only used when building the patch itself, while
the kernel can be built with GCC or other compiler used by the given
Linux distro?
Building on this, LLpatch adds namespace analysis, further
dead/duplicate code elimination, and creation of patch modules
compatible with kernel’s livepatch API.
Arm64 is supported - testing against a livepatch-capable v5.12 arm64
kernel, using the preliminary reliable-stacktrace work from
madvenka@xxxxxxxxxxxxxxxxxxx, LLpatch modules for x86 and arm64 behave
identically to the x86 kpatch-build modules, without requiring any
additional arch-specific code.
On x86, where both tools are available, LLpatch produces smaller patch
modules than kpatch, and already correctly handles most of the kpatch
test cases, without any arch-specific code. This suggests it can work
with any clang-supported kernel architecture.
Work is ongoing, collaboration is welcome.
See https://github.com/google/LLpatch for further details on the
technology and its benefits.
Yonghyun Hwang (yonghyun@xxxxxxxxxx freeaion@xxxxxxxxx)
Bill Wendling (morbo@xxxxxxxxxx isanbard@xxxxxxxxx)
Pete Swain (swine@xxxxxxxxxx swine@xxxxxxxxx)
.
Regards,
Evgenii
