TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Isolating Xwayland in a VM

111 pointsby pmarinover 3 years ago

11 comments

southerntofuover 3 years ago
Friendly reminder that QubesOS, mentioned in the article, is a great system if you have actual security needs. Their blog is full of treasures explaining what their research and development is about.<p><a href="https:&#x2F;&#x2F;www.qubes-os.org&#x2F;news&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.qubes-os.org&#x2F;news&#x2F;</a>
评论 #29648232 未加载
myelinover 3 years ago
This is very very cool. I had coincidentally just spent my evening trying to figure out how to get Wayland and Sommelier working in a slightly odd environment (Crouton, on Chrome OS), and this article showed up on HN just in time for me to appreciate it :)
评论 #29646497 未加载
ncmncmover 3 years ago
It should be noted that Qubes is thus far the only actually secure X environment.<p>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.)<p>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.<p>Regular desktop &quot;panel&quot; widgets and other UI stuff is managed by the secure X VM.<p>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.<p>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.
razemioover 3 years ago
Amazing! Thank you for sharing. I have to admit that I lack a lot in security related stuff. Reading your post is inspiring. I am thinking about experimenting with proxmox to run a similar setup. Currently I isolate each customer in its own vm. This works well but comes with the overhead to run a remote session for each customer. Using your method I could have a much more streamlined work flow while maintaining a high level of isolation.
hhhover 3 years ago
Spectacular article, I couldn’t express more gratitude for the deep context provided around every piece.
xvilkaover 3 years ago
Useful approach, given the troves of applications that cannot be ported to the native Wayland in years to come - all GTK2 apps, e.g. GIMP, all Java apps, and so on...<p>Regarding HiDPI and XWayland, there is work-in-progress PR[1] that so far is being ignored by the Wayland developers.<p>[1] <a href="https:&#x2F;&#x2F;gitlab.freedesktop.org&#x2F;xorg&#x2F;xserver&#x2F;-&#x2F;merge_requests&#x2F;733" rel="nofollow">https:&#x2F;&#x2F;gitlab.freedesktop.org&#x2F;xorg&#x2F;xserver&#x2F;-&#x2F;merge_requests...</a>
评论 #29646906 未加载
评论 #29646875 未加载
评论 #29648236 未加载
评论 #29646407 未加载
评论 #29646885 未加载
kelnosover 3 years ago
This is a bit off topic, but the article reminded me of something that&#x27;s always bothered me: one of the (several) motivations for creating Wayland was to fix the security issues with X11, namely that any X client can read and manipulate the windows belonging to any other X client. And I&#x27;ve heard claims that this problem is just unsolvable.<p>It... doesn&#x27;t seem like it is, really. Couldn&#x27;t we modify the X server so clients just <i>can&#x27;t</i> 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.<p>I expect there are some other issues (and things that will break[0]) with apps not knowing about other apps&#x27; windows, but I&#x27;m not convinced those issues can&#x27;t be solved. I could even imagine that this new regime might only implement partial isolation, where clients can&#x27;t read pixels from or fake events to other clients&#x27; 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.<p>(Just to present some credentials so this doesn&#x27;t come off as a clueless, &quot;duh, this is so easy, you morons&quot;-type post: I&#x27;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&#x27;m not a complete noob here.)<p>Certainly there are other benefits to Wayland over X11, not just security: greatly simplifying the graphics situation, moving the compositor into the &quot;server&quot; where IMO it belongs, etc. But I&#x27;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.<p>I&#x27;m also not convinced that the X server can&#x27;t be extended in other ways to fix other deficiencies. Of course, at the end of the day, I&#x27;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&#x27;s just the way it will be. But it feels like if we&#x27;d put even a fraction of the Wayland effort toward making X11 better, we&#x27;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&#x27;t have to do <i>any</i>). Would it be as objectively &quot;good&quot; as Wayland supposedly is? No, probably not, but perhaps that doesn&#x27;t matter.<p>[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!
评论 #29647687 未加载
评论 #29648704 未加载
Kototamaover 3 years ago
His blog is really great but last time I didn&#x27;t find a way to post a comment or to contact the author. Do somebody knows better?
评论 #29647783 未加载
评论 #29647164 未加载
ossusermivamiover 3 years ago
Very good article,<p>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) :<p><a href="https:&#x2F;&#x2F;github.com&#x2F;vim&#x2F;vim&#x2F;blob&#x2F;9cd063e3195a4c250c8016fa340922ab21fda252&#x2F;src&#x2F;gui.c#L489" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;vim&#x2F;vim&#x2F;blob&#x2F;9cd063e3195a4c250c8016fa3409...</a>
tyingqover 3 years ago
Interesting. WSLG seems to do this as well, bundling Xwayland, Pulse Audio, and Weston into a single separate VM that serves all the user-installed WSL distros on a box. <a href="https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;commandline&#x2F;wp-content&#x2F;uploads&#x2F;sites&#x2F;33&#x2F;2021&#x2F;04&#x2F;diagram-description-automatically-generated.png" rel="nofollow">https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;commandline&#x2F;wp-content&#x2F;upload...</a>
ncmncmover 3 years ago
[Edit: I found the blog entry from March that mentions SpectrumOS.]<p>Maybe you should know about the project SpectrumOS, which seems to have extremely similar goals to yours.<p><a href="https:&#x2F;&#x2F;spectrum-os.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;spectrum-os.org&#x2F;</a><p><i>I think</i> instead of running persistent VMs for different roles, it spins up VMs very quickly to run individual apps in.