From owner-freebsd-arch@freebsd.org Wed Aug 14 00:48:12 2019 Return-Path: Delivered-To: freebsd-arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 90C6DC22B3 for ; Wed, 14 Aug 2019 00:48:12 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 467WCc3Hv9z4c5d for ; Wed, 14 Aug 2019 00:48:12 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 6F01FC22B2; Wed, 14 Aug 2019 00:48:12 +0000 (UTC) Delivered-To: arch@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6D951C22B1 for ; Wed, 14 Aug 2019 00:48:12 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467WCc21ktz4c5c; Wed, 14 Aug 2019 00:48:12 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.5] (unknown [181.52.72.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id CA8D9124EB; Wed, 14 Aug 2019 00:48:11 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: Warner Losh Cc: "freebsd-arch@freebsd.org" References: <542de336-f030-04f9-27d4-bebc96ab20fd@FreeBSD.org> From: Pedro Giffuni Organization: FreeBSD Message-ID: Date: Tue, 13 Aug 2019 19:48:10 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 00:48:12 -0000 On 13/08/2019 18:09, Warner Losh wrote: > > > On Tue, Aug 13, 2019 at 2:49 PM Pedro Giffuni > wrote: > >> Greetings, >> >> As promised for almost the past decade or so, gcc 4.2.1 will be removed >> from the tree before FreeBSD 13 is branched. > Yes !! >> I propose the following timeline for its removal: >> >> 2019-08-31: disconnect gcc 4.2.1 from CI build >> >> Turn off -Werror on gcc 4.2.1 platforms >> >> Turn off all gcc 4.2.1 from universe by default (can be turned on) >> >> 2019-12-31: Turn off gcc 4.2.1 build by default (can be turned on) >> >> 2020-03-31: svn rm gcc 4.2.1 and friends >> >> 2020-05-31: svn rm all non-clang platforms not supported by in-tree LLVM or >> converted to ext toolchain. >> >> 2020-07-31: svn rm all ext toolchain platforms not supported by re@ release >> scripts >> >> The basic notion is that it=E2=80=99s long past time to have a firm plan fo= >> r EOL >> gcc 4.2.1 in the tree. There is ample external toolchain support today for >> platforms that need it to build images, though that integration with >> buildworld could use some more polish. It=E2=80=99s now completely sufficie= >> nt to >> move to the next phase of removing gcc 4.2.1 from the tree. >> > snip ... all fine stuff ... >> Comments? > > I/we have a problem with libssp (part of gcclibs). > > Short story: I have tried to get rid of libssp twice, but I failed > and would appreciate someone with more compiler foo looking at it: > > https://reviews.freebsd.org/D15687 > > Also PR 229348 > > > Yes. This is a known issue that we have a squishy plan for. Obviously, > if we can't execute on the squishy plan, we'd have to re-valuate the > timeline. > > Longer story: libssp was brought along with the stack-protector > after similar code from NetBSD, however the stack protector code > lives in our libc already (libc/secure/stack_protector.c). libssp > is used to support FORTIFY_SOURCE, a feature which we never ported > to FreeBSD and remains unused. > > FWIW, I mentored the implementation of FORTIFY_SOURCE in GSoC2015 > but we only got it working fully with GCC 4.2.1: it is largely > unsupported by clang and obsoleted by stack-protector-strong. > NetBSD doesn't use the libssp included with GCC, they have their > own BSD licensed version, however, given that we don't use it at > all it doesn't make sense to import it. We should just get rid of > it but the libary seems to have grown roots in the compiler > toolchain and even when I am able to build world without it, and > exp-run thinks the compiler is broken. > > Yes. There is also another MIT/BSD licensed implementation that was > mentioned when we were putting together the proposed timeline, as was > doing a clean-room implementation as needed. The GSoC2015 has a rather clean implementation (of the library, the headers are quite another issue): https://wiki.freebsd.org/SummerOfCode2015/FreeBSDLibcSecurityExtensions If we want to get FORTIFY_SOURCE working with clang, then we should look at a newer bionic(Android) instead but most of that is C++. Last time I looked, musl had an only-header implementation that works on modern GCC only. In any case I if replacing the library is the solution, I would strip out all the functions/symbols that are not in the GNU libssp. > It's likely a few hours of somebody's time to create. s/hours/nights/ > I don't recall the details. Thanks for the pointers, and the > confirmation that we almost certainly need to fill this gap. Any > chance there's a pointer to the exp run that shows the failures? > Only antoine@ would know, but by the looks of it, the best is to try the patch in a VM. Hope that helps, Pedro.