Comment on Wayland anti-FUD

[Pekka Paalanen]

On Fri, 11 May 2012 14:40:49 +0000
datenwolf <noreply-comment at blogger.com> wrote:

> datenwolf (http://datenwolf.myid.net/) has left a new comment on
> your post "Wayland anti-FUD":

Hello!

(This comment was private and quite long, so I thought it would be
better to reply on the mailing list.)

> Stacking compositors is a bad idea. Not for performance reasons,
> but because it possibly opens a side channel to leak other user's
> data (it already happens today occasionally with X on different
> VTs if the GPU memory is not properly cleared right before the VT
> change, BTDT). A system compositor keeps around handles to all
> connected user compositors and can be attacked into revaling the
> buffer contexts of those handles.

Yeah, that is a plausible security hole, and does exist at least
for some drivers if not all. I have never heard of any component
clearing graphics memory on VT switch, unless you refer to X
drivers which do it only to avoid showing garbage temporarily.
That is just papering over the problem of handing out uninitialised
memory, which really should be solved in the kernel drivers, just
like it is done for all system memory. Unfortunately, I think
performance and simply getting things to run in the first place
have been higher priority, also considering that is it very
easy to DoS a system by simply running bad gfx apps.

Also, many GPUs don't even have proper memory protection, so
it is possible to send GPU commands for reading arbitrary
graphics memory. The only way that could be prevented is
checking all GPU command streams in the kernel before execution.
Checking can be prohibitively slow and complex.

These are not problems of Wayland or X, they are problems of the
kernel DRM drivers. (I'm ignoring UMS drivers, since they simply
cannot be fixed.)

If we look at Wayland only, it offers no way for clients to spy
on each other. Gfx buffers are shared only with the server,
which will not give them out to clients again. For a client to
steal another client's or server's buffer is at least as hard as
stealing an open file descriptor from another process.

The situation with X you probably know to be horrible.

Btw. actually keeping open handles to graphics buffers will
*prevent* the uninitialised buffer data leaks. If a
handle to a buffer is open, that memory will not be given
out to others, since it is in use.

I don't know what kind of an attack vector you are thinking of.

> Also the way Wayland addresses network transparency I can call
> only ridiculous: Transferring images/video. You say there's no
> overhead? What about compression? You will not transmit raw image
> data. Ideally you apply some x264 or similar with lowlatency
> lossless profile on it. But that eats CPU time. Only because
> current toolkits render all their stuff on the CPU and then blit
> it, doesn't make this a desireable approach. Qt raster... WTF?

Yes, transferring images, any way you see fit. We could start with
something stupid like gzipped raw data for the first experiment,
then move on to jpeg or video codecs or whatever. I never said
going over network would not add overhead. I explicitly wrote that
readers should not mix up those two things in my post.

You have to transfer something, and in Wayland protocol it is
images. The easiest network transport will do the same. Nothing
prevents creating a different transport layer that carries
rendering commands, but that would require adaptation from
all clients that are going to use it.

> Also I think OpenGL is not the right API for rendering GUIs (and
> I really know OpenGL). Yes, Blender does it, as do some other
> programs. But rendering text for example is a huge PITA. The
> XRender extension provides a way to transfer vector glyphs to the
> graphics server and in theory it was possible to have the GPU
> render them in high quality.

Wayland is not specifically forcing OpenGL, any EGL-supported rendering
API will do. And EGL only because it is sort of standard and
available, and a good way forward. Also, nothing else than perhaps
lack of adoption prevents implementing non-EGL ways of passing
hardware accelerated graphics buffers from a client to a server.
Just add another Wayland protocol extension in the standard way,
plus the required OS infrastructure to be able to use it.

Sorry, I thought XRender was all about pixmaps, not vectors at all?
I mean, a library, perhaps client-side, renders a glyph cache
and sends it to the server. When you draw text, you pick rects
from that A8 pixmap to paint pre-rasterised glyphs. No?
You can use the same font rendering libraries with Wayland.

Btw. a shared glyph cache is something that has come up with
Wayland, but we have so far nothing about it in Weston.

> Another thing that Wayland's current design completely neglects
> is disjunct subpixel arrangements and colour profiles in
> multihead environments. Wayland puts all the burden on the
> clients to get it wrong. Effectively this means code duplication
> and that application/toolkit developers have to worry about
> things, they should not. Those are things the graphics system
> should hide from them. Wayland doesn't.

No, we have a plan for color management, and there are some
people looking into it, I think for Gnome unless I'm mistaken.
I did a proposal they seemed to accept as a starting point:
http://people.collabora.com/~pq/wayland-color-management-proposal.png

I talked with krh and we agreed that this does not require
changes to the core protocol, so we can very well add it later
as an extension.

As for subpixel, we have a way to advertise it:
http://cgit.freedesktop.org/wayland/wayland/tree/protocol/wayland.xml#n871
and we also plan to keep clients aware of which outputs they
occupy.

Yes, the burden is on clients, because Wayland is not a
rendering protocol. If Wayland was a rendering protocol,
it would not be a feasible project.

In our modern world, we have the luxury of shared libraries. We
can off-load lots of code into reusable libraries when we see fit.
When X was born, no such things existed, which I hear is a reason
for several awkward design choices.

> Another drawback of Wayland is, that the compositor is also
> responsible for reading and dispatching input events. If there's
> a new class of input device _all_ compositors must be adjusted.
> You could of course invent some kind of generic compositor into
> which one can load modules. And you could add an abstracted color
> management and drawing module into it, keeping track of
> properties of the single displays in a multihead setup. But this
> would just duplicate everything X does.

Yes, Wayland duplicates or reimplements the useful things X does.
The point is, Wayland changes everything else. Isn't that a good
thing?

You are right about input plugins, but there are couple things
that should make it not so bad:
- a majority of input devices are evdev, so we mostly need only
an evdev plugin
- not all compositors need to talk to input devices directly,
others are just Wayland clients to another compositor.

After all, drivers are supposed to exist in the kernel, offering
an abstracted common API (which btw. is practically impossible
for 3D graphics hardware, hence we need EGL/GL and friends).

> And last but not least: Desktop composition as it is used today
> sucks. It's a huge productivity killer. Without any effects I can
> quickly switch between desktops in well under 20ms and see if a
> compile run finished in my console. With desktop effects I've to
> wait for the effect to finish. There are usefull applications for
> composition (I'm experimenting with it myself), but so far it's
> just distracting eyecandy.

That is an argument against effects, not compositing. And
personally I agree. :-)

If you have compositing but no transition effects, switching a
desktop will be *faster* than if you did not have compositing,
because when drawing a new desktop view:
- the clients have already earlier rendered their windows, and
- the server does not need to communicate with any client to
draw the desktop

Wayland is not going to force bling-bling on anyone. It forces
only compositing, whose only downside is that it takes more
memory than strictly on-demand damage-based client-by-client
drawing.

I do hope that all *implementations* of a Wayland compositor
will allow to disable their effects.


Thanks,
pq