[MPlayer-users] Unable to Compile Mplayer Revision 34652

[Vladimir Mosgalin]

Hi Carl Eugen Hoyos!

 On 2012.02.14 at 15:50:07 +0000, Carl Eugen Hoyos wrote next:

> > > >      --extra-cflags="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
> > > > -fexceptions -fstack-protector --param=ssp-buffer-size=4  -m64 
> > > > -mtune=generic" \
> > > 
> > > There are two possibilities:
> > > Either this is useful, then this should be added to our default
> > > flags, so please send benchmarks etc. in this case, or it has 
> > > no benefits, then please remove it.
> > 
> > These are "Red Hat recommended" hardening options
> 
> -g -pipe are hardening options?
> The point is that I suspect -O2 -mtune-generic makes the MPlayer 
> binary slower without adding any additional security.
> -m64 is default where it makes sense.
> The way I understand the gcc manual, -fexceptions does not make 
> much sense for MPlayer compilation (this may be wrong, please 
> correct me in that case).

Of course I was talking about other options :) We both know what -g,
-pipe or -O2 are for.

However I used bad wording. All of above look just like "Red Hat
recommended" options, but, yes, sure, only part of them is about
hardening. To be exact, here is list from RHEL6 (it's about the same for
Fedora 16):

-14: __global_cflags    -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-11: optflags   %{__global_cflags} -m64 -mtune=generic

(here, optflags for i686 builds will be different)

Naturally, these are generally safe options which you can build whole
system with. -O2 makes perfect sense for that, to solve possible
problems like the one mplayer had recently on AVX-supporting systems
with default optimization flags - some parts of it completely broke till
-fno-tree-vectorize was added to default mplayer cflags.

Anyhow by no means these are perfect for mplayer. They are just
"generally safest", feature-wise and security-wise. Some might slow down
mplayer. The only goal of them is not to break anything - and mplayer is
so dangerously optimized at places so it can break from things like new
compiler versions or new CPUs (usually not mplayer's fault - but, well,
life is what it is). Earlier I gave you example I encountered myself,
where compiling mplayer with redhat-provided cflags would make it not
break, and with default configure it broke (this was fixed fast after
noticing). So in certain situations it might make sense to use mplayer
compiled with these flags, though probably people who do that perfectly
understand what they are doing.


-fexceptions doesn't make sense for mplayer, it's among cflags above to
make sure every C library is compiled with them, which makes sense for
C++ code which uses them later.


> (And my gcc manual does not explain -fstack-protector, I 
> thought I remember having read somewhere it *may* fix some 
> security issues but that memory could also be wrong.)

Here is what's written in mine:
`-fstack-protector'
     Emit extra code to check for buffer overflows, such as stack
     smashing attacks.  This is done by adding a guard variable to
     functions with vulnerable objects.  This includes functions that
     call alloca, and functions with buffers larger than 8 bytes.  The
     guards are initialized when a function is entered and then checked
     when the function exits.  If a guard check fails, an error message
     is printed and the program exits.

The link I provided,
http://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_STACKPROTECTOR_.28gcc.2BAC8-g.2B-.2B-_-fstack-protector_--param_ssp-buffer-size.3D4.29
gives exact example on how to check its results.

There seem to be no performance impact on 64-bit platforms from this
option (though there was loss over a percent on i386). Here are some
graphs with numbers:
http://d-sbd.alioth.debian.org/www/?page=ssp

> > -D_FORTIFY_SOURCE=2 seems to be interesting as it's compile-time 
> > only check and should have no effect on mplayer performance, 
> > only on compilation time.
> 
> Please send a patch!

I surely could, but do you think it'll be accepted and won't cause
doubtful threads and ignored in the end?
(heh I'm still sad how my last small patch about fixing non-ascii
symbols in window title when displaying movie name there was never
applied despite following all the requests..)

-- 

Vladimir