Question about the future of Xorg

[Dave Henderson]

On 6/11/25 05:50, Carsten Haitzler wrote:
> On Tue, 10 Jun 2025 11:04:28 -0400 Dave Henderson <daveh at digital-pipe.com> said:
>
>> On 6/9/25 10:52, Carsten Haitzler wrote:
>>> On Mon, 9 Jun 2025 08:48:10 -0500 Vasily <vasil_tik at yahoo.com> said:
>>> My personal opinion is that there are some issues need to be solved before
>>> wayland compositor can substitute X11. So I think X11 will work for us
>>> another 5 -10 years.
>>> oh absolutely. wl needs maturing - a lot. there is much work to do. there
>>> also is no reason you couldn't also take xorg and "strip it down and divide
>>> it up". you could solve a lot of security and boundary issues by e.g.
>>> disabling any xrandr "write" access (modification) to any client by the wm.
>>> first client in wins (wm) and it's in charge. this stops any random client
>>> form messing with screen layout. we could start limiting access to xinput
>>> and xinput devices, limit what events you can listen to on windows that are
>>> not your own (unless you are the wm), and so on - it'd break some
>>> functionality in x - but it'd start solving problems. you could tackle it
>>> from this angle or from "build wayland" angles. either way it'll result in
>>> something breaking and some transition mess etc. etc.
>>>
>>> now my issues with wayland are indeed that it has yet to fully mature. there
>>> have been some not so great decisions that are seemingly heading in the
>>> right direction now. there are other things that are core issues. IMHO
>>> wlroots is a stab at some of that but IMHO there should have been much more
>>> done earlier on here and in ways that are more render-agnostic.
>>>
>> I agree with the "strip it down and divide it up".  X11 does already
>> have some of the "divide it up" using extensions, but this should be
> oh i'd divide extensions too - like xrandr read vs write. ie 99.99% of clients
> never need to modify randr info - ever. it SHOULD be left to the desktop/de/wm
> core tools to decide this and only them. apps should communicate what they
> want on a higher level if there is to be something. allowing apps to read this
> info - sure. but not modify.


I completely agree! Splitting reading and writing into separate 
extensions would be wise (e.g. xrandr and xrandrw).  Again, coming from 
a security standpoint, this would make the most sense and allow for a 
more secure project in the long run.


>
> core protocol - strip out core 2d rendering into its own library. perhaps even
> another process entirely that is message-passed to and just shares dest buffers
> with the server (core rendering here would be rect/line/poly, core text/font,
> xrender etc.).
>
> i'd also possibly strip out cursor handling beyond logical cursor position and
> state. the actual visual rendering could be punted off to the compositor to
> either render it or use an overlay plane (via a new extension feature to
> allow plane access). yes - this model assumes some compositor i guess but you
> can basically have something like xcompmgr, glcompmgr etc.  as a boring
> standard compositor you can use in combo with old school wm's.


Yup!  Strip it down to the bare essentials.  Everything else goes into 
an extension, or is tossed.  Would it be possible to create an extension 
that could preserve existing functionality/API's?  I wouldn't say this 
would be used very much - again only for the handful of people using odd 
software.  It would also obviously suffer from existing issues with X, 
but it may be of value for some users.  I wouldn't have it installed on 
my own system for security reasons.  Well, and I don't run oddball 
software either...


>> applied to the guts.  I've seen numerous people say over the years that
>> X11 still has a lot of legacy aspects to it and I always wondered why
>> all that didn't get pulled from the code base (or again moved into an
>> extension if still "desired").  I understand that some obscure app may
> a lot of the legacy is also features and those were useful at the time but also
> have security/privacy/boundary or abuse problems. the x model assumes everyone
> on your screen plays nice. the world we have though is where more people care
> more about this and want to sandbox apps they don't trust but still use them
> and for this x has lots of issues. to fix this means breaking functionality in
> many places. what you are addressing may range from real security issues to
> "quality of life" ones that would disallow abuse of some feature other than a
> single trusted client etc.
>
> i agree with you - that such breakage might only affect some small things
> and thus is desirable to do in return for the improvements.


Obviously the original X was designed when software was overwhelmingly 
used by techs and devs.  The world is now full of malicious people that 
would sell your soul for $0.02.  As such, security needs to be much more 
part of the design goals of software, especially with everything going 
into a digital realm. With that change, having any aspect of compromised 
security could cause major headaches (screen grabs of your crypto keys, 
passwords, or malicious access to your camera/mic comes to mind...).

And yes, I'd like to sandbox everything I could as a preventative 
measure.  Again, with some of the dialog above, splitting 
reading/writing access is very good too.  This is also why I'd try to 
work towards getting X out of having to be used as root.


>> no longer work, but that would be a fraction of a percent of users.  The
>> benefit to the community would be greater than the encountered headache
>> for that small subset of users (which could just continue using the last
>> working version of X11 with their app(s)).
> thus my point in another mail - if a fork of x happens it'd need to do more
> than just "keep working. it'd been some tender love and care in this domain
> too. partly cleaning up internal code and api's in xorg. partly addressing all
> the issues with x11 protocol and how it can be abused either for
> privacy/security or just for "anti-sociable" reasons by bad clients.


*nods is agreement*


>> In addition to the stripping of outdated/unnecessary code, it would
>> reduce the size of the X system and reduce malicious attack vectors to
>> gain access to a device.  Honestly, I'd try to either make X work
> correct. if all the core rendering beyond just "asssign buffer to fb/hw plane"
> was even punted off to another render process that the xorg core spawned and
> talked to (and this process would become sandboxed with some seccomp efforts
> etc.) this would also limit the attack surface there too


Totally agree!


>> without running as root, or make the "core" part of X as small as
>> possible to address this issue.  As a by-product of stripping out this
>> code, it should speed up the system, even if marginally...
> yeah - and divide some things into sub processes too to sandbox them i guess.
>
>> This is just a list of things provided so far in this thread that could
>> be reworked, removed, or moved to an extension:
>>
>>     (Lyude Paul <lyude at redhat.com>)
>>
>> - heavy round trips in its protocol
>>
>> - the fact that most modern compositing on X is just extension on
>> extension on top of the actual X11 server which no longer does half of
>> the things it's supposed to handle
>>
>> - ability to draw its own widgets
>>
>> - has font rendering
>>
>> - has a  HAL for video drivers and input drivers
>>
>>     (Carsten Haitzler <raster at rasterman.com>)
>>
>> - isolate all the core 2d rendering in xorg into a "legacy" module to
>> keep it "out of sight"
>>
>> - most of the rest of x's problems are the protocol and what is assumed
>> to be allowed by clients or not (like being able to send fake input to
>> any app or read input events on any window anywhere - even not your own
>> etc.)
>>
>> - rendering model can evolve too with a wayland-like explicit buffer
>> "send" model to the compositor in x
>>
>> - some issues like latency will always be an issue as long as you have
>> to bounce messages through many processes
>>
>> - you could solve a lot of security and boundary issues by e.g.
>> disabling any xrandr "write" access (modification) to any client by the wm
>>
>> - limiting access to xinput and xinput devices
>>
>> - limit what events you can listen to on windows that are not your own
>> (unless you are the wm)
> i could probably go on for days tbh and keep listing things. :)

lol baby steps at first my friend...