From: Simon South <simon@simonsouth.net>
To: Leo Famulari <leo@famulari.name>
Cc: 53005@debbugs.gnu.org
Subject: bug#53005: [PATCH 1/1] gnu: glibc: Preserve "__pthread_key_create" symbol.
Date: Wed, 12 Jan 2022 16:22:27 -0500 [thread overview]
Message-ID: <878rvkodik.fsf@simonsouth.net> (raw)
In-Reply-To: <Yd8qUwGKBIZPG0P9@jasmine.lan> (Leo Famulari's message of "Wed, 12 Jan 2022 14:21:55 -0500")
Leo Famulari <leo@famulari.name> writes:
> First, how was the LUKS2 volume created? Was it created by Guix
> System?
No, this would've been a volume I created myself; I expect only users
who are partitioning their drives manually or replacing an existing
system would encounter this. The Guix manual actually instructs users
to select a different PBKDF algorithm[0] for compatibility with GRUB,
one that by coincidence does not appear to be affected[1].
However, remember this problem potentially affects _all_ packages that
use threads in C or C++. It appears that dynamically-linked executables
(i.e. the vast majority) generally sidestep the problem by avoiding any
"dangerous" methods in libgcc, but there could still be crashing bugs
elsewhere waiting to be discovered.
> Is Guix doing something wrong that requires the workaround?
This is all a consequence of stripping libraries with the
"--strip-unneeded" option instead of "--strip-debug"[2], in the interest
of reducing store sizes. The man page for "strip" describes it like
this:
--strip-unneeded
Remove all symbols that are not needed for relocation processing.
My personal opinion is that this option makes sense for executables but
is too aggressive to use on libraries.
- Unlike executables, we generally want to do more with a library than
just relocate it.
- Providing a rich set of symbols is normally a desirable feature of a
library and not a bug.
- Only at link time is it possible to say which of a library's symbols
are truly relevant; therefore, the selection of symbols to retain
should logically be performed by the linker, not an automated step
during the library's packaging (outside of any link context).
Specifically, it's impossible for us to predict cases like this one,
where a symbol not obviously needed to use a library is nonetheless
relied on by an application.
However, Guix's gnu-build-system provides only a single "#:strip-flags"
argument that is applied to all of a package's binaries. So, as an
alternative solution, we could either extend that mechanism to allow
different sets of flags to be applied to different types of binaries, or
revert the changes (commits f32a6055a5 and e0f31baacc) altogether. I
didn't expect either of those options would be popular, and truthfully,
everything does appear to work okay (for now) with only this one change
to glibc.
[0] https://guix.gnu.org/en/manual/devel/en/html_node/Keyboard-Layout-and-Networking-and-Partitioning.html#Disk-Partitioning
[1] But then, neither GRUB nor the Guix installer are commonly used on
non-Intel systems.
[2] Originally proposed in https://issues.guix.gnu.org/42555
--
Simon South
simon@simonsouth.net
next prev parent reply other threads:[~2022-01-12 21:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-04 14:36 bug#53005: cryptsetup-static aborts opening LUKS2 volume with Argon2i PBKDF Simon South
2022-01-04 14:44 ` Simon South
2022-01-08 1:52 ` Simon South
2022-01-10 23:34 ` Simon South
2022-01-10 23:34 ` bug#53005: [PATCH 1/1] gnu: glibc: Preserve "__pthread_key_create" symbol Simon South
2022-01-12 19:21 ` Leo Famulari
2022-01-12 21:22 ` Simon South [this message]
2022-05-01 9:49 ` Tom Fitzhenry
2022-08-19 3:31 ` bug#53005: cryptsetup-static aborts opening LUKS2 volume with Argon2i PBKDF angry rectangle
2024-02-07 19:59 ` Simon South
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878rvkodik.fsf@simonsouth.net \
--to=simon@simonsouth.net \
--cc=53005@debbugs.gnu.org \
--cc=leo@famulari.name \
/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.savannah.gnu.org/cgit/guix.git
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).