linux-kernel - Re: [RFC PATCH 0/4] Add jump table support for objtool on LoongArch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <bad4a7fd-e487-498d-f6ab-b9a17e049dd7@loongson.cn>
Date: Mon, 15 Jul 2024 17:56:03 +0800
From: Tiezhu Yang <yangtiezhu@...ngson.cn>
To: Jinyang He <hejinyang@...ngson.cn>, Josh Poimboeuf <jpoimboe@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>, Huacai Chen <chenhuacai@...nel.org>
Cc: Xi Ruoyao <xry111@...111.site>, loongarch@...ts.linux.dev,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/4] Add jump table support for objtool on LoongArch

On 07/12/2024 06:19 PM, Jinyang He wrote:
> Are we always avoid our problems?
>
> 1, When text section not support "R_LARCH_32_PCREL", update compiler
>    to add AS_HAS_THIN_ADD_SUB.
> 2, When not support jump-table, use "-fno-jump-tables" to avoid it,
>    (and now update compiler to add CC_HAS_ANNOTATE_TABLEJUMP).
> 3, When not support relax, use "-mno-relax" to avoid it.
> 4, When some where in asm can be backtraced but generate warning,
>    use STACK_FRAME_NON_STANDARD to avoid it.
> 5, When the goto-table cannot be handled (I guess the Ruoyao's
>    patch cannot handle goto table), use CONFIG_BPF_JIT_ALWAYS_ON
>    to avoid compile ___bpf_prog_run.
> 6, And other $fp warnings not be solved in clang. Do we only care gcc?
>
> So how to do in the future if compilers have other changed? Do we
> need update compilers (both gcc and clang) again and again? Why
> not just update objtool codes to solves these problems? As many
> RISC arch not support directly find jump table, can we support
> more generic ways to find it?

This is a choose and balance. In principle, I want to make the kernel
code clear and simple to enhance the readability and maintainability,
I do not want to modify too much architecture independent code of the
objtool framework, I just want to implement the architecture specific
function.

As the gcc patch "LoongArch: Add support to annotate tablejump" said,
the objtool program needs to analysis the control flow of each .o file
generated by compiler toolchain, if a jump table is used, objtool has
to correlate the jump instruction with the table, on x86 it's simple:
a relocation entry natrually correlates them because one instruction is
used for table-based jump, but on an RISC machine objtool would have to
reconstruct the data flow if it must find out the correlation on its own,
so emit an additional section to store the correlation info as pairs of
addresses, each pair contains the address of a jump instruction (jr) and
the address of the jump table. This is very trivial to implement in GCC.

For jump table support of objtool on LoongArch, it makes life much easier
with the gcc changes. As far as I can see, the remain issues (goto table
in ___bpf_prog_run() and jump table in assemble code) are only related
with kernel and can be solved with kernel changes.

Thanks,
Tiezhu