Re: x86: PIE support and option to extend KASLR randomization

On 16 August 2017 at 17:26, Daniel Micay [off-list ref] wrote:

quoted

How are these assumptions hardcoded by GCC? Most of the instructions
should be
relocatable straight away, as most call/jump/branch instructions are
RIP-relative.

I.e. is there no GCC code generation mode where code can be placed
anywhere in the
canonical address space, yet call and jump distance is within 31 bits
so that the
generated code is fast?

That's what PIE is meant to do. However, not disabling support for lazy
linking (-fno-plt) / symbol interposition (-Bsymbolic) is going to cause
it to add needless overhead.

arm64 is using -pie -shared -Bsymbolic in arch/arm64/Makefile for their
CONFIG_RELOCATABLE option. See 08cc55b2afd97a654f71b3bebf8bb0ec89fdc498.

The difference with arm64 is that its generic small code model is
already position independent, so we don't have to pass -fpic or -fpie
to the compiler. We only link in PIE mode to get the linker to emit
the dynamic relocation tables into the ELF binary. Relative branches
have a range of +/- 128 MB, which covers the kernel and modules
(unless the option to randomize the module region independently has
been selected, in which case branches between the kernel and modules
may be resolved via PLT entries that are emitted at module load time)

I am not sure how this extrapolates to x86, just adding some context.