[personal profile] mjg59
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 still broken on some single-monitor systems

  • 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.

  • The input driver bug still isn't really fixed

  • 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.

  • It's still missing features

  • 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.

No showstoppers

Date: 2013-10-02 09:50 pm (UTC)
From: (Anonymous)
Nice list of bugs, but none of those look like showstoppers for a non-lts release of Ubuntu.

Re: No showstoppers

Date: 2013-10-02 11:05 pm (UTC)
From: (Anonymous)
"Well, sure, if you're happy to ship shit then quality isn't a problem."


That's the Fedora QA motto, and I'll thank you not to use it without attribution!

Re: No showstoppers

Date: 2013-10-03 06:21 am (UTC)
From: (Anonymous)
Yeah, Ubuntu's done no wrong ever. They've never shipped a piece of software before it was ready... like PulseAudio, "AppIndicators", or Unity...

Re: No showstoppers

Date: 2013-10-03 09:14 am (UTC)
From: (Anonymous)
Yeah. Have you heard of KDE 4.0? Unity is an enterprise-level stability comparing to that (which of course doesn't make Unity's early days better than they were).

Re: No showstoppers

Date: 2013-10-03 02:26 pm (UTC)
From: (Anonymous)
But the exception is that KDE depelovers repeated that KDE 4.0 wasn't ready for production.. but distros began to packagin it and distribute before was ready... Unity was the default in Ubuntu even though they knew it that it wasn't ready

Re: No showstoppers

Date: 2013-10-03 03:25 pm (UTC)
From: (Anonymous)
That is a bit of revisionist history by KDE 4 developers. More importantly. KDE 4.1 and 4.2 weren't exactly quality either and they _were_ sold as the best thing since sliced bread.

Re: No showstoppers

Date: 2013-10-04 09:33 am (UTC)
From: (Anonymous)
That isn't revisionist at all. KDE 4.0 was clearly marked as unstable and not ready for general consumption by the developers before it was released, KDE 4.1 was (in their words) for enthusiasts and people that wanted to take the risk. The first version that was ready for general consumption and given the approval of developers to be considered like that was KDE 4.2 and was fairly stable and complete. In fact, one of the problems of KDE is that it hasn't evolved too much since the KDE 4.2 or 4.3 days.

Re: No showstoppers

Date: 2013-10-03 02:58 pm (UTC)
From: (Anonymous)
Unity enterprise level.... hahahahahahaahah you're a troll.

Re: No showstoppers

Date: 2013-10-03 06:17 pm (UTC)
From: (Anonymous)
How so? Enterprise software is routinely bloated, slow and buggy. Just like Unity.

Re: No showstoppers

Date: 2013-10-02 10:01 pm (UTC)
From: (Anonymous)
If you don't see why leaky input switching is a problem you don't seem to be qualified to comment !

Re: No showstoppers

Date: 2013-10-03 12:18 pm (UTC)
From: (Anonymous)
Thought skuttles himself said if this failed on a users system it would default back to x. So not the case now is it. Lets keep making excuses.

Date: 2013-10-02 10:14 pm (UTC)
From: (Anonymous)

Use Planet Debian Derivatives and stop polluting Planet Debian with butnut crap!

Planet Debian

Date: 2013-10-02 10:29 pm (UTC)
From: (Anonymous)
As one of many people reading Planet Debian, I would very much like for your content to stick around.

Also, anyone who sees this as Ubuntu *publicity* has serious reading comprehension problems.

Planet Debian and other planets don't exist to show only content about the stated topic; they exist to show a view into the world of developers in that community, and by that measure you definitely qualify. (Likewise, this isn't about the kernel, but you're on Kernel Planet, as well you should be.)


Date: 2013-10-02 10:53 pm (UTC)
From: (Anonymous)
Do you think Canonical has the manpower to maintain all of this on their own? I mean, I don't think even Red Hat would undertake this daunting task alone, and Canonical acts as if they'll pull it off with no problems.

Re: Manpower

Date: 2013-10-03 04:34 pm (UTC)
From: (Anonymous)
At some point they can as well reevaluate their assessments and start using Wayland as they planned in the past. Mir gives them no benefits and only requires extra resources to develop. What's the point?

Re: Manpower

Date: 2013-10-03 06:25 pm (UTC)
From: (Anonymous)
Canonical is to arrogant to back down from Mir now. Switching to Wayland would require admitting to being wrong, having to work with upstream, and not being able to own all of the code written purely due to NIH.

Delays? At Canonical?

Date: 2013-10-03 04:41 am (UTC)
From: (Anonymous)
Sticking to a schedule was never one of Canonical's strengths. As they shed employees and move further away from Red Hat's software stack, the schedules will only slip more and more.

Re: Delays? At Canonical?

Date: 2013-10-03 11:52 pm (UTC)
From: (Anonymous)
I hate Ubuntu's decision to create Mir, but I think your comment about schedules is a little unfair. I say 'a little' because Ubuntu have failed to finish projects on time, but you've also got to consider their release schedule for their OS, it's been shipped on time for years and years.

Re: Delays? At Canonical?

Date: 2013-10-05 06:46 pm (UTC)
From: [identity profile] https://www.google.com/accounts/o8/id?id=AItOawnOTxq5kGRTezAmG6N-Uak_HnsPJCo3D3Y
Ubuntu's distro team is a very well-oiled machine. The same isn't true of development projects involving more than one or two people. There's a good reason for that: Distro started with a team of people who already had all the needed skills and had worked together, and retained that culture even as people changed. They produced the first release in six months, so they knew they could do it again and were careful about who they brought on while they built the infrastructure to keep it going. The development side, however, has typically not been staffed with program/project managers but instead by developers promoted into management roles.

It's been a long time since I was at Canonical, so I can't speak to their current makeup, but I'd be very surprised if the schedule given was one vetted by experienced project planners given the complete lack of wiggle room.
From: (Anonymous)
While I guess I agree that there is still a race-condition, which could theoretically someday maybe lead to some sort of exploit, as you point out there is now only a vanishingly small chance that some everyday endusers will accidentally reveal their username and password to IRC or Skype. Although it was a reasonably-serious bug before, that deserved a big red warning on the package, I'm pretty confident that necessity is now well in the past. You point to Xorg as the epitome of secure input handling? And yet, Jamie Zawinski has all my passwords stored away in his underground bunker. http://www.jwz.org/xscreensaver/faq.html#setuid Furthermore, Xorg itself has problems with securing VT sessions -- http://www.jwz.org/xscreensaver/faq.html#no-ctl-alt-bs

Point being, it seems like Mir is at least *level* with the security provided by X, if not ahead. At the risk of sounding like the guy responsible for WinME, security *is* actually relative.

p.s. My other point is short and sweet: getting parts of Mir into 13.10 as the default was never about providing *immediate* user-visible benefits. And although I would agree it was at least partly a publicity stunt, to generate buzz, and get out the gate faster than Wayland, I definitely think that was a secondary or tertiary goal. The number one primary goal was UbuntuPhone deals, which may have been accomplished (we'll know based on whether you can buy one before December 25th). But the big desktop goal was to put the Mir codebase through the gauntlet, of getting real-world beta testing by millions of users on all kinds of nutty hardware. That would make pushing Mir into 14.04 LTS *much* more palatable, even if it was non-default in the LTS flavor. So the big loss for endusers is not that they are missing out on some hypothetical cool feature in 13.10 -- it is that Mir will not be as battle-tested when 14.04 comes around. Long-term benefit was always the key here.
From: (Anonymous)
Its funny that you link to the ancient XScreenSaver FAQ; in current X.org servers, Ctrl-Alt-BackSpace is disabled by default, and must be explicitly enabled. Further, on modern systems, XScreenSaver does not need setuid.

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.
From: (Anonymous)
I am always confused when people discuss security of desktop Linux. If the attacker can send arbitrary requests to X server, we have already lost.
From: (Anonymous)
You are aware that there are multiple trust levels when it comes to X clients, right?
From: (Anonymous)
Would you care to elaborate? Does Ubuntu enable separation of locally run X clients (I hope, we are not speaking about remote X clients as I hope they were disabled long ago).
From: (Anonymous)
The point of bringing up xscreensaver is that, to my understanding, in everything from original X in the 1980s all the way through the Xorg git tree today, the design of X basically necessitates that the screensaver-app checks your password (i.e. when you lock and then unlock your screen). I'm glad ctrl-meta-bkspc security hole is closed, but if you run an Xserver, and you run a screensaver, you have to trust the authors of *both* things with your password. Is this not correct? That was one of the big advantages touted for wayland, after all -- more secure/sane input-handling -- google for wayland screensaver Daniel Stone (of Collabora/Wayland/Xorg).

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.
dreamatdrew: The iconic all-in-one Apple computer icon, frowning and crying. (Sad Mac)
From: [personal profile] dreamatdrew
Malice is not actually required here. Anything which can overload X to the point of (possibly temporary) lockup can cause the same set of problems. In an Xmir environment, you can break out to a VT to try to examine/fix a problem, which could be an actual 'need to bounce X', and you could have sent your login credentials and $deity knows what else to, say, IM, which you would not necessarily know until you checked your logs, assuming you keep IM logs. And with the lag involved between the action and the realization, you can be compromised by an external actor, and have no real way of knowing.

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.
From: (Anonymous)
Perhaps I'm slightly weird, but I find the "fix" far more worrisome than the original bug.

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.
From: (Anonymous)
While I agree that 'solving' malicious exploitation of a security hole by turning a gaping time-window into a millisecond race-condition is bad news... and hope that the fine folks doing the security work on Mir realize it too... what are your feelings on rm rf prophylactics? http://serverfault.com/a/337098 While arguably things like --preserve-root being on by default will in no way increase security, in the hard-nosed sense of Security Versus Malicious Adversaries, I would still say that they are a Good Thing, because they might keep the enduser from accidentally blowing their own foot off.

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.
From: (Anonymous)
rm prophylactics aren't security related - they're "save the admin from a stupid mistake" fixes. However, the key difference is that the failure state when they don't work is to do exactly what the user expects. In the XMir case, I expect that the thing I can see accepting my input is the only thing that's seeing it; XMir's VT switch bug breaks my expectation.

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.
From: (Anonymous)
Your position sounds reasonable to me, overall. I disagree, however, because I don't want a system that is exactly what an old-school person like ourselves expects from rm. Instead, I want the automagical versioned backup filesystem (amvbfs?) in which rm does not actually free any space, does not actually delete any data, but really just adds a new zero-byte version-of-a-file on top of the stack of existing versions-of-that-file. I also want certain system-level utilities (I'm particularly thinking of /sbin/undelete at the moment) that will survive rm rf of the entire drive. Now, as an old-school person, that behavior is *definitely* not like what I would expect, from my previous work with rm, but it *is* pretty close to what I would really want.

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.
From: [identity profile] jmtd.net
Hey, xscreensaver! Xfree86! systems without PAM! C+A+B enabled! Thanks for the blast from the past.

Date: 2013-10-03 01:06 pm (UTC)
From: (Anonymous)
Nice "fedora" tag :P
From: (Anonymous)
I have a more radical sugestion for legacy X support, more due to the experience from the X11 server built from scratch for Android tablets, which was written in Dalvik Java and SurfaceFliger API, and it's driveless, that's mean it don't need any Xorg drivers to work.
The main backwards is the reduced compatibility with window toolkits, and some advanced X engines like Compiz would not be compatible at all.
In real word use, the X emulator for Android was used to the unofficial port of OpenOffice for Android.

Instead to load a full X server in top of other graphic server, with all legacy stuff loaded, why not use the new Mir API directly and write a X11 driveless pseudo-server from stratch to start the X programs ?
That's my fair opinion, and I think is the most stable option to legacy programs.
For more information, I share the project homepage:


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags