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

Message

Chen Zhongjin June 23, 2022, 1:48 a.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 series:
"objtool: Reorganize x86 arch-specific code"
(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 two series are rebased to tip/objtool/core branch:
'commit 22682a07acc3 ("objtool: Fix objtool regression on x32 systems")'

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
similar 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
---
v6 Changes:
Fix conflicts makes patches can't be applied.

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