linux-kernel - Re: [PATCH v3 05/10] objtool: Handle unreachable entry of rodata

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: <c21f145f-c63d-ca37-b13b-2599d91492e8@loongson.cn>
Date: Tue, 19 Nov 2024 18:47:27 +0800
From: Jinyang He <hejinyang@...ngson.cn>
To: Tiezhu Yang <yangtiezhu@...ngson.cn>, Huacai Chen
 <chenhuacai@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
 Peter Zijlstra <peterz@...radead.org>
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 05/10] objtool: Handle unreachable entry of rodata

On 2024-11-19 14:56, Tiezhu Yang wrote:

> When compling with Clang on LoongArch, there exists unreachable entry
> of rodata which points to a nop instruction after the function return
> instruction, this is generated by compiler to fill the non-existent
> switch case, just skip the entry when parsing the relocation section
> of rodata.
>
> This is preparation for later patch on LoongArch, there is no effect
> for the other archs with this patch.
>
> Signed-off-by: Tiezhu Yang <yangtiezhu@...ngson.cn>
> ---
>   tools/objtool/check.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index eb4c89501493..17df3738e087 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -2136,6 +2136,14 @@ static int add_jump_table(struct objtool_file *file, struct instruction *insn,
>   		if (!dest_insn)
>   			break;
>   
> +		/* Handle the special cases compiled with Clang on LoongArch */
> +		if (file->elf->ehdr.e_machine == EM_LOONGARCH &&
> +		    reloc->sym->type == STT_SECTION && dest_insn->type == INSN_NOP &&
Why it points to NOP, and whether it could be some other instruction 
(e.g. break)?
It seems fragile. I think it should fix in Clang.
> +		    (!insn_func(dest_insn) || insn_func(dest_insn)->pfunc != pfunc)) {
> +			prev_offset = reloc_offset(reloc);
> +			continue;
> +		}
> +
>   		/* Make sure the destination is in the same function: */
>   		if (!insn_func(dest_insn) || insn_func(dest_insn)->pfunc != pfunc)
>   			break;