I'd hate to break it to people here but Wayland has potential security problems that eclipse X due to the reliance on direct rendering in applications, and the lack of indirect (network transparent) stream based protocol like X has with with core protocol and GLX. Direct rendering maps video RAM and video hardware interfaces into the applications. This is basically asking for trouble should there be a security problem in the video hardware.
So your giving a much larger body of more questionable application code direct contact with video hardware, whereas the X server traditionally only touched video hardware. With X being a userspace process, it would have been possible to constrain X with a security profile using something like apparmor, with fine grained security controls that give it access just to the hardware resources it needs.
All large C programs have security problems. The problem is C, not X, and speed-fanatics who think that everything needs to be written in dangerous C code for that little bit extra speed. Wayland also is written in C, do not assume it does not have the same problems. Wayland and X.org were written by the same people.
Also, Wayland does reinvent the wheel. There is no point in it. Performance profiling has shown virtually no speed improvement of Wayland over X. Everything Wayland was sold on can be done with double buffering and verticial synchronization extensions to X and by the already underway work to port X.org to an OpenGL/DRI/EGL backend itself. This would fix visual artifacts.
As for legacy features in X, the sensible thing for that would be to have a runtime flag to disable those features and break out legacy support code into runtime loaded libraries for this purpose. Thus if you dont use an app that needs the legacy feature, you dont have to load the code that it uses. These legacy features are not great in number, usually some 2D graphics primatives and some older font APIs.
Its important to note that the problem with the older graphics primatives was they were not powerful enough, most apps now need a rich set of 3D graphics operation. The traditional X protocol provides far, far too few primatives, OpenGL apps need a much richer set of primatives. Wayland apps do use a vast number of OpenGL primatives, which have to make it to the video adapter, it doesnt provide the option of isolating apps from the video hardware however, due to the lack of an indirect protocol.
The rest of the X.org code base can be fuzz tested and scanned with security tools to spot possible problems.
So, one by one, all of the arguments for Wayland can be debunked.
So your giving a much larger body of more questionable application code direct contact with video hardware, whereas the X server traditionally only touched video hardware. With X being a userspace process, it would have been possible to constrain X with a security profile using something like apparmor, with fine grained security controls that give it access just to the hardware resources it needs.
All large C programs have security problems. The problem is C, not X, and speed-fanatics who think that everything needs to be written in dangerous C code for that little bit extra speed. Wayland also is written in C, do not assume it does not have the same problems. Wayland and X.org were written by the same people.
Also, Wayland does reinvent the wheel. There is no point in it. Performance profiling has shown virtually no speed improvement of Wayland over X. Everything Wayland was sold on can be done with double buffering and verticial synchronization extensions to X and by the already underway work to port X.org to an OpenGL/DRI/EGL backend itself. This would fix visual artifacts.
As for legacy features in X, the sensible thing for that would be to have a runtime flag to disable those features and break out legacy support code into runtime loaded libraries for this purpose. Thus if you dont use an app that needs the legacy feature, you dont have to load the code that it uses. These legacy features are not great in number, usually some 2D graphics primatives and some older font APIs.
Its important to note that the problem with the older graphics primatives was they were not powerful enough, most apps now need a rich set of 3D graphics operation. The traditional X protocol provides far, far too few primatives, OpenGL apps need a much richer set of primatives. Wayland apps do use a vast number of OpenGL primatives, which have to make it to the video adapter, it doesnt provide the option of isolating apps from the video hardware however, due to the lack of an indirect protocol.
The rest of the X.org code base can be fuzz tested and scanned with security tools to spot possible problems.
So, one by one, all of the arguments for Wayland can be debunked.
Comment