Add support for Arm64 including all changes in PR #1302 (@swine, @surajjs95, @t-msn, and others) #1439
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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]>
puranjaymohan
changed the title
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]>
ZzzMao
reviewed
Feb 18, 2025
| for (i = 0; (void *)insn < insn_end && *insn == 0xd503201f; i++, insn++) | ||
| ; | ||
|
|
||
| if (i == 2) |
There was a problem hiding this comment.
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.
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?
There was a problem hiding this comment.
In the arm64 kernel build, there could be:
- no nops at the start
- 2 nops at the start
- 2 nops before the start and two after the start.
There could also be a BTI instruction at the entry of the function before the two nops, if they exist.
|
Hi, Puranjay I am testing this pull request using two types of kernels: one [1] that uses the sframe unwinder for livepatch, and one [2] that does not. [1] https://lore.kernel.org/all/[email protected]/ The test environment is as follows:
In both kernels, the "module-LOADED.test" fails during integration testing. The results of reproducing the issue on the command line are as follows: It seems likely that the cause of this issue is the same as the one mentioned in the previous patch submission: https://lore.kernel.org/linux-arm-kernel/[email protected]/ It appears that Adding more information:
Applying the update patch for 6.13 available at https://lore.kernel.org/all/[email protected]/ now causes module-LOADED.test to PASS. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a rebase of #1302 with some more changes and some already merged patches removed.
It is supposed to work with the
sframebased 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