![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The state of XMir
XMir's been delayed from Ubuntu 13.10. The stated reason is that multi-monitor support isn't sufficiently reliable. That's true, but it's far from the only problem that XMir still has:
It's clear that XMir has turned into a larger project than Canonical had originally anticipated, but that's hardly surprising. There's only one developer with previous X experience working on it full-time, and the announced schedule provided no opportunity to deal with unexpected problems. As if that weren't enough, there's obvious conflict between Ubuntu Desktop and Ubuntu Phone when it comes to developer time and required functionality. The one hardware vendor who's willing to take a public stand has demonstrated that they have no interest in supporting XMir, despite Canonical assuring people that they were already engaging in productive negotiations with GPU manufacturers.
Multiple monitor support may be the single most obvious feature where XMir is lacking, but it's not the only one. Technically and politically, this code is a long way from being ready for prime time. Without significant community contribution, Canonical need to focus on prioritising it appropriately rather than expecting a tiny number of developers to perform miracles. Or, alternatively, they could just drop XMir entirely and focus on Unity 8.
- It's still broken on some single-monitor systems
- The input driver bug still isn't really fixed
- It's still missing features
Some machines have display corruption. There are writes to freed memory. To be fair, some of the behaviour that's been seen has been down to underlying bugs in the Xorg drivers that were never triggered under normal use but are hit by XMir. Others are down to implicit assumptions made in the drivers that XMir happens to violate. The problem is that there doesn't appear to have been enough room in the schedule to deal with these interactions, presumably because nobody accounted for the inevitable "This thing we thought would be easy turns out to be difficult" part of the project.
I've mentioned this bug before. It's now marked "Fix released" which is kind of true but not really. Mir now tells XMir that the VT is changing before the VT is changed, but it doesn't wait for that to complete before switching the VTs. Until XMir is scheduled and runs, it's still receiving input events. In most circumstances that window is small, so there's no real risk of triggering it accidentally.
There's one corner case where it might still cause problems. Simply running isn't enough - XMir has to make progress through its event loop. That'll only happen if the X server is processing its wakeup events, and it's possible to effectively stall that by submitting a sufficiently awkward drawing request to the server. The X server will appear to freeze, and if the user then attempts to work out what's going on by switching to a VT and logging in, those input events will still be going to XMir. It's left as an exercise to the reader to construct ways to take advantage of this.
This can't happen in Xorg because the VT switch is blocked until the input devices have been released. Mir could have done the same, but doesn't because of a conscious design decision - in the Ubuntu Phone world, clients stop doing things when they're told to. Ubuntu Desktop is expected to behave the same way.
This is an unfortunate situation to be in. Ubuntu Desktop was told that they were switching to XMir, but Mir development seems to be driven primarily by the needs of Ubuntu Phone. XMir has to do things that no other Mir client will ever cope with, and unless Mir development takes that into account it's inevitably going to suffer breakage like this. Canonical management needs to resolve this if there's any hope of ever shipping XMir as the default desktop environment.
XMir doesn't support colour profiles. XRandR properties aren't exposed, so there's no way to control TV output encoding or overscan. There's still no hardware cursor support. Switching to XMir now would reduce functionality without providing any user-visible gain.
It's clear that XMir has turned into a larger project than Canonical had originally anticipated, but that's hardly surprising. There's only one developer with previous X experience working on it full-time, and the announced schedule provided no opportunity to deal with unexpected problems. As if that weren't enough, there's obvious conflict between Ubuntu Desktop and Ubuntu Phone when it comes to developer time and required functionality. The one hardware vendor who's willing to take a public stand has demonstrated that they have no interest in supporting XMir, despite Canonical assuring people that they were already engaging in productive negotiations with GPU manufacturers.
Multiple monitor support may be the single most obvious feature where XMir is lacking, but it's not the only one. Technically and politically, this code is a long way from being ready for prime time. Without significant community contribution, Canonical need to focus on prioritising it appropriately rather than expecting a tiny number of developers to perform miracles. Or, alternatively, they could just drop XMir entirely and focus on Unity 8.
Re: Security is relative, and short-term user-visible benefit was prolly never the point
(Anonymous) 2013-10-03 07:56 am (UTC)(link)Finally, Ctrl-Alt-BackSpace is not a hole in the way that XMir VT switching is a hole. It kills the X server; you end up on the VT that launched X, which takes over the display before it starts processing input. XMir VT switching is far more insidious; you've switched display to the new VT, your input is clearly going to the new VT, and yet the same input is *also* going to the hidden XMir session.
Now, when XMir catches up and discovers that the VT switch has happened, it'll stop accepting input, but that's an unknown time in the future. But (to give an example), if you do what I typically do when X appears to lock up, and press Ctrl-Alt-F2 to get a new VT, wait for the login prompt, and log in as root so that I can examine the state of the system as a whole and make changes, you've now created an opportunity under XMir for a malicious application to stall X with a big chunk of work, and then capture all input. Hey presto, it's caught my root password. Joy.
So the important difference is that in the case mentioned in JWZ's FAQ, I can avoid being caught out by watching the screen. If it changes to a VT, I should stop typing immediately, and then I won't lose more than a character or two to the wrong process. In the XMir case, I have to somehow wait for XMir to catch up, which takes unbounded time thanks to the nature of the X protocol - oh, and I can't examine the state of the system to tell when XMir has caught up.
Re: Security is relative, and short-term user-visible benefit was prolly never the point
(Anonymous) 2013-10-03 09:16 am (UTC)(link)Re: Security is relative, and short-term user-visible benefit was prolly never the point
(Anonymous) 2013-10-03 12:05 pm (UTC)(link)Re: Security is relative, and short-term user-visible benefit was prolly never the point
(Anonymous) 2013-10-03 06:11 pm (UTC)(link)Re: malicious xscreensaver getting your passwd, vs malicious mir-hog getting your passwd
(Anonymous) 2013-10-03 03:29 pm (UTC)(link)So if that is the current state of password security in X, what is the current state in mir, compared to before the bug was marked fixed-released? As you explain, the current hypothetical security hole (in the sense that there are no script-kiddie exploits in the wild) is that a Malicious App could do such and such and so and so, then maybe capture your password. But as the first reply points out, once you have malicious apps installed locally, you are already in a world of hurt. (Harking back to our discussion of a hypothetically malicious xscreensaver installed locally.)
The *previous* state of mir was worse: no malicious app was required, just bad luck could send your password unencrypted over the internet. If you were in irc or skype or similar, and then hit ctrl-alt-f2, your username + enter + passwd + enter would be accidentally transmitted. *That* is a significant security flaw, even though it depends on several things all being true -- sooner or later, somebody was bound to get bitten. The current state is better, and arguably on par with the current state of Xorg. (Of course, mir is a ton of new code, written in haste, and is thus far less trustworthy heuristically than Xorg. But as far as *known* flaws they are prima facie on the same level.)
MJG is correct when he calls this 'not really' fully fixed, but I think he is being pedantic. Mir is now 'good enough' relative to the security level of X, that it prolly would be suitable for broad release, with few Big Red Warnings on the tin. Canonical delayed making it default on dtops because of the multi-monitor thing, the general immaturity of the code, and other usability-regressions, not because of any security worries. That's not to say I don't want Mir's security improved, including the fixing of the Malicious App hogs mir to capture your passwd flaw... but I take such fixes in context, relative to the security of wayland and Xorg.
Re: malicious xscreensaver getting your passwd, vs malicious mir-hog getting your passwd
The only way around this would be to log in remotely via ssh or something similar, which requires having another system available and up and ready. Lacking that, the only way to bounce the system without compromising security is to pull a system reset at the box, which poses filesystem damage concerns.
Anything that makes me choose between security and possibly completely hosing my system (admittedly unlikely, but it could happen) is not getting installed on any box I control. And any distro which defaults to it is going on my blacklist.
Re: malicious xscreensaver getting your passwd, vs malicious mir-hog getting your passwd
(Anonymous) 2013-10-03 06:18 pm (UTC)(link)The original bug was a security bug, plain and simple. Not good, but understandable given the schedules Canonical is working to.
The "fix" does not actually solve the bug; it just hides it, so that it's harder to hit. If this is how security bugs in Mir proper (not just XMir) are going to be treated, then I'm not going to use it - one thing I've seen throughout my career is that if you convert a security bug to a race condition, the black hats just work out how to win the race.
Re: accidentally compromising your own passwd, vs malicious mir-hog getting your passwd
(Anonymous) 2013-10-04 10:18 pm (UTC)(link)Canonical's bugfix is intended to address the blow-your-own-foot-off aspect, i.e. the chance that a real-life non-malicious enduser might have skype open, and then flop over to ctrl+alt+f2, jam in their uid enter passwd enter, and then later notice (or fail to notice) they just compromised their own box. Calling this 'fixed' is definitely moving the goalposts, sure, but it is also true, more or less, if you are just talking about non-malicious endusers. Whether to re-open the existing bug-num, to solve the race-condition-against-malicious-app aspect, or to open that as a new bug-num, is simply semantics.
p.s. What would be a *real* fix for the VT switching security flaw? Our host mjg suggests that Canonical's design decisions, that concentrate on the phone use-case at the expense of the desktop use-case, have screwed them over. Part of the reason they don't have multi-head support working right is because smartphones usually only have one screen (sigh... maybe the forgot tablets with hdmi-out jacks?), and part of the reason that VT switching was broken in the first place is that phones don't usually provide ctrl+alt+f2, and now part of the reason that VT switching is still a concern when you talk about malicious adversaries is because canonical made a design choice that works for phones... but not as well for desktops. Maybe they can more permanently fix the problem, or maybe they are stuck with a band-aid.
p.p.s. By contrast, what would be the *real* fix to rm rf? Automated versioned backups of the filesystem (RAID is not good enough in this case -- or in general for any case where you need actual backups -- because rm rf will span your raid volumes just as easily as it will wipe a single drive partition). That is quite obviously a hard problem. So instead we get --preserve-root, the band-aid.
p.p.p.s. And Now For Something Completely Different.... here is another blast from the past. http://betanews.com/2007/12/04/mpaa-s-student-p2p-sniffer-pulled-over-copyright-issues/ Being from ye olde year of our laird two thousand ought seven, there is no Mir stuff , but there is juicy mjg and xubuntu stuff. Did the changes made by the unnamed hired mpaa guns ever get released under GPL? Did the uSpywareToolkit truly die in 2007, or did it return in a new cloak? The news cough*infotainment*cough articles just mention the irony of the sit, and then never do any followup. Okay, okay, back on topic.
Re: accidentally compromising your own passwd, vs malicious mir-hog getting your passwd
(Anonymous) 2013-10-04 11:41 pm (UTC)(link)The concern I have over the VT switching is that I've personally experienced interactions between bugs in X drivers and bugs in older versions of Mozilla Firefox such that a website's JavaScript triggered behaviour can cause X to lock up for apparently infinite time - a VT switch still worked, it just takes around 15 seconds to happen. Once that's done, I can log in, kill Firefox and recover control.
In XMir land, that VT switch is instant; however, as I'm logging in and killing Firefox, the application I had focused gets my input, too. This is unexpected behaviour - I thought I was typing into the VT, but in fact I'm typing into the VT and XMir (and hence into Skype, Empathy, or other IM app).
And the fix is simple in design (albeit possibly hard to implement, depending on how poor Mir's codebase is) - use the same mechanism as Xorg does to prevent a VT switch happening while X is still accepting input. Put that mechanism in place instead of the racy one they're using now.
It's all about expectations, basically. XMir breaks my model of when it's safe to type into another VT, and doesn't provide me with the tools to create a new model. rm prophylactics do provide me with the tools to create a new model.
Link to where mir's vt-switching is being designed
(Anonymous) 2013-10-08 01:20 pm (UTC)(link)As for XMir and VT, our expectations are similar, and our analysis is similar... where we differ is that it sounds like you want XMir to be finished now, and I think XMir is still very much in beta and thus fluid. In other words, it is still under heavy development, and until 13.10 has been debugged, and the final kinks worked out for what ships with 14.04, I'm reserving judgement on whether Mir/Xmir are going to offer something relatively (to Xorg) secure speedy stable shiny useful intuitive et cetera. Here is the blog of one of the mir/xmir folks that is particularly interested in fixing up terminal-switching. https://dvdhrm.wordpress.com/ See particularly the Sane Session-Switching and the How VT-switching Works. Do you see serious problems with what he's talking about in those, security or otherwise? That's where mir&xmir are heading, from what I can grok, which is *not* necessarily the same thing as where the beta release-early-release-often codebase actually is right now.
The 'racy one' used now is just a prophylactic, to prevent 99.9% of security-pregnancies. If you are in one of those 0.1% situations that you describe, where firefox is hanging up X, and you think you might have left your cursor-focus in an IM chat window, the workaround is to unplug your LAN cable (or use Fn+F12 or somesuch to power off your wifi). But be fair here: 99.9% of the time, the racy band-aid keeps the typical enduser from shooting themselves in the foot. That's good enough for beta stuff, which is what Mir is, really. If they *keep* using the racy band-aid indefinitely, then I agree that's not a Good Thing, but that remains to be seen.