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 [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 8C0833858D37 for ; Mon, 20 Nov 2023 21:56:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8C0833858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8C0833858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700517399; cv=none; b=QlNz9zbKQT9zOS0IoHm3XSo9Qh/vV8/mrqMi9yYxbCHxiwnZbAFoknISOh+Z0JE99HRzQLMJRykn+B/yRUBGiS1rtzRzqdzze7+fcRG+cnaqAsI02FsVo4tLM2ISiCLsgDYMCsvehLBLqz8awogW/xGpBFrehChBWff0VMT3nFg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700517399; c=relaxed/simple; bh=6Jyq1Sf4zeUMxDVYApEEjNxGgndEcvrKyxL55qmTYCA=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=BzZLSKXWj3kRn01LNCx7I2lAPzl2ZQ1fBiQwRYkZ2WYlildlsK6mbJo+JdzNzb5hUz/SIMOoOGydrQywsbZEvC1Q6xb8WWFU9SAgV1MoQ6ysxl09EcUCn+5Z9AAhuwuz+/UtaGsbKiyvIJ0L2E6giCv9HYBgkQhNwn8nmFQoiUE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1700517396; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=RumnDvr1ug4ha5oM0q5whjtBE4AWUXhIrJ9BwAVlRw4=; b=UY9WN9PqcLsHIcDjC0cCokGccwJNQRYlnqVxfjMo10qwTLUX8wt6bSmyoLeAcEPqiIf7kp Y4XDOcZCw7E3FI7yKrDCvqs9D/Oxqxu4K1Cxmy7gGfJ8uyB8lP+OZaU57OlBrTwcjRfZpO EjsTapaqvR+q7VMGu4UsRzSeOAYGNcY= Received: from mail-ed1-f70.google.com (mail-ed1-f70.google.com [209.85.208.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-237-wEZE7Zl2NrCsrN2kME-K5w-1; Mon, 20 Nov 2023 16:56:34 -0500 X-MC-Unique: wEZE7Zl2NrCsrN2kME-K5w-1 Received: by mail-ed1-f70.google.com with SMTP id 4fb4d7f45d1cf-548b55f4b6aso264889a12.1 for ; Mon, 20 Nov 2023 13:56:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700517393; x=1701122193; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RumnDvr1ug4ha5oM0q5whjtBE4AWUXhIrJ9BwAVlRw4=; b=HKVupzThRdPRwfoNMQvzAtMTnLSGt9rFmz2YKOFVjdp20Fo5Hl9Xz9iiNpkWrjijca UghIQKsnrs7N6rJXG+IcOHaVHXFvx1RQQKI1YYyrETBFYcV6GUXJQVJzfNUXD3JGhhvv E/b2u9MfhlRPdq8Awm9s39lmGFW94z+ZXKJyzgdFaXTPqKGGoAKrLR8bd6PV01SDuHsJ DDgQ5tOzCVci4AdjSLLFG4AmMhiUWnmVUTsBYjsC2mfH/IApgOV3LZydwFVWKhZrJmVO AVem5l6TEssi6CmNUPDcepP42pS/iVgL7HiHOlM4BjnlQaU+tZdnn5rioZBCw89WZhC/ BZMw== X-Gm-Message-State: AOJu0YxDbG6oz/MmWSZKcrSM6QOXqninD9rLLy41QWZOg8/buevBtc7T Dty3zxwd2qzM+FbeYx0ZaLPIm1+X1AIPK9LXDc/7aS17O+yXVJHqPDsA8LAdEW4/FHVlwqqbhgQ 1Z7aPOPvtJ/nwwooWekW38/IA+h952nh74B5BL7M= X-Received: by 2002:a05:6402:e8d:b0:548:b2b1:fe9f with SMTP id h13-20020a0564020e8d00b00548b2b1fe9fmr4057765eda.4.1700517393186; Mon, 20 Nov 2023 13:56:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IF2nTP/B1zC/e7SF4PpA6lyIDtYmq1EMFD2Ieg5CMa5Os08jzDpfBPR/6QFSqCV/1wdgbY02WDDVUBOHNqK8Z8= X-Received: by 2002:a05:6402:e8d:b0:548:b2b1:fe9f with SMTP id h13-20020a0564020e8d00b00548b2b1fe9fmr4057754eda.4.1700517392928; Mon, 20 Nov 2023 13:56:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeff Johnston Date: Mon, 20 Nov 2023 16:56:21 -0500 Message-ID: Subject: Re: Usage of __assert_func in standard library To: newlib@sourceware.org, Jeff Johnston X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="00000000000023de86060a9c8f78" X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --00000000000023de86060a9c8f78 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 20, 2023 at 5:34=E2=80=AFAM Corinna Vinschen wrote: > On Nov 18 19:13, Alex Tarasov wrote: > > Dear developers of Newlib, > > > > I think we have a bit of an issue concerning usage of *__assert_func > *function > > in the current version of the standard library. > > [...] > > ld.exe: > PathToCompiler/../lib/gcc/arm-none-eabi/13.2.1/thumb/v7e-m+fp/hard\libg.a= (libc_a-closer.o): > > in function `_close_r': > > closer.c:(.text._close_r+0xc): undefined reference to `_close' > > [...] > > The analysis of cross reference table in the .map file showed me the > source > > of these errors. Somehow, in the newer toolchain functions from the > > standard library (*strtod* in my case) call *"__assert_func"* which in > turn > > lead to various system calls. I downloaded the latest Newlib version on > the > > "main" branch and saw this code in the *newlib/libc/stdlib/mprec.h* fil= e: > > > > #define eBalloc(__reent_ptr, __len) ({ \ > > void *__ptr =3D Balloc(__reent_ptr, __len); \ > > if (__ptr =3D=3D NULL) \ > > __assert_func(__FILE__, __LINE__, (char *)0, "Balloc succeeded"); \ > > __ptr; \ > > }) > > > > According to *git log* this *eBalloc* macro was introduced in commit > > with f88aece242178ff0c187d56e34a79645fbc44a23 > > hash on October 4th 2019. This leads to several functions in the standa= rd > > library calling *__assert_func* inside them. Standard definition of this > > function in *newlib/libc/stdlib/assert.c* calls *abort* and *fiprintf* > > functions > > which in turn drag a lot of system functions (see error log that I > > mentioned above). > > > > This leads to several issues: > > > > - If I want to use some functions from the standard library (like > > *strtod*) but I don't want any system calls, I need to redefine > > *__assert_func* in my project. I have to do it even if I don't use > > assert's anywhere in my own code. > > - There is a project where I use and my own > > implementation of *__assert_func. > > *I expect that when I build my project with NDEBUG macro defined > > (release configuration), I would not see any calls to that function. > That > > is not the case if any function from Newlib's standard library that > uses > > *eBalloc* macro gets linked. > > > > I think this behaviour is too implicit and needs to be fixed. I suggest > > removing *__assert_func* from *eBalloc* macro or making some other > changes > > to Newlib that will get rid of the mentioned issues. > > Yeah, that looks a tad too aggressive. > > I see only ~20 calls to eBalloc in newlib. Maybe somebody can take > a stab at it and convert the calls to Balloc plus error checking? > > However, the parent functions of the functions calling eBalloc > potentially don't check error conditions either, so this might be indeed > a bit more work than a quick count of the eBalloc calls indicates... > > Jeff? Any idea how to go forward? > > > The eBalloc macro calling __assert_func is a fix for a CVE whereby a write to 0 could occur silently within newlib. It is intentional that it aborts and doesn't disable with NDEBUG. As mentioned by Corinna, the call chain of eBalloc isn't checking results and it was why we chose to use the assert to handle the CVE. That said, one issue for you seems to be the fiprintf() call. A possible solution is to have a macro which disables the fiprintf() or you can choose to override the fiprintf() method yourself. -- Jeff J. Corinna > > --00000000000023de86060a9c8f78--