Re: Linux Plumbers Conf 2021

[Peter Zijlstra <peterz@infradead.org>]

On Tue, May 18, 2021 at 07:48:19AM -0500, Josh Poimboeuf wrote:
> Fixing linux-toolchains list address.
> 
> On Tue, May 18, 2021 at 07:43:13AM -0500, Josh Poimboeuf wrote:
> > On Tue, May 18, 2021 at 01:14:48PM +0100, Will Deacon wrote:
> > > 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.

 - 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.