-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/52645/#review151886
-----------------------------------------------------------




3rdparty/libprocess/Makefile.am (line 16)
<https://reviews.apache.org/r/52645/#comment220515>

    Needs a comment explaining the purpose of these flags.



3rdparty/libprocess/Makefile.am (line 17)
<https://reviews.apache.org/r/52645/#comment220514>

    Comment should end in a period.



src/Makefile.am (line 92)
<https://reviews.apache.org/r/52645/#comment220516>

    This should be moved up above the preceding comment (the comment describes 
the `-Wl,--as-needed` line below).


(1) Do we need to make the `CXXFLAGS` conditional on being supported by the 
current compiler? Seems like these flags are quite specific to (certain 
versions of?) gcc/clang.

(2) You should split this review into three separate reviews: a single review 
should make changes to at most one of Mesos, libprocess, and stout.

(3) What _specific_ attack vectors are these changes intended to prevent?

- Neil Conway


On Oct. 7, 2016, 7:22 p.m., Aaron Wood wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52645/
> -----------------------------------------------------------
> 
> (Updated Oct. 7, 2016, 7:22 p.m.)
> 
> 
> Review request for mesos and Michael Park.
> 
> 
> Bugs: MESOS-6229
>     https://issues.apache.org/jira/browse/MESOS-6229
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Use a default set of flags to provide additional security and hardening to 
> Mesos. Additionally, check and catch more warnings/errors.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/Makefile.am 020b0e1 
>   3rdparty/stout/Makefile.am fda069d 
>   src/Makefile.am bfdb66a 
> 
> Diff: https://reviews.apache.org/r/52645/diff/
> 
> 
> Testing
> -------
> 
> Compared the benchmarks with and without the flags being used. Also did a 
> comparsion with the flags being used with and without optimizations and 
> without the flags being used with and without optimizations. Overall the 
> performance hit was very small with a 3-8% overhead (optimizations brings 
> this down slightly). Most benchmarks were about 5% (or less) slower.
> 
> 
> Thanks,
> 
> Aaron Wood
> 
>

Reply via email to