From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104917 invoked by alias); 30 Nov 2018 14:57:38 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 104899 invoked by uid 89); 30 Nov 2018 14:57:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=matz, Matz, U*matz X-HELO: sam.airs.com Received: from sam.airs.com (HELO sam.airs.com) (64.13.145.90) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Nov 2018 14:57:35 +0000 Received: (qmail 6880 invoked by uid 10); 30 Nov 2018 14:57:33 -0000 Received: (qmail 10635 invoked by uid 500); 30 Nov 2018 14:57:28 -0000 Mail-Followup-To: nickc@redhat.com, jakub@redhat.com, gcc-patches@gcc.gnu.org, binutils@sourceware.org, sgayou@redhat.com, jason@redhat.com, matz@suse.de From: Ian Lance Taylor To: Michael Matz Cc: Nick Clifton , Jakub Jelinek , gcc-patches@gcc.gnu.org, binutils@sourceware.org, sgayou@redhat.com, jason@redhat.com Subject: Re: RFA/RFC: Add stack recursion limit to libiberty's demangler References: <87muprdko7.fsf@redhat.com> <20181130084211.GX12380@tucnak> <173817ca-0aa0-e1a2-6725-37e079ead545@redhat.com> Date: Fri, 30 Nov 2018 14:57:00 -0000 In-Reply-To: (Michael Matz's message of "Fri, 30 Nov 2018 13:46:17 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-11/txt/msg02581.txt.bz2 Michael Matz writes: > On Fri, 30 Nov 2018, Nick Clifton wrote: > >> Not without modifying the current demangling interface. The problem is= =20 >> that the context structure is created for each invocation of a=20 >> demangling function (from outside the library), and no state is=20 >> preserved across demangling calls. Thus in order to have a recursion=20 >> limit which is configurable by the caller, you either need to have a=20 >> global variable or else extend the demangling interface to include a=20 >> recursion limit parameter. >>=20 >> I did consider just having a fixed limit, that the user cannot change,=20 >> but I thought that this might be rejected by reviewers. (On the grounds= =20 >> that different limits are appropriate to different execution=20 >> environments). Note - enabling or disabling the recursion limit is=20 >> controlled by a separate feature of the proposed patch, ie the new=20 >> DMGL_RECURSE_LIMIT flag in the options field of the cplus_demangleXXX()= =20 >> functions. But there is not enough room in the options field to also=20 >> include a recursion limit value. > > Or we decide to not ignore this part of the GNU coding standard ... > >> 4.2 Writing Robust Programs >>=20=20 >> Avoid arbitrary limits on the length or number of any data structure,=20 >> including file names, lines, files, and symbols, by allocating all data= =20 >> structures dynamically. In most Unix utilities, =E2=80=9Clong lines are = silently=20 >> truncated=E2=80=9D. This is not acceptable in a GNU utility. > > ... just because script kiddies do mindless fuzzing work. I realize that= =20 > you didn't implement a fixed limit, but IMHO it's bordering with that. That section is "Writing Robust Programs." Robustness guarantees have to be different for utilities and servers. A robust server doesn't crash because of arbitrary user input, but there are servers that demangle names that are provided by the user. So we need two modes for the demangler: one that takes anything and sometimes crashes, for utilities like c++filt, and one that doesn't crash, for servers. And it seems like that is what Nick is suggesting. Ian