Trend Micro Uncovers Yet Another X.Org Server Vulnerability: CVE-2023-1393

[mSparks]

X11 for IO is not X11 network transparency. This is a different argument..

X11 because the machines the applications are running on do not have a keyboard/mouse/screen attached and VNC would be even more stupid than using wayland for gaming.

The whole point of X11 is
220px-X_client_server_example.svg.png
The only point of wayland is to prevent network streaming, but all that micromanaging every key click, mouse movement and frame change comes at such a performance cost it seems unlikely to me it will ever see widespread adoption, especially when X11 is feature complete and the only thing left to fix are CVEs as they are found by the likes of trend micro while building someone yet another HPC platform based on X11/Xorg.

[oiaohm]

X11 because the machines the applications are running on do not have a screen attached and VNC would be even more stupid than using wayland for gaming.

Except the use case you described is why xpra exists.

https://archive.fosdem.org/2020/schedule/event/interactive_hpc/attachments/slides/4093/export/events/attachments/interactive_hpc/slides/4093/FOSDEM20_Interactive_applications_on_HPC_systems_notes.pdf

Need to understand this.

https://docs.galaxyproject.org/en/master/admin/special_topics/interactivetools.html

Out of the 5 options there listed for interactive HPC only 1 support X11 applications directly. Like galaxy the last one is vnc or nothing no remote X11 support at all.

A machine without screen attached is what the different HPC job management software is for.

The whole point of X11 is
220px-X_client_server_example.svg.png
The only point of wayland is to prevent network streaming, but all that micromanaging every key click, mouse movement and frame change comes at such a performance cost it seems unlikely to me it will ever see widespread adoption, especially when X11 is feature complete and the only thing left to fix are CVEs as they are found by the likes of trend micro while building someone yet another HPC platform based on X11/Xorg.

Feature complete that diagram what happens to the network connect Xclient(xterm) if a few packets are lost. The xterm network connected terminates and everything you were doing on it is now lost. The x11 protocol networking streaming is not reliable this is why xpra exists.

The reality is new HPC systems are being built without X11 all the time in fact it the normal to have no X11 support. Remember how you said you had never seen HPC with html5 this is very much coming the normal.

X11 protocol mandates more micro management that what Wayland does.

mSparks I could say a T55 tank is feature complete. Feature complete again does not equal fit of purpose. X11 protocol network streaming is not fit for purpose for HPC usage this why xpra is funded to exist.

The IO cost of sending X11 protocol over network is massive this has been heavily studied and documented by the virtualgl developer and confirmed by the xpra developer. There is a problem virtualgl development documented as network latency increases X11 application that would normally start instantly can take min to hours to start. Remember HPC you time is allocated you cannot be wasting time. X11 protocol lack X11 forwarding is horrible flawed with many faults.

Wayland dropped network streaming because it does not make sense. Xpra like running local compositor that knows how to send over network. What is going wrong causing application With X11 forwarding to stall out its need to send message over network get response back over network before application can proceed forwards. So network latency spikes X11 forwarding is in trouble. HPC think job finish lots of data now need to move back though network to storage network is now full of traffic network latency now spikes massively.

Xpra latency spikes Xpra is a local compositor/server it can let the application proceed forwards. Yes a local vnc x!1 server makes more sense in HPC than doing X11 protocol forwarding same reason. Network latency spikes application on HPC node can proceed forwards yes the user cannot see what is exactly going on in the spike but they are not wasting there allocated HPC time being stalled by using Xpra, vnc or html5 solutions. You use X11 protocol network streaming you could be using all your HPC allocated processing time doing nothing bar being stuck in stalled caused by the X11 protocol design..

mSparks Like it or not the HPC use case does not work with X11 protocol networking streaming because it design is stall happy garbage and does not tolerate disruptions. HPC has network traffic spikes with matching network latency problems caused by them.

HPC is another name for massive traffic overload network. There is no HPC setup that has the perfect amount of network transport it always way short at times.

mSparks yes lot of education places have X11 forwarding in the entry documentation on HPC mostly so new people use it and get burnt badly while at collage before going out in the workforce and causing major problems.

Yes the X11 diagram you put up presumes X11 is operating in a ideal network with no network disruption or latency issues caused by traffic. HPC is not ideal world this is why X11 protocol network streaming is not suitable it not designed for the HPC problem space.

[mSparks]

X11 protocol mandates more micro management that what Wayland does.

Theoretically I would agree.
Practically it seems not to be the case:

mSparks Like it or not the HPC use case does not work with X11 protocol networking streaming

Then why is Trend Micro investing in X11 instead of Wayland? - you know, the topic of the thread?

Wayland dropped network streaming because it does not make sense

For their use case, "secure" video streaming (ROFL).

I could say a T55 tank is feature complete.

And that's why they are used so widely. :shrug:

is what the different HPC job management software is for.

And that job management software is an X11 client.... so....

[oiaohm]

Theoretically I would agree.
Practically it seems not to be the case:

The problem with benchmarks there are other benchmarks the other way. Any major problem you expect a few issues here and there.

Then why is Trend Micro investing in X11 instead of Wayland? - you know, the topic of the thread?

if you had read my response to weasel about this. The party that fixed the fault that Trend Micro found was the Xwayland developers. Who did Trend Mirco contact first. Xwayland developers. X.org Server and XWayland have a common code base. Guess what part of the x.org code base Trend Micro was scanning Xwayland part not the bare metal.

Basically you have just jumped to completely the wrong result it paid to check who did the fix. Different team should have done the fix if X11 x.org server bare metal had been contacted first.

Trend Micro was scanning Wayland related stuff. This is a problem here just because big parties are still reporting CVE against the x.org server code base does not mean they are scanning the bare metal parts.

And that's why they are used so widely. :shrug:

Every army bar russia is slowly getting rid of all their T55 because they are no longer fit for purpose in real battles. X11 protocol fairly much in the location of the T55 tank it still around but its been removed all over the place because its not fit for purpose.

This is catch again still widely used does not equal fit for purpose and that its not in the process of being completely removed.

And that job management software is an X11 client.... so....

https://archive.fosdem.org/2020/schedule/event/interactive_hpc/attachments/slides/4093/export/events/attachments/interactive_hpc/slides/4093/FOSDEM20_Interactive_applications_on_HPC_systems_notes.pdf

There are 5 HPC job management software solutions in that pdf and they are all html5. SLURM in the xpra setup description is html5 and is the HPC job management system. You don't find HPC job management software as X11 only any more not even as open source projects. Majority are html5.

You get some with graphical clients like opencue but those are coded that they don't care if you are running wayland or X11.

Lets say you have to operate old HPC with a old X11 client job management you will end up using xpra because you cannot afford to be crashing the job allocation program half way though allocations. X11 protocol network streaming is not safe to use with X11 based HPC job management its how xpra got into HPC so much. Having a X11 protocol network streaming issue stuffing up the complete X11 HPC job que result in the complete cluster processing nothing is a very expensive outcome.

Reliability is very important to HPC.

[mSparks]

The problem with benchmarks there are other benchmarks the other way.

Not that Ive seen, especially recently as performance has degraded.
There are a few benchmarks that have it almost as good.

Not seen any benchmarks ever that show it meaningfully better, certainly nothing to justify saying X11 underperforms compared to wayland in any meaningful way.

Trend Micro was scanning Wayland related stuff

given your earlier misunderstandings I can see why you would think that, but the only way this CVE is related to wayland is that wayland now shares a lot of code in common with xorg as they have shoehorned X11 features into it, if they carry on at the current rate wayland will be just another X11 server, just not as good or widely adopted.

[oiaohm]

Not that Ive seen, especially recently as performance has degraded.
There are a few benchmarks that have it almost as good.

Not seen any benchmarks ever that show it meaningfully better, certainly nothing to justify saying X11 underperforms compared to wayland in any meaningful way..

https://linuxcool.net/en/reviews/laptops-last-longer-with-wayland-than-with-xorg/

There is a very meaningful benchmark. Power consume. Steamdeck is going to remain Wayland not for the crap you think but because power usage is way worse with baremetal X11. That power-saving in there even when Wayland is faster so it not a lower performance thing causing this problem.

This is a big problem for HPC. Yes Xwayland with xpra vs X.org server with xpra the Xwayland is also less power usage.

Xwayland X11 protocol subset removes lot of horrible X11 protocol bare-metal stuff that results in higher CPU usage .

Remember you said IO. If your task is CPU bound not GPU bound Wayland wins over x.org baremetal. Now xpra XWayland vs xpra with virtualgl(again xpra is a sub set of X11 protocol) xpra with virtual wins in the CPU bound.

Raw X11 protocol forwarding is the worse in CPU usage/power usage than every other option. No means to bundle up and compress the X11 traffic comes with a huge cost in CPU usage so this is not only poor in the reliability department its poor in the CPU usage/power usage department .

Yes the order of choice in HPC for X11 application is
1)xpra
2)xpra with virtualgl
3) xpra with weston(this is power lighter than kde and gnome) and Xwayland
4) xpra with X11 x.org server.
Yes each step here is increasing power/cpu usage resulting in increasing heat production that can in fact lower HPC performance.

Yes interesting one that single machine benchmark that can show something running under X11 is slightly faster than something running under Xwayland can be totally reversed once its in HPC massive processing. Power-usage vs performance is a very important metric.

Yes HPC investing money to fix up the Xwayland problem why particular application does not work well is worth their time.

X11 x.org server baremetal need to go on a major diet of it CPU usage.

Maybe X11 x.org server on baremetal could claw back some of this power difference by getting rid of X11 forwarding. Getting rid of the network items out of xlib and xcb would be helpful to hpc users its not that using this code/feature does them any good.

given your earlier misunderstandings I can see why you would think that, but the only way this CVE is related to wayland is that wayland now shares a lot of code in common with xorg as they have shoehorned X11 features into it, if they carry on at the current rate wayland will be just another X11 server, just not as good or widely adopted.

When weasel asked who did the patching I went looking. The answer in this case is that this was Xwayland. So this CVE does not show any major party working on bare metal X11. This is not a miss understanding. XWayland and X.org server baremental have different maintainers. Sigend off and committed by the Xwayland maintainer is in the git logs of x.org server. If it a CVE reported to both the X.org server baremetal maitnainer than the Xwayland mantainer this happened last year in fact then it signed by both. If it reported to the x.org server baremetal maintainer and not the Xwayland maintainer then it signed of only by the x.org server baremetal maintainer.

The party who signs of the patch fixing the CVE shows what team the CVE was reported to. Trend did not report to the X11 bare mental maintainer. Git commit logs tell some very important stories.

Steamdeck is using Wayland because of it powerusage more than anything else.

HPC uses in order of power effectiveness based on cpu usage(take task that not using GPU or not using lots of GPU).
1) direct to GPU/job controlled
2) html5, (yes embedding html5 server in your application we are being horrible insecure here no encryption)
3) xpra
4) xpra with virtual gl
5) xpra with weston and xwayland
6/7) Vnc xpra with x.org baremental server
X11 protocol forwarding is not just not reliable its your worse in power effectiveness. Yes seams counter to logic you run less processes yet you manage to consume more CPU time resulting in more power consumed that is exactly what X11 protocol forwarding manages to pull off. This is impressively defective where X11 protocol forward/network transparency manages to fail all metric of good.. Yet due to it being the first people have kept on attempt to use it and getting burnt at some point you have be like users of the T55 tank accept T55/X11 protocol forward no longer fit and stop using T55/X11 protocol forwarding.

Laptop users power-usage is also important. Business users power usage is important a few watts saves over 20 machines does add up quickly. Basically you have been overlooking very important metric. Being a power effective option will get funding.

[mSparks]

https://linuxcool.net/en/reviews/laptops-last-longer-with-wayland-than-with-xorg/

There is a very meaningful benchmark. Power consume. Steamdeck is going to remain Wayland not for the crap you think but because power usage is way worse with baremetal X11. That power-saving in there even when Wayland is faster so it not a lower performance thing causing this problem.

If you really want to count no statistical difference in power consumption (at least they put the error bars on there) as meaningful you could probably convince a few people to try it before they switch back after seeing no difference in battery life for reduced performance.

although if mobile is your thing, get yourself an m2 mac, absolutely nothing comes close. and it uses X11, so all your existing stuff will still work.

[oiaohm]

If you really want to count no statistical difference in power consumption (at least they put the error bars on there) as meaningful you could probably convince a few people to try it before they switch back after seeing no difference in battery life for reduced performance.

3 watts out of 30 watts of usage is 10 percent. 10% more battery life/less cpu powerusage turns out to be very noticeable and that 10%+ is there even in cases where the Wayland performance is equal to the X11 performance.

Apple will not sell valve their CPUs for the steamdeck, HPC.... mSparks valve developers choose Wayland for the steamdeck for the power usage reason not for security.

There are CPU processing areas that the m2 is weak and limited battery size options.

I like how its now no statistical difference that is what you could claim about the performance differences between X11 and Wayland in most cases.

Please note X11 protocol forwarding is absolutely not small when it stuff you over you are talking 90% extra cpu usage doing nothing useful. So the X11 protocol forwarding/network transparency being a power hog is not statistical difference. Its just something that is horrible bad. HPC users are using xpra for very good reasons. You want to have a bad time on HPC use X11 protocol forwarding.

[mSparks]

3 watts out of 30 watts of usage is 10 percent.

3 watts is more than the total average powerdraw of an M2 macbook air in normal use..... giving you 18 hours of battery life instead of 2.

10% of 2 hours is 12 minutes.....

Welcome to the real meaning of statistically insignificant.

[oiaohm]

3 watts is more than the total average powerdraw of an M2 macbook air in normal use..... giving you 18 hours of battery life instead of 2.

10% of 2 hours is 12 minutes.....

Note that 30 watts with 3 watts saving was the normal power draw of the test system. So on a M2 macbook if they can get x11 bare metal and Wayland to work decently you will be looking at a 0.3 watt power saving or more going Wayland. So 1.8 hours of extra battery life.

Yes the steam-deck(2h-8h) battery)is makes 12-48 mins difference if you go by the 10% this also make the system run cooler so less heat to deal with. Then when you think about the average time for players get between save points in many games that 12-48 mins is kind of important.

This 10%+ difference turns up with raspberry pi and other arm systems. x86-64 and powerpc from all the benchmarking so far.

10% is a simple number to do maths with. benchmarks give you horribles numbers like 12.46% or outliers are like 24%. Remember I rounded up to 30 that was not the wattage the site I got the 3watt system in fact used. So the gain saving is higher that 10%.

X11 bare mental vs Wayland using Xwayland you are expecting at least a 10% power-saving sometimes a lot more. This is not the power-saving when you put a native wayland application against X11 application yes this is greater saving. This is going to be interesting to see what happens on steamdeck when proton/wine gets a fully working native wayland backend.

You know that old X11 diagram you dug up. The network connection in that diagram is the old X11 protocol TCP connection. X11 servers most distributions have listen to TCP turned off. When you ssh X11 forwarding this is not using X11 protocol network forwarding. ssh forwards the local X11 socket across the network and was a coping across the XAuthority file so effectively bypassing all the network protection features of xhost..

ssh X11 forwarding and "X11 protocol network forwarding" is not the same thing either. ssh X11 forwarding does not improve the stability .

xlib and xcb both have code to directly talk X11 protocol straight over TCP. Just bad of an idea for the "X11 protocol network transparency" that is in the "X11 protocol".
1) x11 tcp protocol has no concept of encryption.
2) has nothing to prevent man in middle attacks.
3) with applications at times static linking in xlib/xcb altering the over-wire protocol to fix up issues with stability over network and the like comes next to impossible. Yes bundling the traffic though a single connection when you have multi applications on the same computer to get to a single X11 server is not possible either because each application is doing it connection individually..
X11 protocol straight over TCP is basically saying you will use telnet instead of ssh for computer administration.
4) of course you have all the issues with X11 Protocol mandating state be stored in the X11 server and that applications are to die of that state is lost.

Yes "X11 protocol forwarding" is also saying using this TCP interface if you are basing what you are writing based on the standard..

From my point of view the complete stack of TCP functionality include the xhost network bits should disappear out the x11 servers. If anyone still need make some proxy applications at least then people who are not using this totally broken part of the X11 protocol have the option of not having it installed. Yes this would apply to Xwayland as well.

ssh is a little better on the security side of course but you still have point 4. Yes ssh helps on reducing the number of network connections.

xpra this get good.
1)xpra can implement any workaround required for network travel without needing to alter the application because it just appears to be a local X11 server.
2) xpra is keeping a copy of the application state. xpra in fact breaches X11 protocol defined behavior here.

waypipe is kind of the same thing as xpra early for Wayland but still very immature people have found advantages putting compositors on top of waypipe to that applications don't have to wait for responses back over the network. Yes feature of xpra waypipe does not have yet is the means to respond instantly early xpra did not have the latency mitigation features.

KDE developer working on the means to restart wayland compositor and applications keep on running. Now Wayland applications after these modification are able to take care of their own individual state storage something x11 applications do not do natively.
Yes interesting right just hold a socket open and you can kill the wayland compositor out right and the wayland application does not die and just keeps on running.


Like it or not no one should be using the network transparency as described in the "X11 protocol" its the same age as telnet with even more problems. Mind you it has been found in some absolutely stupid places like automated milking machines. Of course someone went to the fun of brute forcing the Xauthority on that.

One of the good things about the Wayland protocol is the choice not to include a network protocol and force that out to a independent part. People and animals that have been harmed by developer making mistake and having X11 TCP feature on is long with quite a few deaths in there.

Yes there are sections of X11 protocol that are still in the X11 protocol that are just as foolish as T55/T70/T90 ammo storage.
.