From: Sergei Trofimovich <slyfox@gentoo.org>
To: musl@lists.openwall.com, libc-alpha@sourceware.org,
gcc@gcc.gnu.org, toolchain@gentoo.org
Subject: [musl] musl, glibc and ideal place for __stack_chk_fail_local
Date: Sat, 25 Jan 2020 10:53:31 +0000 [thread overview]
Message-ID: <20200125105331.7c5d284b@sf> (raw)
[ sending it to musl, glibc and gcc devel mailing list as we need
to build a consensus across the projects ]
To support smash stack protection gcc emits __stack_chk_fail
calls on all targets. On top of that gcc emits __stack_chk_fail_local
calls at least on i386 and powerpc:
https://bugs.gentoo.org/706210#c9
gcc can either use libssp/libssp_nonshared fallback or rely on libc
to provide __stack_chk_fail. Where ideally should gcc pick
__stack_chk_fail_local?
Looks like gcc/glibc and musl disagree on that:
- gcc: gcc either provides it from libssp_nonshared.a if libc has
no ssp support or pulls it from libc
- glibc: provides both __stack_chk_fail (deault) and
__stack_chk_fail_local (avoid PLT) symbols.
__stack_chk_fail_local comes from libc_nonshared.a and is
added to linker script as: $ cat /usr/lib/libc.so
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) )
- musl: provides only __stack_chk_fail (default) and
refuses to provide __stack_chk_fail_local:
https://www.openwall.com/lists/musl/2018/09/11/2
This makes musl effectively not support ssp on i386 and probably powerpc.
Currently gcc's assumption is that musl supports ssp symbols
from libc on all targets:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/configure.ac;h=a7521ee99436a7c12159bdde0471dc66d3c4288e;hb=HEAD#l6079
6088 case "$target" in
6089 *-*-musl*)
6090 # All versions of musl provide stack protector
6091 gcc_cv_libc_provides_ssp=yes;;
Clearly that assumption is not correct as __stack_chk_fail_local
is not provided by musl and linking fails.
This sounds like a expectation mismatch between gcc and musl
of what it takes to implement an ssp interface.
What should we do to make it fixed long term and short term?
Long term:
Is there a vision of perfect end state agreed with gcc/glibc/musl
folk so we could just implement it? If there is none let's try to
form one.
My understanding of requirements for libc that exposes ssp support:
- __stack_chk_fail is implemented as a default symbol
- __stack_chk_fail_local is implemented as a local symbol to avoid PLT.
(Why is it important? To avoid use of potentially already broken stack?)
My understanding of possible perfect end state:
1. All libcs are required to somehow provide both __stack_chk_fail
and __stack_chk_fail_local: be it linker script, crt*.o files or an extra
libc_nonshared.a which gcc explicitly uses. Which one is best?
2. All libcs are required to provide only __stack_chk_fail and gcc always
provides __stack_chk_local from libgcc.a, or from new libgcc_ssp.a.
Evntually glibc drops it's __stack_chk_fail definition.
3. Your variant.
How do you gcc/glibc/musl folk see it? Once we decide I'll file bugs
against agreed projects. At least gcc could explicitly document the
interface.
Short term:
While the above is not addressed what should we do about musl in gcc?
Should gcc stop trying use musl on i386/powerpc here:
6088 case "$target" in
6089 *-*-musl*)
6090 # All versions of musl provide stack protector
6091 gcc_cv_libc_provides_ssp=yes;;
and fall back to libssp instead?
If it makes sense I'll create a bug against gcc.
Thanks!
--
Sergei
next reply other threads:[~2020-01-25 10:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-25 10:53 Sergei Trofimovich [this message]
2020-01-25 15:54 ` Rich Felker
2020-01-30 12:33 ` Segher Boessenkool
2020-01-30 13:37 ` Rich Felker
2020-01-30 14:56 ` Segher Boessenkool
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200125105331.7c5d284b@sf \
--to=slyfox@gentoo.org \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=musl@lists.openwall.com \
--cc=toolchain@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).