Could LSI be misinterpreted as cheating in games?

[ianliu]

I know this is not a bug, but I was wondering if using LD_PRELOAD and other techniques could be misinterpreted as cheating in games. I think this is a real concern for people using LSI since some games have anti-cheat software's, and one could be blocked out of their own (usually payed) game. This should at least be clarified in the README page.

I know that some people were getting banned from games like Warcraft when playing with Wine, that's why I'm posting this issue.

[ikeydoherty]

That's the reason all of LSI is explicitly hard-coded to follow specific paths, so that it cannot be extended by third parties.

Notice LD_PRELOAD is usually always needed with Steam anyway, so the usage of LD_PRELOAD could hardly be considered cheating (Users without LSI have to use it to make libx11/etc work with open source drivers)

As for LD_AUDIT (where the real work actually happens) this is only controlling the dynamic linker and not the games themselves, ensuring they use the correct system libraries. You're more than welcome to take this up with the Valve devs (if you know any to ping) - but they've listed LSI as Solus's solution on their known workarounds page for the Steam runtime...

[ikeydoherty]

Also note that the LD_PRELOAD module can be disabled from within the LSI UI, and it only exists to fix Project Highrise and ARK: Survival Evolved, though I'd much rather those bugs were fixed upstream.

[ikeydoherty]

@kisak-valve I know it's slightly unorthodox to ping outside the main repository - but I thought I would ask here to get some clarification before raising it further - do you believe this to be misinterpreted as cheating? Personally I don't see it that way as the aim is to actually fix games from not launching/working, and doesn't actually empower the user beyond that..

[kisak-valve]

The steam client lightly uses LD_PRELOAD add the steam overlay, beyond that, by default the client heavily uses LD_LIBRARY_PATH to setup an order of preference in what libraries are used, and no extra use of LD_PRELOAD should be needed once the steam client is bootstrapped.

The current steam default checks the system libraries against the steam runtime, and pins steam runtime libraries that are newer than the system, and uses libraries in the following order: pinned libraries, system libraries, steam runtime, then ld.so.conf.

I can't definitively say that there won't be issues with anti-cheat middleware, but there is an established trend of preferring system libraries and currently there is not one true set of libraries that must be used with steam games.

[ikeydoherty]

Thank you @kisak-valve for your input, much appreciated!

The next evolutionary step for LSI is to stop being a distro package and to become a snap, perhaps at that point I will add internal verification to LSI to ensure its coming from a trusted origin (or even allow a handshake so that Steam can refuse unknown LSI builds).

Right now we have very specific paths that will perform library redirection to host libraries, using rtld-audit (glibc feature) to undo some of the LD_LIBRARY_PATH and RPATH/RUNPATH foo - which is a must on rolling releases. It means that folks get to use Steam as you guys intended, without you guys needing to worry so much about the pains of distros.

The other portion is the LD_PRELOAD library which explicitly checks the binary is either Project Highrise or ARK: Survival Evolved, and will use the Steam install directories to ensure it's only touching the right places. It intercepts a broken fopen64() call in Project Highrise which fixes the file path, as it tries to open (then mmap) a directory as a file, and dies. The other fixes the broken shader path in ARK so that water renders properly. (We have a VDF parser to make sure we're doing things by the book and only looking at Steam installed games)

[ikeydoherty]

@ianliu if you believe this matter resolved I'm going to close the issue then :D

[ianliu]

@ikeydoherty Ok! Thank you for the clarification!

[ikeydoherty]

np :)