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.6 required=5.0 tests=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 17033 invoked from network); 18 Jul 2021 08:17:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 18 Jul 2021 08:17:12 -0000 Received: (qmail 19784 invoked by uid 550); 18 Jul 2021 08:17:10 -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 19766 invoked from network); 18 Jul 2021 08:17:09 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=lmsM1C96XQgKqO4lkgFiFlPa7KNjsuoaiT1V1jX1pg4=; b=o+dEvq7MwVF7i22MG4veXYk344kz8OIfgiN+706f3napqQIwozgIhFr2zJQL4BDHra dmTvkMjtVq573J7/OmvJ8TrtlDILJeXawqfchktZqayW15/k04ERAify82ZRWvJc1zzD ybP4d9N1rsy+jfD3IgeSbs4G2fG0jfN5Jm+gvcKanz97iIoeBWYUBRk2g0nqIvVlRnfn ULHsWqKcnA6bbMUB5xFOiaIwr/1kJEKLttRIHe+AGtOXKANykAak0oev7z2jXjkbNzFm FASRz3hVc1kNJIUU3JWqcWKDKS8AOnj+3kSHk7Pjh3SEqNmzSe8Zvi9TXKiW8oE785UF Ibrg== X-Gm-Message-State: AOAM533PWzqsizLzCcSYoMAz5cmRC1i+Cfs/sKgU1hR0KwbK6RXW3XCk uzClzg6xQznKz9M4v8NqagI= X-Google-Smtp-Source: ABdhPJyPBBMeKxreF6rfIaFbXyCkeYn4MDaKWF99tcAUC6AqRLnNiwjZ/Av0Jh8srieyMN4ELKIDIw== X-Received: by 2002:a05:6512:2629:: with SMTP id bt41mr14107479lfb.95.1626596218257; Sun, 18 Jul 2021 01:16:58 -0700 (PDT) Date: Sun, 18 Jul 2021 11:16:55 +0300 From: Timo Teras To: Rich Felker Cc: Ariadne Conill , musl@lists.openwall.com Message-ID: <20210718111655.6ec25889@vostro> In-Reply-To: <20210717004131.GE13220@brightrain.aerifal.cx> References: <20210716121625.38409b91@vostro> <20210716155735.GC13220@brightrain.aerifal.cx> <20210717004131.GE13220@brightrain.aerifal.cx> X-Mailer: Claws Mail 4.0.0 (GTK+ 3.24.28; x86_64-alpine-linux-musl) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [musl] option to enable eh_frame Hi, I want to still clarify few things here. On Fri, 16 Jul 2021 20:41:31 -0400 Rich Felker wrote: > On Fri, Jul 16, 2021 at 05:06:48PM -0500, Ariadne Conill wrote: > > > > On Fri, 16 Jul 2021, Rich Felker wrote: > > > > >You can solve this problem just as well for the things you want to > > >have work by including the (part of) the debug info you want in the > > >main libc.so binary: .debug_frame. Of course I can't stop Alpine > > >from doing it in a different way locally, but I would strongly > > >recommend you do that rather than making a contract that diverges > > >from musl. > > > > The problem is that Alpine users want backtrace(3) to work. You > > This is a very different narrative from the request I received to take > this patch. I'm concerned about that. This was not the driving pattern for me. And is actually sort of unrelated as backtrace(3) can be made work libunwind --enable-debug-frame and .debug_frame. I see this as quite different thing. > Alpine is a security-oriented distribution. Doing introspective > debugging when a crash happens is *inviting* exploitation; the reason > that's the case has been discussed extensively before. Applications > trying to do this should be patched not to do it. I think musl .eh_frame is not big thing on this. Most backtrace() issues would likely be exploitable if the application has .eh_frame and it starts backtracing it's own stack. This is about whether or not to include backtrace() at all in OS. > > I am concerned about the unilateral approach we have taken to enable > > backtrace(3) though, if we are forking the musl ABI, we probably > > will wind up forking the musl API too to add user-requested > > functionality. > > This would be very unfortunate, and would make me actively recommend > against use of Alpine. One of the core values of musl is consensus > process, not attempts to unilaterally force something like this, > especially when it's been done in a way that feels misleading. This is quite different stand from what you communicated on the MR -or at least how I understood it. I got the impression from your comment that we can do whatever we want and you don't care too much, but your preference is to use .debug_frame. I did not understand that you feel so strongly about this that it would affect your recommendation or relationship to us. We all want to work together with you, not against. The fact that I presented more questions and counter-arguments in the MR and not getting responses lead me to think that you don't care. This was a misinterpretation on my side. We have at times carried some patches for long time on musl - usually cherry-picked commits - but at times non-upstreamed ones too, and I think there is still at least one non-upstreamed. Please also understand that me and Ariadne have been talking about the reasons separately as individuals, not on behalf of the Alpine project. And we had not established any scheme to get this done to sneak in unwanted features by misleading. My motivation has been only the debugging side. I know others have other reasons to it too. As explained I have valid technical reasons to want and prefer .eh_frame for debugging purposes, and I for me the "contract" to users is the same regardless of which section we provide. Ariadne went already to revert the change - if she hadn't, I would have done it now. And as said in the other thread, I'm working to do the .debug_frame. But given the reasons, I'd still hope we can discuss the matter of .eh_frame (as default-on or default-off) could be made acceptable as debugging feature by some other changes that still give same "contract" of showing user that it's not there to support unwinding through C-library? E.g. by wiring the most problematic functions to abort on unwind attempt. Timo