Comments (2)
This is very similar to the .smp_locks issue, except these relocations are 8 bytes:
Relocation section [73] '.rela__jump_table' for section [72] '__jump_table' at offset 0x11bb0 contains 36 entries:
Offset Type Value Addend Name
000000000000000000 X86_64_64 000000000000000000 +43 .text.call_timer_fn
0x0000000000000008 X86_64_64 000000000000000000 +160 .text.call_timer_fn
0x0000000000000010 X86_64_64 0x0000000000000280 +8 __tracepoint_timer_expire_entry
0x0000000000000018 X86_64_64 000000000000000000 +54 .text.call_timer_fn
0x0000000000000020 X86_64_64 000000000000000000 +112 .text.call_timer_fn
0x0000000000000028 X86_64_64 0x0000000000000240 +8 __tracepoint_timer_expire_exit
0x0000000000000030 X86_64_64 000000000000000000 +257 .text.run_timer_softirq
0x0000000000000038 X86_64_64 000000000000000000 +416 .text.run_timer_softirq
0x0000000000000040 X86_64_64 0x0000000000000200 +8 __tracepoint_timer_cancel
0x0000000000000048 X86_64_64 000000000000000000 +20 .text.init_timer_key
0x0000000000000050 X86_64_64 000000000000000000 +112 .text.init_timer_key
0x0000000000000058 X86_64_64 0x0000000000000300 +8 __tracepoint_timer_init
0x0000000000000060 X86_64_64 000000000000000000 +35 .text.detach_if_pending
0x0000000000000068 X86_64_64 000000000000000000 +128 .text.detach_if_pending
0x0000000000000070 X86_64_64 0x0000000000000200 +8 __tracepoint_timer_cancel
0x0000000000000078 X86_64_64 000000000000000000 +32 .text.migrate_timer_list
0x0000000000000080 X86_64_64 000000000000000000 +120 .text.migrate_timer_list
0x0000000000000088 X86_64_64 0x0000000000000200 +8 __tracepoint_timer_cancel
0x0000000000000090 X86_64_64 000000000000000000 +80 .sched.text
0x0000000000000098 X86_64_64 000000000000000000 +440 .sched.text
0x00000000000000a0 X86_64_64 0x0000000000000300 +8 __tracepoint_timer_init
0x00000000000000a8 X86_64_64 000000000000000000 +237 .sched.text
0x00000000000000b0 X86_64_64 000000000000000000 +504 .sched.text
0x00000000000000b8 X86_64_64 0x00000000000002c0 +8 __tracepoint_timer_start
0x00000000000000c0 X86_64_64 000000000000000000 +115 .text.add_timer_on
0x00000000000000c8 X86_64_64 000000000000000000 +176 .text.add_timer_on
0x00000000000000d0 X86_64_64 0x00000000000002c0 +8 __tracepoint_timer_start
0x00000000000000d8 X86_64_64 000000000000000000 +95 .text.mod_timer_pinned
0x00000000000000e0 X86_64_64 000000000000000000 +232 .text.mod_timer_pinned
0x00000000000000e8 X86_64_64 0x00000000000002c0 +8 __tracepoint_timer_start
0x00000000000000f0 X86_64_64 000000000000000000 +128 .text.mod_timer_pending
0x00000000000000f8 X86_64_64 000000000000000000 +256 .text.mod_timer_pending
0x0000000000000100 X86_64_64 0x00000000000002c0 +8 __tracepoint_timer_start
0x0000000000000108 X86_64_64 000000000000000000 +136 .text.mod_timer
0x0000000000000110 X86_64_64 000000000000000000 +144 .text.mod_timer
0x0000000000000118 X86_64_64 0x00000000000002c0 +8 __tracepoint_timer_start
from kpatch.
Revised analysis:
__jump_table is a table of struct jump_entry
, 24 bytes in size on x86_64, init'ed to 0. All three fields are reloc'ed.
from arch/x86/include/asm/jump_label.h
#ifdef CONFIG_X86_64
typedef u64 jump_label_t;
#else
typedef u32 jump_label_t;
#endif
struct jump_entry {
jump_label_t code;
jump_label_t target;
jump_label_t key;
};
.rela__jump_table looks like this:
Relocation section [73] '.rela__jump_table' for section [72] '__jump_table' at offset 0x11bb0 contains 36 entries:
Offset Type Value Addend Name
000000000000000000 X86_64_64 000000000000000000 +43 .text.call_timer_fn
0x0000000000000008 X86_64_64 000000000000000000 +160 .text.call_timer_fn
0x0000000000000010 X86_64_64 0x0000000000000280 +8 __tracepoint_timer_expire_entry
The "code" and "target" fields point to locations within the function with the tracepoint. The "key" field points to a symbol "__tracepoint_timer_expire_entry" which references the __tracepoints section. There is a _tracepoint* symbol for each tracepoint in the __tracepoints section.
The __tracepoints section, in turn, is a table of struct tracepoints
, 64 bytes in size on x86_64, init'ed to 0.
from include/linux/tracepoint.h
struct tracepoint {
const char *name; /* Tracepoint name */
struct static_key key;
void (*regfunc)(void);
void (*unregfunc)(void);
struct tracepoint_func __rcu *funcs;
};
The "name" field is reloc'ed, referencing an offset in a string table contained in the __tracepoints_strings section:
Relocation section [288] '.rela__tracepoints' for section [287] '__tracepoints' at offset 0x14f88 contains 13 entries:
Offset Type Value Addend Name
000000000000000000 X86_64_64 000000000000000000 +0 __tracepoints_strings
0x0000000000000040 X86_64_64 000000000000000000 +10 __tracepoints_strings
0x0000000000000080 X86_64_64 000000000000000000 +24 __tracepoints_strings
...
There are _tpstrtab* symbols pointing to each string in the string in the table.
Additionally there is a __tracepoints_ptrs section that is a table of pointers that reference the struct tracepoints
in the __tracepoints section. There are also _tracepoint_ptr* symbols that reference the pointers in __tracepoint_ptrs.
So... this rabbit hole goes much deeper than originally thought.
from kpatch.
Related Issues (20)
- Do we need more robust archeticture protection HOT 4
- kpatch-build: verify_patch_files might miss a parameter HOT 2
- ERROR in find_local_syms, couldn't find matching XXX local symbols in vmlinux symbol table HOT 14
- Can you add support for Rocky and Alma? HOT 1
- relocation with type R_X86_64_GOTPCREL is not supported HOT 5
- Arch Compile kpatch-git test failed HOT 4
- Regarding "statically allocated data" again HOT 2
- kpatch-build error when modifying an object file's only syscall
- nowhere to find the definition of klp_register_patch HOT 5
- x86 paravirt code uses alternatives v6.8+ HOT 1
- special-static.patch can fail to build on s390x / upstream v6.8 HOT 6
- CONFIG_FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY not supported on ppc64le HOT 6
- function __pfx_new_sync_read has no fentry/mcount call, unable to patch HOT 6
- Unchanged and unpatchable function moves from .text to .text.unlikely HOT 5
- Why did the kpatch-build script export the KPATCH-BUILD environment variable from the BUILD directory to the SOURCE directory? HOT 3
- CONFIG_WERROR=y and CONFIG_LD_ORPHAN_WARN_LEVEL="error" break kpatch-build HOT 2
- linux 6.9.0-rc6 can't find special struct paravirt_patch_site size HOT 6
- fair.o: changed section .data..read_mostly not selected for inclusion HOT 11
- find_local_syms: 218: couldn't find matching cm.c local symbols in ib_mad symbol table HOT 7
- Kernel Warning: Unpatched return thunk in use. This should not happen! HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kpatch.