From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from crane.ash.relay.mailchannels.net (crane.ash.relay.mailchannels.net [23.83.222.43]) by sourceware.org (Postfix) with ESMTPS id 381833858D35 for ; Tue, 4 Jul 2023 16:04:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 381833858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6DBFB2C0FA0; Tue, 4 Jul 2023 16:04:09 +0000 (UTC) Received: from pdx1-sub0-mail-a286.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 262DD2C0EBD; Tue, 4 Jul 2023 16:04:08 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1688486648; a=rsa-sha256; cv=none; b=uF8zksIXifLeB0JoC9f0ubEVM3aDte5rU8QxWEFLwg6ewsZXOxi5VwNqQikK7dQMwypc+b a7Uyjh8EObBaw3xwsN9xMnmKF0W8w+2rSbVMJKShfPsieL/6xOzRBG0+QFiq/H/we4q/Hj uVwF6sjEdcDL9f9wjZQUib3TNABD14pFk258zJXXMe5kDop7EBEeXAkfsYBqEYYqBaV4n/ Ru1j+29sRlEYYW2/wSu+mjv8bN7Er1HffIdD9xc+jhrClEEpbJzMJuWMGGUIZQrRXCeSS3 aHoiexXZ+3F3kb8qgGqVgMWpV0DClArypHUBd8oCRSpaIFLIySDPTfJhRCSrHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1688486648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=4aaoAqqKZyCHSX8P+Svs+ishcnYUzqx5RASbV8RUnVY=; b=9eFVfsYYjSYIi2eFYCRtuqMk6R+saWyb0LhiAumbRO7+E+nPf0I12FSCQAMEYv7U5unPSb 7Ygf0BkEhtDh/gQISeFZ0ioG2CHav99E60dQGatSSU8XdI/rcJAztn2+0w8Y+/G8N9f+lg 957T8UdTKi/AatZTMz3C0U/QT2dlLtYmVhS6YDfubpAhJk1NhH0jY1EN9Jsfpzd+WJzgZO wXr6IsJdNP0TjFdSHYvcgHCmXhq7tqjsWaW9m8cVoMiI/oJ+Tue7TtvZmOfhZYze1VXkg5 X4SyfG6YpYRRGR7wKXJe0X5j9njestBHcgFGTK06s6sE/TG6JBA319+AuSCw4Q== ARC-Authentication-Results: i=1; rspamd-7ccd4b867f-q26mn; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Supply-Continue: 5a8dc73d7bb2b8ae_1688486649342_4052095699 X-MC-Loop-Signature: 1688486649342:2284457803 X-MC-Ingress-Time: 1688486649342 Received: from pdx1-sub0-mail-a286.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.115.231.140 (trex/6.9.1); Tue, 04 Jul 2023 16:04:09 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-09-174-91-45-44.dsl.bell.ca [174.91.45.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a286.dreamhost.com (Postfix) with ESMTPSA id 4QwSK34yH3zTP; Tue, 4 Jul 2023 09:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1688486648; bh=4aaoAqqKZyCHSX8P+Svs+ishcnYUzqx5RASbV8RUnVY=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=xXSA8TbbAOa1m6adcjWVXArdU9w8r2SD4tsoeeqZjCpkkTw+l2YRtuC90Xkb20Tyq jEwND0x8m72M6s41QO+YRR8KB9Ym9g9ozEIYfMCzJfgPqo2NUvYb16Ob4KckVLCTgB OmRJVTWrOleFnR5GwiP2XXip9ZJp/Um/zJk1nqiw5c4pPv2BJYeTRcLaRMyD4Uk2uf FjdEVAVFItG1Wg9dj4440z26OmKCy3uh9RIfvIGKUIwJkoauV0noCkKqX0ShjyFtbd W8hsA5K1MD/p6+Grrc4+Gmbs1+T3wn2I4+he7wLzR01g0hldx/iPyqeTzNDe097wM7 iePXFgVgghUEQ== Message-ID: <782060ba-5277-8f91-a89f-40c1d87f5365@gotplt.org> Date: Tue, 4 Jul 2023 12:04:01 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v3 02/16] Exclude routines from fortification Content-Language: en-US To: Frederic Berat Cc: libc-alpha@sourceware.org References: <20230628084246.778302-1-fberat@redhat.com> <20230628084246.778302-3-fberat@redhat.com> <1b46ffc4-5d65-faeb-96f0-c0828dc89cfb@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3037.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,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: On 2023-07-03 11:16, Frederic Berat wrote: > > > On Fri, Jun 30, 2023 at 4:55 PM Siddhesh Poyarekar > wrote: > > On 2023-06-28 04:42, Frédéric Bérat wrote: > > Since the _FORTIFY_SOURCE feature uses some routines of Glibc, > they need to > > be excluded from the fortification. > > > > On top of that: > >   - some tests explicitly verify that some level of fortification > works > >     appropriately, we therefore shouldn't modify the level set > for them. > >   - some objects need to be build with optimization disabled, which > >     prevents _FORTIFY_SOURCE to be used for them. > > > > Assembler files that implement architecture specific versions of the > > fortified routines were not excluded from _FORTIFY_SOURCE as > there is no > > C header included that would impact their behavior. > > --- > >   debug/Makefile                              | 12 +-- > >   io/Makefile                                 | 16 ++++ > >   libio/Makefile                              | 21 +++++- > >   login/Makefile                              |  6 ++ > >   misc/Makefile                               |  7 ++ > >   posix/Makefile                              | 11 +++ > >   rt/Makefile                                 |  5 ++ > >   setjmp/Makefile                             |  9 +++ > >   socket/Makefile                             |  6 ++ > >   stdio-common/Makefile                       | 15 +++- > >   stdlib/Makefile                             |  7 ++ > >   string/Makefile                             | 17 +++++ > >   sysdeps/ieee754/ldbl-128ibm-compat/Makefile | 81 > +++++++++++++++++---- > >   sysdeps/ieee754/ldbl-opt/Makefile           | 29 ++++++++ > >   sysdeps/pthread/Makefile                    |  4 + > >   sysdeps/unix/sysv/linux/Makefile            |  3 + > >   wcsmbs/Makefile                             | 23 +++++- > >   17 files changed, 247 insertions(+), 25 deletions(-) > > > > diff --git a/debug/Makefile b/debug/Makefile > > index 9d658e3002..434e52f780 100644 > > --- a/debug/Makefile > > +++ b/debug/Makefile > > @@ -171,13 +171,13 @@ CFLAGS-recvfrom_chk.c += -fexceptions > -fasynchronous-unwind-tables > >   # set up for us, so keep the CFLAGS/CPPFLAGS split logical as > the order is: > >   # > >   CFLAGS-tst-longjmp_chk.c += -fexceptions > -fasynchronous-unwind-tables > > -CPPFLAGS-tst-longjmp_chk.c += -D_FORTIFY_SOURCE=1 > > +CPPFLAGS-tst-longjmp_chk.c += > $(no-fortify-source),-D_FORTIFY_SOURCE=1 > >   CFLAGS-tst-longjmp_chk2.c += -fexceptions > -fasynchronous-unwind-tables > > -CPPFLAGS-tst-longjmp_chk2.c += -D_FORTIFY_SOURCE=1 > > +CPPFLAGS-tst-longjmp_chk2.c += > $(no-fortify-source),-D_FORTIFY_SOURCE=1 > >   CFLAGS-tst-longjmp_chk3.c += -fexceptions > -fasynchronous-unwind-tables > > -CPPFLAGS-tst-longjmp_chk3.c += -D_FORTIFY_SOURCE=1 > > -CPPFLAGS-tst-realpath-chk.c += -D_FORTIFY_SOURCE=2 > > -CPPFLAGS-tst-chk-cancel.c += -D_FORTIFY_SOURCE=2 > > +CPPFLAGS-tst-longjmp_chk3.c += > $(no-fortify-source),-D_FORTIFY_SOURCE=1 > > +CPPFLAGS-tst-realpath-chk.c += > $(no-fortify-source),-D_FORTIFY_SOURCE=2 > > +CPPFLAGS-tst-chk-cancel.c += > $(no-fortify-source),-D_FORTIFY_SOURCE=2 > > > >   # _FORTIFY_SOURCE tests. > >   # Auto-generate tests for _FORTIFY_SOURCE for different levels, > compilers and > > @@ -215,7 +215,7 @@ src-chk-nongnu = \#undef _GNU_SOURCE > >   # cannot be disabled via pragmas, so require -Wno-error to be used. > >   define gen-chk-test > >   tests-$(1)-$(4)-chk += tst-fortify-$(1)-$(2)-$(3)-$(4) > > -CFLAGS-tst-fortify-$(1)-$(2)-$(3)-$(4).$(1) += > -D_FORTIFY_SOURCE=$(3) -Wno-format \ > > +CFLAGS-tst-fortify-$(1)-$(2)-$(3)-$(4).$(1) += > $(no-fortify-source),-D_FORTIFY_SOURCE=$(3) -Wno-format \ > > >  -Wno-deprecated-declarations \ > >                                         -Wno-error > >   $(eval $(call cflags-$(2),$(1),$(3),$(4))) > > diff --git a/io/Makefile b/io/Makefile > > index d573064ecc..6ccc0e8691 100644 > > --- a/io/Makefile > > +++ b/io/Makefile > > @@ -149,6 +149,22 @@ routines := \ > >     write \ > >     # routines > > > > +# Exclude fortified routines from being built with _FORTIFY_SOURCE > > +routines_no_fortify += \ > > +  getcwd \ > > +  getwd \ > > +  open \ > > +  open64 \ > > +  openat \ > > +  openat64 \ > > +  poll \ > > +  ppoll \ > > +  read \ > > +  readlink \ > > +  readlinkat \ > > +  ttyname_r \ > > +  # routines_no_fortify > > + > >   others := \ > >    pwd \ > >    # others > > diff --git a/libio/Makefile b/libio/Makefile > > index 2877fec484..f5c487d9f5 100644 > > --- a/libio/Makefile > > +++ b/libio/Makefile > > @@ -53,6 +53,21 @@ routines   := >                           \ > > > >   gen-as-const-headers += libio-macros.sym > > > > +# Exclude fortified routines from being built with _FORTIFY_SOURCE > > +routines_no_fortify += \ > > +  fwprintf \ > > +  iofgets \ > > +  iofgets_u \ > > +  iofgetws \ > > +  iofgetws_u \ > > +  swprintf \ > > +  vasprintf \ > > +  vsnprintf \ > > +  vswprintf \ > > +  vwprintf \ > > +  wprintf \ > > +  # routines_no_fortify > > + > >   tests = tst_swprintf tst_wprintf tst_swscanf tst_wscanf > tst_getwc tst_putwc   \ > >       tst_wprintf2 tst-widetext test-fmemopen tst-ext tst-ext2 \ > >       tst-fgetws tst-ungetwc1 tst-ungetwc2 tst-swscanf > tst-sscanf           \ > > @@ -165,11 +180,15 @@ CFLAGS-iofgets_u.c += > $(config-cflags-wno-ignored-attributes) > >   CFLAGS-iofputs_u.c += $(config-cflags-wno-ignored-attributes) > >   # XXX Do we need filedoalloc and wfiledoalloc?  Others? > > > > +# Prevent fortification as these are built with -O0 > > +CFLAGS-tst-bz24051.c += $(no-fortify-source) > > +CFLAGS-tst-bz24153.c += $(no-fortify-source) > > + > >   CFLAGS-tst_putwc.c += -DOBJPFX=\"$(objpfx)\" > > > >   # These test cases intentionally use overlapping arguments > >   CFLAGS-tst-sprintf-ub.c += -Wno-restrict > > This should also be built without fortification because the test > specifically tries to validate the sprintf entry point; the > __sprintf_chk entry point ought to get checked by the > tst-sprintf-chk-ub.c test. > > In fact, I wonder if *all* tests should be built without fortification > by default regardless of whether glibc is built with fortification.  We > have specific tests in debug/ to test the _chk entry points and it > seems > like the tests should stick to validating only the regular entry points > unless otherwise specified. > > I'm not so sure.  The fact that fortification is enabled doesn't > diminish the validity of the tests, at the very end fortified function > shouldn't modify the behavior of these routines (modulo the additional > tests on input parameters). > Unless the test breaks because of fortification (like when tests > voluntarily mess with input parameters in a way that the test aborts on > chk routines), I don't see the need to undefine _FORTIFY_SOURCE. > > Thus, by having fortification enabled during the tests, I could catch > errors in the tests (e.g. Incorrect maxlen parameter for swprintf > 427dbaee86bcec31ba2fe9a42f32842cf17c4e77). > > On top of that in the current configuration, assuming > "--enable-fortify-source" is **not** set, and the _FORTIFY_SOURCE macro > is **not** set through the environment neither, these are still tested > without fortification. > In one sense, having the glibc CI testing the entry points directly, > while the community will probably test with fortification, may help > catch unwanted behavioral changes (if that ever happens) due to > incorrect check routines implementation. > > All of that said, we may need to reconsider the tests like > tst-sprintf-chk-ub.c though, considering the capability to enable > fortification from configure. > > What do you think ? OK that's fine, just that we'd need to do further fixups to tests in future where we're testing fortified and unfortified variants. Sid