linux-kernel - Re: c6x linker issue on linux-next-20160808 + some linker table work

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:	Tue, 9 Aug 2016 20:40:23 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Mark Salter <msalter@...hat.com>
Cc:	Guenter Roeck <linux@...ck-us.net>,
	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	Aurelien Jacquiot <a-jacquiot@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Josh Poimboeuf <jpoimboe@...hat.com>
Subject: Re: c6x linker issue on linux-next-20160808 + some linker table work

On Tue, Aug 09, 2016 at 01:04:00PM -0400, Mark Salter wrote:
> On Tue, 2016-08-09 at 06:37 -0700, Guenter Roeck wrote:
> > On 08/09/2016 01:11 AM, Luis R. Rodriguez wrote:
> > > 
> > > Mark, Aurelien,
> > > 
> > > I've run into a linker (ld) issue caused by the linker table work I've
> > > been working on [0]. I looked into this and for the life of me, I
> > > cannot comprehend what the problem is, so was hoping you folks might
> > > be able to chime in.
> > > 
> > For reference, the error is
> > 
> > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> > c6x-elf-ld: drivers/built-in.o: SB-relative relocation but __c6xabi_DSBT_BASE not defined
> 
> DSBT is a reference to the no-MMU userspace ABI used by c6x. The kernel shouldn't
> be referencing DSBT base. The -mno-dsbt gcc flag should prevent it.

I see -mno-dsbt on arch/c6x/Makefile already -- however at link time this is
an issue if linker tables are used it seems. Do you have any other recommendation?

I will note that it would seem that even i386 and x86-64 compiler/binutils seem
to have relocation issues on older compiler/binutils, for instance:

gcc-4.7.2
binutils-2.22 

Yields:

x86_64:allyesconfig || x86_64:allmodconfig
Invalid absolute R_X86_64_64 relocation: __per_cpu_load 

i386:defconfig
Invalid absolute R_386_32 relocation: __vvar_page

This issue on x86 is not observed as so far as of gcc 5.2.1
and binutils-2.26.1.

hpa -- if you can think of a work around for this for older compilers/linkers
let me know... unless we are OK to increase the requirements for x86.

  Luis