From owner-freebsd-toolchain@freebsd.org Fri Aug 26 16:43:05 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 321CBB74F71 for ; Fri, 26 Aug 2016 16:43:05 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EE1E1EE3 for ; Fri, 26 Aug 2016 16:43:04 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1472229783; bh=9ZVW2WmW6QvaQI79JpEL/4z+oUUJEOo0lguNmhDkV1Y=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=kMPZ4QOqr5j9LY1QQvXNeu/7BFpVlAhoMbFZ8zH8X1AVv3Q7rUiYSioc6N/pVwlH+7wGdd2toHX6K+mJ0sLD8LMkHptIxZhHGXrIytzyFP4xttnLg4L/GMdE3iJcD6pBG0MpRuNys4+LyMRssa0tTJ05STZ2TgViCHQkfTTlrzAJYzthyeDvum7XSjzgBujXhXbD0S+2QtkZhAUVhNhqt4Fy8wO8B2k9BhB3DtZK+t+Hmzh5HjiY9wmBUBGsk+pcX3VjSZD8VZ3I6bF/TEZUSTP6jKBt8n1IYS+RVwNcl4LTNZEeiHb03ECs9yRV1SAlGUy+dgg8JDVdI1IRIOfOsA== Received: from [98.139.215.140] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 16:43:03 -0000 Received: from [98.139.211.203] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 16:43:03 -0000 Received: from [127.0.0.1] by smtp212.mail.bf1.yahoo.com with NNFMP; 26 Aug 2016 16:43:03 -0000 X-Yahoo-Newman-Id: 575161.60388.bm@smtp212.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: b2si3lYVM1kj4rRFCgCr3llxsfhjsspeOCkGhKbCyiqB.dM PoE52V0z1KeyfJQhUQdxxOYyf8dVjoSVuE5jf67iG0bibLk4t0ttRpM9ca0d DcHMSBKUPlUrPo09.MRRhPTUuOzdUAIEAoPc3wC6onzY0c5A9ne8BSqB6zUT oL0aW8lD6ouScypIoAlDiFlw6hc6NIzZKOXFH4f7DntOXekzcTGa1OcWB9I9 iNTjGG.EnPGRM5oO0yw5aGcXK7Kn9BMR6BNgoo16jknzPPHJU88yXiNDRGlO sMmIZA4leJWjWri24FL1brOfuqS9PBu6s44vyAgnyqkm4mXtvkgXuUnM4DE3 lQMYEl3zttFOVqYgnOqDw0kCIQG.rWFJzM97WAdvN2UQLm_Yvw9YA22tglwz gkpwI_9TB1pkvpdFRcC2ZUl2dgZaUzunEkZkiQmHk28a3wMjUyExOrokPd2P j_HVsiT7vx2iOxrsIDRlxsFuF3Dd5kD8vcRtHQ5YHI1zCiofE.cSJ0PDTWXv rpjS2acqJTyIEHD0ZbuTBL.B30eRHlHyXENfLCdtZu2d7kg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Subject: Re: Time to enable partial relro To: Konstantin Belousov References: <20160826105618.GS83214@kib.kiev.ua> <20160826160009.GU83214@kib.kiev.ua> Cc: freebsd-toolchain@FreeBSD.org From: Pedro Giffuni Message-ID: Date: Fri, 26 Aug 2016 11:43:13 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160826160009.GU83214@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 16:43:05 -0000 Hello; On 26/08/2016 11:00, Konstantin Belousov wrote: > On Fri, Aug 26, 2016 at 10:00:58AM -0500, Pedro Giffuni wrote: >> >> On 08/26/16 05:56, Konstantin Belousov wrote: >>> On Thu, Aug 25, 2016 at 05:50:31PM -0500, Pedro Giffuni wrote: >>>> Hello; >>>> >>>> GNU RELRO support was committed in r230784 (2012-01-30) but we never >>>> enabled it by default. >>>> >>>> There was some discussion about it on >>>> https://reviews.freebsd.org/D3001 >>>> >>>> By now, all Linux distributions, NetBSD and DragonFly support it and >>>> it is the default for most systems in binutils 2.27. >>>> >>>> This doesn't affect performance, I ran it through an exp-run last >>>> year, no other OS has had issues etc ... seems safe and can be >>>> disabled if needed when linking. >>> Exp-run does not test anything interesting about relro. If all testing >>> that was done is basically just an exp-run, then there was no useful >>> runtime testing done. >>> >> The exp-run does cover Java and other VM-type thingies that bootstrap. >> For upstream binutils this is now the default (at least for linux, >> they never ask us if we want to follow). So the change has been tested >> extensively but perhaps not on cases that are relevant to us. >> >> Note that the "fix" for any port is ultimately trivial: >> LDFLAGS+= "-z norelro" >> >>>> I think it's time to enable it be default in our base binutils. If >>>> there are no objections, I will just commit the attached patch over >>>> the weekend. >>> There are objections, the change must be runtime tested on large and >>> representative set of real-world applications before turning the knob. >>> >> You are not giving any hint on what would be a "representative set of >> real-world applications". Given that you committed the initial support >> your objection stands very high and is a blocker. :( > Well, I indeed do not think that 'works on my desktop' is good enough > testing for this change. I understand that it is impossible to test > all ports at runtime, or even a significant percentage of them, not to > mention programs which sit on the user's storage. > > What actually worries me in the fate of such changes is that submitter > never starts monitoring user complains and see whether the change causes > some delayed random breakage. It just ends up in the 'BSD is broken' > basket with one more supportive case. The change is now in linux too, so they will be saying "BSD and Linux are broken". ;) I understand the concern, and admittedly there's no way to catch all issues, but that's why we have -current and -stable, so we can isolate all of those cases before the users in a release get hit by it. I see this change pretty much in the lines of the "stack-protector-strong" change: FreeBSD 11 will be the first release to include the change (only in base). I recall there was one overflow in the FAT filesystem which was caught by the change and by now I hope/wish we have figured out any issue. Had we committed the change earlier it might have received more testing. There is no perfect time to make such changes but it's better to try to keep in line with the changes upstream (binutils in this case) than to stay still while the rest of the world moves on. >> As I see it committing it now would give ample time to test this in >> current before it hits any release. If you want more extensive testing >> merging it in -stable right after the 11-Release is guaranteed to help >> weed out any remaining update ports may need. > It is useless 'testing' when the cause of breakage is not actively > looked for and identified. You commit it now, five months later some > unlucky user reports that his application coredumps. What next ? Unlucky user must be running -current to be affected: if we don't MFC the change it will take more than one year until it hits end users in a release. If the breakage is in base, we want to know as early as we can, if the breakage is in third party ports, they will benefit from upstream getting the BSD and linux breakage reports. BTW, I wonder how lld handles RELRO, is it supported or even the default? Pedro.