linux-kernel - Re: objtool "no non-local symbols" error with tip of tree LLVM

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]

Message-ID: <20220518161725.2bkzavre2bg4xu72@treble>
Date:   Wed, 18 May 2022 09:17:25 -0700
From:   Josh Poimboeuf <jpoimboe@...nel.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        llvm@...ts.linux.dev, linux-kernel@...r.kernel.org,
        kasan-dev@...glegroups.com
Subject: Re: objtool "no non-local symbols" error with tip of tree LLVM

On Wed, May 18, 2022 at 07:30:06AM +0200, Peter Zijlstra wrote:
> On Tue, May 17, 2022 at 06:24:29PM -0700, Josh Poimboeuf wrote:
> > On Tue, May 17, 2022 at 05:42:04PM +0200, Peter Zijlstra wrote:
> > > +	for (;;) {
> > > +		symtab_data = elf_getdata(s, symtab_data);
> > > +		if (t)
> > > +			shndx_data = elf_getdata(t, shndx_data);
> > >  
> > > +		if (!symtab_data) {
> > > +			if (!idx) {
> > > +				void *buf;
> > 
> > I'm confused by whatever this is doing, how is !symtab_data possible,
> > i.e. why would symtab not have data?
> 
> Elf_Data *elf_getdata(Elf_Scn *scn, Elf_Data *data);
> 
> is an iterator, if @data is null it will return the first element, which
> you then feed into @data the next time to get the next element, once it
> returns NULL, you've found the end.
> 
> In our specific case, we iterate the data sections, if idx fits inside
> the current section, we good, otherwise we lower idx by however many did
> fit and try the next.

Ok, I think I see.  But why are there multiple data blocks to begin
with?  It's because of a previous call to elf_newdata() right?

If so then I don't see how it would "fit" in an existing data block,
since each block should already be full.  Or... is the hole the one you
just made, by moving the old symbol out?

If so, the function seems weirdly generalized for the two distinct cases
and the loop seems unnecessary.  When adding a symbol at the end, just
use elf_newdata().  When adding a symbol in the middle, the hole should
be in the first data block.

-- 
Josh