Default entry point for ELF shared objects

Default entry point for ELF shared objects

[Florian Weimer]

BFD ld currently sets a non-zero entry point address for ELF shared
objects even if the object does not have a _start symbol.

Is there a reason for this behavior (particularly for ELF ET_DYN
output)?

On Linux, the kernel will happily load and execute shared objects using
this entry point address, typically leading to crashes.

If the entry point address in the ELF header were zero, it might be
possible to detect the missing entry point, and refuse to execute the
shared object as if it were a program.

Thanks,
Florian

Re: Default entry point for ELF shared objects

[Fangrui Song]

On 2021-09-13, Florian Weimer via Binutils wrote:
>BFD ld currently sets a non-zero entry point address for ELF shared
>objects even if the object does not have a _start symbol.
>
>Is there a reason for this behavior (particularly for ELF ET_DYN
>output)?
>
>On Linux, the kernel will happily load and execute shared objects using
>this entry point address, typically leading to crashes.
>
>If the entry point address in the ELF header were zero, it might be
>possible to detect the missing entry point, and refuse to execute the
>shared object as if it were a program.
>
>Thanks,
>Florian

This behavior is documented at https://sourceware.org/binutils/docs/ld/Entry-Point.html

"the address of the first byte of the ‘.text’ section, if present;"

The rule is quite ad-hoc and I'd support the removal.

Re: Default entry point for ELF shared objects

[Florian Weimer]

* Fangrui Song:

> On 2021-09-13, Florian Weimer via Binutils wrote:
>>BFD ld currently sets a non-zero entry point address for ELF shared
>>objects even if the object does not have a _start symbol.
>>
>>Is there a reason for this behavior (particularly for ELF ET_DYN
>>output)?
>>
>>On Linux, the kernel will happily load and execute shared objects using
>>this entry point address, typically leading to crashes.
>>
>>If the entry point address in the ELF header were zero, it might be
>>possible to detect the missing entry point, and refuse to execute the
>>shared object as if it were a program.
>>
>>Thanks,
>>Florian
>
> This behavior is documented at https://sourceware.org/binutils/docs/ld/Entry-Point.html
>
> "the address of the first byte of the ‘.text’ section, if present;"
>
> The rule is quite ad-hoc and I'd support the removal.

I saw that.  I still wonder where it came from originally.  It seems
more like something for a bare-metal target.  Maybe it can be kept for
those, but removed for Linux ELF targets, especially ET_DYN output
objects.

Thanks,
Florian

Re: Default entry point for ELF shared objects

[Andreas Schwab]

On Sep 16 2021, Florian Weimer via Binutils wrote:

> I saw that.  I still wonder where it came from originally.

For a.out, it makes totally sense.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Default entry point for ELF shared objects

[Hans-Peter Nilsson]

On Thu, 16 Sep 2021, Florian Weimer via Binutils wrote:

> * Fangrui Song:
>
> > On 2021-09-13, Florian Weimer via Binutils wrote:
> >>BFD ld currently sets a non-zero entry point address for ELF shared
> >>objects even if the object does not have a _start symbol.
> >>
> >>Is there a reason for this behavior (particularly for ELF ET_DYN
> >>output)?
> >>
> >>On Linux, the kernel will happily load and execute shared objects using
> >>this entry point address, typically leading to crashes.
> >>
> >>If the entry point address in the ELF header were zero, it might be
> >>possible to detect the missing entry point, and refuse to execute the
> >>shared object as if it were a program.
> >>
> >>Thanks,
> >>Florian
> >
> > This behavior is documented at https://sourceware.org/binutils/docs/ld/Entry-Point.html
> >
> > "the address of the first byte of the ?.text? section, if present;"
> >
> > The rule is quite ad-hoc and I'd support the removal.
>
> I saw that.  I still wonder where it came from originally.  It seems
> more like something for a bare-metal target.  Maybe it can be kept for
> those,

Even if so, IMHO it should be updated to be "the text segment"
or words to that effect, as the .text *section* is likely just
main code located after .startup or .init or similar.

> but removed for Linux ELF targets, especially ET_DYN output
> objects.
>
> Thanks,
> Florian
>

brgds, H-P

Re: Default entry point for ELF shared objects

[Paul Koning]

> On Sep 16, 2021, at 11:14 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> 
> On Thu, 16 Sep 2021, Florian Weimer via Binutils wrote:
> 
>> * Fangrui Song:
>> 
>>> ...
>>> This behavior is documented at https://sourceware.org/binutils/docs/ld/Entry-Point.html
>>> 
>>> "the address of the first byte of the ?.text? section, if present;"
>>> 
>>> The rule is quite ad-hoc and I'd support the removal.
>> 
>> I saw that.  I still wonder where it came from originally.  It seems
>> more like something for a bare-metal target.  Maybe it can be kept for
>> those,
> 
> Even if so, IMHO it should be updated to be "the text segment"
> or words to that effect, as the .text *section* is likely just
> main code located after .startup or .init or similar.

A default entry point really doesn't make any sense for any target, bare metal or otherwise.  Yes, it's possible such a random guess is the right answer some of the time, but clearly any build can always supply an explicit start address -- and in my view that should be required.

As an example, the DEC object format has a special code point meaning "no start address", and that is the default.

	paul

Re: Default entry point for ELF shared objects

[Hans-Peter Nilsson]

On Thu, 16 Sep 2021, Paul Koning wrote:

>
>
> > On Sep 16, 2021, at 11:14 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> >
> > On Thu, 16 Sep 2021, Florian Weimer via Binutils wrote:
> >
> >> * Fangrui Song:
> >>
> >>> ...
> >>> This behavior is documented at https://sourceware.org/binutils/docs/ld/Entry-Point.html
> >>>
> >>> "the address of the first byte of the ?.text? section, if present;"
> >>>
> >>> The rule is quite ad-hoc and I'd support the removal.
> >>
> >> I saw that.  I still wonder where it came from originally.  It seems
> >> more like something for a bare-metal target.  Maybe it can be kept for
> >> those,
> >
> > Even if so, IMHO it should be updated to be "the text segment"
> > or words to that effect, as the .text *section* is likely just
> > main code located after .startup or .init or similar.
>
> A default entry point really doesn't make any sense for any
> target, bare metal or otherwise.  Yes, it's possible such a
> random guess is the right answer some of the time, but clearly
> any build can always supply an explicit start address -- and in
> my view that should be required.
>
> As an example, the DEC object format has a special code point
> meaning "no start address", and that is the default.

Let me rephrase: since we *can't* say "no start address", a
guess that is much more likely to be correct, is "the address of
the first byte of the text *segment*" (for formats where that
term applies) than the that of the .text *section*.  This
because code for embedded targets is likely linked into one blob
with the .text section being located only after other named
sections in the text segment and the start address being the
first address of that blob.

Perhaps we just talk past each other.

brgds, H-P

Re: Default entry point for ELF shared objects

[Florian Weimer]

* Hans-Peter Nilsson:

> Let me rephrase: since we *can't* say "no start address", a
> guess that is much more likely to be correct, is "the address of
> the first byte of the text *segment*" (for formats where that
> term applies) than the that of the .text *section*.

Just to be clear, ELF specifies 0 as “no start address”.  And I'm only
interested in ELF these days …

Thanks,
Florian

Re: Default entry point for ELF shared objects

[Paul Koning]

> On Sep 16, 2021, at 12:54 PM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> 
> On Thu, 16 Sep 2021, Paul Koning wrote:
>> ...
>> A default entry point really doesn't make any sense for any
>> target, bare metal or otherwise.  Yes, it's possible such a
>> random guess is the right answer some of the time, but clearly
>> any build can always supply an explicit start address -- and in
>> my view that should be required.
>> 
>> As an example, the DEC object format has a special code point
>> meaning "no start address", and that is the default.
> 
> Let me rephrase: since we *can't* say "no start address", a
> guess that is much more likely to be correct, is "the address of
> the first byte of the text *segment*" (for formats where that
> term applies) than the that of the .text *section*.  This
> because code for embedded targets is likely linked into one blob
> with the .text section being located only after other named
> sections in the text segment and the start address being the
> first address of that blob.

I see the problem.  Yes, if there is no encoding for "no address" (not even zero) then your suggestion is the best available option.

	paul

Re: Default entry point for ELF shared objects

[dvalin]

  On 16.09.21 19:01, Florian Weimer via Binutils wrote:
  > * Hans-Peter Nilsson:
  >
  > > Let me rephrase: since we *can't* say "no start address", a
  > > guess that is much more likely to be correct, is "the address
of
  > > the first byte of the text *segment*" (for formats where that
  > > term applies) than the that of the .text *section*.
  
  The linker script has to put .vector and .init_n input sections
into the .text 
  output section, if it doesn't place them first in the text segment,
so in my  decades of embedded experience, it comes down to how you
hack the  script.
  > Just to be clear, ELF specifies 0 as “no start address”. 
And I'm only
  > interested in ELF these days …

  Is it then not ideal to leave things as they are? With “no start
address”
  specified, ELF defaults to indicating “no start address”.

  The status quo evidently emanates from the glory days when bare
metal
  applications were all there was. (And still is here, 40 years
later.)

  On reset, many a microprocessor sets the program counter to zero,
which
  is the start of the text segment. (OK, that'll be the start of the
  interrupt vector table in many cases that I've encountered, and
hardware 
  reset can be viewed as the mother of all interrupts.)

  There are a few exceptions, requiring some target-specific start
address,
  sometimes selectable between piggy-in-the-middle and a bit short of
top
  of the address space. Exceptions have always required an explicit
start
  address, and there is nothing to take exception to there.

   So the safest course is to not rock the boat. That said, a change
from 
   hard-coded zero to start of the text segment ought to have zero
negative   effect in the common low-end embedded case, and may
beneficially 
  serve a number of non-zero start targets. (E.g. Boot from high
ROM,  then copy at least vectors down to zero address, possibly
followed by  the whole app. There, text LMA is ROM, VMA is in RAM for
all but the  bootstrap.)

  /2c

Erik