From: Szabolcs Nagy <Szabolcs.Nagy@arm.com>
To: Florian Weimer <fweimer@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>
Cc: nd <nd@arm.com>, "libc-alpha@sourceware.org" <libc-alpha@sourceware.org>
Subject: Re: i386: Lazy binding trampoline and vector register usage
Date: Thu, 9 Jan 2020 10:49:26 +0000 [thread overview]
Message-ID: <7648385b-ebd0-efa6-73e8-1a91cfc517f0@arm.com> (raw)
In-Reply-To: <87lfra2as7.fsf@oldenburg2.str.redhat.com>
On 18/12/2019 10:22, Florian Weimer wrote:
> We have this in sysdeps/i386/Makefile:
>
> # Make sure no code in ld.so uses mm/xmm/ymm/zmm registers on i386 since
> # the first 3 mm/xmm/ymm/zmm registers are used to pass vector parameters
> # which must be preserved.
> # With SSE disabled, ensure -fpmath is not set to use sse either.
> rtld-CFLAGS += -mno-sse -mno-mmx -mfpmath=387
> ifeq ($(subdir),elf)
> CFLAGS-.os += $(if $(filter $(@F),$(patsubst %,%.os,$(all-rtld-routines))),\
> $(rtld-CFLAGS))
>
> tests-special += $(objpfx)tst-ld-sse-use.out
> $(objpfx)tst-ld-sse-use.out: ../sysdeps/i386/tst-ld-sse-use.sh $(objpfx)ld.so
> @echo "Checking ld.so for SSE register use. This will take a few seconds..."
> $(BASH) $< $(objpfx) '$(NM)' '$(OBJDUMP)' '$(READELF)' > $@; \
> $(evaluate-test)
> else
> CFLAGS-.os += $(if $(filter rtld-%.os,$(@F)), $(rtld-CFLAGS))
> endif
>
> The idea is that we do not need to save and restore vector registers in
> the trampoline (or align the stack) if we compile ld.so in such a way
> that only general registers are used. But that does not actually work
> in all cases because lazy binding can call malloc, which lives in
> libc.so or might even be interposed, and is thus free to use vector
> registers.
>
> What should we do about this? Calling malloc from _dl_fixup is unsafe
> for other reasons because lazy binding can happen in signal handlers, so
> maybe this would be fixed if we switched to a non-interposable
> async-signal-safe allocator?
note that ifunc resolvers can also run during lazy binding
and those can execute arbitrary user code (even if the
allocator issue is fixed).
next prev parent reply other threads:[~2020-01-09 10:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 10:22 i386: Lazy binding trampoline and vector register usage Florian Weimer
2020-01-08 22:55 ` H.J. Lu
2020-01-09 10:49 ` Szabolcs Nagy [this message]
2020-02-01 6:14 ` Carlos O'Donell
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://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7648385b-ebd0-efa6-73e8-1a91cfc517f0@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=fweimer@redhat.com \
--cc=hjl.tools@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=nd@arm.com \
/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).