[haiku-commits] Re: BRANCH pdziepak-github.aslr - src/system/kernel/vm src/system/runtime_loader headers/private/kernel/arch/x86
- From: Pawel Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 9 Apr 2013 16:37:13 +0200
2013/4/9 Alex Smith <alex@xxxxxxxxxxxxxxxx>:
> On 8 April 2013 23:00, pdziepak-github.aslr <community@xxxxxxxxxxxx> wrote:
>>
>> 65ed4fa: vm: implement B_RANDOMIZED_IMAGE_ADDRESS address specification
>>
>> On some 64 bit architectures program and library images have to be
>> mapped in
>> the lower 2 GB of the address space (due to instruction pointer relative
>> addressing). Address specification B_RANDOMIZED_IMAGE_ADDRESS ensures
>> that
>> created area satisfies that requirement.
>
>
> As far as I'm aware, this isn't necessary. All of our program and library
> images are compiled as PIC which doesn't need to be kept in the lower 2GB.
> For RIP-relative addressing there is a maximum offset of +/- 2GB as the
> offset is 32-bit, however this should only apply to code within the same
> image. Cross-image calls/variable accesses go through the PLT/GOT which uses
> 64-bit absolute addresses.
>
> There is a requirement to be in the bottom/top 2GB of the address space for
> non-PIC code, but the only things that aren't PIC are the runtime_loader and
> the kernel, both of which have a fixed load address.
Looks like I misunderstood what GCC documentation has to say about
code model in x86_64, should have use better source (i.e. System V ABI
for AMD64). Indeed, B_RANDOMIZED_IMAGE_ADDRESS is not necessary.
Thanks for pointing that out.
I wonder why are we making program images position independent, since
PIC code is almost always slower than non-PIC code. Obviously, on x86
it has to be that way because of ABI compatibility, this is not the
case on x86_64, though. The only obvious (for me) advantage of program
being PIC is the ability to randomize its location but I doubt that it
is worth the performance loss. Is it because machine independent parts
of Haiku code assume too much thus making such change for one
architecture too difficult?
Paweł
Other related posts:
