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