9 ms·

Yes. That's the problem. Not only is the resulting stack less resilient to crashes, but also it takes away flexibility by needlessly welding together two orthog

by jude- 6y ago

Yes. That's the problem. Not only is the resulting stack less resilient to crashes, but also it takes away flexibility by needlessly welding together two orthogonal design concerns (window management vs rendering). Sway is like putting X11, the window manager, the global hotkey daemon, screenshot grabber, and so on, all into the same address space. What could possibly go wrong? /s Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. Like, aren't keystrokes propagated as packets sent through an X11-owned UNIX domain socket in /tmp? Can't we just attach a policy to that socket to decide which PIDs (or process groups, session groups, containers, etc.) get to see which messages?

sprash 6y ago
> I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point. The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand. 1.: https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/
- cycloptic 6y ago
  The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
  - jude- 6y ago
    Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.
    - cycloptic 6y ago
      Maybe that's true if that's your only concern, but there are other reasons to replace X11 than just this. Also, X11 is arguably not the whole graphics stack, at this point the DRM/Mesa piece is much larger and more significant, and Wayland doesn't replace it outright anyway -- it makes it optional if needed for backwards compatibility, in the same way that macOS has XQuartz.
      - jude- 6y ago
        The other two concerns in GP are no screen tearing, and better hidpi / multi-monitor support. Is it truly less work and less disruptive to address these to concerns within X11 than it is to throw X11 out (and also leave all nvidia users high and dry)? Also, keep in mind that throwing X11 out and replacing it will take more than just technical legwork -- it will also take ecosystem buy-in and standardization, and if we're being honest with ourselves, this is the harder problem. Recall that the X11 ecosystem has a 30-year head start on this, and there's a crap-ton of 3rd party software that assumes an X11 environment that Wayland is going to need to emulate. If X11 does indeed go the way of the dodo, I think we can reasonably expect another 30 years of bug reports in the form of "Fuck Wayland! I upgraded to Wayland and my $IMPORTANT_THING broke!". I very much doubt that at the end of the day the switch to Wayland is going to be overall easier than just fixing X11, but would love to be convinced otherwise.
        cycloptic 6y ago
        The usual way to fix other concerns like that has been to add more WM atoms or add more X extensions, which is a similarly uphill battle requiring buy-in and standardization, and typically old X clients just won't be updated to support those new things. The way to get the most value out of such things would be to add support to the major toolkits, but those have already been ported to Wayland for some years now. The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.
        6y ago
chousuke 6y ago
It's a theoretical problem. The window-management parts of sway are tiny and having them in the same process means you don't have to do IPC every time your windows do something. That simplicity means it's easier to write code that doesn't crash. Most of the heavy-lifting is done in wlroots anyway. wlroots based compositors really do implement just their own flavour of compositing what you see on the screen on top. That said, you still can use IPC, if you really want to; I have an external window manager that augments Sway's tiling system via its i3-compatible IPC mechanism to arrange my windows in a way that Sway doesn't do natively. If you really wanted to, there's nothing stopping you from writing a wayland compositor that uses an external window manager. At any rate, I don't buy the reliability argument at all. I've used sway since 0.10 or something, and I only ever remember crashing it once, and I fixed that bug myself. :P
- 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
hawski 6y ago
I hear you, but a compositor could be multi-process - it was not yet done, but in time it will be.
kelnos 6y ago
> Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. The response I've heard to this question is entirely nonsensical: it could be done with an X extension, but getting adoption from various parties to make this work would be difficult. As if building an entirely new display system doesn't require orders of magnitude more work and buy-in.
- kaba0 6y ago
  Basically everything would stop working with X, because X simply relies on being able to listen to everything. Actually there are nested xservers that do something like this, but now global hotkeys don’t work, it doesn’t have an api for screenshots, so those won’t work either and the like. And you can probably add some X extension which can’t be queried properly, but then you can just as well create a new display protocol that actually knows about GPUs
  - jude- 6y ago
    I don't care if X sees everything (hell, even if X didn't, the kernel certainly still would). I only care that I can control which programs see which X11 events. Like, my hotkey program can see everything, but my Web browser can only see its own x-windows' events.
    - cycloptic 6y ago
      There is some rough support for that in the X server, but it is lacking a good API or user interface, and the desktops that would implement that are doing it in Wayland.
      - jude- 6y ago
        Doesn't that strike you as odd? Like, why is it that X11 was so close to fixing the problem, but everyone who would benefit from it (and who touts Wayland's ability to do it) decides to just throw it all away and re-built everything from the ground up? I'd sure like to know what they know about this.

by jude- 6y ago

sprash 6y ago

> I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs This can be done via firejail[1] + xpra/xephyr but is a rather cumbersome endeavor. The X11 standard also contains access control hooks that allow you to "firewall" any aspect of your application. However it is used by no application I personally know of and is rendered useless by how the xinput mechanism is implemented at this point. The reason nobody bothered to deal with this so far is that people almost never run untrusted software on FOSS systems which is what X11 primarily targets. There was no demand. 1.: https://firejail.wordpress.com/documentation-2/x11-guide/ https://firejail.wordpress.com/documentation-2/x11-guide/

cycloptic 6y ago
The demand there would be with products like Qubes and Subgraph, which are currently using Xephyr and Xpra. Eventually Wayland should be able to improve performance there, and bring some of the security benefits of those setups to other distributions.
- jude- 6y ago
  Seems to me that firewalling X11 programs from one another would take a lot less work and be a lot less disruptive than requiring users to run multiple VMs with multiple X11 servers and/or replace the whole graphics stack.
  - cycloptic 6y ago
    Maybe that's true if that's your only concern, but there are other reasons to replace X11 than just this. Also, X11 is arguably not the whole graphics stack, at this point the DRM/Mesa piece is much larger and more significant, and Wayland doesn't replace it outright anyway -- it makes it optional if needed for backwards compatibility, in the same way that macOS has XQuartz.
    - jude- 6y ago
      The other two concerns in GP are no screen tearing, and better hidpi / multi-monitor support. Is it truly less work and less disruptive to address these to concerns within X11 than it is to throw X11 out (and also leave all nvidia users high and dry)? Also, keep in mind that throwing X11 out and replacing it will take more than just technical legwork -- it will also take ecosystem buy-in and standardization, and if we're being honest with ourselves, this is the harder problem. Recall that the X11 ecosystem has a 30-year head start on this, and there's a crap-ton of 3rd party software that assumes an X11 environment that Wayland is going to need to emulate. If X11 does indeed go the way of the dodo, I think we can reasonably expect another 30 years of bug reports in the form of "Fuck Wayland! I upgraded to Wayland and my $IMPORTANT_THING broke!". I very much doubt that at the end of the day the switch to Wayland is going to be overall easier than just fixing X11, but would love to be convinced otherwise.
      - cycloptic 6y ago
        The usual way to fix other concerns like that has been to add more WM atoms or add more X extensions, which is a similarly uphill battle requiring buy-in and standardization, and typically old X clients just won't be updated to support those new things. The way to get the most value out of such things would be to add support to the major toolkits, but those have already been ported to Wayland for some years now. The backwards compatibility is done through XWayland which functions similarly to XQuartz, in that it is just the Xorg server running using Wayland as a backend driver.
        6y ago

chousuke 6y ago

It's a theoretical problem. The window-management parts of sway are tiny and having them in the same process means you don't have to do IPC every time your windows do something. That simplicity means it's easier to write code that doesn't crash. Most of the heavy-lifting is done in wlroots anyway. wlroots based compositors really do implement just their own flavour of compositing what you see on the screen on top. That said, you still can use IPC, if you really want to; I have an external window manager that augments Sway's tiling system via its i3-compatible IPC mechanism to arrange my windows in a way that Sway doesn't do natively. If you really wanted to, there's nothing stopping you from writing a wayland compositor that uses an external window manager. At any rate, I don't buy the reliability argument at all. I've used sway since 0.10 or something, and I only ever remember crashing it once, and I fixed that bug myself. :P

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

hawski 6y ago

I hear you, but a compositor could be multi-process - it was not yet done, but in time it will be.

kelnos 6y ago

> Regarding security, I'm honestly surprised no one has just tried to make it so you can "firewall" X11 programs from one another. The response I've heard to this question is entirely nonsensical: it could be done with an X extension, but getting adoption from various parties to make this work would be difficult. As if building an entirely new display system doesn't require orders of magnitude more work and buy-in.

kaba0 6y ago
Basically everything would stop working with X, because X simply relies on being able to listen to everything. Actually there are nested xservers that do something like this, but now global hotkeys don’t work, it doesn’t have an api for screenshots, so those won’t work either and the like. And you can probably add some X extension which can’t be queried properly, but then you can just as well create a new display protocol that actually knows about GPUs
- jude- 6y ago
  I don't care if X sees everything (hell, even if X didn't, the kernel certainly still would). I only care that I can control which programs see which X11 events. Like, my hotkey program can see everything, but my Web browser can only see its own x-windows' events.
  - cycloptic 6y ago
    There is some rough support for that in the X server, but it is lacking a good API or user interface, and the desktops that would implement that are doing it in Wayland.
    - jude- 6y ago
      Doesn't that strike you as odd? Like, why is it that X11 was so close to fixing the problem, but everyone who would benefit from it (and who touts Wayland's ability to do it) decides to just throw it all away and re-built everything from the ground up? I'd sure like to know what they know about this.