|
klp checksum hashes a data symbol's length, its bytes, and every relocation
it carries -- as the target's name and adjusted addend, except a reference
into a string section, which contributes the string's contents instead.
Nothing covered any of it.
Each is load-bearing, and the failure is always the same shape: a checksum
which ignores one calls a changed object unchanged, klp diff leaves it out
of the patch, and the patched code goes on reading the kernel's old copy.
The string case cannot be caught by hashing bytes: the pointer is
identical, same section and same offset, and only the text it refers to
moved.
One fixture, six variants applied to the patched build alone. Each was
verified by sabotaging the line it covers and watching the test fail:
raw bytes initialiser change
length a .bss object grows; its bytes are never hashed
string contents literal edited in place, pointer untouched
reloc target name pointer moved to another function
reloc addend same array, different index
section-symbol path the same, via a static's section symbol
Two of those needed the fixture rebuilding. An initialised array does not
isolate the length, because growing one changes the hashed bytes too --
hence .bss, where there are none. And a named char[] does not reach the
contents-hashing path at all: that keys on SHF_STRINGS, which the compiler
sets on the mergeable section a literal lands in and not on an array given
a section of its own.
Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence <joe.lawrence@redhat.com>
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu <song@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20260916184351.2720310-47-song@kernel.org
|
