Debian Bug report logs - #493705
ffmpeg-debian: Libraries have text relocations

Package: libswscale0; Maintainer for libswscale0 is Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>;

Reported by: Russell Coker <russell@coker.com.au>

Date: Mon, 4 Aug 2008 10:45:02 UTC

Severity: normal

Merged with 528080

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Russell Coker <russell@coker.com.au>:
New Bug report received and forwarded. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Russell Coker <russell@coker.com.au>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: libswscale0: The library has text relocations
Date: Mon, 04 Aug 2008 20:42:31 +1000
Package: libswscale0
Version: 0.svn20080206-8
Severity: normal

http://etbe.coker.com.au/2007/02/10/execmod/

The above URL has background information on the execmod denial from SE
Linux.

The following command shows that some parts of the library have not been
comiled with -fpic or -fPIC - in this case it's actually assembly code
which is not position independent.

# eu-findtextrel /usr/lib/libswscale.so.0|uniq

The following patch fixes this.

diff -ru ffmpeg-free-0.svn20080206/libswscale/rgb2rgb.c fixed/libswscale/rgb2rgb.c
--- ffmpeg-free-0.svn20080206/libswscale/rgb2rgb.c	2008-01-29 14:58:10.000000000 +0000
+++ fixed/libswscale/rgb2rgb.c	2008-08-04 10:15:06.000000000 +0000
@@ -158,6 +158,9 @@
 #define RENAME(a) a ## _C
 #include "rgb2rgb_template.c"
 
+/* The MMX, MMX2, and 3DNOW versions all have text relocations */
+# if 0
+
 #if defined(ARCH_X86) && defined(CONFIG_GPL)
 
 //MMX versions
@@ -188,6 +191,7 @@
 #include "rgb2rgb_template.c"
 
 #endif //ARCH_X86 || ARCH_X86_64
+#endif
 
 /*
  rgb15->rgb16 Original by Strepto/Astral




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #10 received at 493705@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Russell Coker <russell@coker.com.au>, 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 12:59:56 +0200
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>

 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.

-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #15 received at 493705@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Russell Coker <russell@coker.com.au>, 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 13:01:15 +0200
On Mon, Aug 04, 2008, Loïc Minier wrote:
>  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>

 References:
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=329762
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=268603

-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to russell@coker.com.au:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #20 received at 493705@bugs.debian.org (full text, mbox):

From: Russell Coker <russell@coker.com.au>
To: Loïc Minier <lool@dooz.org>
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 22:04:22 +1000
On Monday 04 August 2008 20:59, Loïc Minier <lool@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.





Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Reinhard Tartler <siretart@tauware.de>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #25 received at 493705@bugs.debian.org (full text, mbox):

From: Reinhard Tartler <siretart@tauware.de>
To: Russell Coker <russell@coker.com.au>
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 04 Aug 2008 14:34:09 +0200
Russell Coker <russell@coker.com.au> writes:

> The following patch fixes this.

Are you sure that this is the only occurence of text relocations? TBH, I
doubt that. I acknowledge that text relocations are a resonable concern,
but the patch does not directly address them. It is not clear where the
textrelocation actually happens, and for what purpose.

A more maintainable approach to this matter would probably be to add
--disable-mmx to ffmpeg's configure flags, which would in turn disable
any usage of MMX code.

As for the PIC/PIE discussion: Upstream is deliberatly compiling the
code with PIC on i386, and maintains a list of architectures that
require PIC to build shared objects. This is done for performance
reasons. Now security is of course another interesting concern.

TBH, If at all, we could build another variant of ffmpeg library
packages like libavcodec-security or something. However given the
current complexity of the ffmpeg package, I'm not that keen on
implementing and maintaining this.

All in all, I think this needs seriously more thought. The proposed
patch is certainly not suitable for inclusion upstream, since it just
disables handwritten optimized coded and as such I'm not willing to
maintain that patch in the debian package.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #30 received at 493705@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Russell Coker <russell@coker.com.au>, 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 15:03:23 +0200
On Mon, Aug 04, 2008, Russell Coker wrote:
> The following command shows that some parts of the library have not been
> comiled with -fpic or -fPIC - in this case it's actually assembly code
> which is not position independent.
> 
> # eu-findtextrel /usr/lib/libswscale.so.0|uniq

 BTW lintian already does this; I don't think you need a custom tool:
    % grep -ir textrel /usr/share/lintian/checks
    /usr/share/lintian/checks/shared-libs:my %TEXTREL;
    /usr/share/lintian/checks/shared-libs:    } elsif (m/^\s*TEXTREL\s/o) {
    /usr/share/lintian/checks/shared-libs:        $TEXTREL{$file} = 1;
    /usr/share/lintian/checks/shared-libs:        if ($cur_file eq $real_file and $TEXTREL{$cur_file}) {



-- 
Loïc Minier




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #35 received at 493705@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Russell Coker <russell@coker.com.au>
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 14:59:19 +0200
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




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to russell@coker.com.au:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #40 received at 493705@bugs.debian.org (full text, mbox):

From: Russell Coker <russell@coker.com.au>
To: Reinhard Tartler <siretart@tauware.de>
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 23:32:08 +1000
On Monday 04 August 2008 22:34, Reinhard Tartler <siretart@tauware.de> wrote:
> Russell Coker <russell@coker.com.au> writes:
> > The following patch fixes this.
>
> Are you sure that this is the only occurence of text relocations? TBH, I
> doubt that.

I built the package with the patch in question and the text relocations were 
gone.

> I acknowledge that text relocations are a resonable concern, 
> but the patch does not directly address them. It is not clear where the
> textrelocation actually happens, and for what purpose.

It happens in the .c file when it is included in the three ways that I 
disabled.

> A more maintainable approach to this matter would probably be to add
> --disable-mmx to ffmpeg's configure flags, which would in turn disable
> any usage of MMX code.

However there is no need to disable all MMX code, just that one function.

> TBH, If at all, we could build another variant of ffmpeg library
> packages like libavcodec-security or something. However given the
> current complexity of the ffmpeg package, I'm not that keen on
> implementing and maintaining this.

Or we could try and find a way of changing the assembler to need one less 
register.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Reinhard Tartler <siretart@tauware.de>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #45 received at 493705@bugs.debian.org (full text, mbox):

From: Reinhard Tartler <siretart@tauware.de>
To: russell@coker.com.au
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 04 Aug 2008 15:44:18 +0200
Russell Coker <russell@coker.com.au> writes:

> On Monday 04 August 2008 22:34, Reinhard Tartler <siretart@tauware.de> wrote:
>> Russell Coker <russell@coker.com.au> writes:
>> > The following patch fixes this.
>>
>> Are you sure that this is the only occurence of text relocations? TBH, I
>> doubt that.
>
> I built the package with the patch in question and the text relocations were 
> gone.

In libswscale. I strongly assume that there are more in the other
libraries of ffmpeg:

E: libpostproc51: shlib-with-non-pic-code usr/lib/i686/cmov/libpostproc.so.51.1.0
E: libpostproc51: shlib-with-non-pic-code usr/lib/libpostproc.so.51.1.0
E: libavutil49: shlib-with-non-pic-code usr/lib/libavutil.so.49.6.0
E: libavutil49: shlib-with-non-pic-code usr/lib/i686/cmov/libavutil.so.49.6.0
E: libavformat52: shlib-with-non-pic-code usr/lib/i686/cmov/libavformat.so.52.7.0
E: libavformat52: shlib-with-non-pic-code usr/lib/libavformat.so.52.7.0
E: libavdevice52: shlib-with-non-pic-code usr/lib/i686/cmov/libavdevice.so.52.0.0
E: libavdevice52: shlib-with-non-pic-code usr/lib/libavdevice.so.52.0.0
E: libavcodec51: shlib-with-non-pic-code usr/lib/libavcodec.so.51.50.0
E: libavcodec51: shlib-with-non-pic-code usr/lib/i686/cmov/libavcodec.so.51.50.0


>> I acknowledge that text relocations are a resonable concern, 
>> but the patch does not directly address them. It is not clear where the
>> textrelocation actually happens, and for what purpose.
>
> It happens in the .c file when it is included in the three ways that I 
> disabled.
>
> [...]  we could try and find a way of changing the assembler to need
> one less register.

indeed. please note that this discussion has occured several times on
upstream mailing list, and every time I read such a thread it endes in
blaming gcc for being too wastful wrt available registers on i386. (Yes,
ffmpeg upstream has very strong opinions on gcc and code quality here,
which makes ffmpeg a very, uhm, interesting package to maintain).

IOW: yes, such a patch would be prefererred, but is hard work, because
upstream expectations are rather high on such patches. If someone wants
to work on such a patch, feel free to attach it to this bug.

As a maintainer, I think one acceptable solution would be to provide a
replacement package that is compiled specially. However this would add
additional complexity to the package that I'm not convinced of.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to russell@coker.com.au:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #50 received at 493705@bugs.debian.org (full text, mbox):

From: Russell Coker <russell@coker.com.au>
To: Loïc Minier <lool@dooz.org>
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 23:49:58 +1000
On Monday 04 August 2008 22:59, Loïc Minier <lool@dooz.org> 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;

It is only a performance hit in cases where you actually need the register.

>  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).

Custom built assembly can require the extra register, which is what happens 
with the code in question.  The code does build with PIC, it just happens to 
not be position independent.  Thus the reserving of a register in all the 
other code in the shared object has all been wasted.

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

It's not just SE Linux, it's anything that tries to prevent writable and 
executable memory.

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

If you care about security then you assume that all code gets broken 
eventually.  The question is whether you have a safety net when the first 
layer gets broken or whether you just lose.

>  However 
>  performance is useful in all cases.  So I still think it's a compromise
>  which needs wider consensus.

How much performance are we talking about?

Performance is not of such great use if the system is already fast enough.  If 
you run a task that performs well on an 800MHz P3 system (such as playing AVI 
files in 800*600 resolution) on a faster machine (EG any P4 system) then a 
small amount of performance loss isn't going to be noticed.  In fact in that 
example you could halve the performance and not notice it!

#if 1 //is faster only if multiplies are reasonably fast (FIXME figure out on 
which CPUs this is faster, on Athlon it is slightly faster)

Also there are comments such as the above near the assembly code.




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. Full text and rfc822 format available.

Acknowledgement sent to Loïc Minier <lool@dooz.org>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. Full text and rfc822 format available.

Message #55 received at 493705@bugs.debian.org (full text, mbox):

From: Loïc Minier <lool@dooz.org>
To: Russell Coker <russell@coker.com.au>
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: libswscale0: The library has text relocations
Date: Mon, 4 Aug 2008 16:21:52 +0200
On Mon, Aug 04, 2008, Russell Coker wrote:
> >  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;
> 
> It is only a performance hit in cases where you actually need the register.

 I think it's hard to find real CPU bound applications where additional
 registers don't help performance.

> >  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).
> 
> Custom built assembly can require the extra register, which is what happens 
> with the code in question.  The code does build with PIC, it just happens to 
> not be position independent.  Thus the reserving of a register in all the 
> other code in the shared object has all been wasted.

 Then this is another case; there is custom assembly which wont build at
 all in PIC mode because gcc doesn't have enough registers to offer when
 entering this code and needs to do some relocations.

> > > 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.
> 
> It's not just SE Linux, it's anything that tries to prevent writable and 
> executable memory.

 Are you suggesting Fedora added the patch for other reasons than
 SELINUX support?  Could you expand on these reasons?

> > > 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.
> 
> If you care about security then you assume that all code gets broken 
> eventually.  The question is whether you have a safety net when the first 
> layer gets broken or whether you just lose.

 Sure, and if you care about security, you don't connect your computer
 to the internet, or you don't use a computer at all.

 Perhaps we want Debian packages to favor performance, or perhaps we
 want them to favor security features; this decision doesn't belong to
 the two of us but to the project as a whole.

> >  However 
> >  performance is useful in all cases.  So I still think it's a compromise
> >  which needs wider consensus.
> 
> How much performance are we talking about?
> 
> Performance is not of such great use if the system is already fast enough.  If 
> you run a task that performs well on an 800MHz P3 system (such as playing AVI 
> files in 800*600 resolution) on a faster machine (EG any P4 system) then a 
> small amount of performance loss isn't going to be noticed.  In fact in that 
> example you could halve the performance and not notice it!
> 
> #if 1 //is faster only if multiplies are reasonably fast (FIXME figure out on 
> which CPUs this is faster, on Athlon it is slightly faster)
> 
> Also there are comments such as the above near the assembly code.
> 

 I gave pointers on this already; it can be 10%.

-- 
Loïc Minier




Changed Bug title to `ffmpeg-debian: Libraries have text relocations' from `libswscale0: The library has text relocations'. Request was from Andres Mejia <mcitadel@gmail.com> to control@bugs.debian.org. (Mon, 06 Jul 2009 20:30:04 GMT) Full text and rfc822 format available.

Bug no longer marked as found in version 0.svn20080206-8. Request was from Andres Mejia <mcitadel@gmail.com> to control@bugs.debian.org. (Mon, 06 Jul 2009 20:33:10 GMT) Full text and rfc822 format available.

Bug marked as found in version 4:0.5+svn20090420-2. Request was from Andres Mejia <mcitadel@gmail.com> to control@bugs.debian.org. (Mon, 06 Jul 2009 20:33:11 GMT) Full text and rfc822 format available.

Bug reassigned from package `libswscale0' to `ffmpeg-debian'. Request was from Andres Mejia <mcitadel@gmail.com> to control@bugs.debian.org. (Mon, 06 Jul 2009 20:36:11 GMT) Full text and rfc822 format available.

Merged 493705 528080. Request was from Andres Mejia <mcitadel@gmail.com> to control@bugs.debian.org. (Sun, 12 Jul 2009 00:54:03 GMT) Full text and rfc822 format available.

Bug reassigned from package 'ffmpeg-debian' to 'ffmpeg'. Request was from Andres Mejia <mcitadel@gmail.com> to control@bugs.debian.org. (Tue, 01 Sep 2009 00:03:09 GMT) Full text and rfc822 format available.

Bug reassigned from package 'ffmpeg' to 'libswscale0'. Request was from Reinhard Tartler <siretart@tauware.de> to control@bugs.debian.org. (Fri, 18 Jun 2010 12:36:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. (Sat, 23 Oct 2010 11:24:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to russell@coker.com.au:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. (Sat, 23 Oct 2010 11:24:02 GMT) Full text and rfc822 format available.

Message #74 received at 493705@bugs.debian.org (full text, mbox):

From: Russell Coker <russell@coker.com.au>
To: 493705@bugs.debian.org
Subject: This also occurs on amd64
Date: Sat, 23 Oct 2010 22:20:05 +1100
The library /usr/lib/libavcodec.so.52.20.1 from libavcodec52 version 4:0.5.2-6 
also has this problem on amd64.

Would it be possible to get this fixed on amd64 as there is no lack of 
registers there?

-- 
russell@coker.com.au
http://etbe.coker.com.au/          My Main Blog
http://doc.coker.com.au/           My Documents Blog




Information forwarded to debian-bugs-dist@lists.debian.org, Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>:
Bug#493705; Package libswscale0. (Sat, 23 Oct 2010 15:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Reinhard Tartler <siretart@tauware.de>:
Extra info received and forwarded to list. Copy sent to Debian multimedia packages maintainers <pkg-multimedia-maintainers@lists.alioth.debian.org>. (Sat, 23 Oct 2010 15:21:03 GMT) Full text and rfc822 format available.

Message #79 received at 493705@bugs.debian.org (full text, mbox):

From: Reinhard Tartler <siretart@tauware.de>
To: russell@coker.com.au
Cc: 493705@bugs.debian.org
Subject: Re: Bug#493705: This also occurs on amd64
Date: Sat, 23 Oct 2010 16:44:28 +0200
On Sat, Oct 23, 2010 at 13:20:05 (CEST), Russell Coker wrote:

> The library /usr/lib/libavcodec.so.52.20.1 from libavcodec52 version 4:0.5.2-6 
> also has this problem on amd64.
>
> Would it be possible to get this fixed on amd64 as there is no lack of 
> registers there?

Depends on what you mean with 'fixed'. the libraries are already linked
with -fPID -DPIC on amd64, otherwise they wouldn't even link. If you
mean to avoid text relocations in both avcodec and swscale completely,
then I fear it's going to be harder.  You might also be interested in
(re)reading this thread:

http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/71516/focus=76622

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4




Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 25 08:17:35 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.