unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>
To: Siddhesh Poyarekar <siddhesh@sourceware.org>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH v2] ld.so: Handle read-only dynamic section gracefully [BZ #28340]
Date: Wed, 15 Sep 2021 14:18:48 +0200	[thread overview]
Message-ID: <87zgserpzr.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <fa9e27d5-24c6-9c40-1d6f-cbbe3e6c465b@sourceware.org> (Siddhesh Poyarekar's message of "Wed, 15 Sep 2021 17:40:41 +0530")

* Siddhesh Poyarekar:

> On 9/15/21 4:10 PM, Florian Weimer wrote:
>> As far as I can tell, this does not check whether the DYNAMIC segment is
>> actually covered by a read-write LOAD segment.  I wonder how much value
>> this imperfect check has.
>
> I reckon there's less value in trying to make this corner case work; I
> can't think of a reason for someone (outside of the VDSO use case) to
> do this on purpose.  Read-only DYNAMIC segments in ET_DYN objects
> shouldn't be a supported use case.

Sure, but the corresponding LOAD segment is read-only as well, that's
what actually matters.

>> Would it make more sense to fix the kernel linker script that generates
>> those bogus vDSO reference files?
>
> The vdso is not meant to be relocated, which is why all segments in it
> are read-only.  setup_vdso only pretends to relocate it in the
> interest of internal consistency in ld.so.

And they do not want multiple LOAD segments because it can fit all on
the same page.  We would end up with an RWX segment if we made this
single LOAD segment writable, which is probably even more confusing.

So I guess the status quo is probably best.

Maybe someone else can comment on the additional detection.  In the
past, we said that crashes on corrupt ELF files weren't something we
cared about, but I increasingly see th value of good diagnostics for
common special cases.

(See also the discussion about DSOs without entry points.)

Thanks,
Florian


  reply	other threads:[~2021-09-15 12:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15  1:36 [PATCH v2] ld.so: Handle read-only dynamic section gracefully [BZ #28340] Siddhesh Poyarekar via Libc-alpha
2021-09-15 10:40 ` Florian Weimer via Libc-alpha
2021-09-15 12:10   ` Siddhesh Poyarekar via Libc-alpha
2021-09-15 12:18     ` Florian Weimer via Libc-alpha [this message]
2021-09-15 13:04       ` Siddhesh Poyarekar via Libc-alpha

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=87zgserpzr.fsf@oldenburg.str.redhat.com \
    --to=libc-alpha@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=siddhesh@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).