From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 12376 invoked from network); 18 Jul 2021 02:23:45 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Jul 2021 02:23:45 -0000 Received: (qmail 3427 invoked by uid 550); 18 Jul 2021 02:23:43 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 3407 invoked from network); 18 Jul 2021 02:23:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dereferenced.org; s=mailbun; t=1626575010; bh=T7AR/qk1ikjWrpGeA0t2O5x4yXR7dJeXQ3tspTt8w1k=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jc2HMdZMg6veNpFa7liLpq9+2w3A0uzu7bQ8cv19bD8BQd0rzNd4Jyb5p9b0hUWdC XVtiFLCpz8jYffQBntUWKNUEFnkqGMzqh2UvzDZsM2jjJKgD8oHeyndAGTSxxNh5oD fkESJ02KoQgg5jMaBbMURdAWUuZDFnGSHedzMBI5elw+sVJkmCx9hQ1SQ01bVHlqf4 wju5kQA8vDHdmCeGEmLl5nA6sp1MmZcvBzQneTihTW4ByTZjg0xG9ZZNECYoo3Nv3l Xy1H/CGZcHvBXp1ZIQPskt0uLOrwHnc4yHHH+dBDjXzmiWdo/Vc7/Y+q1V85gPyDgP PsOkM+7OTM9Aw== Date: Sat, 17 Jul 2021 21:23:29 -0500 (CDT) From: Ariadne Conill To: musl@lists.openwall.com cc: Ariadne Conill , Timo Teras In-Reply-To: <8f47b969-c2a5-54df-5bb6-541fcb1fd5df@dereferenced.org> Message-ID: References: <20210716121625.38409b91@vostro> <20210716155735.GC13220@brightrain.aerifal.cx> <20210717103338.3085f754@vostro> <20210717132543.GG13220@brightrain.aerifal.cx> <20210717184010.246e7895@vostro> <20210717160936.GH13220@brightrain.aerifal.cx> <7aebea1d-b662-75c4-14cb-b614ff1aac9f@dereferenced.org> <20210717235635.GI13220@brightrain.aerifal.cx> <8f47b969-c2a5-54df-5bb6-541fcb1fd5df@dereferenced.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Re: [musl] option to enable eh_frame Hello, On Sat, 17 Jul 2021, Ariadne Conill wrote: > 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 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.) As another side note: this has been reverted in Alpine musl 1.2.2-r5. Let us work together on the musl list to find consensus on a solution, then push that solution out in musl 1.2.2-r6. Ariadne