Bug#493705: libswscale0: The library has text relocations

[Loïc Minier]

On Mon, Aug 04, 2008, Russell Coker wrote:
> The references you provide seem to indicate that the exception is for
> the case where faster assembly is not available.  IE you have a choice
> between fast assembly and a slower compiled language.  While if the
> difference is only 10% (between two different versions of assembly
> code) then PIC is the way to go.

 Based on my memory of the discussions, it seemed to me that there is a
 performance hit in all cases if you use PIC instead of non-PIC on i386
 because a register is used for the relocations; I think this impacts
 both assembly and compiled languages, however I could imagine cases
 where custom assembly wont build at all if PIC is used (as it might
 require more registers than PIC mode provide).

> I expected that the probability of you including my patch to disable the 
> assembler was low (although a similar patch is in the Fedora tree for 
> libtheora), but if nothing else it clearly illustrates where the problem is 
> for anyone who wants to have a go at writing some assembler.

 Well, it's interesting to note that Fedora favors SELINUX support
 before speed; perhaps something you can bring up in a wider discussion
 of this policy decision.

> >  I see two ways to go forward: implement a way to disable execution of
> >  such binaries when under SELINUX, or force usage of -fPIC, even in
> >  performance critical code.
> 
> If the performance critical code is going to be handling data from sources of 
> low integrity (EG playing video downloaded from youtube etc) then I think 
> that we want all the available security features enabled!

 I'm not sure I agree with the rationale; certainly having SELINUX
 properly working in apps playing remote contents is a laudable goal,
 but I understand SELINUX doesn't make any difference if the libs are
 secure already, and we do want the libs to be secure.  However
 performance is useful in all cases.  So I still think it's a compromise
 which needs wider consensus.

> But having library A try and load library B at runtime and then load
> library C if B fails (where B is the non-PIC version and C is the PIC
> version) would be a viable option.

 Definitely.  Some multimedia frameworks such as GStreamer are perfectly
 capable of doing this if you offer two versions of the same plugin with
 different ranks -- the ones failing to load simply aren't added to the
 registry of available plugins.

-- 
Loïc Minier