linux-kernel - Re: [RFC PATCH v3 13/13] objtool: arm64: Enable stack validation for arm64

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] [day] [month] [year] [list]

Message-ID: <c6f69fc4-0d8f-baa8-2d13-6ac765bbc2c3@huawei.com>
Date:   Fri, 8 Apr 2022 17:25:59 +0800
From:   Chen Zhongjin <chenzhongjin@...wei.com>
To:     Peter Zijlstra <peterz@...radead.org>
CC:     <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>, <jthierry@...hat.com>,
        <catalin.marinas@....com>, <will@...nel.org>,
        <mark.rutland@....com>, <ardb@...nel.org>, <masahiroy@...nel.org>,
        <jpoimboe@...hat.com>, <ycote@...hat.com>
Subject: Re: [RFC PATCH v3 13/13] objtool: arm64: Enable stack validation for
 arm64

Hi Peter,

You are right that Julien had tried to use gcc plugin to fix this but 
refused by Ard.

With jump tables objtool will give some sibling call errors because we 
can't detect
jump table correctly on arm64. Then in the v2 patch they gave a 
conclusion that
it is acceptable to close jump table.

Now we still have some problems on arm64. The todo list includes:

- BRK insns are decoded as INSN_BUG and then marked as dead_end, which 
makes objtool
stop checking and cause unreachable error.

- Some functions need to be annotated by UNWIND micro or marked as noreturn.

- arm64 and x86 share the code for check.c and it can make some problem.
Now I found some errors about __ex_table which is related to alternative 
entry
search code for x86 in special.c.

- Some *.S file still contain data inside text section which cannot be 
excluded or
decoded such as head.S. Also, we have a assembly file kuser32.S which 
reporting
undecodable error.

Now I'm trying to fix these problems with minimum change on arm64 
architecture
and objtool code. To be honest, objtool check grows to a huge x86 wool 
ball now and
make migration a bit difficult. Josh mentions there will be a 
refectoring for objtool
features and maybe we can separatedly support features on different 
arches which will
make things easier.

Also, Madhaven has commited a new patch for stack validation. It's seems 
an available
approch that using DWARF to make stack validation so that we don't need 
to adapt to
different architectures. I'm checking the code and planning to help to 
test it.

Anyway, besides stack validation I think it's still valuable to migrate 
objtool on arm64.
So let things going on and if you have any advise or help I'll be vary 
appriciate for that.

Thanks for your time!

On 2022/4/7 20:19, Peter Zijlstra wrote:
> IIRC this is a sore spot for the whole endeavour..