3 ms·

I'd say it's a very practical problem. Why put N different things that used to run in separate protection domains into the same protection domain? Have we got

by jude- 6y ago

I'd say it's a very practical problem. Why put N different things that used to run in separate protection domains into the same protection domain? Have we gotten N times better at writing code that doesn't crash? Do we believe that we can put N different things into the same address space but somehow ensure that a security hole in one of them won't compromise all of them? Have computers gotten so slow in the last 30 years that doing IPC is no longer an option? I'm glad that you have personally not encountered a crash in Sway -- I really, truly am. But let's not pretend that a data point of 1 indicates a trend.

cycloptic 6y ago
In practice, placing everything in one process seems to reduce the total attack surface. There is quite a lot of code required to synchronize state between the X server, window manager and compositor. When you combine them, you can throw out most of those bits that are largely serialization/deserialization.
- jude- 6y ago
  > In practice, placing everything in one process seems to reduce the total attack surface. Surely you're joking. Privilege separation [1] is a thing for a reason. If we believed that putting different things into the same address space made them more secure, then why stop there? Why not just put the kernel, the shell, X11, your HTTP server, and everything else into the same address space? Let's just do away with processes -- let all schedulable units be threads that can all read and write to each other's memory, because what could possibly go wrong? /s [1] https://en.wikipedia.org/wiki/Privilege_separation https://en.wikipedia.org/wiki/Privilege_separation
  - cycloptic 6y ago
    There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn't make much sense to keep them separated, I know you were joking but it's true: they might as well be threads, it saves you the serialization/deserialization step.
    - jude- 6y ago
      In Wayland, a fail-stop bug in the window management logic will now bring down your compositor and every program that was connected to it. In X11, a fail-stop bug in the window management logic only crashes your window manager -- everything else keeps running. This is a really nice property to have -- in general, why make the "blast radius" of a fail-stop bug bigger when we don't need to? Like, what's the upside of making it so a bug in the window management logic can crash the entire GUI? You claim latency due to no need for serialization/deserialization across process boundaries, and you claim potentially less-complex code. I'm very skeptical about the complexity reduction -- you're replacing the IPC with global state guarded by critical sections which your threads all need to respect. Getting rid of IPC isn't "free" -- you're replacing it with something that could be even worse. So, I'll need to see some actual case studies here. I agree that there is measurable latency (context switches and all), but if it's a difference of only a few extra microseconds -- i.e. something the user won't notice because computers are insanely fast these days compared to when X11 and window managers were first written -- then I'm disinclined to give up my crash resilience. Do you have data to show that there is noticeable, irreducible performance lag in having a separate window manager process from a compositor?
      - cycloptic 6y ago
        I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific environment. I'm speaking in terms of code complexity here, if you want to follow the threaded approach then minimum two threads will do the job (one for the scenegraph, one for the sockets), and an X compositor should potentially be doing this anyway to avoid lag caused by slow rendering. The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server. Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...

by jude- 6y ago

cycloptic 6y ago

In practice, placing everything in one process seems to reduce the total attack surface. There is quite a lot of code required to synchronize state between the X server, window manager and compositor. When you combine them, you can throw out most of those bits that are largely serialization/deserialization.

jude- 6y ago
> In practice, placing everything in one process seems to reduce the total attack surface. Surely you're joking. Privilege separation [1] is a thing for a reason. If we believed that putting different things into the same address space made them more secure, then why stop there? Why not just put the kernel, the shell, X11, your HTTP server, and everything else into the same address space? Let's just do away with processes -- let all schedulable units be threads that can all read and write to each other's memory, because what could possibly go wrong? /s [1] https://en.wikipedia.org/wiki/Privilege_separation https://en.wikipedia.org/wiki/Privilege_separation
- cycloptic 6y ago
  There is no real security boundary or privilege separation in that case, the window manager and compositor are getting full access to the screen and the input devices and all the client windows. That's part of the reason why it doesn't make much sense to keep them separated, I know you were joking but it's true: they might as well be threads, it saves you the serialization/deserialization step.
  - jude- 6y ago
    In Wayland, a fail-stop bug in the window management logic will now bring down your compositor and every program that was connected to it. In X11, a fail-stop bug in the window management logic only crashes your window manager -- everything else keeps running. This is a really nice property to have -- in general, why make the "blast radius" of a fail-stop bug bigger when we don't need to? Like, what's the upside of making it so a bug in the window management logic can crash the entire GUI? You claim latency due to no need for serialization/deserialization across process boundaries, and you claim potentially less-complex code. I'm very skeptical about the complexity reduction -- you're replacing the IPC with global state guarded by critical sections which your threads all need to respect. Getting rid of IPC isn't "free" -- you're replacing it with something that could be even worse. So, I'll need to see some actual case studies here. I agree that there is measurable latency (context switches and all), but if it's a difference of only a few extra microseconds -- i.e. something the user won't notice because computers are insanely fast these days compared to when X11 and window managers were first written -- then I'm disinclined to give up my crash resilience. Do you have data to show that there is noticeable, irreducible performance lag in having a separate window manager process from a compositor?
    - cycloptic 6y ago
      I don't have any raw data for performance numbers and that wouldn't matter anyway because they may not be relevant to your set up; if you're concerned about that you should run a test comparing them yourself on your specific environment. I'm speaking in terms of code complexity here, if you want to follow the threaded approach then minimum two threads will do the job (one for the scenegraph, one for the sockets), and an X compositor should potentially be doing this anyway to avoid lag caused by slow rendering. The difference is that the X compositor is just storing a copy of large amounts of state from the X server, whereas the Wayland compositor would store the canonical data and wouldn't need to worry about falling out of sync with the X server. Also, the way that X does it is overly complicated and is unnecessary to have protection against window manager crashes. A similar type of crash protection could be done with a Wayland implementation and it could be done in a much simpler way than moving the entire window manager out into a separate process. You just need to have another process that can hold the client fds and cache a minimum amount of state needed to resume the clients, it wouldn't need to know as much as the X server does to accomplish that task. Prior art is in the Arcan Wayland bridge, other Wayland implementations have not implemented this but they could eventually: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...