On Monday, 15 January 2018 2:15:40 PM AEDT James Cowgill wrote: > > Sorry, we do not control the binaries that Valve > > use in Steam. You're welcome to take this upstream to > > https://github.com/ValveSoftware/steam-for-linux/issues/ if you believe > > the use of generic i386 binaries is a security problem. > > > > path="/home/rjc/.steam/ubuntu12_32/libavutil.so.55" > > Arguably this is an ffmpeg bug. I expect you will find that this will > also happen if you try to run any program which uses ffmpeg on a machine > with Debian i386 and SELinux installed.
It's a compilation choice for ffmpeg. Last time I checked that same choice was made by the maintainers of the Debian package, so for some years I had a repository of alternate ffmpeg packages to support a more strict configuration of SE Linux on the i386 desktop - which incidentally also made things more secure for i386 users who didn't use SE Linux. I stopped supporting thost packages because i386 desktops are almost never used nowadays, the i386 architecture is uncommon and most use of it is for routers and embedded systems. But in this case the compilation choice was made by Steam upstream. I filed a bug report here so that everyone is aware of it and anyone who looks up the issue will know that it's a known issue. > This happens because ffmpeg contains some i386 assembly routines which > intentionally use TEXTRELs in the name of performance. Maybe the code > should be reworked to be totally position independent. It would be > interesting to see the exact performance cost of enabling PIC for these > specific routines. I've seen claims of as much as a 15% performance hit in the past. IMHO it's worth losing 15% of performance for security given that security is decreased for every application which links against that library or any other library that links against it. In this case the Steam downloader is using that library. The Steam downloader is a network facing application that includes a small web browser among other things. I think that the security issue is more important than the theoretical performance issue in this case. Particularly as 64bit code would give both better performance (solving the lack of registers problem that led to all of this) as well as better security. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/
