From owner-svn-src-head@FreeBSD.ORG Sun Jun 8 20:49:56 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC1F473B; Sun, 8 Jun 2014 20:49:56 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 69ECF27AD; Sun, 8 Jun 2014 20:49:56 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s58KnpLu094225; Sun, 8 Jun 2014 23:49:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s58KnpLu094225 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s58KnpWP094224; Sun, 8 Jun 2014 23:49:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 8 Jun 2014 23:49:50 +0300 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: svn commit: r267233 - in head: . bin/rmail gnu/usr.bin/binutils/addr2line gnu/usr.bin/binutils/nm gnu/usr.bin/binutils/objcopy gnu/usr.bin/binutils/objdump gnu/usr.bin/binutils/readelf gnu/usr.bin/... Message-ID: <20140608204950.GC3991@kib.kiev.ua> References: <201406081729.s58HTWkc006213@svn.freebsd.org> <74512A27-DD5F-4D43-BFA1-0AC04E0D08B4@FreeBSD.org> <20140608182728.GX3991@kib.kiev.ua> <5394ABD2.5040009@mu.org> <20140608184451.GZ3991@kib.kiev.ua> <5394B607.1000109@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SuZWD+5recMkC1v4" Content-Disposition: inline In-Reply-To: <5394B607.1000109@mu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bryan Drewery X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jun 2014 20:49:56 -0000 --SuZWD+5recMkC1v4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 08, 2014 at 12:14:15PM -0700, Alfred Perlstein wrote: > On 6/8/14 11:44 AM, Konstantin Belousov wrote: > > On Sun, Jun 08, 2014 at 11:30:42AM -0700, Alfred Perlstein wrote: > >> On 6/8/14 11:27 AM, Konstantin Belousov wrote: > >>> On Sun, Jun 08, 2014 at 05:38:49PM +0000, Bjoern A. Zeeb wrote: > >>>> On 08 Jun 2014, at 17:29 , Bryan Drewery wrot= e: > >>>> > >>>>> Author: bdrewery > >>>>> Date: Sun Jun 8 17:29:31 2014 > >>>>> New Revision: 267233 > >>>>> URL: http://svnweb.freebsd.org/changeset/base/267233 > >>>>> > >>>>> Log: > >>>>> In preparation for ASLR [1] support add WITH_PIE to support buil= ding with -fPIE. > >>>>> > >>>>> This is currently an opt-in build flag. Once ASLR support is rea= dy and stable > >>>>> it should changed to opt-out and be enabled by default along wit= h ASLR. > >>>>> > >>>>> Each application Makefile uses opt-out to ensure that ASLR will = be enabled by > >>>>> default in new directories when the system is compiled with PIE/= ASLR. [2] > >>>>> > >>>>> Mark known build failures as NO_PIE for now. > >>>> No, no, no, no more NOs! > >>>> > >>>> I?ll leave it to others who understand the current build system in d= ays when it?s not broken to fix this entire splattering across all these Ma= kefiles; we really need a better way for this. > >>> I have no words to express my dissatisfaction with this commit. > >>> If change to the build of _some_ usermode binaries require patching > >>> of loader', csu and rtld Makefiles, obviously it is done wrong. > >>> > >>> Why almost half of the binaries require opt-out ? > >>> > >>> PLEASE REVERT THIS. > >> Wait. Does this not serve as a useful stake in the ground for people = to > >> come in and update things? Instead of asking to back out, shouldn't we > >> be doing an announcement "ok folks, it's now time to fix this!" and mo= ve > >> forward? Otherwise we may never get any pie. > > Let me reformulate. > > > > Somebody commits broken change, despite it was pointed out by many > > before the commit. From the changes it is obvious that people which > > proposed it do not understand what they hack on. And then, somebody else > > must run and 'fix' previously non-broken code. > > > > Sure, you get the pie. > Sure, but hasn't the default stayed unchanged? No, they were changed, in very buggy and unuseful way, which is indicated by the need to modify the Makefiles for the completely unrelated things which I listed before. The change modified the VA layout of all affected binaries, and also added overhead of relocation to the previously fixed-mapped binaries. >=20 > It seems like you have to enable ASLR first before you see all the=20 > breakage. Right now it seems like goal was to document what even=20 > compiles versus doesn't compile with ASLR. Afaik there is not setting=20 > of ASLR on by default. The change of binaries to the shared objects, which was done by the discussing commit, is not about ASLR. It is required to get that snake oil to function, but by itself it is not ASLR. And no, it is not about what works/does not work with ASLR. Seemingly, it is about what the authors were able to mangle, or not able. E.g., FreeBSD cannot execute static 'binaries' compiled with PIE, since our csu does not perform relocations. So whatever is changed by a knob to become static (WITHOUT_SHARED_ROOT or how is it called now) is plain broken after the commit, if the knob is tweaked. Similarly, if something becomes shared-linked by knob (WITHOUT_STATIC_TOOLCHAIN ?) the NO_PIE is not needed. That said, the change is wrong on its principle. >=20 > There has to be a way to call out what works and what doesn't work and=20 > form a transition from a world with no ASLR to one with some ASLR and=20 > eventually one with almost entirely ASLR coverage. I'm not sure it can= =20 > be done in one fell swoop. Hooks like this in -current allow for this=20 > to be done as a group effort. >=20 > It would be very unlikely that we retain the semantics all the way until= =20 > a -stable release. I do not understand this two paragraphs at all. --SuZWD+5recMkC1v4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJTlMxuAAoJEJDCuSvBvK1BDq0QAKilZ+CtzFLJAUnVE/NcNoRO OF3zcbXeLMZtKcYK9zmj5TKVn0woeUFKR2R7Jc+W6Y2Vsusx19PtM/4Zjfe9b/fN rfgcYuSklI7nKgbkwwURp62pJlMONJqiCwNou9iy2hhMW+igWro3C11YjPGMEbm6 8hl3UMiEMtmrpMEz7H/Kecod365Rv6NZcRuJeLfEkB7iFatyse5pTGNg7FJFdYUT CKNxTDDbjnJhd4RBKwbqyFiwa417Vzb44HqHrYQUArNoKkmfoK9n0n4epVGCMoXE RaUPj7PUoRpguTtHawYuNR6LTte6pY9NhBwAfBOEdvPDAdyJ6JlR10HY1X7M0h88 qrQz+XWL4nq/Jml0fruPkOt9doEHYb2O0saxvNfySWWKitngKbEHtOBO8xmdLiLv lfD/U887NSiwm05V9DrQ3wAW/vmI9yE58bHbSnuyd36EWC4pLV2kxWoslHFl524d jxwCxEC730oX14mV10unhO2JUbDBh5Sn+aTv1VOKdMSa8w/z38CdpD8fA2U/jzgB xwFbLL9KJ/XJQzVe9L83blLEGpP5WouHQfaATwoaRl19KF7QIgibx/eSVDuXc2RC i+s9x+2Qda3uyFRB3V3UtAABas5W533KWBJ4KLi57IYgcRWZVVAFza6eIxEXSWz5 TR7+7b6L8thjF64LVcVs =mNXH -----END PGP SIGNATURE----- --SuZWD+5recMkC1v4--