> What I would really like to see, please, is pointers to the criteria used in
> the decision making for switching to Wayland-for-default.
I cannot give you those criteria. I don't think there was any sort of
formal document listing requirements that had to be met, any more than
there was for stretch (where we reluctantly decided that Wayland mode
had too many issues at that stage, and shipped a version of GNOME for
which the upstream default was Wayland mode, but patched it to have
X11 as default and Wayland as an option for the adventurous). Laurent
Bigonville said on IRC that he was the one who reverted our patch that
switched the default to X11 mode, in 2017, so perhaps he can clarify
the factors that went into this decision.
(Or if you mean the criteria used by GNOME upstream, I suggest asking
them.)
The status quo of GNOME is that the default *is* Wayland, and if we want
the default in Debian to be X11 instead, we have to patch something (as
we did in stretch). I firmly believe that distributions sometimes need
to diverge from their upstreams, but that any such divergence needs to
have a justification, so I could turn this around: what are the criteria
that you believe should be used in the decision making for switching to
X11-for-default? (I'm not sure which component would need to change if
we wanted to go back to the stretch situation: most likely gnome-session,
or perhpas gdm3.)
My understanding (again, I am not an expert and I don't have an infallible
overview) is that the advantages and disadvantages of Wayland mode by
default go something like this. You'll notice that many things turn up
in both lists, because they're an advantage or a disadvantage or both,
depending how you look at them.
Advantages of Wayland mode over X11 mode
----------------------------------------
The Wayland protocol is suitable for privilege separation: ordinary
apps cannot be keyloggers, or forge input events, or copy each others'
window contents. With X11, if a sandboxed app (Flatpak, Snap, etc.)
can draw its own windows, then it can spy on other apps or send input
to them. Deliberately using a protocol that doesn't have useful privilege
separation doesn't necessarily send a great message about the importance
we put on privacy/security.
- Rebuttal: some X11 apps want to do those things for non-malicious
reasons; see below. In principle sandboxing frameworks could filter
X11 access with something like Xpra, although I am not aware of a
concrete implementation.
If the Wayland compositor (GNOME Shell) crashes, that can't result
in a lock-screen bypass, because the compositor is the display-server
equivalent: if there is a crash bug that is triggerable by an attacker on
a locked session, it is denial of service (end of session), which, while
undesirable, is less bad than the privilege escalation (ability to see
or manipulate unintended windows) that would often be seen when an X11
compositor/WM crashes.
- Rebuttal: denial of service is also bad, and crashes can occur for
reasons other than malice.
There might be performance advantages for native Wayland apps such as
GTK3 apps, from being able to use a more direct rendering path that
is a better match for how the hardware works.
- Rebuttal: many apps aren't native Wayland apps and won't benefit
from this. Wayland is relatively new, so perhaps these performance
advantages are only theoretical at this stage.
Wayland mode has been GNOME's upstream default for several years, so
it's what upstream will be expecting, and is the most likely to get
useful feedback on bug reports.
Full-screen apps (games) can't arbitrarily change your screen resolution,
then crash without changing it back.
- Rebuttal: they also can't change your screen resolution even if you
want them to.
There are some X11-specific bugs.
- Rebuttal: there are also some Wayland-specific bugs.
Advantages of X11 mode over Wayland mode
----------------------------------------
Some X11 apps want to do things that Wayland doesn't normally allow:
capture global keyboard shortcuts (which involves doing the same thing
a keylogger would do), or create input events (which involves doing the
same thing you'd do if maliciously forging input events), or take
screenshots or capture video (e.g. for screencasting or screen-sharing)
via X11 (which involves doing the same things you'd do if you were
maliciously spying on other apps).
- Rebuttal: it's good when apps do these things with the user's knowledge
and permission, but very bad when they do them maliciously (see above),
and the display protocol is not in an a position to judge intent. In
Wayland mode, many of these things can be done via D-Bus by a
sufficiently-privileged app, and any useful app-sandboxing framework
already needs to filter access to the D-Bus session bus anyway;
however, this does require code changes in the privileged app.
If the X11 compositing manager/window manager (GNOME Shell) crashes, the
X server and the X session in general continue to run, and the session
manager (GNOME Shell) has the opportunity to restart the compositing
manager/window manager.
- Rebuttal: While the Shell is restarting, apps become visible even if
they should not have been, which can be a security problem if an
attacker can trigger a crash in the lock screen (see above).
Some of the protocols used by X11 apps are not emulated well by the
combination of Xwayland and GNOME Shell: in particular I've seen reports
of intermittent issues with drag-and-drop between native Wayland apps
and X11 apps. PRIMARY selection (middle-click paste) and pointer barriers
("mouse capture" typically used by games) were also problematic in older
versions, and if I remember correctly they were the major blockers for
Wayland-by-default in stretch, but I think those were fixed shortly
after stretch.
X11 typically allows root processes to draw windows on other users'
displays. Applications that don't have privilege separation, such as
synaptic, rely on this. Wayland restricts the display to be used by
a matching uid only, and Xwayland is typically configured to do the same.
- Rebuttal: Applications that do this are running a full graphical
toolkit as the most privileged user, so bugs (or privilege escalation
opportunities, if the owner of the display is not already totally
trusted) can be disastrous. Graphical toolkits typically (have to)
trust their display server completely, so it is very likely that
applications that do this can be subverted by the owner of the display
or by their other apps, and any privilege separation that might appear
to result from the use of su/sudo/pkexec is likely to be breakable.
There might be performance advantages for X11 apps in being able to go
app -> Xorg -> hardware, instead of app -> Xwayland -> GNOME Shell ->
hardware.
- Rebuttal: X11 compositing is sufficiently complicated that I could
well believe that these performance advantages might be small or
nonexistent (in particular, GNOME Shell ends up compositing the app's
window into its scene graph either way).
Some apps (such as historical versions of gVim and pasystray) use a
toolkit like GTK that is capable of using both X11 and Wayland, but
have the bug that they blindly assume that every display is an X11
display. These apps will crash or otherwise misbehave on Wayland, unless
they are patched to force use of GTK's X11 backend (as gVim and
pasystray were).
- Rebuttal: these apps were always making unwarranted assumptions,
which would be equally untrue for e.g. Mir, and the solution is one
line of code.
X11 has built-in network forwarding.
- Rebuttal: it works decreasingly well as apps' rendering moves from
the X11 server to the client. X was designed to work the way apps
worked in the 80s (requesting high-level drawing operations that made
sense to a 1980s GUI designer within the constraints of contemporary
hardware, like "draw a stippled rectangle"); Wayland is designed to
work the way graphical toolkits, games, etc. work in practice now (have
a drawable/surface/texture representing the window, and draw on it).
There are some Wayland-specific bugs.
- Rebuttal: there are also some X11-specific bugs.
---
Regards,
smcv
