Re: Linux Plumbers Conf 2021

On Tue, May 18, 2021 at 6:23 AM Peter Zijlstra [off-list ref] wrote:

On Tue, May 18, 2021 at 07:48:19AM -0500, Josh Poimboeuf wrote:

quoted

Fixing linux-toolchains list address.

On Tue, May 18, 2021 at 07:43:13AM -0500, Josh Poimboeuf wrote:

quoted

On Tue, May 18, 2021 at 01:14:48PM +0100, Will Deacon wrote:

quoted

If it's not too late, I'd definitely be interested in a discussion around
objtool support for arm64. Specifically, I would very much like us _not_
to have a hard dependency on objtool and instead treat it as a binary
linter of sorts. However, this likely requires help from the toolchain
where some of the jobs which are performed by objtool on x86 today now
need to be done by the compiler/linker for arm64.

I don't have a good handle on exactly what is needed and whether there's
any appetite from the toolchain developers to implement this, so it would
be very helpful to kick that discussion off.

Objtool stack validation already is pretty much a "binary linter".  If
all the warnings are fixed then we can trust the unwind metadata (e.g.
frame pointers) for reliable unwinding / live patching.

All warnings are expected to be fixed by humans, so objtool doesn't have
to edit the binary (assuming no ORC, which is optional).  Objtool is
only considered a hard dependency for live patching because unfixed
warnings could mean a livepatch fail.

So I wonder what specifically you have in mind?

Things objtool does (in no apparent order):

 - validate stack frames

 - generate ORC unwind data (optional)

 - validates unreachable instructions; specifically the lack thereof
   (optional)

 - validates retpoline; or specifically the lack of indirect jump/call
   sites (with annotations for those few that are okay). (optional)

 - validates uaccess rules; specifically no call/ret in between
   __user_access_begin() and __user_access_end(). (optional)

 - validates noinstr annotation; *HOWEVER* we rely on objtool to NOP
   all __sanitizer_cov_* calls in .noinstr/.entry text sections because
   __no_sanitize_cov is 'broken' in all known compilers.

^ Do you have more information on this?

 - generates __mcount_loc section and NOPs the __fentry call sites
   (optional)

 - generates .static_call_sites section for STATIC_CALL_INLINE support

 - rewrites compiler generates call/jump to the retpoline thunk to an
   alternative such that we can patch out the thunk with an indirect
   call/jmp when retpolines are disabled. (arch dependent)

 - rewrites specific jmp.d8 sites (as found through the __jump_table
   section) to nop2, because GAS is unable to determine if a jmp becomes
   a jmp.d8 or jmp.d32 and emit the right sized nop. (optional)


So all except the __sanitize_cov__ crud would be fine, but that thing in
specific really wants fixing in the toolchains. Aside of that, all the
things where objtool generates/modifies sections/code are optional and
or architecture dependent.

Aside of that, objtool depends on being able to reconstruct the code
flow as generated by the compiler and a few code-gen options are known
to generate things objtool simply cannot follow, arm64 in specific had
some trouble with jump-tables.

-- 
Thanks,
~Nick Desaulniers