From owner-freebsd-arch@freebsd.org Mon Aug 12 10:58:36 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 9D904AEBC7 for ; Mon, 12 Aug 2019 10:58:36 +0000 (UTC) (envelope-from sent62096@spread5send2.com) Received: from mail228189.app5.reasonable5.com (mail228189.app5.reasonable5.com [103.71.228.189]) by mx1.freebsd.org (Postfix) with ESMTP id 466Xrq2N0Kz4Bdc for ; Mon, 12 Aug 2019 10:58:35 +0000 (UTC) (envelope-from sent62096@spread5send2.com) Received: from WIN-SSI6NU53F8N (mail228002.app5.reasonable5.com [103.71.228.2]) by mail228189.app5.reasonable5.com (Postfix) with ESMTPA id 353651E2CA3 for ; Mon, 12 Aug 2019 18:39:07 +0800 (HKT) From: "Toby Lu" To: "freebsd-arch@freebsd.org" Date: Mon, 12 Aug 2019 18:39:10 +0800 Subject: Diamond Tools & Stone Machinery X-Mailer: aspNetEmail ver 3.7.0.19 X-Spread-CampaignId: 86874 X-Spread-SubscriberId: 82978871 X-Spread-SpreaderId: 62096 X-Spread-Engine-Build: 4.0.6505.30962 Message-ID: X-Rspamd-Queue-Id: 466Xrq2N0Kz4Bdc X-Spamd-Bar: ++++++++ Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of sent62096@spread5send2.com designates 103.71.228.189 as permitted sender) smtp.mailfrom=sent62096@spread5send2.com X-Spamd-Result: default: False [8.26 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:103.71.228.0/22:c]; MIME_MA_MISSING_TEXT(2.00)[]; URI_COUNT_ODD(1.00)[7]; FORGED_SENDER(0.30)[info3@wanlongdiamondtools.com,sent62096@spread5send2.com]; RCVD_NO_TLS_LAST(0.10)[]; MIME_TRACE(0.00)[0:+,1:~]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:133054, ipnet:103.71.228.0/22, country:HK]; FROM_NEQ_ENVFROM(0.00)[info3@wanlongdiamondtools.com,sent62096@spread5send2.com]; PHISHING(1.24)[stonemachines->spread5send2,wanlongstone.ru->spread5send2.com,wanlongstone->spread5send2]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.77)[0.773,0]; MIME_GOOD(-0.10)[multipart/alternative]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; HAS_LIST_UNSUB(-0.01)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_MEDIUM(0.99)[0.994,0]; IP_SCORE(0.47)[ipnet: 103.71.228.0/22(1.28), asn: 133054(1.01), country: HK(0.07)]; NEURAL_SPAM_LONG(0.99)[0.993,0]; TO_DN_EQ_ADDR_ALL(0.00)[]; MIME_HTML_ONLY(0.20)[]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_COUNT_TWO(0.00)[2]; GREYLIST(0.00)[pass,body] X-Spam: Yes MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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: Mon, 12 Aug 2019 10:58:36 -0000 From owner-freebsd-arch@freebsd.org Mon Aug 12 11:56:16 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 4BD79B08B8 for ; Mon, 12 Aug 2019 11:56:16 +0000 (UTC) (envelope-from b.mailink@orange.fr) Received: from msa.smtpout.orange.fr (msa07.smtpout.orange.fr [193.252.23.66]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "Bizanga Labs SMTP Client Certificate", Issuer "Bizanga Labs CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 466Z7M4vGpz4G2h for ; Mon, 12 Aug 2019 11:56:15 +0000 (UTC) (envelope-from b.mailink@orange.fr) Received: from [192.168.1.22] ([2.10.203.86]) by mwinf5d70 with ME id oBwD2001N1sMRFm03BwE43; Mon, 12 Aug 2019 13:56:14 +0200 X-ME-Helo: [192.168.1.22] X-ME-Auth: Yi5tYWlsaW5rQHdhbmFkb28uZnI= X-ME-Date: Mon, 12 Aug 2019 13:56:14 +0200 X-ME-IP: 2.10.203.86 Message-ID: Date: Mon, 12 Aug 2019 13:56:12 +0200 To: freebsd-arch@FreeBSD.org From: performArts Reply-To: c.depardieu@performarts.net Subject: www. performarts.net X-Emailink: Ref=Elk-147481-31755 X-Mailer: eMailink 4 X-Rspamd-Queue-Id: 466Z7M4vGpz4G2h X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of b.mailink@orange.fr has no SPF policy when checking 193.252.23.66) smtp.mailfrom=b.mailink@orange.fr X-Spamd-Result: default: False [4.34 / 15.00]; HAS_REPLYTO(0.00)[c.depardieu@performarts.net]; FREEMAIL_FROM(0.00)[orange.fr]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[86.203.10.2.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[orange.fr]; ASN(0.00)[asn:3215, ipnet:193.252.20.0/22, country:FR]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:~]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.71)[0.709,0]; IP_SCORE_FREEMAIL(0.00)[]; DMARC_NA(0.00)[orange.fr]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.98)[0.979,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; NEURAL_SPAM_LONG(0.95)[0.955,0]; RCVD_IN_DNSWL_NONE(0.00)[66.23.252.193.list.dnswl.org : 127.0.5.0]; MIME_HTML_ONLY(0.20)[]; R_SPF_NA(0.00)[]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(0.00)[ipnet: 193.252.20.0/22(1.80), asn: 3215(1.12), country: FR(-0.01)] MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" 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: Mon, 12 Aug 2019 11:56:16 -0000 From owner-freebsd-arch@freebsd.org Tue Aug 13 16:00:44 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 56A02B3D7F for ; Tue, 13 Aug 2019 16:00:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467HVz5MrGz42dH for ; Tue, 13 Aug 2019 16:00:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x730.google.com with SMTP id m2so6215851qki.12 for ; Tue, 13 Aug 2019 09:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=hbeWk6FZ9VvexZHDslruuBSvfg+3/M9+X1nf4n3ly4w=; b=nbOCVDqG2P7Jrv9lgHNFDQnRWwrBLykz1kVyhLwIqwRRFIv7Ul/S9i7OSpMFSDZGv0 uKgmaIgN1ECN8kd/pmw7mzkpGbsdomosNfZ2o2S7AXxG1IL2ZNon+uqwXcquA1WIV2mn fJVSxbWUatOALr0nv/VMdVcVJY5ESxAUPoYI+p/RRvnfEtN/Kwnf0yd9CWRjW8/wMQ5G XV1QbW5EoHr3Qem02/86ywaMQ71HQVtfJmj9RCR0yB4fUcOLlX0BaVy3bpvpdaG+ThVb PxuhggesWLTm3Qa2GvaQEslxBFeouv+cmO7do9chXFdKfpauV1LHOZmFOBZa0LCaEhYd xAIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hbeWk6FZ9VvexZHDslruuBSvfg+3/M9+X1nf4n3ly4w=; b=dj2nnPYu9OnyJUvMeZdAAITGk8veSwO3ZqLvJ4muOL8Yr/UQFAOCFeTiMayDBeQzpe 08UW9w95eiE+GEggO0xUjWVRQfCOt5xeI4f/+sdb0NHY7CRAO3eWl0moLAONZ/5QD5nN M/JxLorK+7Cf6Te6yZ7/nUAcxGvlaEtp/OsY4j8BIQDEZvaVqe0Gj69w8y1Trboj7Mbt 41avbI42aQ2K4kf7sOA2e5gBPRgzlsAD2QbT8YT+8Fnq/IWnoCjsf/4peAqxwfDukcrI 5V0nwGZU7wVGbof9lhPBE1ux/4rOUftq9u2rN25WtwlG2Juz6gK6GW6rJnAlEQofHzsG jS6Q== X-Gm-Message-State: APjAAAXT+xYS+4NY/vA+4DgcZnszD2QJVhx8CFkIsvP8Xp6/+5RptR1y 0O0l3TJV7jUi8dsbwxGs+GIRJ/fiPWodmYGIBasS1jqJADGzQg== X-Google-Smtp-Source: APXvYqyg+xoqVVHLX+NTZC9b0Latru6Y/9eZ+B1eWz++yFeKsFD6iomPe6eXl+G9n5yYBmshsf6E8j9mrrMUrgMSno0= X-Received: by 2002:a37:83c4:: with SMTP id f187mr33757076qkd.380.1565712041884; Tue, 13 Aug 2019 09:00:41 -0700 (PDT) MIME-Version: 1.0 From: Warner Losh Date: Tue, 13 Aug 2019 10:00:30 -0600 Message-ID: Subject: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 467HVz5MrGz42dH X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=nbOCVDqG; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::730) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_ONE(0.00)[1]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; RCVD_IN_DNSWL_NONE(0.00)[0.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; TO_DN_EQ_ADDR_ALL(0.00)[]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.96)[ip: (-9.41), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Tue, 13 Aug 2019 16:00:44 -0000 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. 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. We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should somewhat mitigate the risk for cross-compiler portability. This is a long-established part of our CI. We want to retain gcc support for modern versions of gcc since its debuggability is higher. Notifications for this are currently turned off, but will be enabled soon. It=E2=80=99s expected t= hat this always will be working later in the year. We=E2=80=99ll work to update the committers guide to reflect this, as well as give a recipe for testing. The first phase will be at the end of the month. We=E2=80=99ll turn off -We= rror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). We=E2=80=99ll then stop = building all platforms that require it as part of CI. New warnings will come up, but will no longer waste developer time in trying to fix. Gcc 4.2.1 platforms will no longer be built as part of universe, unless you add -DMAKE_OBSOLETE_GCC is added to the command line. We plan on implementing this by 2019-08-31. An experimental branch will be created that will remove gcc related bits to expose gaps in planning and to come up with a list of action items needed to ensure Tier 1 platforms are unaffected by the gcc removal. The timeline for this is by the end of September. Next, we=E2=80=99ll turn off building gcc by default. This will effectively= break all gcc platforms with in-tree compilers. The external toolchain support we have will suffice here, and patches will be accepted for whatever integration are needed for these platforms with our current ports / packages. The onus for these changes will be squarely on people that want the platforms to continue. However, as a stop-gap gcc building can be turned on for those people transitioning gcc-only platforms until gcc 4.2.1 is removed. This will happen on or about 2019-12-31. After a 3 month transition period, gcc 4.2.1 will be removed from the tree. This will be done on or about 2020-03-31. After an additional 2 month transition period, all those platforms that have not integrated with the FreeBSD CI system, work in a make universe with the proper packages installed, and are shown to boot on real hardware will be removed from the tree. This will happen on or about 2020-05-31. After an additional 2 month grace period, those platforms that require external toolchain integration that aren=E2=80=99t supported by the release engineer=E2=80=99s release scripts will be removed. This will happen on or= about 2020-07-31. The timeline gives powerpc, mips, mips64, and sparc64 9 months to integrate either into an in-tree compiler, or to have a proven external toolchain solution. This is on top of the many-years-long warnings about this being the end game of the clang integration. This is the proposed timeline, but should there be a significant issue that=E2=80=99s discovered, the timeline can be amended. Also note: the all toolchains in tree discussions are specifically out of bounds here. Let=E2=80=99s remove one compiler and get the infrastructure n= eeded to make external toolchains robust before embarking on that discussion. Comments? Warner From owner-freebsd-arch@freebsd.org Tue Aug 13 16:08:18 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 15BF8B42D2 for ; Tue, 13 Aug 2019 16:08:18 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467Hgj0Yxfz43Tw for ; Tue, 13 Aug 2019 16:08:16 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk1-x72c.google.com with SMTP id m2so6237666qki.12 for ; Tue, 13 Aug 2019 09:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hfRG2KwGApzi617KcKFaoyUnZF361kq5GMfN4sDHfH8=; b=Tmr/jzAT4RiC3hJ81jce7FADXGjktTbFeEE2PpfKxHXvtMM0dczhtqSYuIeRTNo4sG oxokT6Zo3iehzUZ+xZ7GZUBrFoxZot4icmcErVbKydI4lyJyt1IbvO0z3bu4N29CxTIU X8cNJToGlKVbBABg6JvoBblTrYZ9oT13t3+atrpH1yei1OebrDD1KAxkP83dkMpFy10H gs0IdJrlRYuyN63bcaWA5dQmcck201ublVgyZ0VgbaGfqHW8JGRaVCpSSPvYU/rKv2+D sKFEEFTfeZA6yBpuZFlsdMgc0XV/NlBU3H8O+/TIROss1jrPiyE7vEAmpW6NOkhJCkKP mXMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hfRG2KwGApzi617KcKFaoyUnZF361kq5GMfN4sDHfH8=; b=Bmr/e0W2B8jeQyUqWSKc/Qv8VGvG4USFVQXF9oXFYKq5KsEFNU3JKRBeCg6Oy9pCHN 0e5EBRLFRMT9esrqbsDy5Mw3VrxG9q7yzjSgfqgKjmYSeo0g2vVF6mZ9f2n+hWhfb0up d7XMd7CRKEmMiNKqPJapdBQXw3YbpxSkpLPV6SYR3s+/e2LAKva+6pqcvc6XUwQ9+C3y MXMEHqMckUY70/Kpjk6pQPywONlfTfp910ZuLjOc2yIEAfsR8I7ngOTtUtsVv4NIWRcs 3VpauWbqJxqnfAA2hyuJzDwiSbyXU/mO/QSZJbyraivNnul8QR8YiPYoSFugbAY4+9Y1 95VA== X-Gm-Message-State: APjAAAXs5/ZFmKz3BLsc4H1rnX/v2TqRC5DZS9icf4R3GPK6UYu8t/+T pyqHCF03xZXadUAuFk1/LM7LMCvWxf7l8g== X-Google-Smtp-Source: APXvYqy27ZYsrYIvV/hSvth3FS647FPxTolz3wM3XC4QHvdzX+7YcX9oj02NXKTazow+MzHnt8pR1g== X-Received: by 2002:a37:4b49:: with SMTP id y70mr947830qka.447.1565712495736; Tue, 13 Aug 2019 09:08:15 -0700 (PDT) Received: from mutt-hbsd ([63.88.83.108]) by smtp.gmail.com with ESMTPSA id b1sm22250824qkk.8.2019.08.13.09.08.14 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 13 Aug 2019 09:08:15 -0700 (PDT) Date: Tue, 13 Aug 2019 12:08:14 -0400 From: Shawn Webb To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <20190813160814.w34txatdfizslcg6@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="v6lphrg4stipl4vu" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: 467Hgj0Yxfz43Tw X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=Tmr/jzAT; dmarc=none; spf=pass (mx1.freebsd.org: domain of shawn.webb@hardenedbsd.org designates 2607:f8b0:4864:20::72c as permitted sender) smtp.mailfrom=shawn.webb@hardenedbsd.org X-Spamd-Result: default: False [-8.05 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[c.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-2.95)[ip: (-9.36), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)] 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: Tue, 13 Aug 2019 16:08:18 -0000 --v6lphrg4stipl4vu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2019 at 10:00:30AM -0600, Warner Losh wrote: > Comments? Kill it with fire. --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 --v6lphrg4stipl4vu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl1S4GkACgkQ/y5nonf4 4fpipw/7BTbZ6K5sy61iq967i3VN3SAb+9hIJ2veZTmtwRGwviCSTCJ2uR8Vqeto GghH+0/UbKoi4YhbeYuP5opYSeiDBYaN0TyWZbpTQiecaq+LWWaGx21VBk5/GJ2v 3QRmMX1o6i2o8W5Dz8XwVn8QaUkxq267MBsNyGHdIoevYY7tn82wurCvPhrFVgBc q2gdwaxcR2m/ywN/u+DVNaPF4cAADrNnVNJ+sLEP2ZzAWIJWeL+9EBK+ZVHx57PJ rHgAoZwRKmjZ2cS7sCjb27WYM7SBQBcmAOXXfp6NeeLTvs9DCAAMGq8vOzscgIsU eU2wbLGvdxSmUTsKdFAPAIVGZaP9uW+G3Cib20+U2XZIw3UyyEXc1hI2RLjwoe1Q A0pDQEmn3M4P0RfE2PXLMWZw/H7zdsHJkaOLeVrCo0HflhmUSnqgKiKTtK01H8CQ 2jZF3V0mCkBhjCBC0zSkEQU0GO4Xo5qY+7hSNxoFENNPck2HPUncMxG3BDX/NP0U 9259HgJACCrRqO0XHDHwL5gNWCHAeip7pkuyMUfP8XTqpaIVfAp7siujknn/88FO YEJuDyPKPrc7yLni6tvz3dUAVgWesglxh8e7D7eLNymo8+n5srHqbwIriNOkEiE2 gMQwtMJC/UVl6CO7jm4YbacfuzrPzPUltUq81a0FNJ1FA1rYvZY= =ErsL -----END PGP SIGNATURE----- --v6lphrg4stipl4vu-- From owner-freebsd-arch@freebsd.org Tue Aug 13 16:30:03 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 88C2DB4B7E for ; Tue, 13 Aug 2019 16:30:03 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467J8p51v7z44dy for ; Tue, 13 Aug 2019 16:30:02 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ot1-x32d.google.com with SMTP id g17so23855412otl.2 for ; Tue, 13 Aug 2019 09:30:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=UisUB8MdyhveaM7thzTVH9QB2vQAgexhCU2rexTlhmE=; b=JgOFoIQdRaSBfW4OVv9B7+n3GVZhiql8q5sXXguAEfmyixRCBvm2YKioaOsz49QNQM AbeL3qcfmGa0Wb/IfaohBe69iqayG6MqQk0kQfane+eHpEfr1dnch49Hg+gI4BauiO9y roReyb3y3NkdoKb+63if47PRAM2VsfNQ0orfpfYUnPXvfsMp9dH7hZrPQE5k57pGWG09 vIdTflJY1mvSWC6mzps5cLUSubwQmmVvqCwaQAhPXLCaSw0T1IiBRMuSL/tiZXk8KqWm wfrWIPFfkKoZUbVmnhI1RB0COxZULfnsd4hippVIxgCU6FTYh2JWbcsnMGGftKxkIhqg ZbAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=UisUB8MdyhveaM7thzTVH9QB2vQAgexhCU2rexTlhmE=; b=pGP4NxbIyJIiqQ+0MJKjUd3x005kUgax+lBvEKJq7EPEH8fmgr4WQgPZr+0+O0i+5Q zv1dSmHMduDa6REbAFS4ixKCLlJ0W+s7QaquXsv8G15pARHEBq3WHu+b+mNLAHGa7qPi d5r0OxicK1pPOaDazutW0l8GE6GikDbv1cgDKCa4ACocKQafsquXXZ10HrnYtdz2YrtE IhLCw5Mqgyg/zlqNNCi42SbDBXajL9+1eSZLri3x0Y5sBJ6kxKwG85nt7lNscnC0xJJM OnGis/m/vpH/vWzWIZs9jk7F8kNkmDYYNnF2qg/AengPvIt2NaoiFcC4ObUApQUN/XCJ JpRA== X-Gm-Message-State: APjAAAUiJFPin7siIWJW7EpFJ6EtbAHSa1wVR4v/b2hbc0079vfIiO05 6sZBNnrDPMgXLJLwQhz45So= X-Google-Smtp-Source: APXvYqwHp0rbIU7Pb9zNtfGIYVq/tSZjmS790XZbRplQiFflwo9Bl7VarPB1qD6KGeSH/9ILhh4Qyg== X-Received: by 2002:a02:3946:: with SMTP id w6mr27380723jae.55.1565713801112; Tue, 13 Aug 2019 09:30:01 -0700 (PDT) Received: from ralga.knownspace (173-25-245-129.client.mchsi.com. [173.25.245.129]) by smtp.gmail.com with ESMTPSA id p3sm178915290iom.7.2019.08.13.09.30.00 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 13 Aug 2019 09:30:00 -0700 (PDT) Date: Tue, 13 Aug 2019 11:29:56 -0500 From: Justin Hibbits To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <20190813112956.7c9f648e@ralga.knownspace> In-Reply-To: References: X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 467J8p51v7z44dy X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=JgOFoIQd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::32d as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; RECEIVED_SPAMHAUS_PBL(0.00)[129.245.25.173.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[d.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-9.25), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] 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: Tue, 13 Aug 2019 16:30:03 -0000 On Tue, 13 Aug 2019 10:00:30 -0600 Warner Losh wrote: > Greetings, >=20 > As promised for almost the past decade or so, gcc 4.2.1 will be > removed from the tree before FreeBSD 13 is branched. >=20 > I propose the following timeline for its removal: >=20 > 2019-08-31: disconnect gcc 4.2.1 from CI build >=20 > Turn off -Werror on gcc 4.2.1 platforms >=20 > Turn off all gcc 4.2.1 from universe by default (can be turned on) >=20 > 2019-12-31: Turn off gcc 4.2.1 build by default (can be turned on) >=20 > 2020-03-31: svn rm gcc 4.2.1 and friends >=20 > 2020-05-31: svn rm all non-clang platforms not supported by in-tree > LLVM or converted to ext toolchain. >=20 > 2020-07-31: svn rm all ext toolchain platforms not supported by re@ > release scripts >=20 > The basic notion is that it=E2=80=99s long past time to have a firm plan = for > 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 sufficient to move to the next phase of removing gcc 4.2.1 > from the tree. >=20 > We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should > somewhat mitigate the risk for cross-compiler portability. This is a > long-established part of our CI. We want to retain gcc support for > modern versions of gcc since its debuggability is higher. > Notifications for this are currently turned off, but will be enabled > soon. It=E2=80=99s expected that this always will be working later in the > year. We=E2=80=99ll work to update the committers guide to reflect this, = as > well as give a recipe for testing. >=20 > The first phase will be at the end of the month. We=E2=80=99ll turn off > -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). We=E2=80=99= ll > then stop building all platforms that require it as part of CI. New > warnings will come up, but will no longer waste developer time in > trying to fix. Gcc 4.2.1 platforms will no longer be built as part of > universe, unless you add -DMAKE_OBSOLETE_GCC is added to the command > line. We plan on implementing this by 2019-08-31. >=20 > An experimental branch will be created that will remove gcc related > bits to expose gaps in planning and to come up with a list of action > items needed to ensure Tier 1 platforms are unaffected by the gcc > removal. The timeline for this is by the end of September. >=20 > Next, we=E2=80=99ll turn off building gcc by default. This will effective= ly > break all gcc platforms with in-tree compilers. The external > toolchain support we have will suffice here, and patches will be > accepted for whatever integration are needed for these platforms with > our current ports / packages. The onus for these changes will be > squarely on people that want the platforms to continue. However, as a > stop-gap gcc building can be turned on for those people transitioning > gcc-only platforms until gcc 4.2.1 is removed. This will happen on or > about 2019-12-31. >=20 > After a 3 month transition period, gcc 4.2.1 will be removed from the > tree. This will be done on or about 2020-03-31. >=20 > After an additional 2 month transition period, all those platforms > that have not integrated with the FreeBSD CI system, work in a make > universe with the proper packages installed, and are shown to boot on > real hardware will be removed from the tree. This will happen on or > about 2020-05-31. >=20 > After an additional 2 month grace period, those platforms that require > external toolchain integration that aren=E2=80=99t supported by the relea= se > engineer=E2=80=99s release scripts will be removed. This will happen on = or > about 2020-07-31. >=20 > The timeline gives powerpc, mips, mips64, and sparc64 9 months to > integrate either into an in-tree compiler, or to have a proven > external toolchain solution. This is on top of the many-years-long > warnings about this being the end game of the clang integration. >=20 > This is the proposed timeline, but should there be a significant issue > that=E2=80=99s discovered, the timeline can be amended. >=20 > Also note: the all toolchains in tree discussions are specifically > out of bounds here. Let=E2=80=99s remove one compiler and get the > infrastructure needed to make external toolchains robust before > embarking on that discussion. >=20 > Comments? >=20 > Warner Hi Warner, I like this proposal. All powerpc targets (powerpc, powerpc64, powerpcspe) will switch to clang when we get 9.0 into the tree, which won't be until September or October. That said, I think we should not MFC disabling -Werror on gcc 4.2.1 to 12 and 11, since we cannot MFC the clang migration for powerpc64 to 12, as it will break the ABI (lld only supports ELFv2, not ELFv1). - Justin From owner-freebsd-arch@freebsd.org Tue Aug 13 16:39:59 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 36F37B505C for ; Tue, 13 Aug 2019 16:39:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467JNG31yRz452V for ; Tue, 13 Aug 2019 16:39:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x831.google.com with SMTP id j15so13386907qtl.13 for ; Tue, 13 Aug 2019 09:39:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L/DZx3Zy6kRmRjF0Glafl6VZRYLUiqgUwEpESVz5/rI=; b=Cs+z1y2jZZDuYASvvXYTSCTwmb3uVthvSbmyTC26oc9oH1bhdFqRje9mqBccqSRkBH 3QWwjSjE8IJfFZ+fgEMPtQzJwYvfTlzFO5FMHj7h3RwpKRySO/YpTHFB9H2jm3JZt4bm vhDUM0sILO5YPwR/IBh5bIaW4xGfWsv4DqmVbVbQYikBeAJMBw8OyDnpaDwd3HL8UGvp C1EHiQTe0KhAOFpFDX7Afv4brgrH6XoFtqOUY0w6yOje6995W/xO/Ul3WIFkoLBNxtRK G29NDuFuiDJ19CFcNewLnz5jZiamIY5yOiLi6ReltxUMEHE0yqbjzcLwdG8epLuGKJo2 69eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L/DZx3Zy6kRmRjF0Glafl6VZRYLUiqgUwEpESVz5/rI=; b=T2mgd+wov+bsZxIiLbQ/8kUMnZYCLAXqQM0jwBHwFvhFDXeYLc67CjnlB3WlKBco9E 6jLeJljrqD9C5NV33308spdzQmHtDc+qQGZ0dlJ96lmL3iZNIeiD4TvlPzskIytrqTZh 0jW5ei1idtgM52LadToHDOKBztq/VBPqPNOKpHMD89qUSYl8duXrMvoYAoWf9rkdvmxg LCl3O4UZEFXbW+75VTAVWUig4p5IKuFP1BOYulIoatnJ1pimjREGesz0sMqCYStVEbCP iLbfD9dGR5k/NMVnXx9OjXlf9rJMJ5oF2WRkstXA0XPqpj94G+ngeOOJyw1N+4DFHjTe Ns7g== X-Gm-Message-State: APjAAAXInafH1CpFUMcOswX0y4a+wDtUugAA5cNWNkdLi5PoLifUslcX 2rXYS69kbASbV0PIWsV1PMboz5DeZeP9sKdN9b+iiiOMhRQ= X-Google-Smtp-Source: APXvYqw1o+/ETxDfIOTR4u7oBCNCeFtEF+RbpK2zSeEfF8ShKfWVy+fQgtYMUcPrID10HIq4ay82GGKgIuAkNVXLvAw= X-Received: by 2002:aed:34a6:: with SMTP id x35mr5947841qtd.187.1565714396792; Tue, 13 Aug 2019 09:39:56 -0700 (PDT) MIME-Version: 1.0 References: <20190813112956.7c9f648e@ralga.knownspace> In-Reply-To: <20190813112956.7c9f648e@ralga.knownspace> From: Warner Losh Date: Tue, 13 Aug 2019 10:39:45 -0600 Message-ID: Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: Justin Hibbits Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 467JNG31yRz452V X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=Cs+z1y2j; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::831) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-5.95 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[1.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.96)[ip: (-9.36), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: Tue, 13 Aug 2019 16:39:59 -0000 On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits wrote: > On Tue, 13 Aug 2019 10:00:30 -0600 > Warner Losh 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. > > > > 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 pla= n for > > 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 no= w > > completely sufficient to move to the next phase of removing gcc 4.2.1 > > from the tree. > > > > We already have gcc 6.4 as an xtoolchain on amd64 in CI. This should > > somewhat mitigate the risk for cross-compiler portability. This is a > > long-established part of our CI. We want to retain gcc support for > > modern versions of gcc since its debuggability is higher. > > Notifications for this are currently turned off, but will be enabled > > soon. It=E2=80=99s expected that this always will be working later in t= he > > year. We=E2=80=99ll work to update the committers guide to reflect this= , as > > well as give a recipe for testing. > > > > The first phase will be at the end of the month. We=E2=80=99ll turn off > > -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). We=E2=80= =99ll > > then stop building all platforms that require it as part of CI. New > > warnings will come up, but will no longer waste developer time in > > trying to fix. Gcc 4.2.1 platforms will no longer be built as part of > > universe, unless you add -DMAKE_OBSOLETE_GCC is added to the command > > line. We plan on implementing this by 2019-08-31. > > > > An experimental branch will be created that will remove gcc related > > bits to expose gaps in planning and to come up with a list of action > > items needed to ensure Tier 1 platforms are unaffected by the gcc > > removal. The timeline for this is by the end of September. > > > > Next, we=E2=80=99ll turn off building gcc by default. This will effecti= vely > > break all gcc platforms with in-tree compilers. The external > > toolchain support we have will suffice here, and patches will be > > accepted for whatever integration are needed for these platforms with > > our current ports / packages. The onus for these changes will be > > squarely on people that want the platforms to continue. However, as a > > stop-gap gcc building can be turned on for those people transitioning > > gcc-only platforms until gcc 4.2.1 is removed. This will happen on or > > about 2019-12-31. > > > > After a 3 month transition period, gcc 4.2.1 will be removed from the > > tree. This will be done on or about 2020-03-31. > > > > After an additional 2 month transition period, all those platforms > > that have not integrated with the FreeBSD CI system, work in a make > > universe with the proper packages installed, and are shown to boot on > > real hardware will be removed from the tree. This will happen on or > > about 2020-05-31. > > > > After an additional 2 month grace period, those platforms that require > > external toolchain integration that aren=E2=80=99t supported by the rel= ease > > engineer=E2=80=99s release scripts will be removed. This will happen o= n or > > about 2020-07-31. > > > > The timeline gives powerpc, mips, mips64, and sparc64 9 months to > > integrate either into an in-tree compiler, or to have a proven > > external toolchain solution. This is on top of the many-years-long > > warnings about this being the end game of the clang integration. > > > > This is the proposed timeline, but should there be a significant issue > > that=E2=80=99s discovered, the timeline can be amended. > > > > Also note: the all toolchains in tree discussions are specifically > > out of bounds here. Let=E2=80=99s remove one compiler and get the > > infrastructure needed to make external toolchains robust before > > embarking on that discussion. > > > > Comments? > > > > Warner > > Hi Warner, > > I like this proposal. All powerpc targets (powerpc, powerpc64, > powerpcspe) will switch to clang when we get 9.0 into the tree, which > won't be until September or October. > > That said, I think we should not MFC disabling -Werror on gcc 4.2.1 to > 12 and 11, since we cannot MFC the clang migration for powerpc64 to 12, > as it will break the ABI (lld only supports ELFv2, not ELFv1). > Why would that be a problem? It will allow us to ease the MFCs that might otherwise trigger errors because some new warning (likely bogus) is triggered... It would make things easier to cope with not being able to MFC the clang thing, I'd think. Am I missing something? Warner From owner-freebsd-arch@freebsd.org Tue Aug 13 16:45:19 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 99C06B54FC for ; Tue, 13 Aug 2019 16:45:19 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467JVQ6Wm6z45Pw for ; Tue, 13 Aug 2019 16:45:18 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ot1-x335.google.com with SMTP id q20so22133494otl.0 for ; Tue, 13 Aug 2019 09:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=14EppGj7yeVV53oHtoiCfp7YesslbVijXWY0J93wOTk=; b=pNuMCOKD/qQ5rPB8AxisHHJGZrhDUR4BE+bw74dB3CSFKygh5ykYT2jizlXsS6/aXY Wd+39mzaVBP5fHJlxuBu6Li0xiUcDk8yMwI9mXOkQt4xLUWD2S6Xzi8Nyi90iFJnKat+ kJzNW80Ze9COU7KN61ZzOLOuL7RlYcLc01WSZlmLz0KKK561/pRb2AnfANCs0+L3q7bz LSV0EY39uTB2iGFv8wny2sxT+LXt4h3K/QWPYTHr7Q2VJ+JbWYjJKLN49RBPguUodpB8 xWklnsqEo/d4APlsnLkB3GDJh1x4aBYPwmOlkUPU7uiVE2aiHjD1YzbBgyjH9u3lVeiC r+Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=14EppGj7yeVV53oHtoiCfp7YesslbVijXWY0J93wOTk=; b=t0+P2cA7LMOAq5JaYpDjR8R6a9ZNk4Y/cjgw4HGxFZyuAs1upGB5mraFAYtSdeGMvb UIxwePId6hRdWx9rgNxvtKNFC6V7kdbzcOaoJXbnRnYdn9R6Jy4+qKLWb08kU/HobSHH uK3aWyGmE51xDaRpowSS/JxElLo+h0pQl01I5Zk3i8qAuELmtVoCOb/aMsSmXLYqycn4 8oIkmYrC1YKS8j2a1s0ly1WdWvmLSzUFu0kzoCi1fvFlFynnpZOXlwPZSfqQSH6wBAFW uuBvoFFKx8GIAUamzalp1LIqOdLkPi5V9oiLQHYssw6rC4no9iECeEdVuOtsaAt46xSu QKDA== X-Gm-Message-State: APjAAAUC1M90qo8z7DiXZbXtY5I6vRklthuymRvyvhK96YquBBQrb3At awQFQhxpLNUiin14iatGmFU= X-Google-Smtp-Source: APXvYqxltZpyb1xioKJCRTGRsi/uJpeABCpU2kcdLyqLYTi2J2G+iNfzEWHERsgh5xU7QEAd/XgQPQ== X-Received: by 2002:a02:b88b:: with SMTP id p11mr44418786jam.144.1565714716864; Tue, 13 Aug 2019 09:45:16 -0700 (PDT) Received: from ralga.knownspace (173-25-245-129.client.mchsi.com. [173.25.245.129]) by smtp.gmail.com with ESMTPSA id m4sm91239677iok.68.2019.08.13.09.45.16 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Tue, 13 Aug 2019 09:45:16 -0700 (PDT) Date: Tue, 13 Aug 2019 11:45:12 -0500 From: Justin Hibbits To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <20190813114512.7ec4910e@ralga.knownspace> In-Reply-To: References: <20190813112956.7c9f648e@ralga.knownspace> X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; powerpc64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 467JVQ6Wm6z45Pw X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=pNuMCOKD; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of chmeeedalf@gmail.com designates 2607:f8b0:4864:20::335 as permitted sender) smtp.mailfrom=chmeeedalf@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.996,0]; RECEIVED_SPAMHAUS_PBL(0.00)[129.245.25.173.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[5.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(0.00)[ip: (-8.75), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; RCVD_TLS_ALL(0.00)[] 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: Tue, 13 Aug 2019 16:45:19 -0000 On Tue, 13 Aug 2019 10:39:45 -0600 Warner Losh wrote: > On Tue, Aug 13, 2019 at 10:30 AM Justin Hibbits > wrote: >=20 > > On Tue, 13 Aug 2019 10:00:30 -0600 > > Warner Losh wrote: > > =20 > > > 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. > > > > > > 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 p= lan > > > for 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 sufficient to move to the next phase of removing > > > gcc 4.2.1 from the tree. > > > > > > We already have gcc 6.4 as an xtoolchain on amd64 in CI. This > > > should somewhat mitigate the risk for cross-compiler portability. > > > This is a long-established part of our CI. We want to retain gcc > > > support for modern versions of gcc since its debuggability is > > > higher. Notifications for this are currently turned off, but will > > > be enabled soon. It=E2=80=99s expected that this always will be worki= ng > > > later in the year. We=E2=80=99ll work to update the committers guide = to > > > reflect this, as well as give a recipe for testing. > > > > > > The first phase will be at the end of the month. We=E2=80=99ll turn o= ff > > > -Werror on gcc 4.2.1 (and MFC it to stable/11 and stable/12). > > > We=E2=80=99ll then stop building all platforms that require it as par= t of > > > CI. New warnings will come up, but will no longer waste developer > > > time in trying to fix. Gcc 4.2.1 platforms will no longer be > > > built as part of universe, unless you add -DMAKE_OBSOLETE_GCC is > > > added to the command line. We plan on implementing this by > > > 2019-08-31. > > > > > > An experimental branch will be created that will remove gcc > > > related bits to expose gaps in planning and to come up with a > > > list of action items needed to ensure Tier 1 platforms are > > > unaffected by the gcc removal. The timeline for this is by the > > > end of September. > > > > > > Next, we=E2=80=99ll turn off building gcc by default. This will > > > effectively break all gcc platforms with in-tree compilers. The > > > external toolchain support we have will suffice here, and patches > > > will be accepted for whatever integration are needed for these > > > platforms with our current ports / packages. The onus for these > > > changes will be squarely on people that want the platforms to > > > continue. However, as a stop-gap gcc building can be turned on > > > for those people transitioning gcc-only platforms until gcc 4.2.1 > > > is removed. This will happen on or about 2019-12-31. > > > > > > After a 3 month transition period, gcc 4.2.1 will be removed from > > > the tree. This will be done on or about 2020-03-31. > > > > > > After an additional 2 month transition period, all those platforms > > > that have not integrated with the FreeBSD CI system, work in a > > > make universe with the proper packages installed, and are shown > > > to boot on real hardware will be removed from the tree. This will > > > happen on or about 2020-05-31. > > > > > > After an additional 2 month grace period, those platforms that > > > require external toolchain integration that aren=E2=80=99t supported = by > > > the release engineer=E2=80=99s release scripts will be removed. This > > > will happen on or about 2020-07-31. > > > > > > The timeline gives powerpc, mips, mips64, and sparc64 9 months to > > > integrate either into an in-tree compiler, or to have a proven > > > external toolchain solution. This is on top of the many-years-long > > > warnings about this being the end game of the clang integration. > > > > > > This is the proposed timeline, but should there be a significant > > > issue that=E2=80=99s discovered, the timeline can be amended. > > > > > > Also note: the all toolchains in tree discussions are specifically > > > out of bounds here. Let=E2=80=99s remove one compiler and get the > > > infrastructure needed to make external toolchains robust before > > > embarking on that discussion. > > > > > > Comments? > > > > > > Warner =20 > > > > Hi Warner, > > > > I like this proposal. All powerpc targets (powerpc, powerpc64, > > powerpcspe) will switch to clang when we get 9.0 into the tree, > > which won't be until September or October. > > > > That said, I think we should not MFC disabling -Werror on gcc 4.2.1 > > to 12 and 11, since we cannot MFC the clang migration for powerpc64 > > to 12, as it will break the ABI (lld only supports ELFv2, not > > ELFv1).=20 >=20 > Why would that be a problem? It will allow us to ease the MFCs that > might otherwise trigger errors because some new warning (likely > bogus) is triggered... It would make things easier to cope with not > being able to MFC the clang thing, I'd think. Am I missing something? >=20 > Warner Good point. The concern I have is legitimate warnings getting lost. However, that can probably be dealt with without too much hassle, on a case-by-case basis. - Justin From owner-freebsd-arch@freebsd.org Tue Aug 13 18:26:51 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 DC4DEB828A for ; Tue, 13 Aug 2019 18:26:51 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 467Llb0qnwz4ChD for ; Tue, 13 Aug 2019 18:26:50 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 419D43C0199; Tue, 13 Aug 2019 18:26:44 +0000 (UTC) Date: Tue, 13 Aug 2019 18:26:44 +0000 From: Brooks Davis To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Message-ID: <20190813182644.GQ94703@spindle.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zROEGoKAXsG5UqGB" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 467Llb0qnwz4ChD X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of brooks@spindle.one-eyed-alien.net has no SPF policy when checking 199.48.129.229) smtp.mailfrom=brooks@spindle.one-eyed-alien.net X-Spamd-Result: default: False [-7.45 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[freebsd.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.985,0]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[]; SIGNED_PGP(-2.00)[]; FORGED_SENDER(0.30)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; RCVD_COUNT_ZERO(0.00)[0]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:36236, ipnet:199.48.128.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[brooks@freebsd.org,brooks@spindle.one-eyed-alien.net]; IP_SCORE(-3.57)[ip: (-9.30), ipnet: 199.48.128.0/22(-4.63), asn: 36236(-3.87), country: US(-0.05)] 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: Tue, 13 Aug 2019 18:26:51 -0000 --zROEGoKAXsG5UqGB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 13, 2019 at 10:00:30AM -0600, Warner Losh wrote: > Greetings, >=20 > As promised for almost the past decade or so, gcc 4.2.1 will be removed > from the tree before FreeBSD 13 is branched. Thank you for writing this up. > The timeline gives powerpc, mips, mips64, and sparc64 9 months to integra= te > either into an in-tree compiler, or to have a proven external toolchain > solution. This is on top of the many-years-long warnings about this being > the end game of the clang integration. We'll find time at $DAYJOB to get mips64 over the last hurdles if someone doesn't beat us there since we still need it until we get our CHERI RISC-V port up and stable (and any PhD students whose work depends on MIPS graduate). -- Brooks --zROEGoKAXsG5UqGB Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJdUwDjAAoJEKzQXbSebgfACTsIAIyWoUuCaJ+0Vx2/9oQbgkbc ueZr9kw0+QWcrhfyWqvx227VGPTBvrTJpXT00iQw42XX3Lk1s1qxPp9fxVjGAZtG ttNlwxm4tzjRUOhJCxyvxPVWD6J42ffXQ7s3Vc0XffdflkmOI2l4aeNsAGVo2RJj QszO9Ew7gE/HEy5Ey5ENPyZ5kUvREJarXu0aPVOzLoPu/uvWuevdu7WLZHHsB601 XMJovX4aMRbwZTJqmmY4oHSF6o53z7LaBL7q1QFg5sDvPbb131SKl2ESQDsvlQqk sup+nH1dKBEvDBeYmgYewsFjmWebSvrxd4Ck9fNuTo/JJWz1EpCEBOEVVBUqfiI= =jbOo -----END PGP SIGNATURE----- --zROEGoKAXsG5UqGB-- From owner-freebsd-arch@freebsd.org Tue Aug 13 19:40:25 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 19CEABA5A5 for ; Tue, 13 Aug 2019 19:40:25 +0000 (UTC) (envelope-from neerajpal09@gmail.com) Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467NNS1wpkz4JBK for ; Tue, 13 Aug 2019 19:40:23 +0000 (UTC) (envelope-from neerajpal09@gmail.com) Received: by mail-ot1-x32c.google.com with SMTP id g17so25829454otl.2 for ; Tue, 13 Aug 2019 12:40:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=9EDkJWM/QLa8zwZrQJrgpug9OAr9B/Ke9HfKE4K4STQ=; b=EUetp50PIkDCJFRxjfQeSWix4HrX/fmy+7l44PDIYAvofHmAhq6VfO68WBryaQNQIH 0XsP2h7/7lJu3eVYVxFWuW2JVunVRyq18B0eiX4nNE4L+25UCpGevUzt5kS9YlequOlD /rJv/XQLx49agyFQ7jkik9vPIFtfLNqoOVs+ZE16OmqfZx9h4iFVFu04TZ9lR3fdb1dC dvWZXSNrWNiQUKX28HS5rezK+0SAIJDGjpZRGzjDj7OXLhug1cx5/DXSG5OywfowOvlk CNBZ8zmN6ZLgXn5MxRUn9BaXJqWTXvqZUJeK3oxJM5PNNqSA1B4J11UEvMWq1SS3PfVI O6vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=9EDkJWM/QLa8zwZrQJrgpug9OAr9B/Ke9HfKE4K4STQ=; b=th+oKhlh0O/t+ZknYC/SQGQsBlQYVRODp2iO25bWn/o8ARdRw3IPEGdhUmEgTtevLy MVu85r0JADo3nrNJzgd0O7VOSEfzOvqHTxwfqci3dTdPo5kPoIBh8fgHYOUpRZkF1LZT Xcaw5rRJvbN9t/IZZg4YFy2/MjqeTd8OfA4r+5yal5A78gQW0gu/1tliab8Vv/300ieo rDIHWdzv2PoEch5ytzLllfBTECtcEF8boQgMFe1XZWogsJbbUkpoh5MhaoLlu8gCgUsb 3qjId4ZJ8wzuLYyT0H4w/iEcrutfMSBUuZKZcIGUR1LqW9yavZPs3gq1+T22XtmeNkfa x+Ow== X-Gm-Message-State: APjAAAXWRuJaUZ7taEBPmRv50jrlCXXblDEKe4QCQRL4n/Kd1fUpZNHD b5wLYMJB7A3RI8zS1iRGBdxt1BgVVU6uRFdpBPT0cQk85lQ= X-Google-Smtp-Source: APXvYqzhwdJoEzEXrIoJfw7UhNw1xnM7KL6fZC5EpQQY0zRStbrMFwWTTuH5Ksj9CYzmH6Km22b0a3HERdxqqEcXr5c= X-Received: by 2002:a9d:7dc6:: with SMTP id k6mr14233955otn.99.1565725222262; Tue, 13 Aug 2019 12:40:22 -0700 (PDT) MIME-Version: 1.0 From: Neeraj Pal Date: Wed, 14 Aug 2019 01:10:10 +0530 Message-ID: Subject: Regarding the bug in FreeBSD kernel driver(s) To: freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 467NNS1wpkz4JBK X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=EUetp50P; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of neerajpal09@gmail.com designates 2607:f8b0:4864:20::32c as permitted sender) smtp.mailfrom=neerajpal09@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[15]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.997,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-9.07), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[c.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" 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: Tue, 13 Aug 2019 19:40:25 -0000 Hi there, After discussing the issue with the security-team, I have posted it publicly. Please find the bug information given below with workaround diff: I have observed the "NULL pointer dereference" bug inside the FreeBSD kernel driver code due to which kernel gets in panic (or DOS) mode and then it has to reboot. Actually, this vulnerability resides in lots of kernel drivers like "uhub0", "ubt0", "umass0", "run0", "uhid0" etc. I have tested and observed the panic for following kernel drivers: - usb, - umass (storage), - ubt(bluetooth), - run0(wifi), - uhid Please find the PoC in the link: https://www.dropbox.com/s/hd1c0a518nrw749/crash_poc_info.tar.gz?dl=0 I have observed that the devices which are using the structure "usb_attach_arg" with function (or api) device_get_ivars(9) as mentioned below: "struct usb_attach_arg *uaa = device_get_ivars(dev)" are prone to "NULL Pointer Dereference" vulnerability as there is no check for the same and the API device_get_ivars(9) is returning NULL. There are still lots of drivers which are lacking this NULL pointer dereference check but due to unavailability of devices I am not able to test the drivers. However, I am sure about others also. I have tested the following FreeBSD kernel versions: - FreeBSD 13-CURRENT, amd64 - FreeBSD 12-RELEASE, amd64 - FreeBSD 12-STABLE, amd64 [Problem Description] function (or API) device_get_ivars(9) from the file "/usr/src/sys/kern/subr_bus.c" returns a NULL pointer, which get assigned to *uaa structure object (function "uhub_probe" from file "/usr/src/sys/dev/usb/usb_bus.c"), then, after that there is a if-else condition which is checking the usb_mode from that structure and there panic occurs due to dereferencing the NULL pointer Same valid for other kernel drivers. [Background] devctl disable device: it is expected to disable the given device, and devctl enable device: it is supposed to enable the given disabled device. Panic occurs here, after enabling the already disabled device (but only with usb related drivers) [Impact] Puts FreeBSD OS/Kernel in panic mode and then to operate it, a reboot is required. [Privilege] Root privilege is required. [Reproducibility] Reproducibility is 100% [Workaround/Patch] Please find the attached patch for the file "usb_hub.c", "ng_ubt.c", "if_run.c", "umass.c" and "uhid.c" After appyling the patch, it first returns the "ENXIO" as mentioned in the patch code then later invocation returns "EBUSY" as device is enabled, which can be verified by disabling it again. diff -ruN freebsd_orig/sys/dev/usb/input/uhid.c freebsd_13/sys/dev/usb/input/uhid.c --- freebsd_orig/sys/dev/usb/input/uhid.c 2019-08-05 09:46:11.170388578 +0530 +++ freebsd_13/sys/dev/usb/input/uhid.c 2019-08-05 10:28:45.305146412 +0530 @@ -677,6 +677,9 @@ int error; void *buf; uint16_t len; + + if (uaa == NULL) + return (ENXIO); DPRINTFN(11, "\n"); diff -ruN freebsd_orig/sys/dev/usb/storage/umass.c freebsd_13/sys/dev/usb/storage/umass.c --- freebsd_orig/sys/dev/usb/storage/umass.c 2019-08-05 10:13:33.378982245 +0530 +++ freebsd_13/sys/dev/usb/storage/umass.c 2019-08-05 09:36:58.339765496 +0530 @@ -872,6 +872,9 @@ struct usb_attach_arg *uaa = device_get_ivars(dev); struct umass_probe_proto temp; + if (uaa == NULL) + return (ENXIO); + if (uaa->usb_mode != USB_MODE_HOST) { return (ENXIO); } diff -ruN freebsd_orig/sys/dev/usb/usb_hub.c freebsd_13/sys/dev/usb/usb_hub.c --- freebsd_orig/sys/dev/usb/usb_hub.c 2019-08-05 10:25:57.276874204 +0530 +++ freebsd_13/sys/dev/usb/usb_hub.c 2019-08-05 08:18:08.537617812 +0530 @@ -1111,6 +1111,9 @@ { struct usb_attach_arg *uaa = device_get_ivars(dev); + if (uaa == NULL) + return (ENXIO); + if (uaa->usb_mode != USB_MODE_HOST) return (ENXIO); diff -ruN freebsd_orig/sys/dev/usb/wlan/if_run.c freebsd_13/sys/dev/usb/wlan/if_run.c --- freebsd_orig/sys/dev/usb/wlan/if_run.c 2019-08-05 10:13:33.398982487 +0530 +++ freebsd_13/sys/dev/usb/wlan/if_run.c 2019-08-05 09:36:08.982716789 +0530 @@ -720,6 +720,8 @@ { struct usb_attach_arg *uaa = device_get_ivars(self); + if (uaa == NULL) + return (ENXIO); if (uaa->usb_mode != USB_MODE_HOST) return (ENXIO); if (uaa->info.bConfigIndex != 0) diff -ruN freebsd_orig/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c freebsd_13/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c --- freebsd_orig/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c 2019-08-05 10:13:33.318981516 +0530 +++ freebsd_13/sys/netgraph/bluetooth/drivers/ubt/ng_ubt.c 2019-08-05 09:33:46.941575792 +0530 @@ -513,6 +513,9 @@ struct usb_attach_arg *uaa = device_get_ivars(dev); int error; + if (uaa == NULL) + return (ENXIO); + if (uaa->usb_mode != USB_MODE_HOST) return (ENXIO); I have manually applied necessary checks for this bug to 5 device driver code (names are mentioned above) I have also tried to directly check for "NULL pointer" in the function "device_get_ivars(dev)" but it is returning directly to the structure as mentioned above but still a check is required to be at driver code for structure pointer, that is, *uaa. So, it wasn't working. Now, either we have to manually patch every driver files which are using the above structure with function "device_get_ivars(dev)" or we have to come up with the one line solution for all drivers. [PoC/Log File/binary] Please find the attached tar file in the link ( https://www.dropbox.com/s/hd1c0a518nrw749/crash_poc_info.tar.gz?dl=0) for PoC code, Log Files and PoC binary [Steps to Reproduce] - untar the file "crash_poc_info.tar.gz" - directly load binary from the directory "crash_poc/" or "make" it then load it - usage: ./crash_poc_bin -- For example: ./crash_bin_poc uhub0 or ./crash_bin_poc ubt0 [Attached Files] - Log crash info: "crash_13-current_info/" - PoC src and binary: "crash_poc_codeWith_binary/" - patch: "patch_info/" [Actual results] Panic Log as follows: freebsd dumped core - see ./vmcore.0 Sat Aug 3 17:31:43 UTC 2019 FreeBSD freebsd 13.0-CURRENT FreeBSD 13.0-CURRENT r350103 GENERIC amd64 panic: page fault GNU gdb (GDB) 8.3 [GDB v8.3 for FreeBSD] Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd13.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /boot/kernel/kernel... Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x38 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80a0ace1 stack pointer = 0x28:0xfffffe0017f97510 frame pointer = 0x28:0xfffffe0017f97510 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1005 (devctl) trap number = 12 panic: page fault cpuid = 3 time = 1564812037 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0017f971d0 vpanic() at vpanic+0x19d/frame 0xfffffe0017f97220 panic() at panic+0x43/frame 0xfffffe0017f97280 trap_fatal() at trap_fatal+0x39c/frame 0xfffffe0017f972e0 trap_pfault() at trap_pfault+0x62/frame 0xfffffe0017f97330 trap() at trap+0x2b4/frame 0xfffffe0017f97440 calltrap() at calltrap+0x8/frame 0xfffffe0017f97440 --- trap 0xc, rip = 0xffffffff80a0ace1, rsp = 0xfffffe0017f97510, rbp = 0xfffffe0017f97510 --- uhub_probe() at uhub_probe+0x11/frame 0xfffffe0017f97510 device_probe_child() at device_probe_child+0x194/frame 0xfffffe0017f97570 device_probe() at device_probe+0x98/frame 0xfffffe0017f975a0 device_probe_and_attach() at device_probe_and_attach+0x32/frame 0xfffffe0017f975d0 devctl2_ioctl() at devctl2_ioctl+0x5e2/frame 0xfffffe0017f976a0 devfs_ioctl() at devfs_ioctl+0xca/frame 0xfffffe0017f976f0 VOP_IOCTL_APV() at VOP_IOCTL_APV+0x63/frame 0xfffffe0017f97710 vn_ioctl() at vn_ioctl+0x13d/frame 0xfffffe0017f97820 devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfffffe0017f97840 kern_ioctl() at kern_ioctl+0x28a/frame 0xfffffe0017f978b0 sys_ioctl() at sys_ioctl+0x15d/frame 0xfffffe0017f97980 amd64_syscall() at amd64_syscall+0x2bb/frame 0xfffffe0017f97ab0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0017f97ab0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80041a31a, rsp = 0x7fffffffea38, rbp = 0x7fffffffeaf0 --- KDB: enter: panic __curthread () at /usr/src/sys/amd64/include/pcpu.h:246 warning: Source file is more recent than executable. 246 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (OFFSETOF_CURTHREAD)); (kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu.h:246 #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392 #2 0xffffffff8049d27b in db_dump (dummy=, dummy2=, dummy3=, dummy4=) at /usr/src/sys/ddb/db_command.c:575 #3 0xffffffff8049d049 in db_command (last_cmdp=, cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482 #4 0xffffffff8049cdc4 in db_command_loop () at /usr/src/sys/ddb/db_command.c:535 #5 0xffffffff8049ff6f in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:252 #6 0xffffffff80c1522c in kdb_trap (type=3, code=0, tf=) at /usr/src/sys/kern/subr_kdb.c:692 #7 0xffffffff81099ba1 in trap (frame=0xfffffe0017f97100) at /usr/src/sys/amd64/amd64/trap.c:621 #8 #9 kdb_enter (why=0xffffffff8132cf49 "panic", msg=) at /usr/src/sys/kern/subr_kdb.c:479 #10 0xffffffff80bcad6a in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:894 #11 0xffffffff80bcaae3 in panic ( fmt=0xffffffff81e88898 "\233\036/\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:832 #12 0xffffffff81099ffc in trap_fatal (frame=0xfffffe0017f97450, eva=56) at /usr/src/sys/amd64/amd64/trap.c:943 #13 0xffffffff8109a062 in trap_pfault (frame=0xfffffe0017f97450, usermode=) at /usr/src/sys/amd64/amd64/trap.c:767 #14 0xffffffff81099644 in trap (frame=0xfffffe0017f97450) at /usr/src/sys/amd64/amd64/trap.c:443 #15 #16 uhub_probe (dev=) at /usr/src/sys/dev/usb/usb_hub.c:1114 #17 0xffffffff80c02574 in DEVICE_PROBE (dev=) at ./device_if.h:115 #18 device_probe_child (dev=0xfffff80003242b00, child=0xfffff800031ff400) at /usr/src/sys/kern/subr_bus.c:2150 #19 0xffffffff80c03388 in device_probe (dev=0xfffff800031ff400) at /usr/src/sys/kern/subr_bus.c:2897 #20 0xffffffff80c03442 in device_probe_and_attach (dev=0xfffff800031ff400) at /usr/src/sys/kern/subr_bus.c:2921 #21 0xffffffff80c08f22 in devctl2_ioctl (cdev=, cmd=, data=0xfffff8002bf80200 "uhub0", fflag=, td=) at /usr/src/sys/kern/subr_bus.c:1776 #22 0xffffffff80a8622a in devfs_ioctl (ap=0xfffffe0017f97728) at /usr/src/sys/fs/devfs/devfs_vnops.c:834 #23 0xffffffff81220263 in VOP_IOCTL_APV ( vop=0xffffffff81aeb458 , a=0xfffffe0017f97728) at vnode_if.c:1052 #24 0xffffffff80cb062d in vn_ioctl (fp=0xfffff80003cce960, com=, data=0xfffff8002bf80200, active_cred=0xfffff800032ba500, td=0x246) at /usr/src/sys/kern/vfs_vnops.c:1492 #25 0xffffffff80a868bf in devfs_ioctl_f (fp=0xfffff800031ff400, com=18446744071590345336, data=0x18, cred=0x0, td=0xfffff8002b3d1000) at /usr/src/sys/fs/devfs/devfs_vnops.c:766 #26 0xffffffff80c3ae2a in fo_ioctl (fp=, com=, data=0xffffffff81fd09d0 , active_cred=0x0, td=) at /usr/src/sys/sys/file.h:333 #27 kern_ioctl (td=, fd=, com=2157462531, data=0xffffffff81fd09d0 "") at /usr/src/sys/kern/sys_generic.c:800 #28 0xffffffff80c3ab2d in sys_ioctl (td=0xfffff8002b3d1000, uap=0xfffff8002b3d13c8) at /usr/src/sys/kern/sys_generic.c:712 #29 0xffffffff8109ab2b in syscallenter (td=0xfffff8002b3d1000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144 #30 amd64_syscall (td=0xfffff8002b3d1000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1180 #31 #32 0x000000080041a31a in ?? () Backtrace stopped: Cannot access memory at address 0x7fffffffea38 (kgdb) Please confirm and let me know if any other info required. -- Thank you! Sincere regards, Neeraj Pal From owner-freebsd-arch@freebsd.org Tue Aug 13 20:09:03 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 AC991BB00A for ; Tue, 13 Aug 2019 20:09:03 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 467P1W2FR0z4KRw for ; Tue, 13 Aug 2019 20:09:02 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1565726941; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Bw51gDIrozopex5ItFHQJPckSNCnzJVUscqlOMhCB5APAL+ey1VMGK7RKYtPzTQQjVdxEWMaQxZms dNJLoSmShnyslothtoshBypDd8XtsjIuS3mb+1WPYaK9qiSJeJvNS0p/gjrMHZBupVxNLEQtmWkfpG wIKOsVwqNg25YTvD8By+7ZtfHxvpjgt6zqrIhBbiIVZPDyxg60GV9DjsvxckPM0YCvam7zn2uz7YQy RNV0UiwuquyG+Ubq613YUT0q8v8Oi89RM+OcuzsSEVWH9xnsw0KgWHtmXHDAI8eJA5oH9EpSEMi4kB hmDPArVNxXA9uPFbHy2FNKF5z/QdyeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=n6tMl5rNL6RKnd/gbflS6y6IWsXZt8teB/NsgrJqErk=; b=QrISt8KkpbvJWfJDwG3pNvAFoe0LnH6ObBTcPs6thN3zfT/wrEEN2IXc6r3sPMj6crt6MojOVAtmf g0HX/2JUIZfY1QEenNzEUbWtl7ldduaXmZ/+V/IFi2KJWs03JszBAO380fs4EdGb1KgZ8I+rk8+FZy OpJkCEZynKAIVrr55S6exis1pfi28b5cfcxyy/roAMeUGjucGLlHzOCEHxAxC3cHSB4hQ0DDNzDnax DCI2m1KZLaaeHSAKa+4S1VBHBEiQiLTDNiwiKH0alyemyAFCd626xe6NtkbRvbPlTB+fZkZDItMDbK 7Gb7z0i9g2RewyBWTyqALY5u8CBvztg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=n6tMl5rNL6RKnd/gbflS6y6IWsXZt8teB/NsgrJqErk=; b=FgGF4LiBefF+GtLZUGmdBsUQz06ZwPXQfHCdKznZij32DDZJK4EKx1j89EYby3C5C5i3nuFU42uSe 8zdyQMCdethCbksakZ+QXL3d5ZqkxiZMrr54DT2QdNHLr9NATk5kQl3KyWNUGZwAmj4joAX9hNU2gH T/vwkfxsiuHfoDtrciuD4aa7nU9/qxIm1+/x1H+fpm+iXJs9S42FWMOcgjxrZyZwic1Z6TaBnnGFcr T1GIyEDWw2+fGqW+S6BQAkKbNRjcYsXOVk6k3JwthBx3dZElC1Ii0tC+sWCmfD2ImvvYDnjp7+DOei 2TnESTI7eW8qUk4Urju7/2MgiIZ8wXw== X-MHO-RoutePath: aGlwcGll X-MHO-User: 2f8a8ba3-be06-11e9-85ec-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 2f8a8ba3-be06-11e9-85ec-13b9aae3a1d2; Tue, 13 Aug 2019 20:09:00 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x7DK8wZt050891; Tue, 13 Aug 2019 14:08:58 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: Subject: Re: Regarding the bug in FreeBSD kernel driver(s) From: Ian Lepore To: Neeraj Pal , freebsd-arch@freebsd.org Cc: Hans Petter Selasky Date: Tue, 13 Aug 2019 14:08:58 -0600 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 467P1W2FR0z4KRw X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US] 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: Tue, 13 Aug 2019 20:09:03 -0000 On Wed, 2019-08-14 at 01:10 +0530, Neeraj Pal wrote: > Hi there, > > After discussing the issue with the security-team, I have posted it > publicly. > > Please find the bug information given below with workaround diff: > > I have observed the "NULL pointer dereference" bug inside the FreeBSD > kernel driver code due to which kernel gets in panic (or DOS) mode > and then > it has to reboot. > > Actually, this vulnerability resides in lots of kernel drivers like > "uhub0", "ubt0", "umass0", "run0", "uhid0" etc. > > I have tested and observed the panic for following kernel drivers: > > - usb, > - umass (storage), > - ubt(bluetooth), > - run0(wifi), > - uhid > > [...] > > Please confirm and let me know if any other info required. > It appears the problem is limited to usb devices, not all devices in the system. It looks like the root of the NULL ivars problem is this code from usb_device.c: if (device_probe_and_attach(iface->subdev) == 0) { /* * The USB attach arguments are only available during probe * and attach ! */ uaa->temp_dev = NULL; device_set_ivars(iface->subdev, NULL); ... So once a device is attached the first time, its usb ivars are wiped out. That code was surely written in a time before the devctl stuff was added to allow disabling/enabling a device on the fly. I'm not sure whether it will be easy to keep the ivar data around, but if so, I think that would be the right fix. The NULL pointer checks in the patches will prevent a kernel panic, but don't really make devctl enable work properly. Speaking of devctl, you don't need a program to test this, you can do it from the command line: devctl disable uhub2 devctl enable uhub2 -- Ian From owner-freebsd-arch@freebsd.org Tue Aug 13 20:15:44 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 1FFA1BB2D8 for ; Tue, 13 Aug 2019 20:15:44 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 467P9B3PdQz4Ks5; Tue, 13 Aug 2019 20:15:41 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 05C2C260205; Tue, 13 Aug 2019 22:15:32 +0200 (CEST) Subject: Re: Regarding the bug in FreeBSD kernel driver(s) To: Ian Lepore , Neeraj Pal , freebsd-arch@freebsd.org References: From: Hans Petter Selasky Message-ID: <52d24915-d295-806d-55c6-f801ef340c7f@selasky.org> Date: Tue, 13 Aug 2019 22:14:52 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 467P9B3PdQz4Ks5 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.84 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.963,0]; IP_SCORE(-2.58)[ip: (-9.11), ipnet: 2a01:4f8::/29(-1.94), asn: 24940(-1.83), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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: Tue, 13 Aug 2019 20:15:44 -0000 On 2019-08-13 22:08, Ian Lepore wrote: > So once a device is attached the first time, its usb ivars are wiped > out. That code was surely written in a time before the devctl stuff > was added to allow disabling/enabling a device on the fly. I'm not > sure whether it will be easy to keep the ivar data around, but if so, I > think that would be the right fix. > > The NULL pointer checks in the patches will prevent a kernel panic, but > don't really make devctl enable work properly. Speaking of devctl, you > don't need a program to test this, you can do it from the command line: > > devctl disable uhub2 > devctl enable uhub2 > Hi, USB drivers are not supposed to be managed outside the USB enumeration thread. Using devctl on USB driver is not supported. Only usbconfig is allowed to attach/detach USB devices. Should we perhaps teach devctl to not touch USB devices? --HPS From owner-freebsd-arch@freebsd.org Tue Aug 13 20:19:07 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 60751BB3E7 for ; Tue, 13 Aug 2019 20:19:07 +0000 (UTC) (envelope-from neerajpal09@gmail.com) Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467PF71tfjz4L0g; Tue, 13 Aug 2019 20:19:07 +0000 (UTC) (envelope-from neerajpal09@gmail.com) Received: by mail-oi1-x243.google.com with SMTP id c15so14259967oic.3; Tue, 13 Aug 2019 13:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pgjbtF/BSZIUNkHhEAvNNK6E2/lp3qr++NM3eCBA9rY=; b=uGt0GpU1Wza+O9725ViJyafiqi40oXqd1egLf4qk60dJGBPdlEHUtnYB1nF/g9LDH2 LDRQB6/iAaImkvPcgkt8p8ENV4IfzeYPJOEwkxiVIMgidS6bw6epEXbTwm5dkeDj/lJe f67jpXUh91LFmZnM8IO2rR3fM8IUmOqVEz2ZXda+RHF3LMCJ4pnerv4tb8/skEcA44aM 1RwQS95yFTWhVT431kS2ZHDAO4nKhkW38KtcyyVygkpthcb59YxiudDf2mozs1Voc9ni Enlj5VMye5VtmjOFyNI//6uirweyJIDXg3sGTIZKFGbdRkmtw+kJFhXlDFvnuVtCf0YC oegg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pgjbtF/BSZIUNkHhEAvNNK6E2/lp3qr++NM3eCBA9rY=; b=Y+b239Q2ampZuHGVRyPT2jbf3RFEjwjEpQQ3IE9YiL0vNh8xcJ7b3H7g2rV92S/OEf izJqA8m3aIe+EqZnPO+WYdZsJuk38v9KVSPsiZeQVz+s3aqaPOYqnW/pqDYEAJSHjQzk UEFiNNdDBk7+KqMhN46O9jOb+LpMD3vdlwRZ8r17L1zOHYphviwGlL+ie179e4Xw/KSB EkZ9WatkrUVwWCzmN0QfSi8zBMfnAPbDXVOq+S1Km9ceDcAxjERbNv/0ebBEzXDtZtjv pWGghKpHRgFIWOmGkhZu6V6GnUeCk7sDy+Am5MUj/snJP34OFGtltrApaMXppxRrYpch c92Q== X-Gm-Message-State: APjAAAWk3mtwaWRnJ27SLYH/DlIHEA8cbbvp6VRZi7igPsPhG41o/8Jo DrDCnn7Wk5gsL9AF57MEJ854moAd1YvAkjBxq0A7+o4jpkU= X-Google-Smtp-Source: APXvYqyYvIdhpUYNBa4miAYo/O5+lYQ6z0O7/N/h6R1Z/BaRSG3muaq1v7rJ0yxZjkXtMg883dvW2pbJo+NIG776fzs= X-Received: by 2002:aca:d44f:: with SMTP id l76mr2740021oig.172.1565727545404; Tue, 13 Aug 2019 13:19:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neeraj Pal Date: Wed, 14 Aug 2019 01:48:54 +0530 Message-ID: Subject: Re: Regarding the bug in FreeBSD kernel driver(s) To: Ian Lepore Cc: freebsd-arch@freebsd.org, Hans Petter Selasky Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 467PF71tfjz4L0g X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.985,0] 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: Tue, 13 Aug 2019 20:19:07 -0000 Hi Ian, On Wed, Aug 14, 2019 at 1:39 AM Ian Lepore wrote: > > On Wed, 2019-08-14 at 01:10 +0530, Neeraj Pal wrote: > > Hi there, > > > > After discussing the issue with the security-team, I have posted it > > publicly. > > > > Please find the bug information given below with workaround diff: > > > > I have observed the "NULL pointer dereference" bug inside the FreeBSD > > kernel driver code due to which kernel gets in panic (or DOS) mode > > and then > > it has to reboot. > > > > Actually, this vulnerability resides in lots of kernel drivers like > > "uhub0", "ubt0", "umass0", "run0", "uhid0" etc. > > > > I have tested and observed the panic for following kernel drivers: > > > > - usb, > > - umass (storage), > > - ubt(bluetooth), > > - run0(wifi), > > - uhid > > > > [...] > > > > Please confirm and let me know if any other info required. > > > > It appears the problem is limited to usb devices, not all devices in > the system. It looks like the root of the NULL ivars problem is this > code from usb_device.c: > > if (device_probe_and_attach(iface->subdev) == 0) { > /* > * The USB attach arguments are only available during probe > * and attach ! > */ > uaa->temp_dev = NULL; > device_set_ivars(iface->subdev, NULL); > ... > > So once a device is attached the first time, its usb ivars are wiped > out. That code was surely written in a time before the devctl stuff > was added to allow disabling/enabling a device on the fly. I'm not > sure whether it will be easy to keep the ivar data around, but if so, I > think that would be the right fix. Yeah, as I informed it is only limited to usb devices, especially, those which are using struct usb_attach_arg with api device_get_ivar(9). > > The NULL pointer checks in the patches will prevent a kernel panic, but > don't really make devctl enable work properly. Speaking of devctl, you > don't need a program to test this, you can do it from the command line: > > devctl disable uhub2 > devctl enable uhub2 > And, yeah it will remove the panic and I verified the devctl after patching with the code and it seems working fine, like enabling and disabling. So, I attached the patch. Please feel free to modify it as per requirements. Yeah, you are right, but for the sack of PoC, I have modified the same devctl code to remove the unnecessary devctl commands. My initial test attempts were from command line only. -- Thank you! Sincere regards; Neeraj Pal From owner-freebsd-arch@freebsd.org Tue Aug 13 20:49:25 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 A560FBC3C4 for ; Tue, 13 Aug 2019 20:49:25 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 467Pw53t5mz4MYp for ; Tue, 13 Aug 2019 20:49:25 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 82FD2BC3C2; Tue, 13 Aug 2019 20:49:25 +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 82BD7BC3C1 for ; Tue, 13 Aug 2019 20:49:25 +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 467Pw52tKsz4MYn; Tue, 13 Aug 2019 20:49:25 +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 E8C1E1089C; Tue, 13 Aug 2019 20:49:24 +0000 (UTC) (envelope-from pfg@FreeBSD.org) To: Warner Losh Cc: "freebsd-arch@freebsd.org" From: Pedro Giffuni Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline Organization: FreeBSD Message-ID: <542de336-f030-04f9-27d4-bebc96ab20fd@FreeBSD.org> Date: Tue, 13 Aug 2019 15:49:22 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 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: Tue, 13 Aug 2019 20:49:25 -0000 > 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 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. Pedro. From owner-freebsd-arch@freebsd.org Tue Aug 13 23:10:04 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 5BD79C07DA for ; Tue, 13 Aug 2019 23:10:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 467T2N0HYSz4XlH for ; Tue, 13 Aug 2019 23:10:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.nyi.freebsd.org (Postfix) id 08184C07D9; Tue, 13 Aug 2019 23:10:04 +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 07DA5C07D8 for ; Tue, 13 Aug 2019 23:10:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467T2M1Qd7z4XlF for ; Tue, 13 Aug 2019 23:10:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x834.google.com with SMTP id z4so108270150qtc.3 for ; Tue, 13 Aug 2019 16:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H3KHgiqkpnhOqkEWnJveFor5QkZI+h5zKIQdgYTqdtw=; b=RaWFnygSyI5gJfRQe+gaydyVtP+8bK1Qpvmr4++s6dQTY/iPPWTv9bbuuhr4e4O3Sh 1gdi/WPlTWW0vr6a+ngHy9k5Zu94n/65ynghbWcA+0OvMkaQLfTUZCFoTmpdj2rasS+s rU/n54fWHsakB/V5DSMHgvl8E4ou/8XV/WYjVdEHgtOU8O+/plHh/mOZlZ21BCcf9AZ7 vu9xihqViueV6V1n3b/bpVSsSfYDYat9C1BDaq+hqQ/KZL3q7I1mE2y3ymajrzSsF/b/ u4rfnpZealwc4QfGcrM2yNTjKYzYCUjHvaA6LUjFokd+kE79srkJCtEHlIeleoXoatcc Mi4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H3KHgiqkpnhOqkEWnJveFor5QkZI+h5zKIQdgYTqdtw=; b=XRKNbBMjbH2fA0b2dzW3mn0nqoiB8huafZeibNnkXwqSgJu8VTFAuwDz6UfH7z95AV S2T6OAQVMFpzr2DVIBS/IdVQreiDiUNRYK8OTX/FVBiXXvxUE3C1PC4z1ajtz/h45/3O 7LbSbmdyQ2UzRfj+dSkJ/h6GGoKTqGUo437AeJjWeJgU8htMl37a3AD945Dk+vk6+gW8 +NbDPqSJy6Dl7w6XSNEox60z7erakIIGPrr1AHYwJdFINkSCEjqdsQ+/hI/JpGkVIfAe ULGRAgYv09ZTHVdqnvzekOnARDbbpdxQOXGcjXlDUq41lCPxJXqFugtxXPVlKCUA6/Qu eb4w== X-Gm-Message-State: APjAAAW6p8Ke5V/c+8oLLbIKuaLWOs/chrPsZh8r/n1MGZzMSmnpnDtP XXq72hzk45lC99HMrIx6nUFqAB9Rc9Bsoz28isJN62OdclI= X-Google-Smtp-Source: APXvYqzISUAt6w+pWinmMWKYwIW+Yth/DdWrSsj/nG5mh5RmuH1Gea/x49kEWKAwrR5uhHsYeITCr8uuRZmC/NVXzmM= X-Received: by 2002:aed:34a6:: with SMTP id x35mr6857269qtd.187.1565737801800; Tue, 13 Aug 2019 16:10:01 -0700 (PDT) MIME-Version: 1.0 References: <542de336-f030-04f9-27d4-bebc96ab20fd@FreeBSD.org> In-Reply-To: <542de336-f030-04f9-27d4-bebc96ab20fd@FreeBSD.org> From: Warner Losh Date: Tue, 13 Aug 2019 17:09:50 -0600 Message-ID: Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: Pedro Giffuni Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 467T2M1Qd7z4XlF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=RaWFnygS; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::834) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-4.96 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[4.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.99)[-0.992,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.97)[ip: (-9.44), ipnet: 2607:f8b0::/32(-2.97), asn: 15169(-2.39), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" 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: Tue, 13 Aug 2019 23:10:04 -0000 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. It's likely a few hours of somebody's time to create. 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? Warner 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. From owner-freebsd-arch@freebsd.org Wed Aug 14 13:07:10 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 2DB09AB0B4 for ; Wed, 14 Aug 2019 13:07:10 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 467qcF2KlWz4HpC for ; Wed, 14 Aug 2019 13:07:09 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id z17so63642642otk.13 for ; Wed, 14 Aug 2019 06:07:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8bzTU0FTEmRqEL1c5VATruaEGzJJDxt7zZSfcBXNTuU=; b=ZkVQrFHg4PeSuJtn/vbpAe2mW9Ob7qyXdXuzJBbPLiQvcaJhp05s6SUwj2NKdzFnt9 +TR4fZon8elbk825zhtZwKQIjVbvQu9HlAKWREpxh5DwU/NpjKad/LGyRjIC/JgFVFgf aJaQa6j89zTiVpCdhSUxr4tjhKO1txdjX0xR+W81YiOce4bUhysU05ZOLqBmnh/+drp8 dIzUpTfL5AkkYPMhn8ewIsv1ymgeaZ+YBJctRWfTiExL2G1b3eXBcm5A2plljTxQLOxm GnMM7RoOET4OYd2fZurr2993YEPSiGodR5f1WcfElvP+jpX3mpMkilNXq2nVji6Q8GHG 2sKw== X-Gm-Message-State: APjAAAU+IE3cMQuq1j5Duiz96o/qG1cmgs6EGfnD/BmF4ItugGefvEIU Gb9Q6ApZXF2oitYW27Y64V82/ecnxxioYLDjO69sDT8Q X-Google-Smtp-Source: APXvYqwrUqeC54v+jOGg+AAK4PWMYHmD9hGaWenibJH/88ORSjW0IIsQB5L65yFCAVgyT4rEARiGE3rCJw3U5ojlop8= X-Received: by 2002:a5e:881a:: with SMTP id l26mr5678673ioj.185.1565788028144; Wed, 14 Aug 2019 06:07:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ed Maste Date: Tue, 13 Aug 2019 19:10:12 -0400 Message-ID: Subject: Re: Gcc 4.2.1 to be removed before FreeBSD 13, a firm timeline To: Warner Losh Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 467qcF2KlWz4HpC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.210.41 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com X-Spamd-Result: default: False [-4.26 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.995,0]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[41.210.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.27)[ip: (-0.53), ipnet: 209.85.128.0/17(-3.37), asn: 15169(-2.39), country: US(-0.05)]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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 13:07:10 -0000 On Tue, 13 Aug 2019 at 12:00, Warner Losh 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. PR 228919 [1] is open to track GCC 4.2.1 removal, and the dependency tree view [2] provides a convenient way to see the open identified issues that need to be addressed. [1] https://bugs.freebsd.org/228919 [2] https://bugs.freebsd.org/bugzilla/showdependencytree.cgi?id=228919&hide_resolved=1 From owner-freebsd-arch@freebsd.org Wed Aug 14 15:47:29 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 9DE3CB001A for ; Wed, 14 Aug 2019 15:47:29 +0000 (UTC) (envelope-from jhb@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 467v9F3jHFz4TB0; Wed, 14 Aug 2019 15:47:29 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id BFDBE18F29; Wed, 14 Aug 2019 15:47:28 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Regarding the bug in FreeBSD kernel driver(s) To: Hans Petter Selasky , Ian Lepore , Neeraj Pal , freebsd-arch@freebsd.org References: <52d24915-d295-806d-55c6-f801ef340c7f@selasky.org> From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <3c8e80d0-d5c8-8e13-bdd4-50f509416550@FreeBSD.org> Date: Wed, 14 Aug 2019 08:47:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <52d24915-d295-806d-55c6-f801ef340c7f@selasky.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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 15:47:29 -0000 On 8/13/19 1:14 PM, Hans Petter Selasky wrote: > On 2019-08-13 22:08, Ian Lepore wrote: >> So once a device is attached the first time, its usb ivars are wiped >> out. That code was surely written in a time before the devctl stuff >> was added to allow disabling/enabling a device on the fly. I'm not >> sure whether it will be easy to keep the ivar data around, but if so, I >> think that would be the right fix. >> >> The NULL pointer checks in the patches will prevent a kernel panic, but >> don't really make devctl enable work properly. Speaking of devctl, you >> don't need a program to test this, you can do it from the command line: >> >> devctl disable uhub2 >> devctl enable uhub2 >> > > Hi, > > USB drivers are not supposed to be managed outside the USB enumeration > thread. Using devctl on USB driver is not supported. Only usbconfig is > allowed to attach/detach USB devices. > > Should we perhaps teach devctl to not touch USB devices? I think fixing USB to not break by preserving ivars is probably a better long-term solution. ivars are not supposed to be freed and rebuilt but should exist for the lifetime of a device_t. -- John Baldwin From owner-freebsd-arch@freebsd.org Wed Aug 14 18:48:16 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 C4E32B673F for ; Wed, 14 Aug 2019 18:48:16 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 467z9q5C6bz3HKH; Wed, 14 Aug 2019 18:48:15 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.235]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B21732602AB; Wed, 14 Aug 2019 20:48:10 +0200 (CEST) Subject: Re: Regarding the bug in FreeBSD kernel driver(s) To: John Baldwin , Ian Lepore , Neeraj Pal , freebsd-arch@freebsd.org References: <52d24915-d295-806d-55c6-f801ef340c7f@selasky.org> <3c8e80d0-d5c8-8e13-bdd4-50f509416550@FreeBSD.org> From: Hans Petter Selasky Message-ID: Date: Wed, 14 Aug 2019 20:47:30 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3c8e80d0-d5c8-8e13-bdd4-50f509416550@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 467z9q5C6bz3HKH X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 2a01:4f8:c17:6c4b::2 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-5.83 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.95)[-0.950,0]; IP_SCORE(-2.58)[ip: (-9.11), ipnet: 2a01:4f8::/29(-1.94), asn: 24940(-1.84), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] 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 18:48:16 -0000 On 2019-08-14 17:47, John Baldwin wrote: > I think fixing USB to not break by preserving ivars is probably a better > long-term solution. ivars are not supposed to be freed and rebuilt but > should exist for the lifetime of a device_t. Even if you fix the ivars, there might be a race, that devctl is attaching/detaching drivers while USB is doing the same. So basically if you add that NULL check, running devctl in a tight loop will still provoke a panic. That's why I think devctl should come with a warning by default. --HPS From owner-freebsd-arch@freebsd.org Thu Aug 15 18:12:33 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 52661B1CA9 for ; Thu, 15 Aug 2019 18:12:33 +0000 (UTC) (envelope-from jhb@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 468ZL91Llkz4F7r for ; Thu, 15 Aug 2019 18:12:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id 2E301B1CA7; Thu, 15 Aug 2019 18:12:33 +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 2DBECB1CA6 for ; Thu, 15 Aug 2019 18:12:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 468ZL90F0bz4F7m for ; Thu, 15 Aug 2019 18:12:33 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-4.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id AF63E568A for ; Thu, 15 Aug 2019 18:12:32 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: "freebsd-arch@freebsd.org" From: John Baldwin Subject: Patch for review: Kernel portion of in-kernel TLS (KTLS) Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <24f79e96-f1f2-e502-71a7-d45d2966bbf9@FreeBSD.org> Date: Thu, 15 Aug 2019 11:12:29 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Thu, 15 Aug 2019 18:12:33 -0000 One of the projects I have been working on for the past several months in conjunction with several other folks is upstreaming work from Netflix to handle some aspects of Transport Layer Security (TLS) in the kernel. In particular, this lets a web server use sendfile() to send static content on HTTPS connections. There is a lot more detail in the review itself, so I will spare pasting a big wall of text here. However, I have posted the patch to add the kernel-side of KTLS for review at the URL below. KTLS also requires other patches to OpenSSL and nginx, but this review is only for the kernel bits. Patches and reviews for the other bits will follow later. https://reviews.freebsd.org/D21277 -- John Baldwin