Bug#493705: libswscale0: The library has text relocations

Russell Coker russell at coker.com.au
Mon Aug 4 12:04:22 UTC 2008


On Monday 04 August 2008 20:59, Loïc Minier <lool at dooz.org> wrote:
> On Mon, Aug 04, 2008, Russell Coker wrote:
> > http://etbe.coker.com.au/2007/02/10/execmod/
> >
> > The above URL has background information on the execmod denial from SE
> > Linux.
>
>  If you want to file bugs about binaries not using -fpic / -fPIC on
>  i386, then I think you need to start a wider discussion on
>  debian-devel@: this was debated and I understand there's now an
>  exception for performance critical code (such as libswscale's case):
>     <http://www.debian.org/doc/debian-policy/footnotes.html#f61>

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.

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.

>  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!

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.






More information about the pkg-multimedia-maintainers mailing list