From: Max Filippov <jcmvbkbc@gmail.com>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Initial xtensa/fdpic port review
Date: Thu, 29 Feb 2024 08:25:12 -0800 [thread overview]
Message-ID: <CAMo8BfKQQky7HT-RWZjag5_j3kYURqpf2onzOJWWpkaZwi95Lw@mail.gmail.com> (raw)
In-Reply-To: <20240228183032.GO4163@brightrain.aerifal.cx>
On Wed, Feb 28, 2024 at 10:30 AM Rich Felker <dalias@libc.org> wrote:
> On Wed, Feb 28, 2024 at 09:20:33AM -0800, Max Filippov wrote:
> > > > diff --git a/ldso/dynlink.c b/ldso/dynlink.c
> > > > index ceca3c98..25563af3 100644
> > > > --- a/ldso/dynlink.c
> > > > +++ b/ldso/dynlink.c
> > > > @@ -1420,6 +1420,7 @@ static void reloc_all(struct dso *p)
> > > > if (!DL_FDPIC)
> > > > do_relr_relocs(p, laddr(p, dyn[DT_RELR]), dyn[DT_RELRSZ]);
> > > >
> > > > +#if 0
> > > > if (head != &ldso && p->relro_start != p->relro_end) {
> > > > long ret = __syscall(SYS_mprotect, laddr(p, p->relro_start),
> > > > p->relro_end-p->relro_start, PROT_READ);
> > > > @@ -1429,6 +1430,7 @@ static void reloc_all(struct dso *p)
> > > > if (runtime) longjmp(*rtld_fail, 1);
> > > > }
> > > > }
> > > > +#endif
> > >
> > > Was this breaking something? Relro linking probably should have been
> > > disabled on fdpic, and we ignore ENOSYS anyway for nommu.
> >
> > Yeah, I do some of the testing in linux-user QEMU, it has MMU
> > and mprotect calls actually succeed. Failures were coming from the
> > relocation code, but my impression was that relro should be applied
> > after the relocation completion and it should just work, hence the
> > WIP pile.
>
> Yes, relro is only supposed to be applied after all relocations were
> done.
So I've found two issues with this. First is that loadmap entries generated
by the QEMU (and by the linux kernel AFAICS) are not page-aligned,
but the relro segment addresses fetched by the loader are. Since the
laddr() doesn't check that a translation for the address it was given
was actually found the results are not always correct, mprotect fails
and it all terminates early.
With a workaround for that part in place I see that relro protection is
applied to the executable image before its __fdpic_fixup had a chance
to run, there are rofixups for the .init_array and .fini_array, but they both
are a part of the relro segment.
--
Thanks.
-- Max
next prev parent reply other threads:[~2024-02-29 16:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 23:24 Rich Felker
2024-02-28 0:13 ` Rich Felker
2024-02-28 17:20 ` Max Filippov
2024-02-28 18:30 ` Rich Felker
2024-02-28 18:37 ` Rich Felker
2024-02-28 19:34 ` Max Filippov
2024-02-28 19:41 ` Max Filippov
2024-02-28 20:14 ` Rich Felker
2024-02-28 20:26 ` Rich Felker
2024-02-28 20:37 ` Rich Felker
2024-02-28 21:28 ` Max Filippov
2024-02-29 12:03 ` Max Filippov
2024-02-29 15:35 ` Rich Felker
2024-02-29 16:25 ` Max Filippov [this message]
2024-02-29 18:16 ` Rich Felker
2024-03-19 15:25 ` Max Filippov
2024-03-19 16:08 ` Max Filippov
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=CAMo8BfKQQky7HT-RWZjag5_j3kYURqpf2onzOJWWpkaZwi95Lw@mail.gmail.com \
--to=jcmvbkbc@gmail.com \
--cc=dalias@libc.org \
--cc=musl@lists.openwall.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.
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).