[PATCH] x86: Don't build vDSO with $(RETPOLINE_CFLAGS) -DRETPOLINE

[PATCH] x86: Don't build vDSO with $(RETPOLINE_CFLAGS) -DRETPOLINE

[H.J. Lu]

[-- Attachment #1: Type: text/plain, Size: 120 bytes --]

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

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>


-- 
H.J.

[-- Attachment #2: 0001-x86-Don-t-build-vDSO-with-RETPOLINE_CFLAGS-DRETPOLIN.patch --]
[-- Type: text/x-patch, Size: 1680 bytes --]

From 711926409e42862de08633ec057892195fdce4e0 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 16 Mar 2018 14:58:29 -0700
Subject: [PATCH] x86: Don't build vDSO with $(RETPOLINE_CFLAGS) -DRETPOLINE

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

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
---
 arch/x86/entry/vdso/Makefile | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 1b8e041d4979..eebcc3bedbf0 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -76,7 +76,7 @@ CFL := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64 \
        -fno-omit-frame-pointer -foptimize-sibling-calls \
        -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
 
-$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
+$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) $(RETPOLINE_CFLAGS) -DRETPOLINE,$(KBUILD_CFLAGS)) $(CFL)
 
 #
 # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
@@ -177,6 +177,7 @@ KBUILD_CFLAGS_32 := $(filter-out -mcmodel=kernel,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS) -DRETPOLINE,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
 KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
-- 
2.14.3

Re: [PATCH] x86: Don't build vDSO with $(RETPOLINE_CFLAGS) -DRETPOLINE

[David Woodhouse]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

On Mon, 2018-03-19 at 14:11 -0700, H.J. Lu wrote:
> vDSO code runs in userspace.  Don't compile it with retpoline.
> 
> Signed-off-by: H.J. Lu <hjl.tools@gmail.com>

There are cases where we might actually want userspace to be using
retpoline though. We still only do IBPB for *some* processes, and
haven't really even finished the argument about the heuristics we use
for that.

If this is only for the switch in __vdso_clock_gettime() then maybe we
turn that into a series of if/else instead of a switch. Or just write
it in asm.

Or better still, teach GCC that when it's using retpoline, a jump table
is *NOT* faster than a series of that many conditional branches. The
costs are higher, and I don't think we taught GCC that yet, did we?

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

Re: [PATCH] x86: Don't build vDSO with $(RETPOLINE_CFLAGS) -DRETPOLINE

[Thomas Gleixner]

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