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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
