public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [PATCH 2/2] elf: Detect PT_LOAD segments that extend beyond EOF and refuse loading
Date: Fri, 05 Nov 2021 15:31:54 +0100	[thread overview]
Message-ID: <87r1buu10l.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAMe9rOryQzYpYyty4+3fCoJirS8a5ig88UT4LJAA-35nuKh5rA@mail.gmail.com> (H. J. Lu's message of "Fri, 5 Nov 2021 07:26:47 -0700")

* H. J. Lu:

> On Fri, Nov 5, 2021 at 7:01 AM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>> We occasionally see elf/tst-debug1 failing with a SIGBUS error
>> with some toolchain versions (recently on aarch64 only).  This test
>> tries to emulate loading separated debuginfo, but whether the test
>> object triggers the crash depends on many factors.  Accurately
>> rejected separated debuginfo in dlopen probably needs ELF markup,
>> at least if this is to be done efficiently using program headers
>> only.  But this change still improves user experience slightly.
>> We already obtain the file size from the kernel in most cases,
>> so no additional system call is added.
>
> Under what conditions does the test trigger SIGBUS?

If the separated debuginfo object is shorter than the original object,
and the dynamic loader tries to access something in the load segment
that extends beyond the end of the file.  I suspect triggering the
actual crash depends on placement of the dynamic segments and of
relocation targets.

> Does your patch makes the test pass or just turn SIGBUS into a
> different failure?

It makes the test pass because the dlopen reports the new error for this
particular error condition.  Of course, the test can still crash due to
invalid data in the dynamic segment if we are unlucky.

Thanks,
Florian


  reply	other threads:[~2021-11-05 14:32 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05 13:59 [PATCH 0/2] Avoid some crashes when loading separate debuginfo Florian Weimer
2021-11-05 13:59 ` [PATCH 1/2] Use sysdeps/posix/dl-fileid.h as the generic and only implementation Florian Weimer
2021-11-08 15:54   ` H.J. Lu
2021-11-05 13:59 ` [PATCH 2/2] elf: Detect PT_LOAD segments that extend beyond EOF and refuse loading Florian Weimer
2021-11-05 14:04   ` H.J. Lu
2021-11-05 14:07     ` Florian Weimer
2021-11-05 14:26   ` H.J. Lu
2021-11-05 14:31     ` Florian Weimer [this message]
2021-11-05 14:37       ` H.J. Lu
2021-11-05 14:41         ` Florian Weimer
2021-11-05 15:03           ` H.J. Lu
2021-11-05 15:50             ` Florian Weimer
2021-11-05 14:30   ` Adhemerval Zanella
2021-11-05 14:35     ` Florian Weimer

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=87r1buu10l.fsf@oldenburg.str.redhat.com \
    --to=fweimer@redhat.com \
    --cc=hjl.tools@gmail.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).