linux-kernel - Re: Commit 0d989ac2c90b broke my x86-64 build.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 25 Oct 2021 11:59:45 -0700
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Rob Landley <rob@...dley.net>,
        Masahiro Yamada <masahiroy@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: Commit 0d989ac2c90b broke my x86-64 build.

On Mon, Oct 25, 2021 at 04:56:37PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 25, 2021 at 07:46:56AM -0700, Josh Poimboeuf wrote:
> > On Mon, Oct 25, 2021 at 11:04:33AM +0200, Peter Zijlstra wrote:
> > > On Sun, Oct 24, 2021 at 09:51:45PM -0500, Rob Landley wrote:
> > > > > Unfortunately I think CONFIG_STACK_VALIDATION is no longer optional on
> > > > > x86-64 these days, because of static calls and retpolines.
> > > > 
> > > > Does it need stack validation, or just a frame unwinder?
> > > 
> > > static_calls rely on objtool to find all "call __SCT*" instructions and
> > > write their location in a .static_call_sites section.
> > > 
> > > The having of static calls is not optional on x86_64, and I have zero
> > > interest in trying to work out what not having static_call() does, or to
> > > maintain that option.
> > 
> > What I meant was, make STATIC_CALL_INLINE optional.  Then it would use
> > out-of-line static calls which should just work, no?
> 
> Yeah, I suppose so... I think we're then missing a STACK_VALIDATION
> dependency for KCOV. We rely on objtool to nop out those
> __sanitizer_cov_* calls.
> 
> I had really hoped to just make objtool an unconditional part of x86_64.

I was hoping the opposite ;-)  Not everybody wants the extra build
overhead, object size, complexity, warnings, etc.  And it should be
pretty easy to make it optional anyway.

Plus it's a good idea to make the dependencies more explicit.  We've
already been looking at modularizing, like creating a new CONFIG_OBJTOOL
option and splitting stack validation out from some of the other
features.  This could be a nice extension of that.

Which reminds me, I'm still thinking we need to make the interface more
easily combinable, like:

objtool run				\
	[--validate]			\
	[--noinstr]			\
	[--retpoline]			\
	[--orc]				\
	[--mcount]			\
	[--static-call]			\
	[--kcov]			\
	[--frame-pointer]		\
	[--vmlinux]			\
	[--uaccess]			\
	[--module]			\
	[--no-unreachable]		\
	[--backup]			\
	[--stats]			\
	[--backtrace]

objtool dump				\
	[--orc]				\
	[--mcount]			\
	[--static-call]			\
	[--alternatives]		\
	[--whatever]

I can hopefully get to it one of these weeks...

-- 
Josh