[PATCH] binfmt_elf: fix PIE load with randomization disabled

[PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

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

Normally, a PIE executable has zero virtual address on the first PT_LOAD
segment and kernel will load such executable at random address when
randomization is enabled.  If randomization is disabled, kernel will load
it at a fixed address.  But if a PIE executable has non-zero virtual
address on the first PT_LOAD segment, kernel will load such executable
at the non-zero virtual address when randomization is enabled. But when
randomization is disabled, kernel ignores the non-zero virtual address
at the non-zero virtual address when randomization is enabled. But when
randomization is disabled, kernel ignores the non-zero virtual address
on the first PT_LOAD segment and loads it at the fixed address.  This
patch makes kernel consistent by loading PIE executable with non-zero
virtual address at the non-zero virtual address, regardless if
randomization is enabled or disabled.


-- 
H.J

[-- Attachment #2: 0001-binfmt_elf-fix-PIE-load-with-randomization-disabled.patch --]
[-- Type: text/plain, Size: 1844 bytes --]

From eee1f1f4f60eb1f1139ac311e787fac50accde30 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Fri, 6 Dec 2013 12:44:41 -0800
Subject: [PATCH] binfmt_elf: fix PIE load with randomization disabled

Normally, a PIE executable has zero virtual address on the first PT_LOAD
segment and kernel will load such executable at random address when
randomization is enabled.  If randomization is disabled, kernel will load
it at a fixed address.  But if a PIE executable has non-zero virtual
address on the first PT_LOAD segment, kernel will load such executable
at the non-zero virtual address when randomization is enabled. But when
randomization is disabled, kernel ignores the non-zero virtual address
on the first PT_LOAD segment and loads it at the fixed address.  This
patch makes kernel consistent by loading PIE executable with non-zero
virtual address at the non-zero virtual address, regardless if
randomization is enabled or disabled.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
---
 fs/binfmt_elf.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4c94a79..a3fd4de 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -809,8 +809,13 @@ static int load_elf_binary(struct linux_binprm *bprm)
 			 * If that is the case, retain the original non-zero
 			 * load_bias value in order to establish proper
 			 * non-randomized mappings.
+			 * If the first PT_LOAD segment has non-zero p_vaddr,
+			 * use the zero load_bias so that a PIE binary will be
+			 * loaded at the specific address even if memory
+			 * randomization is off.
 			 */
-			if (current->flags & PF_RANDOMIZE)
+			if ((current->flags & PF_RANDOMIZE) ||
+			    (!load_addr_set && vaddr))
 				load_bias = 0;
 			else
 				load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr);
-- 
1.8.3.1

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[Jiri Kosina]

On Mon, 9 Dec 2013, H.J. Lu wrote:

> Normally, a PIE executable has zero virtual address on the first PT_LOAD
> segment and kernel will load such executable at random address when
> randomization is enabled.  If randomization is disabled, kernel will load
> it at a fixed address.  But if a PIE executable has non-zero virtual
> address on the first PT_LOAD segment, kernel will load such executable
> at the non-zero virtual address when randomization is enabled. But when
> randomization is disabled, kernel ignores the non-zero virtual address
> at the non-zero virtual address when randomization is enabled. 

Hmm ... isn't actually this the thing that needs to be fixed instead? 

IOW, when randomization is enabled, is there a reason not to load on 
randomized address? (even if the first PT_LOAD segment has non-zero 
vaddr?)

> But when randomization is disabled, kernel ignores the non-zero virtual 
> address on the first PT_LOAD segment and loads it at the fixed address.  
> This patch makes kernel consistent by loading PIE executable with 
> non-zero virtual address at the non-zero virtual address, regardless if 
> randomization is enabled or disabled.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 12:57 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 9 Dec 2013, H.J. Lu wrote:
>
>> Normally, a PIE executable has zero virtual address on the first PT_LOAD
>> segment and kernel will load such executable at random address when
>> randomization is enabled.  If randomization is disabled, kernel will load
>> it at a fixed address.  But if a PIE executable has non-zero virtual
>> address on the first PT_LOAD segment, kernel will load such executable
>> at the non-zero virtual address when randomization is enabled. But when
>> randomization is disabled, kernel ignores the non-zero virtual address
>> at the non-zero virtual address when randomization is enabled.
>
> Hmm ... isn't actually this the thing that needs to be fixed instead?
>
> IOW, when randomization is enabled, is there a reason not to load on
> randomized address? (even if the first PT_LOAD segment has non-zero
> vaddr?)

No, please don't do that.  Normally, PIE has zero load address and kernel
can load it anywhere.  There are multiple reasons why PIE has non-zero
load address.  Saying you need to load a program above 4GB under x86-64,
you can't do that with normal dynamic executable.  PIE with non-zero load
address is the only way to do that on x86-64.

>> But when randomization is disabled, kernel ignores the non-zero virtual
>> address on the first PT_LOAD segment and loads it at the fixed address.
>> This patch makes kernel consistent by loading PIE executable with
>> non-zero virtual address at the non-zero virtual address, regardless if
>> randomization is enabled or disabled.
>


-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[Jiri Kosina]

On Mon, 9 Dec 2013, H.J. Lu wrote:

> >> Normally, a PIE executable has zero virtual address on the first PT_LOAD
> >> segment and kernel will load such executable at random address when
> >> randomization is enabled.  If randomization is disabled, kernel will load
> >> it at a fixed address.  But if a PIE executable has non-zero virtual
> >> address on the first PT_LOAD segment, kernel will load such executable
> >> at the non-zero virtual address when randomization is enabled. But when
> >> randomization is disabled, kernel ignores the non-zero virtual address
> >> at the non-zero virtual address when randomization is enabled.
> >
> > Hmm ... isn't actually this the thing that needs to be fixed instead?
> >
> > IOW, when randomization is enabled, is there a reason not to load on
> > randomized address? (even if the first PT_LOAD segment has non-zero
> > vaddr?)
> 
> No, please don't do that.  Normally, PIE has zero load address and kernel
> can load it anywhere.  There are multiple reasons why PIE has non-zero
> load address.  Saying you need to load a program above 4GB under x86-64,
> you can't do that with normal dynamic executable.  PIE with non-zero load
> address is the only way to do that on x86-64.

Hmm, so if it's because of 4G PT_LOAD limit, how about at least adding 
randomized offset to the supplied vaddr?

PT_LOAD being non-zero causing randomization to be turned off seems like 
quite unexpected behavior to me, with a great potential to cause a lot of 
confusion.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 1:13 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 9 Dec 2013, H.J. Lu wrote:
>
>> >> Normally, a PIE executable has zero virtual address on the first PT_LOAD
>> >> segment and kernel will load such executable at random address when
>> >> randomization is enabled.  If randomization is disabled, kernel will load
>> >> it at a fixed address.  But if a PIE executable has non-zero virtual
>> >> address on the first PT_LOAD segment, kernel will load such executable
>> >> at the non-zero virtual address when randomization is enabled. But when
>> >> randomization is disabled, kernel ignores the non-zero virtual address
>> >> at the non-zero virtual address when randomization is enabled.
>> >
>> > Hmm ... isn't actually this the thing that needs to be fixed instead?
>> >
>> > IOW, when randomization is enabled, is there a reason not to load on
>> > randomized address? (even if the first PT_LOAD segment has non-zero
>> > vaddr?)
>>
>> No, please don't do that.  Normally, PIE has zero load address and kernel
>> can load it anywhere.  There are multiple reasons why PIE has non-zero
>> load address.  Saying you need to load a program above 4GB under x86-64,
>> you can't do that with normal dynamic executable.  PIE with non-zero load
>> address is the only way to do that on x86-64.
>
> Hmm, so if it's because of 4G PT_LOAD limit, how about at least adding

Yes.

> randomized offset to the supplied vaddr?

Yes, people who build PIE with non-zero vaddr can use
 randomized vaddr. But kernel must follow the non-zero vaddr.

> PT_LOAD being non-zero causing randomization to be turned off seems like
> quite unexpected behavior to me, with a great potential to cause a lot of
> confusion.
>

There should be no difference between dynamic executable and PIE
with non-zero vaddr when choosing where to load them.

-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

> 
>> PT_LOAD being non-zero causing randomization to be turned off seems like
>> quite unexpected behavior to me, with a great potential to cause a lot of
>> confusion.
> 
> There should be no difference between dynamic executable and PIE
> with non-zero vaddr when choosing where to load them.
> 

Why is that?  It would seem to be a big difference between a relocatable
binary (PIE) and one with a load address fixed at link time.

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 1:49 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>
>>> PT_LOAD being non-zero causing randomization to be turned off seems like
>>> quite unexpected behavior to me, with a great potential to cause a lot of
>>> confusion.
>>
>> There should be no difference between dynamic executable and PIE
>> with non-zero vaddr when choosing where to load them.
>>
>
> Why is that?  It would seem to be a big difference between a relocatable
> binary (PIE) and one with a load address fixed at link time.
>

PIE with non-zero vaddr should be loaded at non-zero
vaddr.  Otherwise, PIE may not work as expected.


-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

On 12/09/2013 01:52 PM, H.J. Lu wrote:
>>
>> Why is that?  It would seem to be a big difference between a relocatable
>> binary (PIE) and one with a load address fixed at link time.
>>
> 
> PIE with non-zero vaddr should be loaded at non-zero
> vaddr.  Otherwise, PIE may not work as expected.
> 

Please explain why that is the case, as it seems to be implying that PIE
isn't actually relocatable in that case...

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 1:53 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/09/2013 01:52 PM, H.J. Lu wrote:
>>>
>>> Why is that?  It would seem to be a big difference between a relocatable
>>> binary (PIE) and one with a load address fixed at link time.
>>>
>>
>> PIE with non-zero vaddr should be loaded at non-zero
>> vaddr.  Otherwise, PIE may not work as expected.
>>
>
> Please explain why that is the case, as it seems to be implying that PIE
> isn't actually relocatable in that case...
>

A Linux/x86-64 user came to me at the end of 2008.  He needed
to load an executable above 4GB.  I added -Ttext-segment option
to linker:

https://sourceware.org/ml/binutils/2009-01/msg00173.html

so that he could load his program compiled as PIE above 4GB.
If kernel is changed not to honor it, his program won't work any more.
In normal case, PIE has zero vaddr and this doesn't apply.

-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

On 12/09/2013 01:59 PM, H.J. Lu wrote:
> 
> A Linux/x86-64 user came to me at the end of 2008.  He needed
> to load an executable above 4GB.  I added -Ttext-segment option
> to linker:
> 
> https://sourceware.org/ml/binutils/2009-01/msg00173.html
> 
> so that he could load his program compiled as PIE above 4GB.
> If kernel is changed not to honor it, his program won't work any more.
> In normal case, PIE has zero vaddr and this doesn't apply.
> 

That doesn't seem to be PIE at all, and if it is PIE, then it should be
relocatable (I agree btw with randomizing upward from the selected address.)

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 2:01 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/09/2013 01:59 PM, H.J. Lu wrote:
>>
>> A Linux/x86-64 user came to me at the end of 2008.  He needed
>> to load an executable above 4GB.  I added -Ttext-segment option
>> to linker:
>>
>> https://sourceware.org/ml/binutils/2009-01/msg00173.html
>>
>> so that he could load his program compiled as PIE above 4GB.
>> If kernel is changed not to honor it, his program won't work any more.
>> In normal case, PIE has zero vaddr and this doesn't apply.
>>
>
> That doesn't seem to be PIE at all, and if it is PIE, then it should be
> relocatable (I agree btw with randomizing upward from the selected address.)
>

Kernel can consider PIE with non-zero vaddr isn't real PIE.

-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[Jiri Kosina]

On Mon, 9 Dec 2013, H.J. Lu wrote:

> >> so that he could load his program compiled as PIE above 4GB.
> >> If kernel is changed not to honor it, his program won't work any more.
> >> In normal case, PIE has zero vaddr and this doesn't apply.
> >>
> >
> > That doesn't seem to be PIE at all, and if it is PIE, then it should be
> > relocatable (I agree btw with randomizing upward from the selected address.)
> 
> Kernel can consider PIE with non-zero vaddr isn't real PIE.

Why?

I still think PIE with non-zero vaddr should be randomized by putting 
random offset to the vaddr. Don't you think so? Why?

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Wed, Dec 11, 2013 at 5:36 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 9 Dec 2013, H.J. Lu wrote:
>
>> >> so that he could load his program compiled as PIE above 4GB.
>> >> If kernel is changed not to honor it, his program won't work any more.
>> >> In normal case, PIE has zero vaddr and this doesn't apply.
>> >>
>> >
>> > That doesn't seem to be PIE at all, and if it is PIE, then it should be
>> > relocatable (I agree btw with randomizing upward from the selected address.)
>>
>> Kernel can consider PIE with non-zero vaddr isn't real PIE.
>
> Why?
>
> I still think PIE with non-zero vaddr should be randomized by putting
> random offset to the vaddr. Don't you think so? Why?
>

When -Ttext-segment=XXX is used, the program is expected to
load at XXX, regardless -pie is used or not.  I will change the
linker to set type to ET_EXEC in this case so that it will be
independent of kernel.


-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

On 12/11/2013 05:41 AM, H.J. Lu wrote:
> 
> When -Ttext-segment=XXX is used, the program is expected to
> load at XXX, regardless -pie is used or not.
> 

"Expected to" by whom?  I think that is at the very best a matter of
interpretation.

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Wed, Dec 11, 2013 at 9:49 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/11/2013 05:41 AM, H.J. Lu wrote:
>>
>> When -Ttext-segment=XXX is used, the program is expected to
>> load at XXX, regardless -pie is used or not.
>>
>
> "Expected to" by whom?  I think that is at the very best a matter of
> interpretation.
>

# ld --help
...
 -Ttext-segment ADDRESS      Set address of text segment
...


-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

On 12/11/2013 10:21 AM, H.J. Lu wrote:
> On Wed, Dec 11, 2013 at 9:49 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 12/11/2013 05:41 AM, H.J. Lu wrote:
>>>
>>> When -Ttext-segment=XXX is used, the program is expected to
>>> load at XXX, regardless -pie is used or not.
>>>
>>
>> "Expected to" by whom?  I think that is at the very best a matter of
>> interpretation.
> 
> # ld --help
> ...
>  -Ttext-segment ADDRESS      Set address of text segment
> ...
> 

I feel a very circular argument going around here... what do the actual
user(s) of this option expect?

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Wed, Dec 11, 2013 at 11:43 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/11/2013 10:21 AM, H.J. Lu wrote:
>> On Wed, Dec 11, 2013 at 9:49 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 12/11/2013 05:41 AM, H.J. Lu wrote:
>>>>
>>>> When -Ttext-segment=XXX is used, the program is expected to
>>>> load at XXX, regardless -pie is used or not.
>>>>
>>>
>>> "Expected to" by whom?  I think that is at the very best a matter of
>>> interpretation.
>>
>> # ld --help
>> ...
>>  -Ttext-segment ADDRESS      Set address of text segment
>> ...
>>
>
> I feel a very circular argument going around here... what do the actual
> user(s) of this option expect?

User expects the executable will be loaded at the address
specified by -Ttext-segment.

-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[Jiri Kosina]

On Mon, 9 Dec 2013, H.J. Lu wrote:

> >> No, please don't do that.  Normally, PIE has zero load address and kernel
> >> can load it anywhere.  There are multiple reasons why PIE has non-zero
> >> load address.  Saying you need to load a program above 4GB under x86-64,
> >> you can't do that with normal dynamic executable.  PIE with non-zero load
> >> address is the only way to do that on x86-64.
> >
> > Hmm, so if it's because of 4G PT_LOAD limit, how about at least adding
> 
> Yes.
> 
> > randomized offset to the supplied vaddr?
> 
> Yes, people who build PIE with non-zero vaddr can use
>  randomized vaddr. 

I don't follow you here. Do you suggest compile-time randomzation?

> > PT_LOAD being non-zero causing randomization to be turned off seems like
> > quite unexpected behavior to me, with a great potential to cause a lot of
> > confusion.
> >
> 
> There should be no difference between dynamic executable and PIE
> with non-zero vaddr when choosing where to load them.

Could you please elaborate why do you think this statement is true?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

On 12/09/2013 01:03 PM, H.J. Lu wrote:
> 
> No, please don't do that.  Normally, PIE has zero load address and kernel
> can load it anywhere.  There are multiple reasons why PIE has non-zero
> load address.  Saying you need to load a program above 4GB under x86-64,
> you can't do that with normal dynamic executable.  PIE with non-zero load
> address is the only way to do that on x86-64.
> 

Why does it have to be PIE?

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 1:39 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/09/2013 01:03 PM, H.J. Lu wrote:
>>
>> No, please don't do that.  Normally, PIE has zero load address and kernel
>> can load it anywhere.  There are multiple reasons why PIE has non-zero
>> load address.  Saying you need to load a program above 4GB under x86-64,
>> you can't do that with normal dynamic executable.  PIE with non-zero load
>> address is the only way to do that on x86-64.
>>
>
> Why does it have to be PIE?
>

x86-64 small model is limited to 4GB in size.  You can't build
a dynamic executable in small model larger than 4GB.

There are medium and large models.  But they are slower than
small models as well as small models in PIE.  Also there are
no glibc run-times for medium and large models.


-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

On 12/09/2013 01:44 PM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 1:39 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 12/09/2013 01:03 PM, H.J. Lu wrote:
>>>
>>> No, please don't do that.  Normally, PIE has zero load address and kernel
>>> can load it anywhere.  There are multiple reasons why PIE has non-zero
>>> load address.  Saying you need to load a program above 4GB under x86-64,
>>> you can't do that with normal dynamic executable.  PIE with non-zero load
>>> address is the only way to do that on x86-64.
>>>
>>
>> Why does it have to be PIE?
>>
> 
> x86-64 small model is limited to 4GB in size.  You can't build
> a dynamic executable in small model larger than 4GB.
> 
> There are medium and large models.  But they are slower than
> small models as well as small models in PIE.  Also there are
> no glibc run-times for medium and large models.
> 

Compiling for the small PIC model shouldn't automatically mean
generating a PIE (ET_DYN) executable, though (and if those are
inherently linked, that is a fundamental bug IMNSHO.)

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 3:35 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/09/2013 01:44 PM, H.J. Lu wrote:
>> On Mon, Dec 9, 2013 at 1:39 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>>> On 12/09/2013 01:03 PM, H.J. Lu wrote:
>>>>
>>>> No, please don't do that.  Normally, PIE has zero load address and kernel
>>>> can load it anywhere.  There are multiple reasons why PIE has non-zero
>>>> load address.  Saying you need to load a program above 4GB under x86-64,
>>>> you can't do that with normal dynamic executable.  PIE with non-zero load
>>>> address is the only way to do that on x86-64.
>>>>
>>>
>>> Why does it have to be PIE?
>>>
>>
>> x86-64 small model is limited to 4GB in size.  You can't build
>> a dynamic executable in small model larger than 4GB.
>>
>> There are medium and large models.  But they are slower than
>> small models as well as small models in PIE.  Also there are
>> no glibc run-times for medium and large models.
>>
>
> Compiling for the small PIC model shouldn't automatically mean
> generating a PIE (ET_DYN) executable, though (and if those are
> inherently linked, that is a fundamental bug IMNSHO.)

PIE uses PIC. But GCC has -fPIE and -fPIC.  They aren't
the same.   You build PIE with

1. Compile with -fPIE.
2. Link with -pie.

-- 
H.J.

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H. Peter Anvin]

On 12/09/2013 03:53 PM, H.J. Lu wrote:
>>>
>>> x86-64 small model is limited to 4GB in size.  You can't build
>>> a dynamic executable in small model larger than 4GB.
>>>
>>> There are medium and large models.  But they are slower than
>>> small models as well as small models in PIE.  Also there are
>>> no glibc run-times for medium and large models.
>>>
>> Compiling for the small PIC model shouldn't automatically mean
>> generating a PIE (ET_DYN) executable, though (and if those are
>> inherently linked, that is a fundamental bug IMNSHO.)
> 
> PIE uses PIC. But GCC has -fPIE and -fPIC.  They aren't
> the same.   You build PIE with
> 
> 1. Compile with -fPIE.
> 2. Link with -pie.
> 

I'm talking about the memory model ("small PIC model").  I don't see why
it should be encapsulated in a PIE (ET_DYN) container if the user
doesn't want it to be relocatable.

	-hpa

Re: [PATCH] binfmt_elf: fix PIE load with randomization disabled

[H.J. Lu]

On Mon, Dec 9, 2013 at 4:37 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/09/2013 03:53 PM, H.J. Lu wrote:
>>>>
>>>> x86-64 small model is limited to 4GB in size.  You can't build
>>>> a dynamic executable in small model larger than 4GB.
>>>>
>>>> There are medium and large models.  But they are slower than
>>>> small models as well as small models in PIE.  Also there are
>>>> no glibc run-times for medium and large models.
>>>>
>>> Compiling for the small PIC model shouldn't automatically mean
>>> generating a PIE (ET_DYN) executable, though (and if those are
>>> inherently linked, that is a fundamental bug IMNSHO.)
>>
>> PIE uses PIC. But GCC has -fPIE and -fPIC.  They aren't
>> the same.   You build PIE with
>>
>> 1. Compile with -fPIE.
>> 2. Link with -pie.
>>
>
> I'm talking about the memory model ("small PIC model").  I don't see why
> it should be encapsulated in a PIE (ET_DYN) container if the user
> doesn't want it to be relocatable.
>

I see.  Maybe linker can set ET_EXEC if vaddr is non-zero.


-- 
H.J.