[v5,00/33] objtool: add base support for arm64

Message

Chen Zhongjin June 22, 2022, 3:48 p.m. UTC

This series enables objtool to start doing stack validation and orc
generation on arm64 kernel builds.

Based on Julien's previous work(1)(2), Now I have finished most of work
for objtool enable on arm64. This series includes objtool part [1-13]
and arm64 support part [14-33], the second part is to make objtool run
correctly with no warning on arm64 so if necessary it can be taken apart
as two series.

ORC generation feature is implemented but not used because we don't have
an unwinder_orc on arm64, now it only be used to check whether objtool
has correct validation.

This series depends on (https://lkml.org/lkml/2022/6/22/463)
I moved some changes which work for all architectures to that series
because this one becomes too big now.
And it is rebased to tip/objtool/core branch.

I think the series is complete enough so I removed the RFC.
However now there are still (maybe only) two unsolved problems:

1. the switch optimization and dynamic jump
Although this problem has been troubling us for a long time and
temporarily resolved by -no-jump-table. Hopefully we have chance
to fix it. I'm trying for that and it will be updated in next version.

2. alternative_cb
alternative_cb in arm64 is an dynamic patch mechanism on arm64 which is
similiar to alternative instruction but doesn't give instructions explicitly.
It cause trouble when there is a jump instructions inside it and causes some
branch that objtool can't reach.
I have solved some of them by adding UNWIND_HINT one macro
"mitigate_spectre_bhb_loop" can't be fixed because it is used in
different assembly files.

(1) https://lkml.org/lkml/2021/3/3/1135
(2) https://github.com/julien-thierry/linux.git
---
v5 Changes:
Compare to last RFC v4 series, this series does a lot of changes, including
code rebase, refactoring and solution for several warning in last series.
After refactoring and moving some patches out, the number of lines in this
series decrease a thousand.

Here are changes for each patch.

[1] Removed unnecessary part from insn.h and insn.c to avoid extra
dependencies and wired hack. So the patch to add head files also be removed.

[2] Rebase Makefile, clear sync-check for insn.h/c and add arm64 elf
relocation types in elf.h.
Remove other callee saved registers tracking except FP and LR. Beacause
in arm64 there are lots of branches store these CSRs in different order
or positions, tracking them will cause some false stack state mismatch
warnings.

[3-6] Refactor code. Add some macros to make code more clean.
For instructions load/store on stack, Simplifies the logic of moving SP
and accessing data because the order of ops makes no differences.

[7-8] Remove delete in record_invalid_insn because now we don't need to
handle special undecoded instructions.

[13] New patch to enable ORC generation.

[12, 14, 17] Rebase to current branch.

[19-21] Add annotations for trans_pgd-asm.S and some unreachable
branches.

[29] Moves kuser32.S and sigreturn32.S to rodata because they are VDSO.

[31] Remove ignores for hibernate.c.

[33] New patch to fix a fallthrough problem.

---
v4 Changes:
- fix EX_ENTRY_SIZE from 8 to 12.
- modify arm64 for supporting objtool, including annotation,
	asm code modification, ignoring some validation, to make objtool
	be enable to pass arm64 builds.

v3 Changes:
- rebase Julien's version to mainstream and solve conflicts.
- Merge dumplicate "*type = INSN_OTHER".
- When meeting unrecognized instructions such as datas
	in .text code or 0x0 padding insns, last version used
	"loc->ignorable" to mark and remove them from objtool insn list.

	However there are two problems to do so:
	1. when meeting insns can't be decoded or excluded, objtool will
	just stop.
	
	2. deleting every insn can cause problems in fellow procedure.

	So I changed "record_invalid_insn" that we can delete one insn or
	just set it ignored. Now check will throw an error and going on when
	meeting undecodable instructions.

	Also, to prevent the confusion between "loc->ignorable" and
	"insn->ignore" I changed "ignore" to "delete".

v2 Changes:
	- Drop gcc plugin in favor of -fno-jump-tables
	- miscelaneous fixes and cleanups

Comments

Daniel Thompson June 22, 2022, 5:19 p.m. UTC | #1

On Wed, Jun 22, 2022 at 11:48:47PM +0800, Chen Zhongjin wrote:
> This series enables objtool to start doing stack validation and orc
> generation on arm64 kernel builds.
> 
> Based on Julien's previous work(1)(2), Now I have finished most of work
> for objtool enable on arm64. This series includes objtool part [1-13]
> and arm64 support part [14-33], the second part is to make objtool run
> correctly with no warning on arm64 so if necessary it can be taken apart
> as two series.
> 
> ORC generation feature is implemented but not used because we don't have
> an unwinder_orc on arm64, now it only be used to check whether objtool
> has correct validation.
> 
> This series depends on (https://lkml.org/lkml/2022/6/22/463)
> I moved some changes which work for all architectures to that series
> because this one becomes too big now.
> And it is rebased to tip/objtool/core branch.

What is the sha1 of the base?

With b4 and git am the patch series is derailing at patch 6 and I'm even
after a bit of fixup (had to use rediff) I'm still getting a cascade of
errors in later patches to decode.c .


Daniel.

Chen Zhongjin June 23, 2022, 1:37 a.m. UTC | #2

Hi,

On 2022/6/23 1:19, Daniel Thompson wrote:
> On Wed, Jun 22, 2022 at 11:48:47PM +0800, Chen Zhongjin wrote:
>> This series enables objtool to start doing stack validation and orc
>> generation on arm64 kernel builds.
>>
>> Based on Julien's previous work(1)(2), Now I have finished most of work
>> for objtool enable on arm64. This series includes objtool part [1-13]
>> and arm64 support part [14-33], the second part is to make objtool run
>> correctly with no warning on arm64 so if necessary it can be taken apart
>> as two series.
>>
>> ORC generation feature is implemented but not used because we don't have
>> an unwinder_orc on arm64, now it only be used to check whether objtool
>> has correct validation.
>>
>> This series depends on (https://lkml.org/lkml/2022/6/22/463)
>> I moved some changes which work for all architectures to that series
>> because this one becomes too big now.
>> And it is rebased to tip/objtool/core branch.
> 
> What is the sha1 of the base?
> 
> With b4 and git am the patch series is derailing at patch 6 and I'm even
> after a bit of fixup (had to use rediff) I'm still getting a cascade of
> errors in later patches to decode.c .
> 
> 
> Daniel.
> .

Thanks for your review!

It seems I stupidly deleted something before sending the patch. I'm trying to
regenerate it and send another version.

Very sorry for that makes trouble, please try the next version later, thanks!

Best,
Chen