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

[Bryan Drewery]

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.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20140608/7cdbf50c/attachment.sig>