Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Mon, Apr 8, 2019 at 10:56 AM Christopher Lameter wrote: > > On Mon, 8 Apr 2019, Thomas Garnier wrote: > > > > It didn't work originally but I will revisit to see if I missed something. > > > > I revisited and couldn't find a way to prevent relocations to the > > percpu section. Without PIE, you can reference absolute address which > > was convenient for percpu. > > Can you switch PIE off for the percpu section? If not maybe the linker > needs to have an additional option? I don't think so or I didn't find any option to do that. Changing the linker might be a bit too much if we have a software solution which doesn't impact performance. > > Cannot imagine that this is not possible. You neeed to be able to > reference registers that are in fixed memory locations. > > > > Christopher: Did you have something specific in mind? > > I thought that we just leave it as is. I would like to as well. I will try couple things at the assembly level instead of the linker and come back to this thread. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Mon, 8 Apr 2019, Thomas Garnier wrote: > > It didn't work originally but I will revisit to see if I missed something. > > I revisited and couldn't find a way to prevent relocations to the > percpu section. Without PIE, you can reference absolute address which > was convenient for percpu. Can you switch PIE off for the percpu section? If not maybe the linker needs to have an additional option? Cannot imagine that this is not possible. You neeed to be able to reference registers that are in fixed memory locations. > Christopher: Did you have something specific in mind? I thought that we just leave it as is. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Fri, Feb 1, 2019 at 9:13 AM Thomas Garnier wrote: > > On Thu, Jan 31, 2019 at 6:31 PM Christopher Lameter wrote: > > > > On Thu, 31 Jan 2019, Thomas Garnier wrote: > > > > > The per-cpu symbols are in a section that is zero based to create > > > offsets. The compiler doesn't see them as offsets but as relative > > > symbol and try to relocate them. Given the distance between zero and > > > the mapped kernel is much larger than the instruction offset range, it > > > fails to do it. > > > > We switch that off in the linker. If that does not work with your > > modifications then you need to figure out how to update the link > > configuration. > > > > It didn't work originally but I will revisit to see if I missed something. I revisited and couldn't find a way to prevent relocations to the percpu section. Without PIE, you can reference absolute address which was convenient for percpu. Christopher: Did you have something specific in mind? I checked the following: - Changing the FLAGS() on the PHDRS. - using -z noreloc-overflow which actually doesn't seem to apply to PC32 relocations. - Look at all linker options and script format for anything around that. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Thu, Jan 31, 2019 at 6:31 PM Christopher Lameter wrote: > > On Thu, 31 Jan 2019, Thomas Garnier wrote: > > > The per-cpu symbols are in a section that is zero based to create > > offsets. The compiler doesn't see them as offsets but as relative > > symbol and try to relocate them. Given the distance between zero and > > the mapped kernel is much larger than the instruction offset range, it > > fails to do it. > > We switch that off in the linker. If that does not work with your > modifications then you need to figure out how to update the link > configuration. > It didn't work originally but I will revisit to see if I missed something. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Thu, 31 Jan 2019, Thomas Garnier wrote: > The per-cpu symbols are in a section that is zero based to create > offsets. The compiler doesn't see them as offsets but as relative > symbol and try to relocate them. Given the distance between zero and > the mapped kernel is much larger than the instruction offset range, it > fails to do it. We switch that off in the linker. If that does not work with your modifications then you need to figure out how to update the link configuration. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Thu, Jan 31, 2019 at 12:57 PM Christopher Lameter wrote: > > On Thu, 31 Jan 2019, Thomas Garnier wrote: > > > Perpcu uses a clever design where the .percu ELF section has a virtual > > address of zero and the custom linux relocation code avoid relocating > > specific symbols. It makes the code simple and easily adaptable with or > > without SMP support. > > We usually talk about this as offsets rather than addressess. The intend > here is to give every processor its own address that is unique for this > processor. Operations are always relative to a segment register and the > whole area can be relocated at will by simply changing the segment > register. > > > This design is incompatible with PIE. While creating a PIE binary, the > > copmiler tries to make everything relative. The compiler will attempt to > > This is very compatible with PIE because it is already relative. The per-cpu symbols are in a section that is zero based to create offsets. The compiler doesn't see them as offsets but as relative symbol and try to relocate them. Given the distance between zero and the mapped kernel is much larger than the instruction offset range, it fails to do it. > > > generate instructions with the distance between zero and any 64-bit > > virtual address. It will fail as the relocation range cannot fit within > > the possible instructions accessing a segment register. > > Leave the offsets alone and just change the segment register if you need > to relocate the area of a specific processor? > > > The assembly and PER_CPU macros are changed to use relative references > > when PIE is enabled. > > They already use relative reference. What is the point here? > > > --- a/arch/x86/include/asm/percpu.h > > +++ b/arch/x86/include/asm/percpu.h > > @@ -5,9 +5,11 @@ > > #ifdef CONFIG_X86_64 > > #define __percpu_seg gs > > #define __percpu_mov_op movq > > +#define __percpu_rel (%rip) > > The percpu section cannot be IP relative since we need to have separate > address spaces per cpu. > ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
Re: [Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
On Thu, 31 Jan 2019, Thomas Garnier wrote: > Perpcu uses a clever design where the .percu ELF section has a virtual > address of zero and the custom linux relocation code avoid relocating > specific symbols. It makes the code simple and easily adaptable with or > without SMP support. We usually talk about this as offsets rather than addressess. The intend here is to give every processor its own address that is unique for this processor. Operations are always relative to a segment register and the whole area can be relocated at will by simply changing the segment register. > This design is incompatible with PIE. While creating a PIE binary, the > copmiler tries to make everything relative. The compiler will attempt to This is very compatible with PIE because it is already relative. > generate instructions with the distance between zero and any 64-bit > virtual address. It will fail as the relocation range cannot fit within > the possible instructions accessing a segment register. Leave the offsets alone and just change the segment register if you need to relocate the area of a specific processor? > The assembly and PER_CPU macros are changed to use relative references > when PIE is enabled. They already use relative reference. What is the point here? > --- a/arch/x86/include/asm/percpu.h > +++ b/arch/x86/include/asm/percpu.h > @@ -5,9 +5,11 @@ > #ifdef CONFIG_X86_64 > #define __percpu_seg gs > #define __percpu_mov_op movq > +#define __percpu_rel (%rip) The percpu section cannot be IP relative since we need to have separate address spaces per cpu. ___ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
[Xen-devel] [PATCH v6 14/27] x86/percpu: Adapt percpu for PIE support
Perpcu uses a clever design where the .percu ELF section has a virtual
address of zero and the custom linux relocation code avoid relocating
specific symbols. It makes the code simple and easily adaptable with or
without SMP support.
This design is incompatible with PIE. While creating a PIE binary, the
copmiler tries to make everything relative. The compiler will attempt to
generate instructions with the distance between zero and any 64-bit
virtual address. It will fail as the relocation range cannot fit within
the possible instructions accessing a segment register.
This patch solves tihs problem by removing the zero mapping. The .percpu
symbols are now close to the base of the kernel and the compiler
generates appropriate relocations. To accomodate this change, the GS base
is adapted to be the difference between zero and the .percpu section
address. These changes are done only when PIE is enabled. The original
implementation is kept as-is by default.
The assembly and PER_CPU macros are changed to use relative references
when PIE is enabled.
The KALLSYMS_ABSOLUTE_PERCPU configuration is disabled with PIE given
percpu symbols are not absolute in this case.
Position Independent Executable (PIE) support will allow to extend the
KASLR randomization range below 0x8000.
Signed-off-by: Thomas Garnier
---
arch/x86/entry/calling.h | 2 +-
arch/x86/entry/entry_64.S| 4 ++--
arch/x86/include/asm/percpu.h| 25 +++--
arch/x86/include/asm/processor.h | 4 +++-
arch/x86/kernel/head_64.S| 4
arch/x86/kernel/setup_percpu.c | 5 -
arch/x86/kernel/vmlinux.lds.S| 13 +++--
arch/x86/lib/cmpxchg16b_emu.S| 8
arch/x86/xen/xen-asm.S | 12 ++--
init/Kconfig | 2 +-
10 files changed, 55 insertions(+), 24 deletions(-)
diff --git a/arch/x86/entry/calling.h b/arch/x86/entry/calling.h
index efb0d1b1f15f..d5a6d3a0c24b 100644
--- a/arch/x86/entry/calling.h
+++ b/arch/x86/entry/calling.h
@@ -218,7 +218,7 @@ For 32-bit we have the following conventions - kernel is
built with
.endm
#define THIS_CPU_user_pcid_flush_mask \
- PER_CPU_VAR(cpu_tlbstate) + TLB_STATE_user_pcid_flush_mask
+ PER_CPU_VAR(cpu_tlbstate + TLB_STATE_user_pcid_flush_mask)
.macro SWITCH_TO_USER_CR3_NOSTACK scratch_reg:req scratch_reg2:req
ALTERNATIVE "jmp .Lend_\@", "", X86_FEATURE_PTI
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 16a93eb4c11f..fc15fe058d3c 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -298,7 +298,7 @@ ENTRY(__switch_to_asm)
#ifdef CONFIG_STACKPROTECTOR
movqTASK_stack_canary(%rsi), %rbx
- movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
+ movq%rbx, PER_CPU_VAR(irq_stack_union + stack_canary_offset)
#endif
#ifdef CONFIG_RETPOLINE
@@ -841,7 +841,7 @@ apicinterrupt IRQ_WORK_VECTOR
irq_work_interrupt smp_irq_work_interrupt
/*
* Exception entry points.
*/
-#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw) + (TSS_ist + ((x) - 1) * 8)
+#define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss_rw + (TSS_ist + ((x) - 1) * 8))
/**
* idtentry - Generate an IDT entry stub
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/include/asm/percpu.h
index 1a19d11cfbbd..608c15751f29 100644
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@ -5,9 +5,11 @@
#ifdef CONFIG_X86_64
#define __percpu_seg gs
#define __percpu_mov_opmovq
+#define __percpu_rel (%rip)
#else
#define __percpu_seg fs
#define __percpu_mov_opmovl
+#define __percpu_rel
#endif
#ifdef __ASSEMBLY__
@@ -28,10 +30,14 @@
#define PER_CPU(var, reg) \
__percpu_mov_op %__percpu_seg:this_cpu_off, reg;\
lea var(reg), reg
-#define PER_CPU_VAR(var) %__percpu_seg:var
+/* Compatible with Position Independent Code */
+#define PER_CPU_VAR(var) %__percpu_seg:(var)##__percpu_rel
+/* Rare absolute reference */
+#define PER_CPU_VAR_ABS(var) %__percpu_seg:var
#else /* ! SMP */
#define PER_CPU(var, reg) __percpu_mov_op $var, reg
-#define PER_CPU_VAR(var) var
+#define PER_CPU_VAR(var) (var)##__percpu_rel
+#define PER_CPU_VAR_ABS(var) var
#endif /* SMP */
#ifdef CONFIG_X86_64_SMP
@@ -209,27 +215,34 @@ do {
\
pfo_ret__; \
})
+/* Position Independent code uses relative addresses only */
+#ifdef CONFIG_X86_PIE
+#define __percpu_stable_arg __percpu_arg(a1)
+#else
+#define __percpu_stable_arg __percpu_arg(P1)
+#endif
+
#define percpu_stable_op(op, var) \
({ \
typeof(var) pfo_ret__; \
