public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/31042] New: [s390x] .init and .fini padding
@ 2023-11-08 4:12 rui314 at gmail dot com
2023-11-08 4:27 ` [Bug libc/31042] " rui314 at gmail dot com
` (6 more replies)
0 siblings, 7 replies; 8+ messages in thread
From: rui314 at gmail dot com @ 2023-11-08 4:12 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31042] [s390x] .init and .fini padding
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
@ 2023-11-08 4:27 ` rui314 at gmail dot com
2023-11-08 9:41 ` schwab@linux-m68k.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rui314 at gmail dot com @ 2023-11-08 4:27 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31042] [s390x] .init and .fini padding
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
2023-11-08 4:27 ` [Bug libc/31042] " rui314 at gmail dot com
@ 2023-11-08 9:41 ` schwab@linux-m68k.org
2023-11-08 11:33 ` rui314 at gmail dot com
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: schwab@linux-m68k.org @ 2023-11-08 9:41 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31042] [s390x] .init and .fini padding
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
2023-11-08 4:27 ` [Bug libc/31042] " rui314 at gmail dot com
2023-11-08 9:41 ` schwab@linux-m68k.org
@ 2023-11-08 11:33 ` rui314 at gmail dot com
2023-11-15 14:31 ` stli at linux dot ibm.com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rui314 at gmail dot com @ 2023-11-08 11:33 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31042] [s390x] .init and .fini padding
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
` (2 preceding siblings ...)
2023-11-08 11:33 ` rui314 at gmail dot com
@ 2023-11-15 14:31 ` stli at linux dot ibm.com
2023-11-16 3:36 ` rui314 at gmail dot com
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: stli at linux dot ibm.com @ 2023-11-15 14:31 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31042] [s390x] .init and .fini padding
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
` (3 preceding siblings ...)
2023-11-15 14:31 ` stli at linux dot ibm.com
@ 2023-11-16 3:36 ` rui314 at gmail dot com
2023-11-30 12:36 ` stli at linux dot ibm.com
2023-11-30 16:30 ` fweimer at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: rui314 at gmail dot com @ 2023-11-16 3:36 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31042] [s390x] .init and .fini padding
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
` (4 preceding siblings ...)
2023-11-16 3:36 ` rui314 at gmail dot com
@ 2023-11-30 12:36 ` stli at linux dot ibm.com
2023-11-30 16:30 ` fweimer at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: stli at linux dot ibm.com @ 2023-11-30 12:36 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug libc/31042] [s390x] .init and .fini padding
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
` (5 preceding siblings ...)
2023-11-30 12:36 ` stli at linux dot ibm.com
@ 2023-11-30 16:30 ` fweimer at redhat dot com
6 siblings, 0 replies; 8+ messages in thread
From: fweimer at redhat dot com @ 2023-11-30 16:30 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-11-30 16:30 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-08 4:12 [Bug libc/31042] New: [s390x] .init and .fini padding rui314 at gmail dot com
2023-11-08 4:27 ` [Bug libc/31042] " rui314 at gmail dot com
2023-11-08 9:41 ` schwab@linux-m68k.org
2023-11-08 11:33 ` rui314 at gmail dot com
2023-11-15 14:31 ` stli at linux dot ibm.com
2023-11-16 3:36 ` rui314 at gmail dot com
2023-11-30 12:36 ` stli at linux dot ibm.com
2023-11-30 16:30 ` fweimer at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).