From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from crocodile.elm.relay.mailchannels.net (crocodile.elm.relay.mailchannels.net [23.83.212.45]) by sourceware.org (Postfix) with ESMTPS id 7F6463858D28 for ; Wed, 21 Jun 2023 15:26:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7F6463858D28 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 7453C5419EB; Wed, 21 Jun 2023 15:26:02 +0000 (UTC) Received: from pdx1-sub0-mail-a243.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AF177541D57; Wed, 21 Jun 2023 15:26:01 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1687361161; a=rsa-sha256; cv=none; b=AHuZH4mQ9vTs2ZtZrTK6dmDLS9O7iMKzjQAEsgBIm4XvwmAZp9GTwj8gjibbv9T6BhR3Th 1i9uhuhvo37+EH3PRILE5RmjfLO+Eun86ZNAawu359zD9HBQhpAOXW2MJMblNKCx2nnFzz i4UMwhQ1FYDJRBxpOHoQRsAPWyyDk3qMaCh1+hO/X4PjuCtxnwY0YTusWMdT74vs5dVxMv xQjZGJwHmHsPLR2MzE2jIS1PPDNVkKgtHmiVO1hEcJZeDDWwO0+9xkbA0Fm5w7zZfffanO Y3MbzASHk716doWVNKwv2Ue3hIbCn9xzcOJQ8yxx7hVE+7Chh5rtVsg0BDrUwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1687361161; 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=VRYJlRyoW82qPdbr4BVCqc6q3U2RKjKy8mYzb2PRKzg=; b=iD5SPKi8VBfrMYO5yWQZgTcfpDeNJMdjZ5x4+PLUPCdzKBqdvM3Y33uj74KzLh/MI0HIrn ZdvoY8v/orAs7mnFr1VYEzrWWVNm/UVvoScGjAc+st9XpE9vA52CyVH0BAWSchplo1QLbe UPhv4W2hgZyIRXCsA9QF1shl/D2+cn1bIEieGlgFGXgAsJVYiMnI7TjRBrAoLZpVoZe6/+ orktFCAthQSnMdXqGtQ1EdNK8609b4HSxHToKZP7pz+TOR1J0Y+1EJMQ25XFQNoUpit+n6 fbeFZGqvmD/qqgb6eTfDEAgAjLgw8hzB3+bksE7qOA4/iWrziLwlqXvAICcFOg== ARC-Authentication-Results: i=1; rspamd-9fcc56855-jzllm; 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-Reaction-Cure: 4be26a1f665a7cf2_1687361162263_3375260455 X-MC-Loop-Signature: 1687361162263:1674229522 X-MC-Ingress-Time: 1687361162262 Received: from pdx1-sub0-mail-a243.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.24.91 (trex/6.9.1); Wed, 21 Jun 2023 15:26:02 +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) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a243.dreamhost.com (Postfix) with ESMTPSA id 4QmS550ZzWz89; Wed, 21 Jun 2023 08:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1687361161; bh=VRYJlRyoW82qPdbr4BVCqc6q3U2RKjKy8mYzb2PRKzg=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=c04laY1Gwo2gSzd0EhlrE/bqrTIX4N1Iz8T32P0J9WjL/Iw6ZkUd6N1vHSHdW1RRd avCyddR3oiYNc0UBrskcTzY82aoN5LMMUwUIpB3+Z3r7Z2YevZZol5SCYTgH8+HqZZ P3Upio5cqdxYsCMc1ZKkmyEtysfutOKoddDE/1JaD1wq5e4mAaDSbBohye6CvpTP5w MMKMoJdnxEjGvGwzFbBuAN0ZD+PN89MQyy/gL4ds4LDOQIDmrhn5jdjL3dDXokgu1s d234BM5TSU3nGZxpBVnEqvp97Bt7nE7AAWL3o3IHgKFNUsze6l8LQZ+v5h9Byy4iV8 XBpiwSbRsaZ0g== Message-ID: Date: Wed, 21 Jun 2023 11:25:59 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 01/21] Add --enable-fortify-source option Content-Language: en-US To: Frederic Berat , Maxim Kuvyrkov via Libc-alpha References: <20230620181910.1506893-1-fberat@redhat.com> <20230620181910.1506893-2-fberat@redhat.com> Cc: Carlos O'Donell , Sam James 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.5 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_H3,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-06-21 09:18, Frederic Berat wrote: > On Tue, Jun 20, 2023 at 8:19 PM Frédéric Bérat wrote: >> >> It is now possible to enable fortification. >> The level may be given as parameter, if none is provided, the configure >> script will determine what is the highest level possible that can be set >> considering GCC built-ins availability and set it. >> If level is explicitly set to 3, configure checks if the compiler >> supports the built-in function necessary for it or raise an error if it >> isn't. >> >> The result of the configure checks is 2 variables, $fortify_source and >> $no_fortify_source that are used to appropriately populate CFLAGS. >> >> Since the feature needs some of the routines provided by Glibc, these >> are excluded from the fortification. >> --- >> Makeconfig | 33 ++++++++++++++++++++++++--- >> config.make.in | 3 ++- >> configure.ac | 60 +++++++++++++++++++++++++++++++++++--------------- >> elf/rtld-Rules | 2 +- >> 4 files changed, 75 insertions(+), 23 deletions(-) >> >> diff --git a/Makeconfig b/Makeconfig >> index 2514db35f6..59fbd9ebf9 100644 >> --- a/Makeconfig >> +++ b/Makeconfig >> @@ -543,12 +543,13 @@ endif # +link >> # ARM, gcc always produces different debugging symbols when invoked with >> # a -O greater than 0 than when invoked with -O0, regardless of anything else >> # we're using to suppress optimizations. Therefore, we need to explicitly pass >> -# -O0 to it through CFLAGS. >> +# -O0 to it through CFLAGS. By side effect, any fortification needs to be >> +# disabled as it needs -O greater than 0. >> # Additionally, the build system will try to -include $(common-objpfx)/config.h >> # when compiling the tests, which will throw an error if some special macros >> # (such as __OPTIMIZE__ and IS_IN_build) aren't defined. To avoid this, we >> # tell gcc to define IS_IN_build. >> -CFLAGS-printers-tests := -O0 -ggdb3 -DIS_IN_build >> +CFLAGS-printers-tests := -O0 -ggdb3 -DIS_IN_build $(no-fortify-source) >> >> ifeq (yes,$(build-shared)) >> # These indicate whether to link using the built ld.so or the installed one. >> @@ -901,6 +902,16 @@ define elide-stack-protector >> $(if $(filter $(@F),$(patsubst %,%$(1),$(2))), $(no-stack-protector)) >> endef >> >> +# We might want to compile with fortify-source >> +ifneq ($(fortify-source),) >> ++fortify-source=$(fortify-source) >> +endif >> + >> +# Some routine can't be fortified like the ones used by fortify >> +define elide-fortify-source >> +$(if $(filter $(@F),$(patsubst %,%$(1),$(2))), $(no-fortify-source)) >> +endef >> + >> # The program that makes Emacs-style TAGS files. >> ETAGS := etags >> >> @@ -961,6 +972,16 @@ endif # $(+cflags) == "" >> $(+stack-protector) -fno-common >> +gcc-nowarn := -w >> >> +# We must filter out elf because the early bootstrap of the dynamic loader >> +# cannot be fortified. Likewise we exclude dlfcn because it is entangled >> +# with the loader. We must filter out csu because early startup, like the >> +# loader, cannot be fortified. Lastly debug is the fortification routines >> +# themselves and they cannot be fortified. >> +do-fortify = $(filter-out elf dlfcn csu debug,$(subdir)) >> +ifeq ($(do-fortify),$(subdir)) >> ++cflags += $(+fortify-source) >> +endif > > This needs to be adapted to deal with compilers that define > "_FORTIFY_SOURCE" by default (checked on ubuntu 22.04): > > +do-fortify = $(filter-out elf dlfcn csu debug,$(subdir)) > +ifeq ($(do-fortify),$(subdir)) > ++cflags += $(+fortify-source) > +else > ++cflags += $(no-fortify-source) > +endif > > That way, we ensure that even if _FORTIFY_SOURCE is enabled at system > level, we don't build these subdirectories with it. That's likely true for Gentoo as well. Additionally, those distributions will default to fortification being enabled by default, without --enable-fortify-source. This is probably wrong in terms of compatibility and user expectations, i.e. without the configure flag, the code generated should be like in 2.37, i.e. glibc should strictly not be built with fortification enabled. Sam, do you have an opinion on this? Would it be too surprising for Gentoo packaging/users if glibc 2.38 built with fortification on by default? FWIW, we'll likely flip to enabling fortification by default in 2.39 and make the flag --disable-fortify-source, but that's a different bridge to cross. Thanks, Sid