-
Notifications
You must be signed in to change notification settings - Fork 310
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Arm64 including all changes in PR #1302 (@swine, @surajjs95, @t-msn, and others) #1439
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Puranjay Mohan <[email protected]>
The "has_function_profiling" support field in the symbol struct is used to show that a function symbol is able to be patched. This is necessary to check that functions which need to be patched are able to be. On arm64 this means the presence of 2 NOP instructions at function entry which are patched by ftrace to call the ftrace handling code. These 2 NOPs are inserted by the compiler and the location of them is recorded in a section called "__patchable_function_entries". Check whether a symbol has a corresponding entry in the "__patchable_function_entries" section and if so mark it as "has_func_profiling". Signed-off-by: Suraj Jitindar Singh <[email protected]> [Modify to use __patchable_function_entries support added upstream] Signed-off-by: Puranjay Mohan <[email protected]>
…rch64 Add aarch64 support to kpatch_create_ftrace_callsite_sections(). Check for the 2 required NOP instructions on function entry, which may be preceded by a BTI C instruction depending on whether the function is a leaf function. This determines the offset of the patch site. Signed-off-by: Pete Swain <[email protected]> Signed-off-by: Puranjay Mohan <[email protected]>
Add the final support required for aarch64 and enable building on that arch. Signed-off-by: Suraj Jitindar Singh <[email protected]> [kpatch_line_macro_change_only() fixes] Signed-off-by: Puranjay Mohan <[email protected]>
On arm64 when CONFIG_DEBUG_BUGVERBOSE is enabled debugging information about bug sections is stored in the ".rodata.str" section of the object file. If this isn't included then linking fails as labels in this section are referenced by relocations in the bug table. Include this section to enable building patches which contain this bug debug information. Signed-off-by: Suraj Jitindar Singh <[email protected]>
It seems mapping symbols in aarch64 elf has section size of 0. So, exclude it in section symbol replacing code just like kpatch_correlate_symbols(). This fixes the data-read-mostly unit test on aarch64. Signed-off-by: Misono Tomohiro <[email protected]> Signed-off-by: Puranjay Mohan <[email protected]>
Copy from kernel source tree. Signed-off-by: Misono Tomohiro <[email protected]>
For arm64 this option uses -fpatchable-function-entry=M,2, so 2 NOPs are placed before the function entry point (in order to store a pointer to ftrace_ops). When calculating function padding, check for the presence of the two NOPs, and adjust the padding size by 8 if they are found. This was merged in the upstream kernel in v6.8 with: baaf553d3bc3 ("arm64: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS") With this into the equation, the entry of a function can look like one of: 1. Without DYNAMIC_FTRACE_WITH_CALL_OPS and CONFIG_ARM64_BTI_KERNEL ------------------------------------------------------------------- Disassembly of section .text.cmdline_proc_show: 0000000000000008 <cmdline_proc_show>: 8: d503201f nop c: d503201f nop 2. Without DYNAMIC_FTRACE_WITH_CALL_OPS and with CONFIG_ARM64_BTI_KERNEL ------------------------------------------------------------------------ Disassembly of section .text.cmdline_proc_show: 0000000000000008 <cmdline_proc_show>: 0: d503245f bti c 4: d503201f nop 8: d503201f nop 3. With DYNAMIC_FTRACE_WITH_CALL_OPS and without CONFIG_ARM64_BTI_KERNEL ------------------------------------------------------------------------ Disassembly of section .text.cmdline_proc_show: 0000000000000000 <cmdline_proc_show-0x8>: 0: d503201f nop 4: d503201f nop 0000000000000008 <cmdline_proc_show>: 8: d503201f nop c: d503201f nop 4. With DYNAMIC_FTRACE_WITH_CALL_OPS and with CONFIG_ARM64_BTI_KERNEL --------------------------------------------------------------------- Disassembly of section .text.cmdline_proc_show: 0000000000000000 <cmdline_proc_show-0x8>: 0: d503201f nop 4: d503201f nop 0000000000000008 <cmdline_proc_show>: 8: d503245f bti c c: d503201f nop 10: d503201f nop make create-diff-object aware of DYNAMIC_FTRACE_WITH_CALL_OPS and its quirks. Signed-off-by: Dylan Hatch <[email protected]> Signed-off-by: Puranjay Mohan <[email protected]>
The sframe sections can't be normally diffed and need to be created separately. skip them for now. Signed-off-by: Puranjay Mohan <[email protected]>
kpatch_replace_sections_syms() substitutes the object/function symbols for the section symbol in the relocation sections. But relocations in .rela.__patchable_function_entries can point to an instruction ouside the function. This is because with CALL_OPS enabled, two NOPs are added before the function entry. __patchable_function_entries needs the address of the first NOP above the function. We anyway generate __patchable_function_entries again in kpatch_create_ftrace_callsite_sections() so we can skip mangling these relocations Signed-off-by: Puranjay Mohan <[email protected]>
for (i = 0; (void *)insn < insn_end && *insn == 0xd503201f; i++, insn++) | ||
; | ||
|
||
if (i == 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we believe the i
should be either 0 or 2, would it be better if we can report an error here when the i
is some other value?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the function_padding_size is decideced by the nop padding at the start of the function.
The number of nop adding to the function head is decided by the N of building option
-fpatchable-function-entry
.
Or maybe this function padding size can be calculated by this building option of the target kernel
build Makefile? And we can support more specific situation?
This is a rebase of #1302 with some more changes and some already merged patches removed.
It is supposed to work with the
sframe
based reliable stack unwinder posted upstream:[PATCH 0/8] unwind, arm64: add sframe unwinder for kernel
NOTE:
Building and testing a livepatch on a 6.12 arm64 kernel for the following basic patch:
Load and Unload test
Unit tests pass with the objects at: https://github.com/mihails-strasuns/kpatch-unit-test-objs/tree/arm64
Integration tests