As promised in the SDL review some help in getting SDL bugs fixed. I've been
digging into this at home this weekend (where I'm unfortunately without internet
access). And this is somewhat strange.

As to be expected the TEXTREL problems are caused by some asm code left and
right in SDL, and thusn only show up on i386. Strange enough ls -Z
/usr/lib/libSDL-1.2.so.0 gives:
lrwxrwxrwx  root root system_u:object_r:lib_t:s0

And my selinux is in enforcing mode with "allow_execmod --> off", thus this
shouldn't work unless ls -Z /usr/lib/libSDL-1.2.so.0 would give:
lrwxr-xr-x  root root system_u:object_r:textrel_shlib_t:s0

But still SDL seems to work fine, I've even written a special test program to
make sure one of the asm routines got called (as they only get called under very
specific circumstances), verified that my program worked by adding debug
printf's to SDL, and still it works fine ???

Now there may be an explanation for this, I've done much reading on PIC code in
elf objects this weekand and my test programs make SDL use asm code from
src/hermes/*.asm, but that asm code is actually fine as it:
1) the function addresses are not used by to the outside
2) it doesn't contain any data references

and there are 2 possible problems with asm code in PIC
1) your function symbols getting used outside the lib
2) accessing any data both inside or outside the lib

So it seems that I've been trying to trigger the wrong code path to find any
real textrel problems.

Strange enough eu-findtextrel, still complains about the symbols defined in
src/hermes/*.asm

Now this weekend I unfortunately didn't have access to the gentoo patches, now
that I do lets evaluate those:

http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-SDL_stretch.patch
Fixes a asm direct .data access to become a by ref access -> should be applied

http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-hermes-call-dont-jump.patch
Replace a few jmp and jmp backs with call and ret, could have a very slight
performance impact, but otherwise looks fine -> should be applied

http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-hermes-cpuid.patch
Fixes the CPU detect code under src/hermes/x86_main.asm -> this CPU-detect code
isn't used by SDL, probably best to just remove it.

http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-load-mmx-masks-from-stack.patch
Already applied by upstream in 1.2.10

http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-yuv-mmx.patch
Fixes a couple of asm direct .data accesses to become a by ref accesses ->
should be applied

I'll try to apply the patches which I like, strip the non used cpudetect code
and then attach one merged (and tested) patch for this.

Created attachment 147899 [details]
PATCH removing all textrel's

This is a combination of:
http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-hermes-call-dont-jump.patch

and:
http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-yuv-mmx.patch


In combination with removing the unused CPU-detect code.

Notice that:
http://mir2.ovh.net/gentoo-portage/media-libs/libsdl/files/libsdl-1.2.9-PIC-SDL_stretch.patch

Is  not applied as it already was applied upstream

I've confirmed that with this patch all textrel's are gone (according to
eu-findtextrel). I've done some testing with this and all SDL apps still seem
to work fine.

(In reply to comment #1)
> Strange enough ls -Z /usr/lib/libSDL-1.2.so.0 gives:
> lrwxrwxrwx  root root system_u:object_r:lib_t:s0
> 
> And my selinux is in enforcing mode with "allow_execmod --> off", thus this
> shouldn't work unless ls -Z /usr/lib/libSDL-1.2.so.0 would give:
> lrwxr-xr-x  root root system_u:object_r:textrel_shlib_t:s0
> 
> But still SDL seems to work fine

You should not look at the security context of symlinks. At least on my FC6 I
have this output:

[gajownik@cyklop ~]$ ls -Z /usr/lib/libSDL-1.2.so.0*
lrwxrwxrwx  root root system_u:object_r:lib_t          /usr/lib/libSDL-1.2.so.0
-> libSDL-1.2.so.0.7.3
-rwxr-xr-x  root root system_u:object_r:textrel_shlib_t /usr/lib/libSDL-1.2.so.0.7.3
[gajownik@cyklop ~]$ 

Context of the main library is important.

Anyway, big thanks for your work! After applying your patches selinux-policy
should be updated.

(In reply to comment #3)
> (In reply to comment #1)
> > Strange enough ls -Z /usr/lib/libSDL-1.2.so.0 gives:
> > lrwxrwxrwx  root root system_u:object_r:lib_t:s0
> > 
> > And my selinux is in enforcing mode with "allow_execmod --> off", thus this
> > shouldn't work unless ls -Z /usr/lib/libSDL-1.2.so.0 would give:
> > lrwxr-xr-x  root root system_u:object_r:textrel_shlib_t:s0
> > 
> > But still SDL seems to work fine
> 
> You should not look at the security context of symlinks. At least on my FC6 I
> have this output:
> 
> Context of the main library is important.
> 

Ah, that explains why things still work, thanks! 

> Anyway, big thanks for your work! After applying your patches selinux-policy
> should be updated.

Yes indeed.

I see a big problem with these invasive assembler patches, because they are not
upstream and a new version of SDL could require to change big parts of them.

BTW: SDL upstream decided not to add these patches.

I see that TEXTRELs are not good, but I'd like to get this patches upstream, at
least in SDL. Even the actual Hermes library has still these code segments.

For now, I am sorry, but these patches are a no-go in my opinion.

Actually, the patches to the hermes code are trivial, and the only other patch
is to src/video/SDL_yuv_mmx.c, which isn't 100% trivial, but isn't exactly very
complex either. Also this code is not very likely to change (not likely at all).

There used to be a lot more non PIC code pieces, but those are already merged
upstream, I don't know why they didn't merge these 2 particular bits.

I've filed this upstream too now, see:
http://bugzilla.libsdl.org/show_bug.cgi?id=418

Fixed upstream ...

Fixed in package SDL-1.2.12-1 or newer.