The search for the correct amount of split-lock misery [LWN.net]

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 7:17 UTC (Thu) by taladar (subscriber, #68407)
In reply to: The search for the correct amount of split-lock misery by developer122
Parent article: The search for the correct amount of split-lock misery

The number of people gaming on a system where they have limited privileges must be extremely small though.

to post comments

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 10:19 UTC (Thu) by hkario (subscriber, #94864) [Link] (16 responses)

no, it isn't, wine _really_ doesn't like being run as root; everybody is running their wine environments or the whole Steam client from regular user accounts, no sudo prompts in sight

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 10:32 UTC (Thu) by syrjala (subscriber, #47399) [Link] (1 responses)

I believe the point was that most people that need this have the ability to just edit /etc/sysctl.conf or whatever.

And I think most of the remaining cases are probably solved by: "Mom/Dad, can you toggle this sysctl knob for me?". Assuming the kid hasn't found some local root exploit already ;)

The search for the correct amount of split-lock misery

Posted Oct 20, 2022 20:32 UTC (Thu) by developer122 (guest, #152928) [Link]

These same arguments came up in system call emulation and it didn't fly there either.

The search for the correct amount of split-lock misery

Posted Oct 21, 2022 12:11 UTC (Fri) by bartoc (guest, #124262) [Link] (13 responses)

Presumably you would do something similar to how windows programs are installed on steam, upon first launch it (sometimes) requests elevation and installs "things", in this case one such thing could be a suid program that turns off misery mode and then launches the game, restoring misery mode when the game has exited.

The search for the correct amount of split-lock misery

Posted Oct 21, 2022 12:19 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (5 responses)

Mmm, yes, the fun problem of figuring out "what did this program do to my machine?" when trying to uninstall it. Not sure I'd like to import that particular behavior from Windows.

Incidentally, more programs supporting `/etc/prog.d/*.conf`-style configuration would be greatly appreciated :) .

> restoring misery mode when the game has exited.

ABAB problems sound fun with this. Also sounds like a maze full of fun error code paths that will never be reliably tested.

The search for the correct amount of split-lock misery

Posted Oct 21, 2022 12:29 UTC (Fri) by bartoc (guest, #124262) [Link] (4 responses)

Yeah. Though actually another option might be to just have wine know how to bump around the allocations in question to avoid the split-locks in the first place. It would have to be a game-specific hack probably.

I wonder if windows has compat shims for this kinda stuff.

The search for the correct amount of split-lock misery

Posted Oct 21, 2022 15:00 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Yeah, it's done those kinds of things: https://arstechnica.com/gadgets/2022/10/windows-95-went-t...

TheOldNewThing blog by Raymond Chen also has lots of tales to this effect: https://devblogs.microsoft.com/oldnewthing/

The search for the correct amount of split-lock misery

Posted Oct 21, 2022 23:40 UTC (Fri) by bartoc (guest, #124262) [Link] (1 responses)

yeah ofc, but I mean _this specific problem_

The search for the correct amount of split-lock misery

Posted Oct 22, 2022 23:26 UTC (Sat) by developer122 (guest, #152928) [Link]

Not possible, see comment below. This approach was also suggested during the kernel syscall emulation saga and also shot down then too.

The search for the correct amount of split-lock misery

Posted Oct 22, 2022 23:25 UTC (Sat) by developer122 (guest, #152928) [Link]

This is not possible.

This same suggestion *also* came up during the kernel syscall emulation work. It was suggested that instead of having the kernel reroute attempts by a program to call a windows kernel syscall, wine could simply scan for and patch any such attempts.

This is not only hideously complicated and unreliable, it also doesn't work at all with exactly the class of programs we're interested with: Games.

They frequently include a wide variety of very gnarly anti-tampering features which cannot be automatically overcome. It is for this reason wine seeks to emulate the environment around the program, and never ever attempts to reach inside it.

The search for the correct amount of split-lock misery

Posted Oct 22, 2022 23:21 UTC (Sat) by developer122 (guest, #152928) [Link] (6 responses)

This is unfortunately completely unacceptable.

The entire steam linux runtime, and indeed every wine runtime MUST NOT require any more privileges than a regular user program. For installation or during runtime.

One philosophical reason: If it's emulating the windows ABI to run a program that doesn't requires privileges, then it must not as for any additional privileges of it's own.

Privileges during installation have never been required and are not allowed. Privileges that are repeatedly granted through permanently-lodged a setuid program that runs every time the game launches? Unthinkable.

The search for the correct amount of split-lock misery

Posted Oct 23, 2022 0:26 UTC (Sun) by NYKevin (subscriber, #129325) [Link] (1 responses)

> One philosophical reason: If it's emulating the windows ABI to run a program that doesn't requires privileges, then it must not as for any additional privileges of it's own.
>
> Privileges during installation have never been required and are not allowed. Privileges that are repeatedly granted through permanently-lodged a setuid program that runs every time the game launches? Unthinkable.

That is a somewhat odd position to take, because on Windows:

1. Steam installs a service, which runs as "Local System." This is entirely equivalent to a daemon running as root, it's just that Windows uses different terminology.
2. It is not uncommon for Steam games to display a UAC prompt on first run. This is usually to install MSVC++ redistributable or something of that nature, rather than doing some weird custom thing, but it still technically qualifies as elevated privileges.
3. The way that Steam manages to install games without requiring a UAC prompt for every installation is kind of... terrible. Basically, it sets the library as world-writable and world-executable. That means anyone can drop a DLL in the same directory as the game and silently hijack it, because Windows considers the directory permissions to constitute a security boundary (indeed, you could just as easily replace the whole exe file). Now, you may argue that this is irrelevant, since the game is running as an ordinary user rather than a superuser, but we have to consider the https://xkcd.com/1200/ factor.

Note: (3) is my understanding of how it works, but like a lot of gamers, I do something *even more terrible than the above* and install everything into C:\Games instead of Program Files, so I don't know for sure if (3) is the default behavior or just my own damn fault. Why do I do this, if I know it's terrible? Because life is too short, that's why. It is not uncommon for older games to randomly break if they don't have full write access to "everything," so deliberately subverting the OS's security is not uncommon for PC gamers. Even if Steam is doing everything right, that doesn't help when half the users are overriding the defaults and using a less-secure configuration.

The search for the correct amount of split-lock misery

Posted Oct 24, 2022 15:01 UTC (Mon) by developer122 (guest, #152928) [Link]

All of the above is pretty much invalidated by "on windows."
We all know that user account permissions on windows are a total mess.

The point is that high permissions should *never* be required for installing and running a game, which does nothing but:
1) download some files
2) copy them into the home directory
3) launch an executable
4) access graphics APIs/sound APIs/input APIs

NONE of those things have ever warranted elevated privledges. Wine has continued doing it's thing for over a decade now without requiring sudo even once. The use of sudo wasn't needed when the ability to trap and redirect windows syscalls was added to the linux kernel, it sure as hell shouldn't be required because of a performance knob.

The search for the correct amount of split-lock misery

Posted Oct 24, 2022 13:35 UTC (Mon) by implr (guest, #159818) [Link] (3 responses)

>The entire steam linux runtime, and indeed every wine runtime MUST NOT require any more privileges than a regular user program. For installation or during runtime.
It already does, at least for VR. On first run SteamVR will ask for sudo, which it uses to setcap CAP_SYS_NICE on its various binaries. If it detects that it can already run at nice -10, it'll skip that step.

The search for the correct amount of split-lock misery

Posted Oct 24, 2022 15:08 UTC (Mon) by developer122 (guest, #152928) [Link] (2 responses)

*Due to unix's legacy as a multiuser system.* It dates back to the early days of unix that only root can decrease a nice value, giving more cpu time.

Does this privileged tunable make any sense on a singe user system? No it does not.
Worst case scenario, the user only DoSs themselves.

The search for the correct amount of split-lock misery

Posted Oct 24, 2022 21:01 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

And wasn't Unix originally written to run games? Specifically Star Trek, iirc ... :-)

Cheers,
Wol

The search for the correct amount of split-lock misery

Posted Oct 25, 2022 10:22 UTC (Tue) by geert (subscriber, #98403) [Link]

Didn't they just needed an OS to develop a document formatting system for the AT&T patents division? ;-)

https://www.gnu.org/software/groff/manual/html_node/Histo...