[Bug libc/31042] New: [s390x] .init and .fini padding

[Bug libc/31042] New: [s390x] .init and .fini padding

[rui314 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

            Bug ID: 31042
           Summary: [s390x] .init and .fini padding
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: rui314 at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

I noticed this issue while developing the mold linker for the s390x
architecture.

The CRT files for glibc/s390x include .init and .fini sections, which contain
functions for initializing and finalizing a process, respectively. The linker
simply concatenates .init or .fini input sections into a single output section
for each. Upon process startup, the runtime branches to the start of .init as
though it were a single function. The final input .init section contains a ret
instruction to return to the caller.

In this setup, there should be no gaps between the input .init/.fini sections.
However, the .init/.fini sections in glibc/s390x may include trailing padding;
each input section is aligned to a 4-byte boundary, but they do not always end
on these boundaries. As a result, padding may occur between sections after the
linker concatenates them.

The linker can fill this padding with any value. GNU ld appears to use NOPs to
fill the gaps, which happens to work. However, I believe relying on it is an
incorrect approach, or at least a very fragile one.

To fix this issue, you could simply add an `.align 4` directive at the end of
each .init/.fini input section. This would prompt GAS to insert NOPs, ensuring
that each function ends at a 4-byte boundary.

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/s390/s390-64/crti.S;h=11ab75e8d95f86ff225f84673715ff457e8b63cd;hb=HEAD

https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/s390/s390-64/crtn.S;h=0eabcb346caa843a4657c3fb23739bd7bf166091;hb=HEAD

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31042] [s390x] .init and .fini padding

[rui314 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

--- Comment #1 from Rui Ueyama <rui314 at gmail dot com> ---
An alternative approach to address the problem is to remove the `.align`
directive from all but the first `.init`/`.fini` sections, so that input
`.init`/`.fini` sections are concatenated without padding. This seems to be the
approach that glibc/x86-64 takes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31042] [s390x] .init and .fini padding

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
There should be no difference between implicit and explict alignment wrt. nop
filling.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31042] [s390x] .init and .fini padding

[rui314 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

--- Comment #3 from Rui Ueyama <rui314 at gmail dot com> ---
I'm sorry but I don't get what you meant. Would you mind elaborating a bit
further?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31042] [s390x] .init and .fini padding

[stli at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

Stefan Liebler <stli at linux dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stli at linux dot ibm.com

--- Comment #4 from Stefan Liebler <stli at linux dot ibm.com> ---
According to ".align" in GNU AS manual:
https://sourceware.org/binutils/docs/as/Align.html
The second expression (also absolute) gives the fill value to be stored in the
padding bytes. It (and the comma) may be omitted. If it is omitted, the padding
bytes are normally zero. However, on most systems, if the section is marked as
containing code and the fill value is omitted, the space is filled with no-op
instructions.

On s390x without specifying the padding-byte, GNU AS fills the pad-bytes with
nop in the sections containing code.
If GNU LD needs to add padding bytes due to e.g. the alignment requirement in
crtn, it also uses the nops for such a code-section.
mold should also use this behavior in order to be equal to GNU LD. Otherwise
this breaks also other stuff.
Anybody could just add something like this to his own object-files (not part of
glibc):
.section .init
.align 32
lr      %r8,%r8

Then mold would also break it if it pads with 0x0 instead of 0x07.

Nevertheless I think I can just remove the .align 4 in crtn for s390x (64bit).
I don't see a reason why we need it. It is also not needed for s390 (31bit). I
do some further tests and dig a bit in the history. Perhaps I find a reason.
Afterwards I will post a patch to libc-alpha.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31042] [s390x] .init and .fini padding

[rui314 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

--- Comment #5 from Rui Ueyama <rui314 at gmail dot com> ---
> If GNU LD needs to add padding bytes due to e.g. the alignment requirement in crtn, it also uses the nops for such a code-section.
> mold should also use this behavior in order to be equal to GNU LD. Otherwise this breaks also other stuff.

That's correct; that's our approach in mold. That said, it might be a better
idea to eliminate the dependency on that behavior from the hand-written
assembly source files, as it's an obscure dependency on the implementation's
behavior. This also inadvertently creates free NOP slides for attackers. On
other platforms, we fill gaps with trap instructions, ensuring that the program
is immediately terminated if its control reaches an unexpected location.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31042] [s390x] .init and .fini padding

[stli at linux dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

Stefan Liebler <stli at linux dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |2.40
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #6 from Stefan Liebler <stli at linux dot ibm.com> ---
Fixed with commit "Avoid padding in _init and _fini. [BZ #31042]"
https://sourceware.org/git/?p=glibc.git;a=commit;h=807849965bbdeaa9b0a8f675d098efc520eeaaa8

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/31042] [s390x] .init and .fini padding

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31042

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
   Target Milestone|2.40                        |2.39

-- 
You are receiving this mail because:
You are on the CC list for the bug.