Re: [musl] option to enable eh_frame

[Ariadne Conill <ariadne@dereferenced.org>]

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 <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.)

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