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/...

[Pedro Giffuni]

El 6/8/2014 4:39 PM, Bryan Drewery escribió:
> On 6/8/2014 3:13 PM, Pedro Giffuni wrote:
>> Hello;
>>
>> El 6/8/2014 2:14 PM, Alfred Perlstein escribió:
>>> 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 <bdrewery at FreeBSD.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>> building with -fPIE.
>>>>>>>>
>>>>>>>>     This is currently an opt-in build flag. Once ASLR support is
>>>>>>>> ready and stable
>>>>>>>>     it should changed to opt-out and be enabled by default along
>>>>>>>> with 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
>>>>>>> days when it?s not broken to fix this entire splattering across all
>>>>>>> these Makefiles;  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
>>>>> move
>>>>> 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?
>>>
>>> It seems like you have to enable ASLR first before you see all the
>>> breakage.  Right now it seems like goal was to document what even
>>> compiles versus doesn't compile with ASLR.  Afaik there is not setting
>>> of ASLR on by default.
>>>
>>
>> FWIW, and with huge respect to the people working on it, I have come to
>> the conclusion that ASLR is useless. The fact that MS and Apple enable
>> it now by default is not really a point in favor of the technology as
>> the workarounds became popular and finer randomization won't help[1].
>>
>> I am also worried about the performance: Redhat created PIE but
>> backpedaled when they noticed the performance impact and AFAICT only use
>> PIE in a restricted set of binaries.
>>
>> I would like to see these as an option but I don't think it should ever
>> be made the default. Yes, I am aware these patches don't turn anything
>> by default but I (and probably others) am suspecting such a switch may
>> be thrown upon us without much discussion.
>>
>>
>>> There has to be a way to call out what works and what doesn't work and
>>> form a transition from a world with no ASLR to one with some ASLR and
>>> eventually one with almost entirely ASLR coverage.  I'm not sure it can
>>> be done in one fell swoop.  Hooks like this in -current allow for this
>>> to be done as a group effort.
>>>
>>> It would be very unlikely that we retain the semantics all the way until
>>> a -stable release.
>>>
>>
>> I am not (yet) criticizing the patches to the build system as I want to
>> preserve my innocence ;) ... but perhaps if the semantics are not
>> finalized this should be done in a branch. It is my opinion that in
>> general we are not using SVN branches as much as we should.
>>
>> Pedro.
>>
>> For reference:
>>
>> [1] http://youtu.be/dkZ9zdSRQYM
>
> Yes there are performance implications. No, the default of PIE and ASLR
> won't be done without discussion.
>

Sounds fair enough for me, thanks!

For the record, despite my general disagreement around making it 
default, I do appreciate the enthusiasm with which Shawn and Oliver are 
taking these security enhancement projects and Bryan's willingness to 
wear the asbestos pants here.

Pedro.