[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.