From: Jan Kratochvil <jkratochvil@azul.com>
To: Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>
Cc: Jan Kratochvil <jkratochvil@azul.com>,
Florian Weimer <fweimer@redhat.com>,
libc-alpha@sourceware.org, Anton Kozlov <akozlov@azul.com>
Subject: Re: [PATCH] RFC: Provide a function to reset IFUNC PLTs
Date: Thu, 16 Mar 2023 15:38:36 +0100 [thread overview]
Message-ID: <ZBMp6HwLS5Q6afx+@host2.jankratochvil.net> (raw)
In-Reply-To: <676ee95e-9981-a0cd-36b3-231b64b82673@linaro.org> <ce18abb7-04f0-23ff-e9e7-20578c1c6309@linaro.org>
On Thu, 09 Mar 2023 16:47:49 +0100, Adhemerval Zanella Netto wrote:
> I am not sure how the kernel would enumerate new tasks that are created
> while iterating over /proc/self/task.
I have updated the code as you have found a race there. Now this is no longer
relevant as all known tasks are already verified as stopped. So there is no
more running task to create another task. While iterating /proc/self/task:
(1) either there must be already an unstopped task when opendir() was called,
in such case the iteration of /proc/self/task will be retried anyway.
(2) or all tasks are stopped and therefore no task can create any new task.
> On closefrom Linux fallback we have
> a similar problem, where the code iterates over /proc/self/fd, and everytime
> it closes a file descriptor it lseeks back to beginning. It works because
> eventually there will be no more entries on /proc/self/fd, so either you
> will need to certify that kernel adds new tasks at the end of the getdents
> call (used by readdir, or lseek and keep track of all tasks already signaled.
That is not needed, see above.
> While it might work on the JVM where you can not fully control who change
> SIGUSR1 disposition (and I am not sure JVM would prevent a JNI call to do so),
> so you can't really make it generic without explicit reserve a signal to do so,
> similar to what glibc does for SIGCANCEL and SIGSETXID (used to synchronize
> setuid functions over threads). Meaning that callers of sigaction can't
> not explicit set such reserved signal.
>
> This is similar to what we do for SIGSETXID, so I think a proper way to
> do it would to do always install a new signal handler to this on pthread_create,
> on signal handle synchronize with proper async-signal-safe interface
> (pthread_mutex_lock is not, you might accomplish with sem_post but most likely
> you will need a atomic+futex way similar to a barrier), iterate over all
> dl_stack_used (so the interface can work without access to procfs), issue the
> signal handler or each thread, operate on the maps, then synchronize to resume
> threads. We can't really make it generic without accessing the internal
> glibc thread states.
Good to know, if the patch gets a serious consideration for upstreaming
I understand the signal number needs to be handled better.
> And you will also need to reallocate not only glibc, but potentially *all*
> libraries (since ifunc can be used by any function).
This is what the patch already does by _dl_relocate_object().
> > So the only remaining option is that all the programs will be doing
> > setenv("GLIBC_TUNABLES=glibc.cpu.hwcaps=...") and re-exec(). That is
> > a peformance kill and definitely not nice compared to any method of an IFUNC
> > reset.
>
> Assuming you don't reset env variable on process spawning, you can set it as
> default for the session.
The /usr/bin/java program needs to setenv("GLIBC_TUNABLES=glibc.cpu.hwcaps=...")
and then it can either system("itself") or exec("itself"). This is what you
mean by the session?
> Another option would to deploy a glibc built with
> --disable-multi-arch; it will disable ifunc generation.
That is not an option. OpenJDK must be compatible with normal existing Linux
OSes.
> And IMHO this is way nicer because this IFUNC reset as-is, without a proper
> stop-the-word support, is not safe and adds another corner case for the already
> over-complicated ifunc interface.
stop-the-world is already implemented modulo possible bugfixes.
https://github.com/openjdk/crac/pull/41/files#diff-aeec57d804d56002f26a85359fc4ac8b48cfc249d57c656a30a63fc6bf3457adR6029
> > In Java world the other libraries (in general, there are some JNI exceptions)
> > do not matter as they are a Java code JIT-compiled by JVM.
>
> And this won't be a Java specific interface, but rather a GNU extension for C
> library. So we must make it as concise as possible, without adding any other
> security or undefined behavior.
I agree. Handling IFUNC for other libraries is also possible but it has to be
a next step. It does not make sense to handle IFUNC in other libraries when
glibc still crashes first.
On Thu, 09 Mar 2023 18:43:08 +0100, Adhemerval Zanella Netto wrote:
> And the 'handler' signal handler has some potential shortcomings as well:
>
> * backtrace is not async-signal-safe: glibc implementation on first call
> issues dlopen, which calls malloc; and libgcc_eh.so *might* also calls malloc.
I do not see it in practice:
Temporary breakpoint 1, main () at backtrace.c:5
5 backtrace(buf, sizeof(buf)/sizeof(*buf));
(gdb) b dlopen
Breakpoint 2 at 0x7ffff7c88f20: file dlopen.c, line 77.
(gdb) c
Continuing.
[Inferior 1 (process 825695) exited normally]
And neither in the sources:
glibc$ grep dlopen $(find -iname "*backtrace*")
> * pthread calls are not async-signal-safe either.
There are no pthread_* calls, everything is based on kernel tasks.
> * it only handles libc.so, other libraries that uses ifunc for function
> selection also fails.
You are right, I have mostly implemented this hard-coded "libc.so.6" to make
it general (for any libraries containing at least one STT_GNU_IFUNC) although
I haven't finished this implementation due to the last paragraph below.
> * the syscall heuristics do not handle partial results (for instance if
> write syscall returns do EINTR).
I do not think EINTR would matter. The syscall heuristics is there expecting
that any library function which contains syscalls is not an IFUNC function.
> So this code has the potential of deadlock, specially if you have another
> thread issuing malloc.
I may have missed something but I do not see it so according to the answers
above.
According to the other reactions here I doubt this functionality would get
accepted to glibc so we have decided to give up on its upstreaming and use the
setenv("GLIBC_TUNABLES=glibc.cpu.hwcaps=...") + re-exec workaround instead.
That would need to be coded for compatibility with existing/old glibcs anyway.
Thanks,
Jan
next prev parent reply other threads:[~2023-03-16 14:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 8:04 Jan Kratochvil
2023-03-07 8:40 ` Florian Weimer
2023-03-07 13:07 ` Adhemerval Zanella Netto
2023-03-08 10:21 ` Jan Kratochvil
2023-03-08 13:04 ` Adhemerval Zanella Netto
2023-03-09 11:32 ` Jan Kratochvil
2023-03-09 15:47 ` Adhemerval Zanella Netto
2023-03-09 17:43 ` Adhemerval Zanella Netto
2023-03-16 14:38 ` Jan Kratochvil [this message]
2023-03-20 16:47 ` Adhemerval Zanella Netto
2023-03-29 12:12 ` Jan Kratochvil
2023-03-29 13:14 ` Adhemerval Zanella Netto
2023-03-13 13:59 ` Florian Weimer
2023-03-14 12:55 ` Jan Kratochvil
2023-03-14 14:49 ` Florian Weimer
2023-03-14 15:06 ` Jan Kratochvil
2023-03-08 10:23 ` Jan Kratochvil
2023-03-08 10:44 ` Florian Weimer
2023-03-08 11:03 ` Jan Kratochvil
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=ZBMp6HwLS5Q6afx+@host2.jankratochvil.net \
--to=jkratochvil@azul.com \
--cc=adhemerval.zanella@linaro.org \
--cc=akozlov@azul.com \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.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.
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).