linux-kernel - Re: [PATCH] x86: Don't build vDSO with $(RETPOLINE

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1803200912580.6506@nanos.tec.linutronix.de>
Date:   Tue, 20 Mar 2018 09:32:35 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "H.J. Lu" <hjl.tools@...il.com>
cc:     LKML <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [PATCH] x86: Don't build vDSO with $(RETPOLINE_CFLAGS)
 -DRETPOLINE

H.J.

On Mon, 19 Mar 2018, H.J. Lu wrote:

Could you please send patches inline so reply has the patch in it for
review comments?

> vDSO code runs in userspace.  Don't compile it with retpoline.

I think this is a dangerous generalization. Just because code runs in user
space does not mean that it does not have to be compiled with retpoline.

You very much need retpolines in user space to prevent certain types of
inter process attacks. And disabling it in the VDSO gives a nice
predictable vector once the compiler decides to use a indirect jump table
for the clockid switch case.

So we rather keep retpoline enabled and let the build fail so we can
inspect why the compiler decided to convert something to indirect branches
and either annotate the function if it's not dangerous or modify the code
in a way that indirect branches are avoided.

The VDSO clock_gettime() implementation is one of the hottest code pathes
so we really have to think about it. Adding retpolines is going to hurt,
but just blindly dismissing them is wrong.

Thanks,

	tglx