[FFmpeg-devel] TEXTRELs in fft_mmx.asm

[Reinhard Tartler]

Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> The issue in this thread is not related to performance. Putting the
> tables in the correct section should not have any negative performance
> impact; apparently it's just nontrivial to implement such things right
> in yasm code.

I see. Thanks for explanation.

>> I can understand that selinux, pax and similar security urges to severe
>> compromises. However at least some users are willing to give up 20-40%
>> performance if they gain some security benefit. For these users I'm
>> considering building yet another variant, if it was a matter of
>> selecting some switch for the configure switch. [1]
>
> You mean specifically for x86? On AMD64 there should already be no
> textrels except the tables in yasm files.
>
> How familiar are you with the SELinux issues? Would it be possible to
> reduce the risk by some alternative mechanism that allows a binary to
> perform textrels when it's starting but drops those privileges before
> processing any user data? (Obviously dynamic loading of a library
> containing textrels would not be possible.)

Not easily. Let me think aloud a bit. The main problem I see with this
approach is that you would need to change the program context during
runtime. The kernel needs to know somehow when to switch the context of
a program during runtime. This most likely means that you would need to
add selinux specific requests to signal this event. And even if you had
them, you'd still need a policy that actually implements this.

Currently the approach of the reference policy is to allow labeling of
programs that need textrels. A program needs textrels when it either
uses that itself or when some shared library that is loaded into the
program context is loaded.

What you propose whould mean that the library would need to request the
policy to allow textrels for loading and then switch the context back
after it has done its job. TBH, I'm not even sure if this is possible at
all without re'execing the binary.

I fear this problem needs someone with a deep understanding of both the
yasm code used in libavcodec/libswscale and the selinux reference policy
:-(

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