From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id D4882385480E for ; Wed, 5 May 2021 10:01:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D4882385480E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-237-sbGARdMdPuWkdVsxRoteoQ-1; Wed, 05 May 2021 06:01:08 -0400 X-MC-Unique: sbGARdMdPuWkdVsxRoteoQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A03ED10066E5; Wed, 5 May 2021 10:01:07 +0000 (UTC) Received: from localhost (unknown [10.33.36.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3788A1064276; Wed, 5 May 2021 10:01:07 +0000 (UTC) Date: Wed, 5 May 2021 11:01:06 +0100 From: Jonathan Wakely To: =?iso-8859-1?Q?Fran=E7ois?= Dumont Cc: "libstdc++@gcc.gnu.org" , gcc-patches Subject: Re: [PATCH][_GLIBCXX_DEBUG] libbacktrace integration Message-ID: <20210505100106.GT3008@redhat.com> References: <20210503210623.GG3008@redhat.com> <48846543-8644-d37d-0339-3b999147a8bc@gmail.com> MIME-Version: 1.0 In-Reply-To: <48846543-8644-d37d-0339-3b999147a8bc@gmail.com> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 May 2021 10:01:16 -0000 On 04/05/21 08:03 +0200, François Dumont wrote: >On 03/05/21 11:06 pm, Jonathan Wakely wrote: >>On 03/05/21 22:17 +0200, François Dumont via Libstdc++ wrote: >>>Is it too early to consider this patch ? Or just lack of time ? >> >>I haven't had time to review it yet, but my general feeling hasn't >>changed. I still don't like the idea of executing additional code >>after undefined behaviour is detected. I've been convinced by glibc >>folk that every bit of code run when the program state is corrupt >>increases the risk that it can be exploited by an attacker. >> >> >> >Ok, I must have miss (or forgot) this feedback. See https://gcc.gnu.org/pipermail/libstdc++/2018-December/048061.html >Well, isn't it the current situation of the whole _GLIBCXX_DEBUG mode ? Yes, but adding more code makes it worse. >For me _GLIBCXX_DEBUG mode purpose is to detect UB situation and to >assert _before_ any UB code is run. Yes, it stops running the user code, but then runs its own code to format the message to show to the user. The more code that runs when the program is in an inconsistent/undefined state, the more likely it is that some of that code can be exploited to do something bad. >Moreover it is optional. This is a feature to use when _GLIBCXX_DEBUG >is telling you that you have a problem in your code but you just >cannot find where it is called. Which you can do with a debugger. When debug mode calls abort() it will stop the program in a debugger, or produce a core file that can be examined in a debugger. The stacktrace is a convenience, not providing anything that couldn't be done already. Anyway, I'll review the patch...