RFC: Add SHT_GNU_PHDRS

[H.J. Lu]

When -z separate-code is used to create executable, ld won't place any
data in the code-only PT_LOAD segment. If there are no data sections
placed before the code-only PT_LOAD segment, the program headers
won't be mapped into any PT_LOAD segment. When the executable tries
to access it (based on the program header address passed in AT_PHDR),
it will lead to segfault.

I am proposing

#define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */

This is a special read-only SHF_ALLOC zero-size data section. It is the
first output section, which will force a data PT_LOAD segment with program
header before the code-only PT_LOAD segment,

--
H.J.

[Roland McGrath]

Just put the rodata segment first. That's what lld does and it works
great. There is also the nacl layout that specifically addresses exactly
this issue for a platform that requires the code segment to have the lowest
address, but I don't think any other modern platform actually had such a
requirement.

On Wed, Sep 26, 2018, 14:54 H.J. Lu <***@gmail.com> wrote:

> When -z separate-code is used to create executable, ld won't place any
> data in the code-only PT_LOAD segment. If there are no data sections
> placed before the code-only PT_LOAD segment, the program headers
> won't be mapped into any PT_LOAD segment. When the executable tries
> to access it (based on the program header address passed in AT_PHDR),ri
> it will lead to segfault.
>
> I am proposing
>
> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>
> This is a special read-only SHF_ALLOC zero-size data section. It is the
> first output section, which will force a data PT_LOAD segment with program
> header before the code-only PT_LOAD segment,
>
> --
> H.J.
>
> --


Thanks,
Roland

[H.J. Lu]

On Wed, Sep 26, 2018 at 7:53 PM, Roland McGrath <***@hack.frob.com> wrote:
> Just put the rodata segment first. That's what lld does and it works great.

Does it work with relro segment? Also rodata is always required:

[***@gnu-cfl-1 ld]$ readelf -SWl tmpdir/pr23428
There are 13 section headers, starting at offset 0x2008:

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 0000000000400120 000120
000020 00 A 0 0 8
[ 2] .text PROGBITS 0000000000401000 001000
00012d 00 AX 0 0 16
[ 3] .comment PROGBITS 0000000000000000 00112d
00002c 01 MS 0 0 1
[ 4] .debug_aranges PROGBITS 0000000000000000 001160
000060 00 0 0 16
[ 5] .debug_info PROGBITS 0000000000000000 0011c0
000482 00 0 0 1
[ 6] .debug_abbrev PROGBITS 0000000000000000 001642
00016d 00 0 0 1
[ 7] .debug_line PROGBITS 0000000000000000 0017af
000246 00 0 0 1
[ 8] .debug_frame PROGBITS 0000000000000000 0019f8
000040 00 0 0 8
[ 9] .debug_str PROGBITS 0000000000000000 001a38
000374 01 MS 0 0 1
[10] .symtab SYMTAB 0000000000000000 001db0
000198 18 11 11 8
[11] .strtab STRTAB 0000000000000000 001f48
000030 00 0 0 1
[12] .shstrtab STRTAB 0000000000000000 001f78
00008a 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 0x401000
There are 4 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000400000 0x0000000000400000
0x000140 0x000140 R 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000
0x00012d 0x00012d R E 0x1000
NOTE 0x000120 0x0000000000400120 0x0000000000400120
0x000020 0x000020 R 0x8
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

Section to Segment mapping:
Segment Sections...
00 .note.gnu.property
01 .text
02 .note.gnu.property
03
[***@gnu-cfl-1 ld]$ ./tmpdir/pr23428
[***@gnu-cfl-1 ld]$

There is no rodata at all.

> There is also the nacl layout that specifically addresses exactly this issue
> for a platform that requires the code segment to have the lowest address,
> but I don't think any other modern platform actually had such a requirement.
>
> On Wed, Sep 26, 2018, 14:54 H.J. Lu <***@gmail.com> wrote:
>>
>> When -z separate-code is used to create executable, ld won't place any
>> data in the code-only PT_LOAD segment. If there are no data sections
>> placed before the code-only PT_LOAD segment, the program headers
>> won't be mapped into any PT_LOAD segment. When the executable tries
>> to access it (based on the program header address passed in AT_PHDR),ri
>> it will lead to segfault.
>>
>> I am proposing
>>
>> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>>
>> This is a special read-only SHF_ALLOC zero-size data section. It is the
>> first output section, which will force a data PT_LOAD segment with program
>> header before the code-only PT_LOAD segment,
>>
>> --
>> H.J.
>>
> --
>
>
> Thanks,
> Roland



--
H.J.

[Carlos O'Donell]

On 9/26/18 5:53 PM, H.J. Lu wrote:
> When -z separate-code is used to create executable, ld won't place any
> data in the code-only PT_LOAD segment. If there are no data sections
> placed before the code-only PT_LOAD segment, the program headers
> won't be mapped into any PT_LOAD segment. When the executable tries
> to access it (based on the program header address passed in AT_PHDR),
> it will lead to segfault.
>
> I am proposing
>
> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>
> This is a special read-only SHF_ALLOC zero-size data section. It is the
> first output section, which will force a data PT_LOAD segment with program
> header before the code-only PT_LOAD segment,

This seems like a huge hack to me. Either ld ensures that the page-aligned
start of the PT_LOAD mapping includes the program headers, or we have to
define SHT_GNU_PHDRS as having exactly that semantic and we need to clearly
explain what a static linker needs to do to accomplish this task. What you
have here needs more documentation.

--
Cheers,
Carlos.

[H.J. Lu]

On Wed, Sep 26, 2018 at 8:25 PM, Carlos O'Donell <***@redhat.com> wrote:
> On 9/26/18 5:53 PM, H.J. Lu wrote:
>> When -z separate-code is used to create executable, ld won't place any
>> data in the code-only PT_LOAD segment. If there are no data sections
>> placed before the code-only PT_LOAD segment, the program headers
>> won't be mapped into any PT_LOAD segment. When the executable tries
>> to access it (based on the program header address passed in AT_PHDR),
>> it will lead to segfault.
>>
>> I am proposing
>>
>> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>>
>> This is a special read-only SHF_ALLOC zero-size data section. It is the
>> first output section, which will force a data PT_LOAD segment with program
>> header before the code-only PT_LOAD segment,
>
> This seems like a huge hack to me. Either ld ensures that the page-aligned
> start of the PT_LOAD mapping includes the program headers, or we have to
> define SHT_GNU_PHDRS as having exactly that semantic and we need to clearly
> explain what a static linker needs to do to accomplish this task. What you
> have here needs more documentation.

It is to replace another hack:

[***@gnu-cfl-1 ld]$ readelf -SWl tmpdir/pr23428
There are 13 section headers, starting at offset 0x2008:

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 0000000000400120 000120
000020 00 A 0 0 8
[ 2] .text PROGBITS 0000000000401000 001000
00012d 00 AX 0 0 16
[ 3] .comment PROGBITS 0000000000000000 00112d
00002c 01 MS 0 0 1
[ 4] .debug_aranges PROGBITS 0000000000000000 001160
000060 00 0 0 16
[ 5] .debug_info PROGBITS 0000000000000000 0011c0
000482 00 0 0 1
[ 6] .debug_abbrev PROGBITS 0000000000000000 001642
00016d 00 0 0 1
[ 7] .debug_line PROGBITS 0000000000000000 0017af
000246 00 0 0 1
[ 8] .debug_frame PROGBITS 0000000000000000 0019f8
000040 00 0 0 8
[ 9] .debug_str PROGBITS 0000000000000000 001a38
000374 01 MS 0 0 1
[10] .symtab SYMTAB 0000000000000000 001db0
000198 18 11 11 8
[11] .strtab STRTAB 0000000000000000 001f48
000030 00 0 0 1
[12] .shstrtab STRTAB 0000000000000000 001f78
00008a 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 0x401000
There are 4 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000400000 0x0000000000400000
0x000140 0x000140 R 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000
0x00012d 0x00012d R E 0x1000
NOTE 0x000120 0x0000000000400120 0x0000000000400120
0x000020 0x000020 R 0x8
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

Section to Segment mapping:
Segment Sections...
00 .note.gnu.property
01 .text
02 .note.gnu.property
03
[***@gnu-cfl-1 ld]$ ./tmpdir/pr23428
[***@gnu-cfl-1 ld]$

I added a "dummy" .note.gnu.property section in x86 backend so that
program header
can be in a data PT_LOAD segment.

--
H.J.

[Florian Weimer]

* H. J. Lu:

> I am proposing
>
> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>
> This is a special read-only SHF_ALLOC zero-size data section. It is the
> first output section, which will force a data PT_LOAD segment with program
> header before the code-only PT_LOAD segment,

Is it actually a requirement in the ELF specification that all bits
loaded via segments are covered by sections as well?

Thanks,
Florian

[Jan Beulich]

>>> On 27.09.18 at 07:01, <***@redhat.com> wrote:
> * H. J. Lu:
>
>> I am proposing
>>
>> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>>
>> This is a special read-only SHF_ALLOC zero-size data section. It is the
>> first output section, which will force a data PT_LOAD segment with program
>> header before the code-only PT_LOAD segment,
>
> Is it actually a requirement in the ELF specification that all bits
> loaded via segments are covered by sections as well?

Hardly, because the presence of a section table isn't required
in the first place in an executable (iirc).

Jan

[Florian Weimer]

* Jan Beulich:

>>>> On 27.09.18 at 07:01, <***@redhat.com> wrote:
>> * H. J. Lu:
>>
>>> I am proposing
>>>
>>> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>>>
>>> This is a special read-only SHF_ALLOC zero-size data section. It is the
>>> first output section, which will force a data PT_LOAD segment with program
>>> header before the code-only PT_LOAD segment,
>>
>> Is it actually a requirement in the ELF specification that all bits
>> loaded via segments are covered by sections as well?
>
> Hardly, because the presence of a section table isn't required
> in the first place in an executable (iirc).

I think so too, and that is why I don't understand this section hack is
needed.

Thanks,
Florian

[Szabolcs Nagy]

* Florian Weimer <***@redhat.com> [2018-09-27 10:21:40 +0200]:
> * Jan Beulich:
> >>>> On 27.09.18 at 07:01, <***@redhat.com> wrote:
> >> * H. J. Lu:
> >>
> >>> I am proposing
> >>>
> >>> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
> >>>
> >>> This is a special read-only SHF_ALLOC zero-size data section. It is the
> >>> first output section, which will force a data PT_LOAD segment with program
> >>> header before the code-only PT_LOAD segment,
> >>
> >> Is it actually a requirement in the ELF specification that all bits
> >> loaded via segments are covered by sections as well?
> >
> > Hardly, because the presence of a section table isn't required
> > in the first place in an executable (iirc).
>
> I think so too, and that is why I don't understand this section hack is
> needed.

if there is no read-only alloc section then the program
headers are currently not part of a load segment.
https://sourceware.org/bugzilla/show_bug.cgi?id=23428

an alloc .phdr section covering the program headers solves
this problem. if sections are not required for segments
then simply the linker should ensure that there is always
a load segment covering the program headers, possibly
without containing any sections, however elf says
"An object file segment contains one or more sections".

i don't understand why a zero-size section is enough, what
if phdr > pagesize? will that get covered by the load
segment that is created for the zero-size section?

[Florian Weimer]

* Szabolcs Nagy:

> without containing any sections, however elf says
> "An object file segment contains one or more sections".

Interesting. This indeed suggests that a covering section for the
program header is needed, and a new section type for it makes sense.

Thanks,
Florian

[Cary Coutant]

> * Szabolcs Nagy:
>
> > without containing any sections, however elf says
> > "An object file segment contains one or more sections".
>
> Interesting. This indeed suggests that a covering section for the
> program header is needed, and a new section type for it makes sense.

I would argue that "one or more" is careless wording. It goes on to
say "... though this fact is transparent to the program header.
Whether the file segment holds one or many sections also is immaterial
to program loading."

If you need a special section type just to ensure that the BFD linker
will include the program headers in a loadable segment, that's a mere
implementation detail, and doesn't need to be part of the gABI or
psABI.

-cary

[H.J. Lu]

On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
> * Florian Weimer <***@redhat.com> [2018-09-27 10:21:40 +0200]:
>> * Jan Beulich:
>> >>>> On 27.09.18 at 07:01, <***@redhat.com> wrote:
>> >> * H. J. Lu:
>> >>
>> >>> I am proposing
>> >>>
>> >>> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */
>> >>>
>> >>> This is a special read-only SHF_ALLOC zero-size data section. It is the
>> >>> first output section, which will force a data PT_LOAD segment with program
>> >>> header before the code-only PT_LOAD segment,
>> >>
>> >> Is it actually a requirement in the ELF specification that all bits
>> >> loaded via segments are covered by sections as well?
>> >
>> > Hardly, because the presence of a section table isn't required
>> > in the first place in an executable (iirc).
>>
>> I think so too, and that is why I don't understand this section hack is
>> needed.
>
> if there is no read-only alloc section then the program
> headers are currently not part of a load segment.
> https://sourceware.org/bugzilla/show_bug.cgi?id=23428
>
> an alloc .phdr section covering the program headers solves
> this problem. if sections are not required for segments
> then simply the linker should ensure that there is always
> a load segment covering the program headers, possibly
> without containing any sections, however elf says
> "An object file segment contains one or more sections".
>
> i don't understand why a zero-size section is enough, what
> if phdr > pagesize? will that get covered by the load
> segment that is created for the zero-size section?

Linker must keep this zero-size section in output and
create a PT_LOAD segment to cover it even if it is
the only SHF_ALLOC section in the PT_LOAD segment.

--
H.J.

[Florian Weimer]

* H. J. Lu:

> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
>> an alloc .phdr section covering the program headers solves
>> this problem. if sections are not required for segments
>> then simply the linker should ensure that there is always
>> a load segment covering the program headers, possibly
>> without containing any sections, however elf says
>> "An object file segment contains one or more sections".
>>
>> i don't understand why a zero-size section is enough, what
>> if phdr > pagesize? will that get covered by the load
>> segment that is created for the zero-size section?
>
> Linker must keep this zero-size section in output and
> create a PT_LOAD segment to cover it even if it is
> the only SHF_ALLOC section in the PT_LOAD segment.

Based on Szabolcs' comment, I don't think the section can be zero-sized.

Thanks,
Florian

[H.J. Lu]

On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer <***@redhat.com> wrote:
> * H. J. Lu:
>
>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
>>> an alloc .phdr section covering the program headers solves
>>> this problem. if sections are not required for segments
>>> then simply the linker should ensure that there is always
>>> a load segment covering the program headers, possibly
>>> without containing any sections, however elf says
>>> "An object file segment contains one or more sections".
>>>
>>> i don't understand why a zero-size section is enough, what
>>> if phdr > pagesize? will that get covered by the load
>>> segment that is created for the zero-size section?
>>
>> Linker must keep this zero-size section in output and
>> create a PT_LOAD segment to cover it even if it is
>> the only SHF_ALLOC section in the PT_LOAD segment.
>
> Based on Szabolcs' comment, I don't think the section can be zero-sized.
>

Why can't we put a zero-size section in a PT_LOAD segment?
Of course, we need to change linker to do it.

--
H.J.

[Florian Weimer]

* H. J. Lu:

> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer <***@redhat.com> wrote:
>> * H. J. Lu:
>>
>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
>>>> an alloc .phdr section covering the program headers solves
>>>> this problem. if sections are not required for segments
>>>> then simply the linker should ensure that there is always
>>>> a load segment covering the program headers, possibly
>>>> without containing any sections, however elf says
>>>> "An object file segment contains one or more sections".
>>>>
>>>> i don't understand why a zero-size section is enough, what
>>>> if phdr > pagesize? will that get covered by the load
>>>> segment that is created for the zero-size section?
>>>
>>> Linker must keep this zero-size section in output and
>>> create a PT_LOAD segment to cover it even if it is
>>> the only SHF_ALLOC section in the PT_LOAD segment.
>>
>> Based on Szabolcs' comment, I don't think the section can be zero-sized.
>>
>
> Why can't we put a zero-size section in a PT_LOAD segment?
> Of course, we need to change linker to do it.

I'm now under the impression that the bits that are PT_LOAD'ed all need
to be covered by (allocated) sections. A zero-sized section doesn't
cover anything, so it doesn't address this requirement of the ELF
specification.

Thanks,
Florian

[Carlos O'Donell]

On 9/27/18 8:57 AM, Florian Weimer wrote:
> * H. J. Lu:
>
>> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer <***@redhat.com> wrote:
>>> * H. J. Lu:
>>>
>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
>>>>> an alloc .phdr section covering the program headers solves
>>>>> this problem. if sections are not required for segments
>>>>> then simply the linker should ensure that there is always
>>>>> a load segment covering the program headers, possibly
>>>>> without containing any sections, however elf says
>>>>> "An object file segment contains one or more sections".
>>>>>
>>>>> i don't understand why a zero-size section is enough, what
>>>>> if phdr > pagesize? will that get covered by the load
>>>>> segment that is created for the zero-size section?
>>>>
>>>> Linker must keep this zero-size section in output and
>>>> create a PT_LOAD segment to cover it even if it is
>>>> the only SHF_ALLOC section in the PT_LOAD segment.
>>>
>>> Based on Szabolcs' comment, I don't think the section can be zero-sized.
>>>
>>
>> Why can't we put a zero-size section in a PT_LOAD segment?
>> Of course, we need to change linker to do it.
>
> I'm now under the impression that the bits that are PT_LOAD'ed all need
> to be covered by (allocated) sections. A zero-sized section doesn't
> cover anything, so it doesn't address this requirement of the ELF
> specification.

I agree. What we did in the past by relying on phdrs to be accidentally
in the first PT_LOAD segment always irked me as bad design.

If we need access to program header we need clear semantics for doing so,
not hackish kludges to force the linker to get it onto a page that also
happened to be mapped. This is just poor engineering on our part.

--
Cheers,
Carlos.

[H.J. Lu]

On Thu, Sep 27, 2018 at 6:07 AM, Carlos O'Donell <***@redhat.com> wrote:
> On 9/27/18 8:57 AM, Florian Weimer wrote:
>> * H. J. Lu:
>>
>>> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer <***@redhat.com> wrote:
>>>> * H. J. Lu:
>>>>
>>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
>>>>>> an alloc .phdr section covering the program headers solves
>>>>>> this problem. if sections are not required for segments
>>>>>> then simply the linker should ensure that there is always
>>>>>> a load segment covering the program headers, possibly
>>>>>> without containing any sections, however elf says
>>>>>> "An object file segment contains one or more sections".
>>>>>>
>>>>>> i don't understand why a zero-size section is enough, what
>>>>>> if phdr > pagesize? will that get covered by the load
>>>>>> segment that is created for the zero-size section?
>>>>>
>>>>> Linker must keep this zero-size section in output and
>>>>> create a PT_LOAD segment to cover it even if it is
>>>>> the only SHF_ALLOC section in the PT_LOAD segment.
>>>>
>>>> Based on Szabolcs' comment, I don't think the section can be zero-sized.
>>>>
>>>
>>> Why can't we put a zero-size section in a PT_LOAD segment?
>>> Of course, we need to change linker to do it.
>>
>> I'm now under the impression that the bits that are PT_LOAD'ed all need
>> to be covered by (allocated) sections. A zero-sized section doesn't
>> cover anything, so it doesn't address this requirement of the ELF

It depends on how we define it. I did experiment SHT_GNU_PHDRS
to cover the whole program header. But other tools don't expect a
section covering the program header.

>> specification.
>
> I agree. What we did in the past by relying on phdrs to be accidentally
> in the first PT_LOAD segment always irked me as bad design.
>
> If we need access to program header we need clear semantics for doing so,
> not hackish kludges to force the linker to get it onto a page that also
> happened to be mapped. This is just poor engineering on our part.
>

My current dummy program property note section sounds much better
now :-).

--
H.J.

[Carlos O'Donell]

On 9/27/18 9:20 AM, H.J. Lu wrote:
> On Thu, Sep 27, 2018 at 6:07 AM, Carlos O'Donell <***@redhat.com> wrote:
>> On 9/27/18 8:57 AM, Florian Weimer wrote:
>>> * H. J. Lu:
>>>
>>>> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer <***@redhat.com> wrote:
>>>>> * H. J. Lu:
>>>>>
>>>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
>>>>>>> an alloc .phdr section covering the program headers solves
>>>>>>> this problem. if sections are not required for segments
>>>>>>> then simply the linker should ensure that there is always
>>>>>>> a load segment covering the program headers, possibly
>>>>>>> without containing any sections, however elf says
>>>>>>> "An object file segment contains one or more sections".
>>>>>>>
>>>>>>> i don't understand why a zero-size section is enough, what
>>>>>>> if phdr > pagesize? will that get covered by the load
>>>>>>> segment that is created for the zero-size section?
>>>>>>
>>>>>> Linker must keep this zero-size section in output and
>>>>>> create a PT_LOAD segment to cover it even if it is
>>>>>> the only SHF_ALLOC section in the PT_LOAD segment.
>>>>>
>>>>> Based on Szabolcs' comment, I don't think the section can be zero-sized.
>>>>>
>>>>
>>>> Why can't we put a zero-size section in a PT_LOAD segment?
>>>> Of course, we need to change linker to do it.
>>>
>>> I'm now under the impression that the bits that are PT_LOAD'ed all need
>>> to be covered by (allocated) sections. A zero-sized section doesn't
>>> cover anything, so it doesn't address this requirement of the ELF
>
> It depends on how we define it. I did experiment SHT_GNU_PHDRS
> to cover the whole program header. But other tools don't expect a
> section covering the program header.

Which other tools? Specific examples please.

The main problem we have to solve is:

* Segfault when trying to access program headers which are expected to be
mapped in by the leading pages of the PT_LOAD segment.

We can't solve *all* the problems.

The correct solution to the above is to improve the semantics that the
toolchain relies upon to map the phdrs.

Some questions which we might get asked is:

* How does a running program know it's *safe* to look at it's own phdrs?

* How many downstream tools are impacted? Do they really need to understand
SHT_GNU_PHDRS?

>>> specification.
>>
>> I agree. What we did in the past by relying on phdrs to be accidentally
>> in the first PT_LOAD segment always irked me as bad design.
>>
>> If we need access to program header we need clear semantics for doing so,
>> not hackish kludges to force the linker to get it onto a page that also
>> happened to be mapped. This is just poor engineering on our part.
>>
>
> My current dummy program property note section sounds much better
> now :-).

My apologies HJ, I did not intend this to sound like an attack on your
original design, just that a new design like SHT_GNU_PHDRS could be
created with reliable semantics.

--
Cheers,
Carlos.

[H.J. Lu]

On Thu, Sep 27, 2018 at 8:18 AM, Carlos O'Donell <***@redhat.com> wrote:
> On 9/27/18 9:20 AM, H.J. Lu wrote:
>> On Thu, Sep 27, 2018 at 6:07 AM, Carlos O'Donell <***@redhat.com> wrote:
>>> On 9/27/18 8:57 AM, Florian Weimer wrote:
>>>> * H. J. Lu:
>>>>
>>>>> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer <***@redhat.com> wrote:
>>>>>> * H. J. Lu:
>>>>>>
>>>>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <***@port70.net> wrote:
>>>>>>>> an alloc .phdr section covering the program headers solves
>>>>>>>> this problem. if sections are not required for segments
>>>>>>>> then simply the linker should ensure that there is always
>>>>>>>> a load segment covering the program headers, possibly
>>>>>>>> without containing any sections, however elf says
>>>>>>>> "An object file segment contains one or more sections".
>>>>>>>>
>>>>>>>> i don't understand why a zero-size section is enough, what
>>>>>>>> if phdr > pagesize? will that get covered by the load
>>>>>>>> segment that is created for the zero-size section?
>>>>>>>
>>>>>>> Linker must keep this zero-size section in output and
>>>>>>> create a PT_LOAD segment to cover it even if it is
>>>>>>> the only SHF_ALLOC section in the PT_LOAD segment.
>>>>>>
>>>>>> Based on Szabolcs' comment, I don't think the section can be zero-sized.
>>>>>>
>>>>>
>>>>> Why can't we put a zero-size section in a PT_LOAD segment?
>>>>> Of course, we need to change linker to do it.
>>>>
>>>> I'm now under the impression that the bits that are PT_LOAD'ed all need
>>>> to be covered by (allocated) sections. A zero-sized section doesn't
>>>> cover anything, so it doesn't address this requirement of the ELF
>>
>> It depends on how we define it. I did experiment SHT_GNU_PHDRS
>> to cover the whole program header. But other tools don't expect a
>> section covering the program header.
>
> Which other tools? Specific examples please.

Please see the enclosed binary where SHT_GNU_PHDRS section
covers the whole program header:

[***@gnu-cfl-1 ld]$ ../binutils/readelf -lSW foo
There are 14 section headers, starting at offset 0x2f00:

Section Headers:
[Nr] Name Type Address Off Size
ES Flg Lk Inf Al
[ 0] NULL 0000000000000000 000000
000000 00 0 0 0
[ 1] .gnu.phdrs GNU_PHDRS 0000000000400040 000040
0000e0 38 A 0 0 8
[ 2] .text PROGBITS 0000000000401000 001000
00014b 00 AX 0 0 16
[ 3] .rodata PROGBITS 0000000000402000 002000
000006 00 A 0 0 1
[ 4] .comment PROGBITS 0000000000000000 002006
00002c 01 MS 0 0 1
[ 5] .debug_aranges PROGBITS 0000000000000000 002040
000060 00 0 0 16
[ 6] .debug_info PROGBITS 0000000000000000 0020a0
000482 00 0 0 1
[ 7] .debug_abbrev PROGBITS 0000000000000000 002522
00016d 00 0 0 1
[ 8] .debug_line PROGBITS 0000000000000000 00268f
000248 00 0 0 1
[ 9] .debug_frame PROGBITS 0000000000000000 0028d8
000040 00 0 0 8
[10] .debug_str PROGBITS 0000000000000000 002918
000374 01 MS 0 0 1
[11] .symtab SYMTAB 0000000000000000 002c90
0001b0 18 12 12 8
[12] .strtab STRTAB 0000000000000000 002e40
000030 00 0 0 1
[13] .shstrtab STRTAB 0000000000000000 002e70
00008a 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 0x401000
There are 4 program headers, starting at offset 64

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flg Align
LOAD 0x000000 0x0000000000400000 0x0000000000400000
0x000120 0x000120 R 0x1000
LOAD 0x001000 0x0000000000401000 0x0000000000401000
0x00014b 0x00014b R E 0x1000
LOAD 0x002000 0x0000000000402000 0x0000000000402000
0x000006 0x000006 R 0x1000
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000
0x000000 0x000000 RWE 0x10

Section to Segment mapping:
Segment Sections...
00 .gnu.phdrs
01 .text
02 .rodata
03
[***@gnu-cfl-1 ld]$ ./foo
PASS
[***@gnu-cfl-1 ld]$ ../binutils/objcopy ./foo bar
../binutils/objcopy: bar: section .gnu.phdrs lma 0x400040 adjusted to 0x401040
[***@gnu-cfl-1 ld]$

I can fix objcopy. Other tools may also need adjustment.

> The main problem we have to solve is:
>
> * Segfault when trying to access program headers which are expected to be
> mapped in by the leading pages of the PT_LOAD segment.
>
> We can't solve *all* the problems.
>
> The correct solution to the above is to improve the semantics that the
> toolchain relies upon to map the phdrs.
>
> Some questions which we might get asked is:
>
> * How does a running program know it's *safe* to look at it's own phdrs?
>
> * How many downstream tools are impacted? Do they really need to understand
> SHT_GNU_PHDRS?
>
>>>> specification.
>>>
>>> I agree. What we did in the past by relying on phdrs to be accidentally
>>> in the first PT_LOAD segment always irked me as bad design.
>>>
>>> If we need access to program header we need clear semantics for doing so,
>>> not hackish kludges to force the linker to get it onto a page that also
>>> happened to be mapped. This is just poor engineering on our part.
>>>
>>
>> My current dummy program property note section sounds much better
>> now :-).
>
> My apologies HJ, I did not intend this to sound like an attack on your
> original design, just that a new design like SHT_GNU_PHDRS could be
> created with reliable semantics.

None taken.


--
H.J.

[Carlos O'Donell]

On 9/27/18 12:26 PM, H.J. Lu wrote:
> [***@gnu-cfl-1 ld]$ ../binutils/objcopy ./foo bar
> ../binutils/objcopy: bar: section .gnu.phdrs lma 0x400040 adjusted to 0x401040

What is it doing here? Why is it adjusting the lma? How odd.

> [***@gnu-cfl-1 ld]$
>
> I can fix objcopy. Other tools may also need adjustment.

Yes, this just looks like bugs.

* Unknown section types should not be adjusted or touched and minimally passed
through during a copy. We should not adjust them to the next PROGBITS section.

* Backports of the fix to active branches to enable distributions to easily
pickup the fixes.

... and keep moving forward with a proper fix (and consensus around it).


--
Cheers,
Carlos.

[Cary Coutant]

> > I'm now under the impression that the bits that are PT_LOAD'ed all need
> > to be covered by (allocated) sections. A zero-sized section doesn't
> > cover anything, so it doesn't address this requirement of the ELF
> > specification.
>
> I agree. What we did in the past by relying on phdrs to be accidentally
> in the first PT_LOAD segment always irked me as bad design.
>
> If we need access to program header we need clear semantics for doing so,
> not hackish kludges to force the linker to get it onto a page that also
> happened to be mapped. This is just poor engineering on our part.

It seems to me that the kernel loader should make the program headers
available to the dynamic loader through the aux vector, whether
they're part of a PT_LOAD segment or not. That should be part of the
psABI. The gABI clearly requires that the dynamic loader has access to
the program headers (e.g., it needs to find PT_DYNAMIC), but it
doesn't care how the implementation accomplishes that.

-cary

[H.J. Lu]

On Thu, Sep 27, 2018 at 3:34 PM, Cary Coutant <***@gmail.com> wrote:
>> > I'm now under the impression that the bits that are PT_LOAD'ed all need
>> > to be covered by (allocated) sections. A zero-sized section doesn't
>> > cover anything, so it doesn't address this requirement of the ELF
>> > specification.
>>
>> I agree. What we did in the past by relying on phdrs to be accidentally
>> in the first PT_LOAD segment always irked me as bad design.
>>
>> If we need access to program header we need clear semantics for doing so,
>> not hackish kludges to force the linker to get it onto a page that also
>> happened to be mapped. This is just poor engineering on our part.
>
> It seems to me that the kernel loader should make the program headers
> available to the dynamic loader through the aux vector, whether
> they're part of a PT_LOAD segment or not. That should be part of the
> psABI. The gABI clearly requires that the dynamic loader has access to
> the program headers (e.g., it needs to find PT_DYNAMIC), but it
> doesn't care how the implementation accomplishes that.
>

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.

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.


--
H.J.

[Rich Felker]

On Fri, Sep 28, 2018 at 06:42:52AM -0700, H.J. Lu wrote:
> On Thu, Sep 27, 2018 at 3:34 PM, Cary Coutant <***@gmail.com> wrote:
> >> > I'm now under the impression that the bits that are PT_LOAD'ed all need
> >> > to be covered by (allocated) sections. A zero-sized section doesn't
> >> > cover anything, so it doesn't address this requirement of the ELF
> >> > specification.
> >>
> >> I agree. What we did in the past by relying on phdrs to be accidentally
> >> in the first PT_LOAD segment always irked me as bad design.
> >>
> >> If we need access to program header we need clear semantics for doing so,
> >> not hackish kludges to force the linker to get it onto a page that also
> >> happened to be mapped. This is just poor engineering on our part.
> >
> > It seems to me that the kernel loader should make the program headers
> > available to the dynamic loader through the aux vector, whether
> > they're part of a PT_LOAD segment or not. That should be part of the
> > psABI. The gABI clearly requires that the dynamic loader has access to
> > the program headers (e.g., it needs to find PT_DYNAMIC), but it
> > doesn't care how the implementation accomplishes that.
> >
>
> 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).

> 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?

Rich

[Michael Matz]

Hi,

On Thu, 27 Sep 2018, Florian Weimer wrote:

> I'm now under the impression that the bits that are PT_LOAD'ed all need
> to be covered by (allocated) sections.

That is wrong. Szabolcs is reading too much into some careless wording of
the ELF text that simply tries to convey the idea that usually segments
contents are the result of some sections combined by the link editor.
Sections are purely optional in the execution view.

This section hack isn't necessary at all for what we need. The link
editor merely needs to ensure that the program headers are part of some
loadable segment, either by placing it not at the start of the file
(though that would mean the ELF header isn't part of the loaded image,
which is desirable to have), or by creating such loadble segment if
necessary.

No gABI extensions are needed.


Ciao,
Michael.

[Florian Weimer]

* Michael Matz:

> On Thu, 27 Sep 2018, Florian Weimer wrote:
>
>> I'm now under the impression that the bits that are PT_LOAD'ed all need
>> to be covered by (allocated) sections.
>
> That is wrong. Szabolcs is reading too much into some careless wording of
> the ELF text that simply tries to convey the idea that usually segments
> contents are the result of some sections combined by the link editor.
> Sections are purely optional in the execution view.
>
> This section hack isn't necessary at all for what we need. The link
> editor merely needs to ensure that the program headers are part of some
> loadable segment, either by placing it not at the start of the file
> (though that would mean the ELF header isn't part of the loaded image,
> which is desirable to have), or by creating such loadble segment if
> necessary.
>
> No gABI extensions are needed.

That would certainly be nice.

Can we try to update the ELF specification to clarify this? That should
give us additional feedback whether this reading of the specification is
correct.

Thanks,
Florian

[Michael Matz]

Hi,

On Fri, 28 Sep 2018, Florian Weimer wrote:

> > This section hack isn't necessary at all for what we need. The link
> > editor merely needs to ensure that the program headers are part of
> > some loadable segment, either by placing it not at the start of the
> > file (though that would mean the ELF header isn't part of the loaded
> > image, which is desirable to have), or by creating such loadble
> > segment if necessary.
> >
> > No gABI extensions are needed.
>
> That would certainly be nice.
>
> Can we try to update the ELF specification to clarify this?

Maybe.

> That should give us additional feedback whether this reading of the
> specification is correct.

Well, at least the part about sections being purely optional is undeniably
true. The section headers themself were never part of the loaded
image (nor part of any section for that matter).

Now the but: I would agree that it would be nice if all file contents
would be covered by some section if section headers are in the file at
all, simply because the named sections are easier for humans to deal with
than numbered program headers, so that their use in tools (like e.g.
readelf -x) is comfortable. But that's independend and outside of what's
required by ELF. If we go down that route then we should go the full way
and cover the ELF header, the program headers and the section headers with
sections as well. I don't see why they would need their own type though,
PROGBITS is just fine. And again, all that would be optional and a pure
QoI issue.


Ciao,
Michael.