[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 18 Jul 2021 11:16:55 +0300
From: Timo Teras <timo.teras@....fi>
To: Rich Felker <dalias@...c.org>
Cc: Ariadne Conill <ariadne@...eferenced.org>, musl@...ts.openwall.com
Subject: Re: 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 <dalias@...c.org> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
