Re: [PATCH 0/8] unwind, arm64: add sframe unwinder for kernel

Puranjay Mohan <[email protected]>
Newsgroups org.kernel.vger.linux-toolchains,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-kernel,org.kernel.vger.live-patching
Message-ID <[email protected]>
Indu Bhagat <[email protected]> writes:

> On 2/12/25 11:25 PM, Song Liu wrote:
>> On Wed, Feb 12, 2025 at 6:45 PM Josh Poimboeuf <[email protected]> wrote:
>>>
>>> On Wed, Feb 12, 2025 at 06:36:04PM -0800, Song Liu wrote:
>>>>>> [   81.261748]  copy_process+0xfdc/0xfd58 [livepatch_special_static]
>>>>>
>>>>> Does that copy_process+0xfdc/0xfd58 resolve to this line in
>>>>> copy_process()?
>>>>>
>>>>>                          refcount_inc(&current->signal->sigcnt);
>>>>>
>>>>> Maybe the klp rela reference to 'current' is bogus, or resolving to the
>>>>> wrong address somehow?
>>>>
>>>> It resolves the following line.
>>>>
>>>> p->signal->tty = tty_kref_get(current->signal->tty);
>>>>
>>>> I am not quite sure how 'current' should be resolved.
>>>
>>> Hm, on arm64 it looks like the value of 'current' is stored in the
>>> SP_EL0 register.  So I guess that shouldn't need any relocations.
>>>
>>>> The size of copy_process (0xfd58) is wrong. It is only about
>>>> 5.5kB in size. Also, the copy_process function in the .ko file
>>>> looks very broken. I will try a few more things.
>> 
>> When I try each step of kpatch-build, the copy_process function
>> looks reasonable (according to gdb-disassemble) in fork.o and
>> output.o. However, copy_process looks weird in livepatch-special-static.o,
>> which is generated by ld:
>> 
>> ld -EL  -maarch64linux -z norelro -z noexecstack
>> --no-warn-rwx-segments -T ././kpatch.lds  -r -o
>> livepatch-special-static.o ./patch-hook.o ./output.o
>> 
>> I have attached these files to the email. I am not sure whether
>> the email server will let them through.
>> 
>> Indu, does this look like an issue with ld?
>> 
>
> Sorry for the delay.
>
> Looks like there has been progress since and issue may be elsewhere, but:
>
> FWIW, I looked at the .sframe and .rela.sframe sections here, the data 
> does look OK.  I noted that there is no .sframe for copy_process () in 
> output.o... I will take a look into it.

Hi Indu,

I saw another issue in my kernel build with sframes enabled (-Wa,--gsframe):

ld: warning: orphan section `.init.sframe' from `arch/arm64/kernel/pi/lib-fdt.pi.o' being placed in section `.init.sframe'
[... Many more similar warnings (.init.sframe) ...]

So, this orphan sections is generated in the build process.

I am using GNU ld version 2.41-50 and gcc (GCC) 11.4.1

Is this section needed for sframes to work? or can we discard
.init.sframe section with a patch like following to the linker script:

-- 8< --

diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 6a437bd08..8e704c0a6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -1044,9 +1044,16 @@ defined(CONFIG_AUTOFDO_CLANG) || defined(CONFIG_PROPELLER_CLANG)
 # define SANITIZER_DISCARDS
 #endif

+#if defined(CONFIG_SFRAME_UNWIND_TABLE)
+#define DISCARD_INIT_SFRAME *(.init.sframe)
+#else
+#define DISCARD_INIT_SFRAME
+#endif
+
 #define COMMON_DISCARDS                                                        \
        SANITIZER_DISCARDS                                              \
        PATCHABLE_DISCARDS                                              \
+       DISCARD_INIT_SFRAME                                             \
        *(.discard)                                                     \
        *(.discard.*)                                                   \
        *(.export_symbol)                                               \

-- >8 --

Thanks,
Puranjay
signature.asc (application/pgp-signature, 255 B)
-----BEGIN PGP SIGNATURE-----

iIoEARYKADIWIQQ3wHGvVs/5bdl78BKwwPkjG3B2nQUCZ673fRQccHVyYW5qYXlA
a2VybmVsLm9yZwAKCRCwwPkjG3B2ne/eAQC3MvMRgb8+tzHOKgUa02OQ8qhh8Qda
ugo9amOhQSojUwEA/O95Eq3WPvdzumKfUGDoCSjxPWA9E0HeESbhvVIuIAw=
=Qfo9
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.