From: Chen Zhongjin <chenzhongjin@huawei.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <jthierry@redhat.com>,
<catalin.marinas@arm.com>, <will@kernel.org>,
<mark.rutland@arm.com>, <ardb@kernel.org>, <masahiroy@kernel.org>,
<jpoimboe@redhat.com>, <ycote@redhat.com>
Subject: Re: [RFC PATCH v3 13/13] objtool: arm64: Enable stack validation for arm64
Date: Fri, 8 Apr 2022 17:25:59 +0800 [thread overview]
Message-ID: <c6f69fc4-0d8f-baa8-2d13-6ac765bbc2c3@huawei.com> (raw)
In-Reply-To: <20220407121919.GK2731@worktop.programming.kicks-ass.net>
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..
prev parent reply other threads:[~2022-04-08 9:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 12:01 [RFC PATCH v3 00/13] objtool: add base support " Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 01/13] tools: Add some generic functions and headers Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 02/13] tools: arm64: Make aarch64 instruction decoder available to tools Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 03/13] tools: bug: Remove duplicate definition Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 04/13] objtool: arm64: Add base definition for arm64 backend Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 05/13] objtool: arm64: Decode add/sub instructions Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 06/13] objtool: arm64: Decode jump and call related instructions Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 07/13] objtool: arm64: Decode other system instructions Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 08/13] objtool: arm64: Decode load/store instructions Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 09/13] objtool: arm64: Decode LDR instructions Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 10/13] objtool: arm64: Accept non-instruction data in code sections Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 11/13] objtool: arm64: Handle supported relocations in alternatives Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 12/13] objtool: arm64: Ignore replacement section for alternative callback Chen Zhongjin
2022-04-07 12:01 ` [RFC PATCH v3 13/13] objtool: arm64: Enable stack validation for arm64 Chen Zhongjin
2022-04-07 12:19 ` Peter Zijlstra
2022-04-08 9:25 ` Chen Zhongjin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c6f69fc4-0d8f-baa8-2d13-6ac765bbc2c3@huawei.com \
--to=chenzhongjin@huawei.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=jpoimboe@redhat.com \
--cc=jthierry@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
--cc=ycote@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®