mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Ariadne Conill <ariadne@dereferenced.org>
To: musl@lists.openwall.com
Cc: Ariadne Conill <ariadne@dereferenced.org>,
	Timo Teras <timo.teras@iki.fi>
Subject: Re: [musl] option to enable eh_frame
Date: Sat, 17 Jul 2021 20:40:52 -0500 (CDT)	[thread overview]
Message-ID: <8f47b969-c2a5-54df-5bb6-541fcb1fd5df@dereferenced.org> (raw)
In-Reply-To: <20210717235635.GI13220@brightrain.aerifal.cx>

Hello,

On Sat, 17 Jul 2021, Rich Felker wrote:

> On Sat, Jul 17, 2021 at 02:52:48PM -0500, Ariadne Conill wrote:
>> Hello,
>>
>> On Sat, 17 Jul 2021, Rich Felker wrote:
>>
>>> On Sat, Jul 17, 2021 at 06:40:10PM +0300, Timo Teras wrote:
>>>> On Sat, 17 Jul 2021 09:25:44 -0400
>>>> Rich Felker <dalias@libc.org> wrote:
>>>>
>>>>>> Please add in any reasons I may have missed. I would like to have
>>>>>> your complete list of reasons why to remove .eh_frame. So far it
>>>>>> has been coming out in pieces. I'd like constructive discussion if
>>>>>> some of these items could be implemented stronger in other means
>>>>>> than removing ..eh_frame.
>>>>>
>>>>> You're coming at it from the wrong direction. For new, nonstandard
>>>>> functionality requests, musl has a well established process of
>>>>> criteria for inclusion and exclusion, based on invasiveness (this is
>>>>> not just a matter of code change size, but of constraints it imposes),
>>>>> size, how often the lack of the functionality impacts portable or
>>>>> important FOSS programs users want to run on musl, and whether there
>>>>> are other ways the applications that want it could achieve what they
>>>>> want. In this case, all of those criteria indicate against doing it.
>>>>
>>>> Just to be on record, musl used to include .eh_frame until 2012 and
>>>> commit b439c051c7eee4eb4b93fc382f993aa6305ce530 or musl 0.9.5. So back
>>>> then existing "contract" was broken. If this discussion was done then,
>>>> this would be the other angle: why to break something that is working.
>>>
>>> You're still missing the point. Having it there when it just happened
>>> to be (and likewise on archs where there's some weird non-DWARF unwind
>>> table that we haven't opted out of) is not a contract to support it;
>>> it's an artifact of the toolchain. *Explicitly making a change for the
>>> purpose of adding it*, with no other plausible purpose, is such a
>>> contract.
>>>
>>> By the way, I think you're slightly wrong on the history. Prior to
>>> that commit, unwind info was already omitted unless debugging was
>>> enabled; this was because I was not aware that GCC would emit it in
>>> .debug_frame if needed.
>>>
>>>>>> But fundamentally I think if we ship .debug_frame, all people
>>>>>> wanting do backtrace() and the silly stuff, will just enable
>>>>>> .debug_frame support in their code and still do the silly stuff in
>>>>>> worse way, than if .eh_frame was enabled. Since technically they
>>>>>> are the same, even if the intended use case is different. As seen
>>>>>> libunwind does have --enable-debug-frame.
>>>>>
>>>>> They might, but then they're clearly using a debugging interface that
>>>>> only works when debug files are available (or if you include this in
>>>>> main libc.so, when libc.so is not stripped).
>>>>
>>>> But how is this different from the "contract" viewpoint?
>>>>
>>>> You are agreeable to have .debug_frame by default in the main DSO. And
>>>> if we make musl have .debug_frame, and build libunwind with
>>>> --enable-debug-frame, the user gets quite similar "contract" experience
>>>> as with .eh_frame. But just worse than having .eh_frame, because for the
>>>> unwinder to be able to use .debug_frame it needs to do more silly
>>>> things.
>>>
>>> It needs to do "silly" things which explicitly break if debug info is
>>> stripped, making it clear that this is not functionality of the libc
>>> but (strippable) debugging metadata that can't be relied on.
>>>
>>>> Users don't care if it's .debug_frame or .eh_frame as long as the higher
>>>> level functionality works. And it gives same "de facto contract"
>>>> experience.
>>>>
>>>> Sorry for being "stupid" here, but I'm trying to understand your
>>>> viewpoint. So far it's sounding like:
>>>> - same things can be achieved by doing X or Y
>>>> - you argue X is evil and breaking contract, but Y is ok
>>>> - on system/user level the "contract" or "experience" is same
>>>>   regardless of doing X or Y
>>>>
>>>> Basically I'm trying to understand why do you consider .eh_frame so
>>>> much more important "contract" than .debug_frame?
>>>
>>> Because .eh_frame is part of the loaded program segment that ELF
>>> semantics define as being available to the runtime (which is what
>>> makes it non-strippable), and .debug_frame is not.
>>
>> In this case, wouldn't we want to emit .eh_frame for libc.so?  If
>> not, why?  If it's supposed to be available, that seems like a more
>> compelling argument for including it, not excluding it.
>
> I'm not sure who "we" is here and what perspective it's supposed to be
> from.

"We" being in the general sense: if there are tools expecting .eh_frame to 
be present, as part of the ELF specification, then would it not be 
desirable to have it?

> I thought I'd explained the difference. Having something as part
> of the loadable program segment means it's always available, not
> strippable or missing if debug packages are not installed. Having it
> be in a non-load section (not segment) means it's metadata about the
> binary for tooling (e.g. debugger) usage, to be accessed by reading
> the file(s) not runtime data structures mapped in memory. From my
> perspective, the reason for it to be the latter is to reflect that
> this is debug info available only in a debug environment, not part of
> musl's runtime interfaces.

This is not Alpine's position per se: we would like basic debugging to 
work in any environment.  The splitting of debuginfo to -dbg packages is 
intended to reduce image size only.  That decision is not considered by us 
to be a security-impacting decision, even if that is a side effect (and I 
personally consider it not to be a security feature at all, as an attacker 
can simply recreate their attack in a debug environment).

Ultimately, the question is one of how to enable basic debugging features 
without having debuginfo present.  Or in other words, we would like basic 
debugging information, but not necessarily DWARF sections as part of the 
runtime package.

In my opinion -- the solution is to modify the strip functionality in 
abuild to include .debug_frame, and then adjust our libunwind and other 
programs to make use of .debug_frame.  This gives us the basic debugging 
functionality, while also complying with the wishes of upstream musl.

(As a side note, I really do not want to get into a position where Alpine 
is shipping a defacto fork of musl, we already did this with uClibc and it 
created more problems than solutions.  Working with upstream implies a 
social contract that we will abide by upstream's wishes whenever 
reasonable, and I do not see any reason why preferring .debug_frame over 
.eh_frame to solve this problem is an unreasonable request.)

Ariadne

  reply	other threads:[~2021-07-18  1:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-16  9:16 Timo Teras
2021-07-16 15:57 ` Rich Felker
2021-07-16 22:06   ` Ariadne Conill
2021-07-17  0:41     ` Rich Felker
2021-07-17  1:08       ` Ariadne Conill
2021-07-17  1:10         ` Érico Nogueira
2021-07-17  7:24         ` Laurent Bercot
2021-07-18  8:16       ` Timo Teras
2021-07-17  7:33   ` Timo Teras
2021-07-17 10:38     ` Timo Teras
2021-07-17 13:25     ` Rich Felker
2021-07-17 15:40       ` Timo Teras
2021-07-17 16:09         ` Rich Felker
2021-07-17 19:52           ` Ariadne Conill
2021-07-17 23:56             ` Rich Felker
2021-07-18  1:40               ` Ariadne Conill [this message]
2021-07-18  2:23                 ` Ariadne Conill
2021-07-18  6:09               ` Timo Teras
2021-07-18  7:20                 ` Timo Teras
2021-07-24 23:45                   ` Fangrui Song
2022-04-17 19:50     ` Fangrui Song

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=8f47b969-c2a5-54df-5bb6-541fcb1fd5df@dereferenced.org \
    --to=ariadne@dereferenced.org \
    --cc=musl@lists.openwall.com \
    --cc=timo.teras@iki.fi \
    /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).