Isolating Xwayland in a VM
roscidus.com
roscidus.com
[1] https://github.com/QubesOS/qubes-issues/issues/2809
[2] https://reactos.org/forum/viewtopic.php?t=16480
[3] https://github.com/Jeeppler/QubesOS-notes/blob/master/ReactO...
The hardware X server runs in a secure X VM, which has exclusive access to input devices, the GPU, and the physical frame buffer memory. (Ordinary X gives all programs access to all traffic from all input devices, and the whole frame buffer.)
Each client VM runs an X server that really only manages window contents. These windows are mmapped to memory the secure X VM exposes from its address space, It copies pixels from the shared regions to the real frame buffer. UI events that happen in each such window are forwarded to the client VM that owns it.
Regular desktop "panel" widgets and other UI stuff is managed by the secure X VM.
USB devices can be attached, via the secure X UI, to a chosen client VM, or taken back. Likewise, input devices such as microphones. The VM only gets PulseAudio streams forwarded from a microphone, and has no access to the sound chip.
The only awkward thing is that client VMs have no access to any GPU acceleration. This is not a problem for normal use -- browsers all can use CPU-only graphics modes, and they are fast enough for the usual things, including youtube videos, albeit with increased power consumption.
Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers.
[1] https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...
Just curious, what are the Wayland developers expected to do? This seems like an Xwayland and compositor implementation issue.
As for Wayland,
https://wiki.openjdk.java.net/display/wakefield/OpenJDK+Proj...
> It is very unlikely that distros will be ready to ship all the pieces we need in the next 12 months. So the "short term" goal may actually need to wait for somewhat longer than that.
https://wiki.openjdk.java.net/display/wakefield/Meeting+Note...
The way you made your remark could be understood as if nothing was being done at all.
Don't get me wrong, the blame is squarely on the Java ecosystem that is too slow to keep up with the progress, Wayland developers did great job. The problem is that we still use some of that Java software, or some of that GTK2 software (GIMP), so it's better to accomodate the needs of that software, even if just temporarily.
If anything the whole GNU/Linux ecosystem is too slow adopting Wayland.
Feel free to improve and/or review it. Maybe it's very important to you. But it may no be very important to other contributors, and said contributors are just volunteers.
The reviewers have asked for some details about the changes and no response yet, it seems unfair to blame the maintainers here.
But of course that goes against the narrative of "Wayland bad".
Android has a similar, if more centralized feedback loop: AOSP drops, device makers build out customizations on top of it, Google adopts some of these features upstream (whether by building new implementations or merging contributions from vendors), and then those vendors go on to building the next differentiating thing now that they don't have to dedicate those resources to individually maintaining stylus support/multiwindow/notification badges/whatever.
Well, there is a wlroots impl, so I've just added a couple lines to wlroots to invoke this support from an env variable without having to modify the actual compositor :D
https://github.com/unrelentingtech/wlroots/commit/5b8308651c...
but the wlroots impl isn't merged either, so I think there's kind of a mutual dependency here. Either your MR or the wlroots MR should go in first!
It... doesn't seem like it is, really. Couldn't we modify the X server so clients just can't do that anymore? And then introduce a new X extension that provides for cases where this does need to happen, like the window manager (which could be granted blanket permissions), and other apps that would cause a dialog to pop up where the user could approve or deny access (think apps that take screenshots, or video conferencing apps that share the screen or specific windows with other participants). This permissions dialog could be handled by the window manager, or perhaps some standalone app that is somehow securely registered with the X server via this new X extension.
I expect there are some other issues (and things that will break[0]) with apps not knowing about other apps' windows, but I'm not convinced those issues can't be solved. I could even imagine that this new regime might only implement partial isolation, where clients can't read pixels from or fake events to other clients' windows (among other things), but can know the sizes and positions of other windows, and maybe even read some whitelisted set of window properties. I think that would still address most, if not all, security concerns with the current model.
(Just to present some credentials so this doesn't come off as a clueless, "duh, this is so easy, you morons"-type post: I've written an X11 compositor, hacked on a window manager, built a simple toy WM for fun, and was once a co-maintainer of a reasonably popular desktop environment. So I'm not a complete noob here.)
Certainly there are other benefits to Wayland over X11, not just security: greatly simplifying the graphics situation, moving the compositor into the "server" where IMO it belongs, etc. But I'm still not completely sold on the idea that this is worth a multi-decade project to completely replace this critical bit of the Linux GUI stack.
I'm also not convinced that the X server can't be extended in other ways to fix other deficiencies. Of course, at the end of the day, I'm not doing the work, and the nature of open source means that if everyone wants to work on Wayland and no one wants to work on X11 or the xorg server, that's just the way it will be. But it feels like if we'd put even a fraction of the Wayland effort toward making X11 better, we'd be done by now, and people writing X11 applications would mostly not have had to do all that much work to migrate (and many wouldn't have to do any). Would it be as objectively "good" as Wayland supposedly is? No, probably not, but perhaps that doesn't matter.
[0] One thing I can think of here is that some applications need to open more than one connection to the X server, and the X server would see them as separate clients. That could break an application that expects to be able to share and manipulate resources between the multiple connections. But perhaps that could be worked around by grouping permissions not solely by connection, but by process ID. There are probably still some edge cases here, but I think changing the apps here would be ok to do; at least, it seems like less work to accept this sort of breakage and try to fix the apps rather than develop an entirely new windowing system!
security was only a footnote in the list of arguments of why X has/had to go.
X11 maintainer Daniel Stone's[0] very funny but also educational talk[1] from 2013 linux.conf.au has a lot of the gory details that make you say thank fuck and good riddance. The talk will make you feel truly grateful instead of nostalgic. Anyone who missed the 3 decade long discussion of why X is bad give it a go (it'll put good cheer in your heart I promise).
> I'm also not convinced that the X server can't be extended in other ways to fix other deficiencies.
it's not about whether anyone _can_ but if anyone should and is willing to do so is the right question (that Daniel's talk answers).
BUT X IS THE UNIX WAY! << so what is the 1 thing X does, and what is it doing well?
That... Isn't entirely fair. UNIX Philosophy is usually applied at the program level. You're talking the entire X stack, which, like it or not, started as "Network agnostic graphical computing" which was composed out of a handful of programs, and a protocol.
Now. We all know it isn't that now; and I don't buy that it's all X's fault. You have what, going on 40 years worth of dead ends there, that obviously someone thought was going to be important at some point, but which also were emergent outcomes of a bunch of companies doing, among other things, pursuing their own ends without tipping their hand to everyone else trying to yoink an idea or two. If you don't think X suffered for it, I'd like to point you at the rats nest of abstractions you end up having to navigate. And no, a compositor doesn't magically make it go away. Further, how many people here discussing/developing/opining have read, understood and reasoned about the source as a whole to the point of actually getting something working?
I'd wager not many. Next time I have a few months, it's on my TODO list. I have gone through the X.Org Dev docs a couple times though. Need to probably print it out and do some bookmarking to build up my haptic recall model for it.
You WILL be running a Wayland desktop in the near future. Xorg itself is already unmaintained abandonware. The next step is deprecating and removing X support from the major toolkits. Beyond that, who knows. Probably Xwayland itself will be deprecated and removed too.
Best to suck it up, burn your X config to the ground, and start afresh with Wayland. If it's janky, submit bug reports or PRs. Just rip the band-aid off already, because nobody wants to hear your hemming and hawing when the axe finally comes for X.
I'm not going to go over the whole video since it was primarily made for entertainment and therefore any point can be defended by "he was exaggerating for comedic effect". Invoking this video is akin to invoking late night tv hosts when talking about politics.
And then of course he also has some valid points which are unfortunately diminished because the uninformed watcher will not be able to distinguish them for the invalid points.
Meanwhile Wayland's design results in people writing hotkeys as root-running programs that hijack input devices at low level, because the whole system is incapable of providing such feature in pluggable way...
No, the system is perfectly capable, it's just hard to get all compositor authors to agree on a common protocol (and to agree that it's necessary in the first place). Big DEs especially prioritize regular-user usability features (e.g. currently lots of work on IMEs) rather than fancy nerd customizations that don't always need to be a common external program that works with all compositors (is it really a problem to write a plugin for your DE specifically? No!).
And ability to have global hotkeys is not fancy nerd customization. Writing a plugin is also a much more harrowing experience when any bug might take down your entire graphics stack due to above mentioned centralization by design.
Honestly, Wayland by design feels like MVP that forgot that outside certain limited systems they are missing a lot of "filler" APIs, and somehow assumed it would magically happen by itself. Unfortunately there's no DCOM on Linux in practice, and D-Bus is much more annoying to program against, so the expected "do it in D-Bus" never materialized (and was supposed to cover even things like copy-paste in the original discussions).
[1] X11 servers from vendors other than XFree/XOrg had things like advanced access controls over what applications could do, some integrated with OS-wide Mandatory Access Controls. There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
Personally for me I do find D-Bus to be easier to program than Wayland though, the libraries for it are a lot more mature. You might want to try something like pydbus or systemd's sd_bus, or the Rust library zbus. Those are some of the better implementations I've seen.
X11's security mechanisms were never really complete, I don't know of any distribution that actually uses those Mandatory Access Control schemes. Distributions that focus around X security (e.g. Qubes) all seem to use X sandboxing now which should work better than MAC-based security but is quite complicated to set up and still not practical for most other distributions to use. I remember seeing some MAC-based proposals for Wayland but they never caught on because the focus there has also moved to sandboxing.
>There's also the forgotten (by most) part of the protocol for secure entry that one is supposed to use when accepting passwords and the like.
AFAIK there is no special part of the protocol for this and this was never really a good solution. It's just done using an ordinary keyboard grab, which are mostly considered an insecure API that does nothing in practice because all the other X security schemes will try to disable or restrict grabs for security reasons.
D-Bus is still way more problematic to work with than DCOM. Even on the operation model (something that generic libraries will always have hard time papering over).
As for the X11 extensions - no Linux distro (at least on open market). Because XFree86/X.Org != X11. In fact, XFree86 was essentially lowest common denominator, using with little change a design that wasn't specially good back in 1992. Even if glamor helped some of it, it was more a bandaid than rearchitecting the server (which could have been done without changing protocol).
I kind of trust Daniel Stone way more that some rando from internet? https://www.phoronix.com/scan.php?page=search&q=Daniel+Stone
They are mostly synonymous, there is a large amount of software using Xlib that will likely not ever be rewritten to use XCB. And Xlib is still a better option than XCB if you want to use any client libraries because those all require Xlib.
>He gets called out for this by one of the attendees but brushes it away with "but it's really hard to do". It's actually not.
With GTK applications like gedit, it actually is because those are in the category of "won't ever be updated to use XCB". IIRC somebody even tried to port GTK to XCB once and the patches were never merged because it broke everything. XCB is nice for some things but comes with its own set of issues. Please also keep in mind that if you're suggesting the only reasonable solution is to rewrite every client to use a new library, that comes with about the same difficulty as porting to Wayland.
Provide an X server :-P.
The Unix Philosophy not only isn't really a philosophy but also isn't meant to be a dogma - it is meant to be a guideline that, when it makes sense, can be bent.
For example not even the original Unix kernel followed the Unix philosophy because sometimes you need some programs to do more than one things - often in order to enable other programs focus on their "do one thing well" aspect (e.g. window managers).
The limitations that are there are very minor and if someone cared they could be completely eliminated. As you wrote, Xorg is opensource - which also means that these limitations exist since there wasn't much of an interest towards addressing them.
Though there is also the bureaucracy aspect - in recent years i've been trying to provide fixes, improvements, etc on various open source projects i'm using and i've noticed that the more involvement there is by companies in a project, especially among maintainers, the more bureaucracy and harder it is to get things merged to the point where whenever i see an issue with something that has at least one bigger company behind it, my first instinct is to make my own fork, fix it there and leave it at that. Or not bother. Projects that are primarily run by volunteers tend to be way easier to get involved with.
But there isn't really any core limitation of how X works that couldn't make it so that, e.g., some "privileged" applications (like the window manager) can decide what other less privileged clients can see and even create "domains" on the fly (as far as the applications are concerned it'd be like clients connecting/disconnecting from the server) for applications to see each other if needed. It could be possible if there were people interested in it (and interested enough to implement it, of course :-P).
BTW none of the issues occur in D-Bus, that was designed to fit these use cases which is why it typically gets used for "privileged" APIs on Linux. Fixing this issue in X11 would probably entail throwing out the protocol entirely and making something new that works more like D-Bus. Maybe you could avoid that by hacking Xlib and making another X server with an elaborate set of heuristics but that won't work for everything and also seems like a really bad way to do security. At best you probably rewrite the whole X server to end up with something roughly equivalent to XWayland.
Sorry but i do not think you understood my comment at all considering what you wrote. What i wrote is for the X server to pretend the other clients do not exist, which is something it already can do (at least for a single client, if what harporoeder wrote about putting all untrusted clients to a single domain is correct) and...
> you can't really fail anything because errors are usually treated as fatal in Xlib and most clients don't bother with error handling in Xlib
...any errors would be the same as if the other clients didn't exist and handled the same way.
Also the important bit is that you cannot do what i describe right now with the released / existing Xorg, but there is already enough functionality there to show that it is possible if the Xorg server was modified to enable it. This isn't something you can switch on with some configuration or make a couple of lines code change, it does need some effort to implement the necessary functionality and that effort combined with the lack of anyone really needing it is the main reason why it isn't already done.
To me it seems that the author doesn't list contact details on purpose. There's an extensive "about me" section without any contact information, so I think the author might wish not to be contacted.
Edit: actually, his Gmail is in one of the screenshots in this article.
I prefer not to use email for most things because then the reply only benefits one person, whereas replies in a public forum can be read by others and get indexed by search engines.
I've been thinking about creating a Matrix room for each blog post as a discussion forum, but so far most posts have ended up on other discussion sites anyway.
Still close to unusable: Web conferences in the browser (webex for example).
the linked code about vim is incredible tho (and not the good kind of it), I have actually spent a good part of my evening trying to understand how they end up with that implementation (I do have the same kind of spaghetti code and wonder the same about my code) :
https://github.com/vim/vim/blob/9cd063e3195a4c250c8016fa3409...
Maybe you should know about the project SpectrumOS, which seems to have extremely similar goals to yours.
I think instead of running persistent VMs for different roles, it spins up VMs very quickly to run individual apps in.