[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f7df65b0-ae41-8cce-01aa-84349efc387a@huawei.com>
Date: Wed, 21 Sep 2022 11:16:04 +0800
From: Chen Zhongjin <chenzhongjin@...wei.com>
To: Ard Biesheuvel <ardb@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
CC: Michael Matz <matz@...e.de>, Borislav Petkov <bp@...en8.de>,
"Josh Poimboeuf" <jpoimboe@...nel.org>,
<linux-toolchains@...r.kernel.org>,
"Indu Bhagat" <indu.bhagat@...cle.com>,
Nick Desaulniers <ndesaulniers@...gle.com>,
<linux-kernel@...r.kernel.org>,
"Jose E. Marchesi" <jemarch@....org>,
Miroslav Benes <mbenes@...e.cz>,
Mark Rutland <mark.rutland@....com>,
"Will Deacon" <will@...nel.org>, <x86@...nel.org>,
<linux-arm-kernel@...ts.infradead.org>,
<live-patching@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
Sathvika Vasireddy <sv@...ux.ibm.com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Mark Brown <broonie@...nel.org>
Subject: Re: [RFC] Objtool toolchain proposal:
-fannotate-{jump-table,noreturn}
Hi,
On 2022/9/21 0:49, Ard Biesheuvel wrote:
> On Thu, 15 Sept 2022 at 10:47, Peter Zijlstra <peterz@...radead.org> wrote:
>> On Thu, Sep 15, 2022 at 10:56:58AM +0800, Chen Zhongjin wrote:
>>
>>> We have found some anonymous information on x86 in .rodata.
>> Well yes, but that's still a bunch of heuristics on our side.
>>
>>> I'm not sure if those are *all* of Josh wanted on x86, however for arm64 we
>>> did not found that in the same section so it is a problem on arm64 now.
>> Nick found Bolt managed the ARM64 jumptables:
>>
>> https://github.com/llvm/llvm-project/blob/main/bolt/lib/Target/AArch64/AArch64MCPlusBuilder.cpp#L484
>>
>> But that does look like a less than ideal solution too.
>>
>>> Does the compiler will emit these for all arches? At lease I tried and
>>> didn't find anything meaningful (maybe I omitted it).
>> That's the question; can we get the compiler to help us here in a well
>> defined manner.
> Do BTI landing pads help at all here? I.e., I assume that objtool just
> treats any indirect call as a dangling edge in the control flow graph,
> and the problem is identifying the valid targets. In the BTI case,
> those will all start with a 'BTI J' instruction.
Maybe not enough, I guess.
For switch jump tables we need to know its *own* jump targets so that we
can go through all its branches. If there are more than one indirect
jump inside one function, only marks targets with BTI J can't help
matching the entry and its targets.
Anyway I think this job is more for compiler. Switch jump tables is
different from other indirect jump/call. It have fixed control flow just
as if/else flow and the indirect jump table is just a compiler
optimization which hide this.
Best,
Chen
Powered by blists - more mailing lists