RFC: Add GNU_PROPERTY_NEED_PHDRS

[H.J. Lu]

Dynamic loader has no problem. The problem is kernel passes
AT_PHDR to main, which points to the unmmaped address. We can
ask for kernel change or make kernel happy.

Kernel change does not help because nobody is obligated to use a new
kernel. Binutils would be producing binaries that don't work on
existing kernels (if the note hack were reverted or if similar changes
were added to other archs without a note hack; right now of course
it's working again).

True.

My current .note.gnu.property patch only works for x86. We can
add
#define GNU_PROPERTY_PHDRS 3
so that it can be used for all targets.

What would this do?

These are what I have in mind.

[Michael Matz]

Hi,

Post by H.J. Lu

AT_PHDR to main, which points to the unmmaped address. We can ask
for kernel change or make kernel happy.

Kernel change does not help because nobody is obligated to use a new
kernel. Binutils would be producing binaries that don't work on
existing kernels (if the note hack were reverted or if similar changes
were added to other archs without a note hack; right now of course
it's working again).

True.

My current .note.gnu.property patch only works for x86. We can add
#define GNU_PROPERTY_PHDRS 3
so that it can be used for all targets.

What would this do?

These are what I have in mind.

I don't see how the patches fix anything, in particular making sure that
the phdrs are always mapped. If your intention is (it would be good if
you can explain it with words) that they only would be made mapped if this
new property is set, then I'd disagree. I think they should always be
made mapped unconditionally. There are two ways for this: (a) add a new
PT_LOAD that covers them, (b) move the phdrs into the ro data segment. I
find all approaches that add properties or new section types or anything
else that needs documentation and definition dubious.


Ciao,
Michael.

[H.J. Lu]

Post by Michael Matz
Hi,

Post by H.J. Lu

AT_PHDR to main, which points to the unmmaped address. We can ask
for kernel change or make kernel happy.

Kernel change does not help because nobody is obligated to use a new
kernel. Binutils would be producing binaries that don't work on
existing kernels (if the note hack were reverted or if similar changes
were added to other archs without a note hack; right now of course
it's working again).

True.

My current .note.gnu.property patch only works for x86. We can add
#define GNU_PROPERTY_PHDRS 3
so that it can be used for all targets.

What would this do?

These are what I have in mind.

I don't see how the patches fix anything, in particular making sure that
the phdrs are always mapped. If your intention is (it would be good if
you can explain it with words) that they only would be made mapped if this
new property is set, then I'd disagree. I think they should always be
made mapped unconditionally. There are two ways for this: (a) add a new
PT_LOAD that covers them, (b) move the phdrs into the ro data segment. I
find all approaches that add properties or new section types or anything
else that needs documentation and definition dubious.

A .note.gnu.property section will lead to a read-only data PT_LOAD segment
as the first PT_LOAD segment:

[***@gnu-17 ld]$ readelf -WlS tmpdir/pr23428
There are 16 section headers, starting at offset 0x2ed0:

Section Headers:
[Nr] Name Type Address Off Size
ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000
000000 00 0 0 0
[ 1] .note.gnu.property NOTE 0000000000400158 000158
000030 00 A 0 0 8
[ 2] .text PROGBITS 0000000000401000 001000
0000ea 00 AX 0 0 16
[ 3] .rodata PROGBITS 0000000000402000 002000
000006 01 AMS 0 0 1
[ 4] .comment PROGBITS 0000000000000000 002006
00002d 01 MS 0 0 1
[ 5] .debug_aranges PROGBITS 0000000000000000 002040
000060 00 0 0 16
[ 6] .debug_info PROGBITS 0000000000000000 0020a0
0002f7 00 0 0 1
[ 7] .debug_abbrev PROGBITS 0000000000000000 002397
000137 00 0 0 1
[ 8] .debug_line PROGBITS 0000000000000000 0024ce
0001a7 00 0 0 1
[ 9] .debug_frame PROGBITS 0000000000000000 002678
000040 00 0 0 8
[10] .debug_str PROGBITS 0000000000000000 0026b8
0002a1 01 MS 0 0 1
[11] .debug_loc PROGBITS 0000000000000000 002959
000295 00 0 0 1
[12] .debug_ranges PROGBITS 0000000000000000 002bee
000020 00 0 0 1
[13] .symtab SYMTAB 0000000000000000 002c10
0001e0 18 14 14 8
[14] .strtab STRTAB 0000000000000000 002df0
000030 00 0 0 1
[15] .shstrtab STRTAB 0000000000000000 002e20
0000ab 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)

Elf file type is EXEC (Executable file)
Entry point 0x4010c0
There are 5 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000400000 0x0000000000400000
0x000188 0x000188 R 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000
0x0000ea 0x0000ea R E 0x1000
LOAD 0x002000 0x0000000000402000 0x0000000000402000
0x000006 0x000006 R 0x1000
NOTE 0x000158 0x0000000000400158 0x0000000000400158
0x000030 0x000030 R 0x8
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

Section to Segment mapping:
Segment Sections...
00 .note.gnu.property
01 .text
02 .rodata
03 .note.gnu.property
04
[***@gnu-17 ld]$

[Michael Matz]

Hi,

Post by H.J. Lu
A .note.gnu.property section will lead to a read-only data PT_LOAD segment

Yes, and it's a hack. This section isn't necessary, it merely is the
easiest (?) way you found to force ld to create the PT_LOAD segment you
want. What about linker scripts that filter out all .note sections? You
_still_ want the phdrs to be mapped in that case. You basically replace
the current state (where the phdrs are mapped by accident) with a
different state that still only works by accident. It would be better to
make this work by design not accident.


Ciao,
Michael.

Post by H.J. Lu
[Nr] Name Type Address Off Size
ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000
000000 00 0 0 0
[ 1] .note.gnu.property NOTE 0000000000400158 000158
000030 00 A 0 0 8
[ 2] .text PROGBITS 0000000000401000 001000
0000ea 00 AX 0 0 16
[ 3] .rodata PROGBITS 0000000000402000 002000
000006 01 AMS 0 0 1
[ 4] .comment PROGBITS 0000000000000000 002006
00002d 01 MS 0 0 1
[ 5] .debug_aranges PROGBITS 0000000000000000 002040
000060 00 0 0 16
[ 6] .debug_info PROGBITS 0000000000000000 0020a0
0002f7 00 0 0 1
[ 7] .debug_abbrev PROGBITS 0000000000000000 002397
000137 00 0 0 1
[ 8] .debug_line PROGBITS 0000000000000000 0024ce
0001a7 00 0 0 1
[ 9] .debug_frame PROGBITS 0000000000000000 002678
000040 00 0 0 8
[10] .debug_str PROGBITS 0000000000000000 0026b8
0002a1 01 MS 0 0 1
[11] .debug_loc PROGBITS 0000000000000000 002959
000295 00 0 0 1
[12] .debug_ranges PROGBITS 0000000000000000 002bee
000020 00 0 0 1
[13] .symtab SYMTAB 0000000000000000 002c10
0001e0 18 14 14 8
[14] .strtab STRTAB 0000000000000000 002df0
000030 00 0 0 1
[15] .shstrtab STRTAB 0000000000000000 002e20
0000ab 00 0 0 1
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)
Elf file type is EXEC (Executable file)
Entry point 0x4010c0
There are 5 program headers, starting at offset 64
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000400000 0x0000000000400000
0x000188 0x000188 R 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000
0x0000ea 0x0000ea R E 0x1000
LOAD 0x002000 0x0000000000402000 0x0000000000402000
0x000006 0x000006 R 0x1000
NOTE 0x000158 0x0000000000400158 0x0000000000400158
0x000030 0x000030 R 0x8
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10
Segment Sections...
00 .note.gnu.property
01 .text
02 .rodata
03 .note.gnu.property
04

[H.J. Lu]

Post by Michael Matz
Hi,

Post by H.J. Lu
A .note.gnu.property section will lead to a read-only data PT_LOAD segment

Yes, and it's a hack. This section isn't necessary, it merely is the
easiest (?) way you found to force ld to create the PT_LOAD segment you
want. What about linker scripts that filter out all .note sections? You
_still_ want the phdrs to be mapped in that case. You basically replace
the current state (where the phdrs are mapped by accident) with a
different state that still only works by accident. It would be better to
make this work by design not accident.

If linker script discards a section, all bets are off. Anything can happen.

[Michael Matz]

Hi,

Post by H.J. Lu

Post by Michael Matz
Yes, and it's a hack. This section isn't necessary, it merely is the
easiest (?) way you found to force ld to create the PT_LOAD segment
you want. What about linker scripts that filter out all .note
sections? You _still_ want the phdrs to be mapped in that case. You
basically replace the current state (where the phdrs are mapped by
accident) with a different state that still only works by accident.
It would be better to make this work by design not accident.

If linker script discards a section, all bets are off. Anything can happen.

I disagree, but even if I'd agree your solution still is more accidental
than by design. You want to guarantee something about program headers, so
any solution that doesn't do anything specific about/with program headers
is similarly accidental.


Ciao,
Michael.

[H.J. Lu]

Post by Michael Matz
Hi,

Post by H.J. Lu

Post by Michael Matz
Yes, and it's a hack. This section isn't necessary, it merely is the
easiest (?) way you found to force ld to create the PT_LOAD segment
you want. What about linker scripts that filter out all .note
sections? You _still_ want the phdrs to be mapped in that case. You
basically replace the current state (where the phdrs are mapped by
accident) with a different state that still only works by accident.
It would be better to make this work by design not accident.

If linker script discards a section, all bets are off. Anything can happen.

I disagree, but even if I'd agree your solution still is more accidental
than by design. You want to guarantee something about program headers, so
any solution that doesn't do anything specific about/with program headers
is similarly accidental.

Nothing is guaranteed when linker script is used since anything can happen
with linker script.

[Michael Matz]

Hi,

Post by H.J. Lu

Post by Michael Matz

Post by H.J. Lu
If linker script discards a section, all bets are off. Anything can happen.

I disagree, but even if I'd agree your solution still is more
accidental than by design. You want to guarantee something about
program headers, so any solution that doesn't do anything specific
about/with program headers is similarly accidental.

Nothing is guaranteed when linker script is used since anything can
happen with linker script.

Ignore the parts about the linker script, I disagree with you, but that's
immaterial to my main point. Your solution still is only an accidental
one as you don't do anything about program headers but instead just add
magic sections to magic places that happens to do what you want currently.
That's not by design.


Ciao,
Michael.

[H.J. Lu]

Post by Michael Matz
Hi,

Post by H.J. Lu

Post by Michael Matz

Post by H.J. Lu
If linker script discards a section, all bets are off. Anything can happen.

I disagree, but even if I'd agree your solution still is more
accidental than by design. You want to guarantee something about
program headers, so any solution that doesn't do anything specific
about/with program headers is similarly accidental.

Nothing is guaranteed when linker script is used since anything can
happen with linker script.

Ignore the parts about the linker script, I disagree with you, but that's
immaterial to my main point. Your solution still is only an accidental
one as you don't do anything about program headers but instead just add
magic sections to magic places that happens to do what you want currently.
That's not by design.

The problem is

1. Linker kernel passes AT_PHDR to main and assumes that AT_PHDR
is in a PT_LOAD segment.
2. gABI doesn't require phdrs in a PT_LOAD segment.
3. Ld won't create a PT_LOAD segment just to hold phdrs.
4. With -z separate-code, linker won't put any non-code in a PF_X PT_LOAD
segment.

When there are only PF_X PT_LOAD segments, phdrs isn't in any PT_LOAD
segment.

You are looking for a solution to create a PT_LOAD segment just to hold phdrs.
I have investigated it. It is very intrusive. My solution, which you
called a hack,
is to add a read-only SHF_ALLOC section so that a PT_LOAD segment will
be created by ld to hold phdrs when there is only PF_X PT_LOAD segments
otherwise.

[Cary Coutant]

Post by H.J. Lu
1. Linker kernel passes AT_PHDR to main and assumes that AT_PHDR
is in a PT_LOAD segment.

s/Linker/Linux/

One could argue that this is the real (and only) problem. If it's
going to pass a pointer to the program headers, the kernel should make
sure that the headers are mapped, whether or not they're part of a
PT_LOAD segment.

Even with no-separate-code, or with a read-only segment before the
text, the inclusion of the program headers in the first PT_LOAD
segment is merely a happy accident -- it's a side effect of way the
linker rounds segment boundaries down and up to page boundaries, and
depends entirely on the property that the first PT_LOAD segment falls
within the first page of the executable file. If, for some reason, the
linker were to place additional non-loadable stuff between the headers
and the text (e.g., symbol tables, section tables), this could fail.
In fact, if the program headers themselves happen to be so large as to
spill over onto the second page of the file, the first PT_LOAD segment
would not necessarily include the first page of the file.

Now, I understand that fixing the Linux kernel to map the headers even
if they're not part of a PT_LOAD segment isn't a practical
alternative. That leads to...

Post by H.J. Lu
2. gABI doesn't require phdrs in a PT_LOAD segment.

It doesn't belong in the gABI, as the mechanics of making the program
header information available to the dynamic loader and the running
program are processor- and OS-specific.

Since this is a Linux-specific issue, not an architecture-specific
one, we really should put this in an osABI document rather than a
psABI document. I suppose the LSB serves as such. Or maybe the gnu ABI
document?

Post by H.J. Lu
3. Ld won't create a PT_LOAD segment just to hold phdrs.

You seem to be breezing right past the idea of doing exactly this.
Why? The scripting language already allows you to declare which
segment should include FILEHDR and PHDRS. For -z separate-code, why
not use a default linker script with something like the following?

PHDRS
{
headers PT_PHDR PHDRS ;
interp PT_INTERP ;
header_seg PT_LOAD FILEHDR PHDRS ;
text PT_LOAD ;
data PT_LOAD ;
dynamic PT_DYNAMIC ;
}

Post by H.J. Lu
4. With -z separate-code, linker won't put any non-code in a PF_X PT_LOAD
segment.
When there are only PF_X PT_LOAD segments, phdrs isn't in any PT_LOAD
segment.
You are looking for a solution to create a PT_LOAD segment just to hold phdrs.
I have investigated it. It is very intrusive. My solution, which you
called a hack,
is to add a read-only SHF_ALLOC section so that a PT_LOAD segment will
be created by ld to hold phdrs when there is only PF_X PT_LOAD segments
otherwise.

How is it intrusive? If the above linker script doesn't do the job,
isn't that a bug anyway?

And, really, there's no denying that adding an otherwise-unnecessary
note section -- just to get us back into the realm of "it works by
happy accident" -- is a pure hack.

-cary

[Alan Modra]

Post by Cary Coutant
Even with no-separate-code, or with a read-only segment before the
text, the inclusion of the program headers in the first PT_LOAD
segment is merely a happy accident -- it's a side effect of way the
linker rounds segment boundaries down and up to page boundaries, and
depends entirely on the property that the first PT_LOAD segment falls
within the first page of the executable file.

As Michael would say, it's a hack. ;-)

Post by Cary Coutant

Post by H.J. Lu
3. Ld won't create a PT_LOAD segment just to hold phdrs.

You seem to be breezing right past the idea of doing exactly this.
Why? The scripting language already allows you to declare which
segment should include FILEHDR and PHDRS. For -z separate-code, why
not use a default linker script with something like the following?
PHDRS
{
headers PT_PHDR PHDRS ;
interp PT_INTERP ;
header_seg PT_LOAD FILEHDR PHDRS ;
text PT_LOAD ;
data PT_LOAD ;
dynamic PT_DYNAMIC ;
}

The script idea is probably not practical in view of all the
variations of headers we'd need. PT_NOTE, PT_TLS, PT_GNU_EH_FRAME,
PT_GNU_STACK, PT_GNU_RELRO come to mind, some of which depend on
executable contents.

I do agree that ld should be modified to create a PT_LOAD just for
headers when needed, probably keyed off SIZEOF_HEADERS in a script.

Post by Cary Coutant
And, really, there's no denying that adding an otherwise-unnecessary
note section -- just to get us back into the realm of "it works by
happy accident" -- is a pure hack.

I don't particularly like the note section hack, but I can see why HJ
did it that way. Adding a note section no doubt avoids objcopy bugs
that would otherwise need to be fixed.

[Cary Coutant]

Post by Alan Modra

Post by Cary Coutant

Post by H.J. Lu
3. Ld won't create a PT_LOAD segment just to hold phdrs.

You seem to be breezing right past the idea of doing exactly this.
Why? The scripting language already allows you to declare which
segment should include FILEHDR and PHDRS. For -z separate-code, why
not use a default linker script with something like the following?
PHDRS
{
headers PT_PHDR PHDRS ;
interp PT_INTERP ;
header_seg PT_LOAD FILEHDR PHDRS ;
text PT_LOAD ;
data PT_LOAD ;
dynamic PT_DYNAMIC ;
}

The script idea is probably not practical in view of all the
variations of headers we'd need. PT_NOTE, PT_TLS, PT_GNU_EH_FRAME,
PT_GNU_STACK, PT_GNU_RELRO come to mind, some of which depend on
executable contents.

I don't understand why you say it's not practical. How does the number
of variations of individual program header table entries matter?

-cary

[Alan Modra]

Post by Cary Coutant

Post by Alan Modra

Post by Cary Coutant

Post by H.J. Lu
3. Ld won't create a PT_LOAD segment just to hold phdrs.

You seem to be breezing right past the idea of doing exactly this.
Why? The scripting language already allows you to declare which
segment should include FILEHDR and PHDRS. For -z separate-code, why
not use a default linker script with something like the following?
PHDRS
{
headers PT_PHDR PHDRS ;
interp PT_INTERP ;
header_seg PT_LOAD FILEHDR PHDRS ;
text PT_LOAD ;
data PT_LOAD ;
dynamic PT_DYNAMIC ;
}

The script idea is probably not practical in view of all the
variations of headers we'd need. PT_NOTE, PT_TLS, PT_GNU_EH_FRAME,
PT_GNU_STACK, PT_GNU_RELRO come to mind, some of which depend on
executable contents.

I don't understand why you say it's not practical. How does the number
of variations of individual program header table entries matter?

If you specify PHDRS in a script, ld uses exactly those program
headers, and I believe it should continue to operate that way. So to
add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
need a script with PT_GNU_EH_FRAME specified in PHDRS. And another
without PT_GNU_EH_FRAME when the executable doesn't have
.eh_frame_hdr. That soon becomes impractial considering the number of
optional headers, requiring auto-generation of the PHDRS script
snippet.

[Cary Coutant]

Post by Alan Modra
If you specify PHDRS in a script, ld uses exactly those program
headers, and I believe it should continue to operate that way. So to
add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
need a script with PT_GNU_EH_FRAME specified in PHDRS. And another
without PT_GNU_EH_FRAME when the executable doesn't have
.eh_frame_hdr. That soon becomes impractial considering the number of
optional headers, requiring auto-generation of the PHDRS script
snippet.

Oh, I see. Yeah, that does make it impractical.

Still, I'd like to understand why HJ claims it's intrusive to have ld
create a PT_LOAD segment for the headers. I haven't tried it yet in
gold (don't support -z separate-code), but it doesn't seem like it
would be at all difficult or intrusive.

-cary

[H.J. Lu]

Post by Cary Coutant

Post by Alan Modra
If you specify PHDRS in a script, ld uses exactly those program
headers, and I believe it should continue to operate that way. So to
add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
need a script with PT_GNU_EH_FRAME specified in PHDRS. And another
without PT_GNU_EH_FRAME when the executable doesn't have
.eh_frame_hdr. That soon becomes impractial considering the number of
optional headers, requiring auto-generation of the PHDRS script
snippet.

Oh, I see. Yeah, that does make it impractical.
Still, I'd like to understand why HJ claims it's intrusive to have ld
create a PT_LOAD segment for the headers. I haven't tried it yet in
gold (don't support -z separate-code), but it doesn't seem like it
would be at all difficult or intrusive.

The linker part is relatively easy. The problems are with strip and
objcopy. They aren't prepared to deal with it.

[Rich Felker]

Post by H.J. Lu

Post by Cary Coutant

Post by Alan Modra
If you specify PHDRS in a script, ld uses exactly those program
headers, and I believe it should continue to operate that way. So to
add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
need a script with PT_GNU_EH_FRAME specified in PHDRS. And another
without PT_GNU_EH_FRAME when the executable doesn't have
.eh_frame_hdr. That soon becomes impractial considering the number of
optional headers, requiring auto-generation of the PHDRS script
snippet.

Oh, I see. Yeah, that does make it impractical.
Still, I'd like to understand why HJ claims it's intrusive to have ld
create a PT_LOAD segment for the headers. I haven't tried it yet in
gold (don't support -z separate-code), but it doesn't seem like it
would be at all difficult or intrusive.

The linker part is relatively easy. The problems are with strip and
objcopy. They aren't prepared to deal with it.

Can you elaborate on what would go wrong with them? AIUI they can't
remove anything from segments; they can only remove non-loaded
sections. (I found this out the hard way a long time ago trying to get
strip to remove unneeded .eh_frame)

Rich

[H.J. Lu]

Post by Rich Felker

Post by H.J. Lu

Post by Cary Coutant

Post by Alan Modra
If you specify PHDRS in a script, ld uses exactly those program
headers, and I believe it should continue to operate that way. So to
add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd
need a script with PT_GNU_EH_FRAME specified in PHDRS. And another
without PT_GNU_EH_FRAME when the executable doesn't have
.eh_frame_hdr. That soon becomes impractial considering the number of
optional headers, requiring auto-generation of the PHDRS script
snippet.

Oh, I see. Yeah, that does make it impractical.
Still, I'd like to understand why HJ claims it's intrusive to have ld
create a PT_LOAD segment for the headers. I haven't tried it yet in
gold (don't support -z separate-code), but it doesn't seem like it
would be at all difficult or intrusive.

The linker part is relatively easy. The problems are with strip and
objcopy. They aren't prepared to deal with it.

Can you elaborate on what would go wrong with them? AIUI they can't
remove anything from segments; they can only remove non-loaded
sections. (I found this out the hard way a long time ago trying to get
strip to remove unneeded .eh_frame)

Sorry. I don't remember the details.

[Alan Modra]

Post by H.J. Lu

Post by Rich Felker
Can you elaborate on what would go wrong with them? AIUI they can't
remove anything from segments; they can only remove non-loaded
sections. (I found this out the hard way a long time ago trying to get
strip to remove unneeded .eh_frame)

Sorry. I don't remember the details.

One difficulty is what to put in p_vaddr and p_paddr of a segment
without sections. I'm working on a linker/bfd solution that doesn't
require a note section.