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 pfg at FreeBSD.org
Sun Jun 8 20:19:59 UTC 2014


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


More information about the svn-src-head mailing list