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:   Wed, 31 Jan 2018 08:35:30 -0800
From:   Andy Lutomirski <luto@...capital.net>
To:     Borislav Petkov <bp@...en8.de>
Cc:     X86 ML <x86@...nel.org>, Jiri Kosina <jkosina@...e.cz>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] x86/vdso: Remove retpoline flags

On Wed, Jan 31, 2018 at 8:33 AM, Borislav Petkov <bp@...en8.de> wrote:
> From: Borislav Petkov <bp@...e.de>
>
> So this does not fix an existing problem but a hypothetical one. The
> below fires on an old Frankenstein distro kernel and I'm sending it
> only because it is obviously The Right Thing(tm). And in case we change
> things in the vdso in the future and thus manage to generate an indirect
> call for whatever reason...
>
> So on those older vdsos, the compiler can generate indirect calls to the
> retpoline thunks, which manifests itself as:
>
>   /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: arch/x86/vdso/vclock_gettime.o: \
>           relocation R_X86_64_PC32 against undefined symbol `__x86_indirect_thunk_rax' can not be used when \
>           making a shared object; recompile with -fPIC
>   /usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: final link failed: Bad value
>   collect2: error: ld returned 1 exit status
>   nm: 'arch/x86/vdso/vdso.so.dbg': No such file
>   objcopy: 'arch/x86/vdso/vdso.so.dbg': No such file
>   make[2]: *** [arch/x86/vdso/vdso.so] Error 1
>   make[1]: *** [arch/x86/vdso] Error 2
>   make[1]: *** Waiting for unfinished jobs....
>
> However, since the vdso is not part of the kernel, it cannot reference
> kernel symbols so we better not build with with retpoline CFLAGS either.
>
> Thus, export RETPOLINE_CFLAGS to the lower level Makefiles so that they
> can be filtered out in vdso's Makefile.

Hmm.  I'm okay with this, but I'd also be okay doing nothing and
figuring out WTF happened if an upstream kernel fails to build like
this.

--Andy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ