8 ms·

X servers no longer allow byte-swapped clients

100 points by pabs3 4y ago

hulitu 4y ago
It is a bug in Xwayland. Theoretically the rest of the world is not affected. Apparently some people think that breaking compatibilty is the way to go.
- erlkonig 4y ago
  At more centrally-administered sites, a user might not even have the ability to change an X server option. The idea of making a toggle via xset sort-of makes sense, but seriously, isn't the idea generally that you trust the apps you're running anyway. And doesn't a vastly different wrong number in some X call at least produce an effect that makes you aware of the problem (I know, that doesn't make a X server more stable...). It's just baffling to make something near-universally available less so. The next new CPU thing could be bigendian - or quantum, but who knows what byte order that would prefer.
  - eikenberry 4y ago
    > but seriously, isn't the idea generally that you trust the apps you're running anyway Yes, and it is a bad idea. Trusting your apps is how we've gotten in the state we are today with virus scanners and the like. Generally you want to trust as little as possible (at least in tech).
    - sprash 4y ago
      > the state we are today with virus scanners and the like. Generally you want to trust as little as possible This is only true if you run closed source software on non-free systems. I honestly can't remember that I ever had to use a virus scanner on Linux or UNIX.
      - charcircuit 4y ago
        You still have to worry about vulnerabilities. It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys, but unfortunately this is how many Linux distros, ignoring Android based ones, work.
        sprash 4y ago
        > It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys So far this never happened on free operating systems running free software on X11. Hence I refuse to believe this is a realistic threat scenario. Severe sandboxing is only necessary for untrusted/non-FOSS software otherwise it just harms user experience an productivity especially for power users.
        charcircuit 4y ago
        Quassel is an IRC client licensed under the GPLv2 and GPLv3. CVE-2018-1000178 is a RCE vulnerability for it. Yes. It is possible.
        comex 4y ago
        Do you use a modern browser? If so, you use a piece of software that has been exploited many times by attacks in the wild. Those attacks were mostly targeting either a phone OS or Windows or macOS - not because there is anything in desktop Linux that would defend against those attacks, but because it is less popular. Perhaps some attacks did target desktop Linux; it’s hard to tell because few in-the-wild attacks are publicly documented in detail (although Project Zero has a spreadsheet of bugs known to have been exploited in the wild [1]). Regardless, at best you are relying on security by obscurity. And that’s despite the fact that modern browsers already have built-in sandboxing; without it the situation is worse. [1] https://googleprojectzero.blogspot.com/p/0day.html?m=1 https://googleprojectzero.blogspot.com/p/0day.html?m=1
        hulitu 4y ago
        The modern web browser is a RCE vulnerability in itself. That developers seems to think this is a good idea is beyond my comprehension. On a modern system the browser should run ideally in a virtual machine without any access to hardware or filesystem.
- CJefferson 4y ago
  It's really hard to test big-endian software -- because almost no-one (and in particular no devs) really run big-endian CPUs anymore. There are a few programs I work on where we "officially" disabled big-endian support, because it's just impossible to find devs to work on it. It's also hard to test, you can't test it on github actions for example. I'd be happy to see some people step up for testing big-endian, but at the moment it would be a huge time-sink for many projects, when it's not even clear if there are any users.
  - cbmuser 4y ago
    Debian and Gentoo still provide current installation images for various big-endian architectures such as hppa, m68k, ppc32, ppc64 and sparc64.
    - chupasaurus 4y ago
      > hppa, m68k, ppc32, ppc64 and sparc64 None of which are supported officially by Debian, with notable exception of ppc64el (POWER8/9 little-endian). The only official port with big-endian is s390x. [0] [0] https://wiki.debian.org/SupportedArchitectures https://wiki.debian.org/SupportedArchitectures
  - TillE 4y ago
    It's annoying that some file formats (and of course protocols) are still using big endian. Otherwise yes, the world has effectively standardized on little endian, it's fine to let big endian die outside of some weird niches.
  - tyingq 4y ago
    ARM has selectable endianess, but it's difficult to find an OS that will run big endian ARM in any sort of out-of-the-box way. The simplest one I could find is netbsd, which can run big-endian on an Rpi3 and some other boards. https://wiki.netbsd.org/ports/evbarm/ https://wiki.netbsd.org/ports/evbarm/ (see the earmv7hfeb note)
  - asveikau 4y ago
    One approach I've seen to writing big endian safe software is to not load integers directly, and apply the same logic regardless of endianness. Eg. Instead of: uint16_t x; #ifdef BIG_ENDIAN x = swap(*p); #else x = *p; #endif You can write: uint16_t x; unsigned char *q = (unsigned char*)p; x = q[0] | (((uint16_t)q[1]) << 8); (Pardon the rushed job of writing C in an HN form on mobile.) This exercises the same deserialization from little endian regardless of the hardware representation of integers. This means you are testing how it will act on big endian even when running on little endian.
- jmclnx 4y ago
  Yes, seems these days nothing exists but Linux. Almost like the old Microsoft days. Being on a BSD this annoys me. Seems this could be yet another thing that will prevent Wayland from running on anything but Linux on x86 type systems. But I have no plans to ever use Wayland until they get Network Transparency anyway, so as far as I am concerned it is not a huge deal for me (yet). So I will annoy the developers :) Yes, I do understand the Wayland people are working hard and I appreciate their work, but I wish they would make Wayland easily portable to other UN*X Systems.
  - bitwize 4y ago
    Waypipe is a thing.
  - QUrprUd1nCeicw 4y ago
    There's no such thing as "network transparency" anymore. Newer desktop apps are now written to assume GPU rendering and that's local only, even on X11. If they implement software rendering at all, it's a separate code path provided as a slow fallback. If you were using X forwarding to run old clients, you can still use XWayland to forward them. It's the same idea as using XQuartz on Mac, you run rootless X11 on top of another window system. VNC should also work on every Wayland implementation I've seen. Part of the reason Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. Wayland doesn't really have userspace drivers like X11 did, the current implementations assume that the kernel is just going to handle all of this. The other kernels really need to be implementing evdev, DRM and KMS to get the full range of support for input and graphics hardware. Without those APIs, those other kernels are on their own trying to figure out how to get modern hardware to work and how they're going to plug random drivers into Wayland, when that model is obsolete as far as Linux is concerned.
    - wahern 4y ago
      > Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. [...] The other kernels really need to be implementing evdev and dri3 to get the full range of support for input and graphics hardware. Other Unix systems are indeed far behind implementing Linux-specific interfaces. Windows and macOS will likewise have a hard time. Because portability was never a real concern in the Wayland community, it's entirely unsurprising that most of Wayland ecosystem is Linux-specific. In fact, even the parts of Wayland that could be trivially made more portable, such as adding kqueue support in parallel to epoll, still haven't materialized. (See https://gitlab.freedesktop.org/wayland/wayland/-/issues/72 https://gitlab.freedesktop.org/wayland/wayland/-/issues/72 and https://gitlab.freedesktop.org/wayland/wayland/-/issues/214 https://gitlab.freedesktop.org/wayland/wayland/-/issues/214)
- asveikau 4y ago
  The article suggests it's Xorg server too, not just XWayland. Can anyone confirm?
  - classichasclass 4y ago
    Yes, it's an Xorg change which will get incorporated downstream into Xwayland.
  - deleted 4y ago
    [deleted]
- bitwize 4y ago
  No one wants to maintain backward compatibility for decades with computer architectures no one actually uses anymore. There are more innovative, exciting things to work on. Big endian is so dead, you can literally design a binary network protocol that has all fields 64-bit aligned, little endian, slurp the packets into a buffer, cast the buffer to a struct, and be fine across ALL architectures you'll likely run in production. This, by the way, is why X11 itself is slowly bit-rotting into irrelevance also: no one wants to maintain it. Most of the protocol exists strictly for legacy applications -- modern ones use the X server as a framebuffer compositor and that's it.
  - yjftsjthsd-h 4y ago
    The great thing is that if you actually follow this logic you never need to care; nobody uses anything but Windows for graphical applications anyways, so X11 (and Wayland, incidentally) is irrelevant in all cases. Or... did you mean to suggest that your niche platform matters but not this other niche platform?
    - chlorion 4y ago
      I understand where you are coming from, but I think at the end of the day, if there are people on $platform who are willing to contribute, that's all that actually matters. If there aren't enough users, there will be nobody to support it, so it dies. In other words, it not about how much one platform "matters" over another to some users. We can't expect people to work for free to support our platforms with no benefit to them. If you really care, I guess donate some hardware, or pay some developer to work on this, or provide support yourself! I know that sounds rude but it is what it comes down to. It seems like in this specific case X11 will still support whatever exactly this feature is but will put it behind a config option. The idea above applies in general to open source work though.
- bsder 4y ago
  So you are volunteering to step up, test and maintain the big endian code? Feel free to grab some PRs and fix them to demonstrate your willingness. This comment from the article fits: > Having it be an option that's turned off by default just ensures that it will rapidly end up broken because of its "niche"ness, and then removed because it keeps causing breakage. Do it all the way or not at all. The problem is that X11 is actually in a zombie-like state right now. It's not dead because it mostly works, sorta, because people keep stitching extra limbs on when enough people bitch. However, it's not actually alive because nobody really wants to work on it and ... Every single architectural assumption that X11 made is now wrong. CPUs are stupidly powerful. Triangles, not bitmaps, are the fundamental primitive (to be fair, this one may be starting to flip back as GPU computing becomes more ubiquitous). Network is vastly slower than CPU and latency has gotten ferociously worse. Input methods aren't just mouse and cursor. Sharing is a problem and secure should be the default. etc. I have written code for X11. I have written initialization code for graphics cards to deal with X11. X11 coding is hell. Wayland may not be the answer, but X11 needs to die before we will get to that answer.
Karellen 4y ago
...by default. It's still available as a setting in `xorg.conf`, or on the command line.
mannyv 4y ago
This is amusing because network byte order is big endian. The title should say ‘no longer allows big endian clients.’ Or does it deny all byte swapped clients ie if the server is big endian it disallows little endian clients?
- Gibbon1 4y ago
  Only legacy protocols should be big endian at this point though.
- mjg59 4y ago
  The latter.
- Karellen 4y ago
  As it says in TFA: > So to this day whenever a client connects, the first byte it sends is a literal "l" or "B" to inform the server of the client's byte order. Where the byte order doesn't match the X server's byte order, the client is a "swapped client" in X server terminology So it's wherever the client doesn't match the server, which ever way around that is.
drpixie 4y ago
So ... the majority opinion here is that it's fine to break things, because we use Linux on Intel/AMD, and clients from other backgrounds will have to sort things out for themselves. Even though we took X from systems with other backgrounds who considerately handled both byte orders! I hope this is not the new Linux philosophy?
- deleted 4y ago
  [deleted]
- rollcat 4y ago
  An argument was made about reducing the potential attack surface. How many big-endian systems can you currently point out in your environment? How often do you use X11 forwarding? What's the intersection of these two sets? Even if you somehow do have even one such system, you're pitting that incredibly niche use case against the security of literally every single other X11 user on the planet, which is easily millions. They 100% did the right thing.
  - aidenn0 4y ago
    I haven't dug through the X server code, but byte-swapping ought to be an insignificant attack surface of the code. Most network protocols do this already; ssh does it! The only thing that matches with what I have observed from the X developers is that the X code is, in general, a steaming pile of shit that nobody wants to wade through anymore and so any bit that can be disabled and/or removed is unambiguously a Good Thing. The design of Wayland strongly implies that network transparency is a non-feature for the X developers, so everything surrounding it will be a target for removal.
    - QUrprUd1nCeicw 4y ago
      The problem with the X server code is most of the protocol code is very complex and it's hand rolled code predating C89. It (still!) does all the parsing and byte swaps manually. In a modern project you would have the compiler generate the parsers and the dispatch table based on an IDL but X is way too old to have done this. There are just two implementations in the code for everything. No one wants to touch it due to fear of breaking everything even worse. So instead they just slowly try to stop the bleeding by disabling things that cause the worst security issues. It's a bad situation overall, and the time has already passed for a full rewrite of the X server to be viable. The SSH protocol is relatively simple by comparison, and most importantly, there actually are multiple independent modernized implementations of it.
rbanffy 4y ago
> I think the only regular real-world use-case for this is running X clients on an s390x I feel seen. I actually did that, mostly for fun - the latencies between me and the big box made it very impractical.
- classichasclass 4y ago
  Actually, I use it for running AIX X clients on a Fedora ppc64le. Screenshot: https://www.talospace.com/2023/01/your-x-server-may-no-longer-swing-both.html https://www.talospace.com/2023/01/your-x-server-may-no-longe...
  - rbanffy 4y ago
    That reminds me I need to get more interesting hardware in my converted attic.
pelorat 4y ago
I'm just amazed X is still a thing. It's the definition of niche. I can't even imagine putting dev ours into it. It should seriously just be dropped and abandoned. X is one of the most detrimental pieces of technology holding desktop Linux (or *nix) back. I still wish Ubuntu went with Mir over Wayland (which is also trash). If you want remote apps, just transfer pixels... seriously!
- erik_seaberg 4y ago
  GPUs are still rare in datacenters, and definitely not 1:1 with end users’ displays. When a backend needs a GUI, I don’t see much reason to choose anything other than local Javascript or Wasm to display it. It’s thoroughly cross platform and hardware accelerated.
froh 4y ago
the original title has (by default) added to it, and the article points out it remains available as a config flag. so the real discussion should be if it's the clients or the servers obligation to reorder binary integers as needed, or if the standard requests both to be in network byte order. technically do you use hton(3)/ntoh(3) [1] on every call in server and client, or do you apply it conditionally, on just the "smarter" side, and only if server and client native byte order mismatch? if you have the intelligence in the server you're hitting speculative execution all over the server, "penalizing" every user of the server, if ever so slightly, and "hardener" so if you have a mixed bag of clients, so speculative execution fails regularly. so you move the burden to conditionally swap bytes to the clients, all of them. chances are the clients will talk to just one server. the price you pay is clients without byte swap option simply can't connect. I _did_ run (virtual) X Servers on zSeries to run graphical software locally, on The Host (remote access via vnc), and all of this _does_make sense. [1] https://linux.die.net/man/3/htons https://linux.die.net/man/3/htons
shmerl 4y ago
What is the best replacement for X forwarding in the Wayland world these days? Is there a good quality remote desktop for Linux?

100 points by pabs3 4y ago

It is a bug in Xwayland. Theoretically the rest of the world is not affected. Apparently some people think that breaking compatibilty is the way to go.

erlkonig 4y ago
At more centrally-administered sites, a user might not even have the ability to change an X server option. The idea of making a toggle via xset sort-of makes sense, but seriously, isn't the idea generally that you trust the apps you're running anyway. And doesn't a vastly different wrong number in some X call at least produce an effect that makes you aware of the problem (I know, that doesn't make a X server more stable...). It's just baffling to make something near-universally available less so. The next new CPU thing could be bigendian - or quantum, but who knows what byte order that would prefer.
- eikenberry 4y ago
  > but seriously, isn't the idea generally that you trust the apps you're running anyway Yes, and it is a bad idea. Trusting your apps is how we've gotten in the state we are today with virus scanners and the like. Generally you want to trust as little as possible (at least in tech).
  - sprash 4y ago
    > the state we are today with virus scanners and the like. Generally you want to trust as little as possible This is only true if you run closed source software on non-free systems. I honestly can't remember that I ever had to use a virus scanner on Linux or UNIX.
    - charcircuit 4y ago
      You still have to worry about vulnerabilities. It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys, but unfortunately this is how many Linux distros, ignoring Android based ones, work.
      - sprash 4y ago
        > It shouldn't be possible for a chat program that someone exploited to be able to access your ssh private keys So far this never happened on free operating systems running free software on X11. Hence I refuse to believe this is a realistic threat scenario. Severe sandboxing is only necessary for untrusted/non-FOSS software otherwise it just harms user experience an productivity especially for power users.
        charcircuit 4y ago
        Quassel is an IRC client licensed under the GPLv2 and GPLv3. CVE-2018-1000178 is a RCE vulnerability for it. Yes. It is possible.
        comex 4y ago
        Do you use a modern browser? If so, you use a piece of software that has been exploited many times by attacks in the wild. Those attacks were mostly targeting either a phone OS or Windows or macOS - not because there is anything in desktop Linux that would defend against those attacks, but because it is less popular. Perhaps some attacks did target desktop Linux; it’s hard to tell because few in-the-wild attacks are publicly documented in detail (although Project Zero has a spreadsheet of bugs known to have been exploited in the wild [1]). Regardless, at best you are relying on security by obscurity. And that’s despite the fact that modern browsers already have built-in sandboxing; without it the situation is worse. [1] https://googleprojectzero.blogspot.com/p/0day.html?m=1 https://googleprojectzero.blogspot.com/p/0day.html?m=1
        hulitu 4y ago
        The modern web browser is a RCE vulnerability in itself. That developers seems to think this is a good idea is beyond my comprehension. On a modern system the browser should run ideally in a virtual machine without any access to hardware or filesystem.
CJefferson 4y ago
It's really hard to test big-endian software -- because almost no-one (and in particular no devs) really run big-endian CPUs anymore. There are a few programs I work on where we "officially" disabled big-endian support, because it's just impossible to find devs to work on it. It's also hard to test, you can't test it on github actions for example. I'd be happy to see some people step up for testing big-endian, but at the moment it would be a huge time-sink for many projects, when it's not even clear if there are any users.
- cbmuser 4y ago
  Debian and Gentoo still provide current installation images for various big-endian architectures such as hppa, m68k, ppc32, ppc64 and sparc64.
  - chupasaurus 4y ago
    > hppa, m68k, ppc32, ppc64 and sparc64 None of which are supported officially by Debian, with notable exception of ppc64el (POWER8/9 little-endian). The only official port with big-endian is s390x. [0] [0] https://wiki.debian.org/SupportedArchitectures https://wiki.debian.org/SupportedArchitectures
- TillE 4y ago
  It's annoying that some file formats (and of course protocols) are still using big endian. Otherwise yes, the world has effectively standardized on little endian, it's fine to let big endian die outside of some weird niches.
- tyingq 4y ago
  ARM has selectable endianess, but it's difficult to find an OS that will run big endian ARM in any sort of out-of-the-box way. The simplest one I could find is netbsd, which can run big-endian on an Rpi3 and some other boards. https://wiki.netbsd.org/ports/evbarm/ https://wiki.netbsd.org/ports/evbarm/ (see the earmv7hfeb note)
- asveikau 4y ago
  One approach I've seen to writing big endian safe software is to not load integers directly, and apply the same logic regardless of endianness. Eg. Instead of: uint16_t x; #ifdef BIG_ENDIAN x = swap(*p); #else x = *p; #endif You can write: uint16_t x; unsigned char *q = (unsigned char*)p; x = q[0] | (((uint16_t)q[1]) << 8); (Pardon the rushed job of writing C in an HN form on mobile.) This exercises the same deserialization from little endian regardless of the hardware representation of integers. This means you are testing how it will act on big endian even when running on little endian.
jmclnx 4y ago
Yes, seems these days nothing exists but Linux. Almost like the old Microsoft days. Being on a BSD this annoys me. Seems this could be yet another thing that will prevent Wayland from running on anything but Linux on x86 type systems. But I have no plans to ever use Wayland until they get Network Transparency anyway, so as far as I am concerned it is not a huge deal for me (yet). So I will annoy the developers :) Yes, I do understand the Wayland people are working hard and I appreciate their work, but I wish they would make Wayland easily portable to other UN*X Systems.
- bitwize 4y ago
  Waypipe is a thing.
- QUrprUd1nCeicw 4y ago
  There's no such thing as "network transparency" anymore. Newer desktop apps are now written to assume GPU rendering and that's local only, even on X11. If they implement software rendering at all, it's a separate code path provided as a slow fallback. If you were using X forwarding to run old clients, you can still use XWayland to forward them. It's the same idea as using XQuartz on Mac, you run rootless X11 on top of another window system. VNC should also work on every Wayland implementation I've seen. Part of the reason Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. Wayland doesn't really have userspace drivers like X11 did, the current implementations assume that the kernel is just going to handle all of this. The other kernels really need to be implementing evdev, DRM and KMS to get the full range of support for input and graphics hardware. Without those APIs, those other kernels are on their own trying to figure out how to get modern hardware to work and how they're going to plug random drivers into Wayland, when that model is obsolete as far as Linux is concerned.
  - wahern 4y ago
    > Wayland is hard to port to other Unix systems is because most of them are really far behind in kernel APIs compared to Linux. [...] The other kernels really need to be implementing evdev and dri3 to get the full range of support for input and graphics hardware. Other Unix systems are indeed far behind implementing Linux-specific interfaces. Windows and macOS will likewise have a hard time. Because portability was never a real concern in the Wayland community, it's entirely unsurprising that most of Wayland ecosystem is Linux-specific. In fact, even the parts of Wayland that could be trivially made more portable, such as adding kqueue support in parallel to epoll, still haven't materialized. (See https://gitlab.freedesktop.org/wayland/wayland/-/issues/72 https://gitlab.freedesktop.org/wayland/wayland/-/issues/72 and https://gitlab.freedesktop.org/wayland/wayland/-/issues/214 https://gitlab.freedesktop.org/wayland/wayland/-/issues/214)
asveikau 4y ago
The article suggests it's Xorg server too, not just XWayland. Can anyone confirm?
- classichasclass 4y ago
  Yes, it's an Xorg change which will get incorporated downstream into Xwayland.
- deleted 4y ago
  [deleted]
bitwize 4y ago
No one wants to maintain backward compatibility for decades with computer architectures no one actually uses anymore. There are more innovative, exciting things to work on. Big endian is so dead, you can literally design a binary network protocol that has all fields 64-bit aligned, little endian, slurp the packets into a buffer, cast the buffer to a struct, and be fine across ALL architectures you'll likely run in production. This, by the way, is why X11 itself is slowly bit-rotting into irrelevance also: no one wants to maintain it. Most of the protocol exists strictly for legacy applications -- modern ones use the X server as a framebuffer compositor and that's it.
- yjftsjthsd-h 4y ago
  The great thing is that if you actually follow this logic you never need to care; nobody uses anything but Windows for graphical applications anyways, so X11 (and Wayland, incidentally) is irrelevant in all cases. Or... did you mean to suggest that your niche platform matters but not this other niche platform?
  - chlorion 4y ago
    I understand where you are coming from, but I think at the end of the day, if there are people on $platform who are willing to contribute, that's all that actually matters. If there aren't enough users, there will be nobody to support it, so it dies. In other words, it not about how much one platform "matters" over another to some users. We can't expect people to work for free to support our platforms with no benefit to them. If you really care, I guess donate some hardware, or pay some developer to work on this, or provide support yourself! I know that sounds rude but it is what it comes down to. It seems like in this specific case X11 will still support whatever exactly this feature is but will put it behind a config option. The idea above applies in general to open source work though.
bsder 4y ago
So you are volunteering to step up, test and maintain the big endian code? Feel free to grab some PRs and fix them to demonstrate your willingness. This comment from the article fits: > Having it be an option that's turned off by default just ensures that it will rapidly end up broken because of its "niche"ness, and then removed because it keeps causing breakage. Do it all the way or not at all. The problem is that X11 is actually in a zombie-like state right now. It's not dead because it mostly works, sorta, because people keep stitching extra limbs on when enough people bitch. However, it's not actually alive because nobody really wants to work on it and ... Every single architectural assumption that X11 made is now wrong. CPUs are stupidly powerful. Triangles, not bitmaps, are the fundamental primitive (to be fair, this one may be starting to flip back as GPU computing becomes more ubiquitous). Network is vastly slower than CPU and latency has gotten ferociously worse. Input methods aren't just mouse and cursor. Sharing is a problem and secure should be the default. etc. I have written code for X11. I have written initialization code for graphics cards to deal with X11. X11 coding is hell. Wayland may not be the answer, but X11 needs to die before we will get to that answer.

Karellen 4y ago

...by default. It's still available as a setting in `xorg.conf`, or on the command line.

mannyv 4y ago

This is amusing because network byte order is big endian. The title should say ‘no longer allows big endian clients.’ Or does it deny all byte swapped clients ie if the server is big endian it disallows little endian clients?

Gibbon1 4y ago
Only legacy protocols should be big endian at this point though.
mjg59 4y ago
The latter.
Karellen 4y ago
As it says in TFA: > So to this day whenever a client connects, the first byte it sends is a literal "l" or "B" to inform the server of the client's byte order. Where the byte order doesn't match the X server's byte order, the client is a "swapped client" in X server terminology So it's wherever the client doesn't match the server, which ever way around that is.

drpixie 4y ago

So ... the majority opinion here is that it's fine to break things, because we use Linux on Intel/AMD, and clients from other backgrounds will have to sort things out for themselves. Even though we took X from systems with other backgrounds who considerately handled both byte orders! I hope this is not the new Linux philosophy?

deleted 4y ago
[deleted]
rollcat 4y ago
An argument was made about reducing the potential attack surface. How many big-endian systems can you currently point out in your environment? How often do you use X11 forwarding? What's the intersection of these two sets? Even if you somehow do have even one such system, you're pitting that incredibly niche use case against the security of literally every single other X11 user on the planet, which is easily millions. They 100% did the right thing.
- aidenn0 4y ago
  I haven't dug through the X server code, but byte-swapping ought to be an insignificant attack surface of the code. Most network protocols do this already; ssh does it! The only thing that matches with what I have observed from the X developers is that the X code is, in general, a steaming pile of shit that nobody wants to wade through anymore and so any bit that can be disabled and/or removed is unambiguously a Good Thing. The design of Wayland strongly implies that network transparency is a non-feature for the X developers, so everything surrounding it will be a target for removal.
  - QUrprUd1nCeicw 4y ago
    The problem with the X server code is most of the protocol code is very complex and it's hand rolled code predating C89. It (still!) does all the parsing and byte swaps manually. In a modern project you would have the compiler generate the parsers and the dispatch table based on an IDL but X is way too old to have done this. There are just two implementations in the code for everything. No one wants to touch it due to fear of breaking everything even worse. So instead they just slowly try to stop the bleeding by disabling things that cause the worst security issues. It's a bad situation overall, and the time has already passed for a full rewrite of the X server to be viable. The SSH protocol is relatively simple by comparison, and most importantly, there actually are multiple independent modernized implementations of it.

rbanffy 4y ago

> I think the only regular real-world use-case for this is running X clients on an s390x I feel seen. I actually did that, mostly for fun - the latencies between me and the big box made it very impractical.

classichasclass 4y ago
Actually, I use it for running AIX X clients on a Fedora ppc64le. Screenshot: https://www.talospace.com/2023/01/your-x-server-may-no-longer-swing-both.html https://www.talospace.com/2023/01/your-x-server-may-no-longe...
- rbanffy 4y ago
  That reminds me I need to get more interesting hardware in my converted attic.

pelorat 4y ago

I'm just amazed X is still a thing. It's the definition of niche. I can't even imagine putting dev ours into it. It should seriously just be dropped and abandoned. X is one of the most detrimental pieces of technology holding desktop Linux (or *nix) back. I still wish Ubuntu went with Mir over Wayland (which is also trash). If you want remote apps, just transfer pixels... seriously!

erik_seaberg 4y ago
GPUs are still rare in datacenters, and definitely not 1:1 with end users’ displays. When a backend needs a GUI, I don’t see much reason to choose anything other than local Javascript or Wasm to display it. It’s thoroughly cross platform and hardware accelerated.

froh 4y ago

the original title has (by default) added to it, and the article points out it remains available as a config flag. so the real discussion should be if it's the clients or the servers obligation to reorder binary integers as needed, or if the standard requests both to be in network byte order. technically do you use hton(3)/ntoh(3) [1] on every call in server and client, or do you apply it conditionally, on just the "smarter" side, and only if server and client native byte order mismatch? if you have the intelligence in the server you're hitting speculative execution all over the server, "penalizing" every user of the server, if ever so slightly, and "hardener" so if you have a mixed bag of clients, so speculative execution fails regularly. so you move the burden to conditionally swap bytes to the clients, all of them. chances are the clients will talk to just one server. the price you pay is clients without byte swap option simply can't connect. I _did_ run (virtual) X Servers on zSeries to run graphical software locally, on The Host (remote access via vnc), and all of this _does_make sense. [1] https://linux.die.net/man/3/htons https://linux.die.net/man/3/htons

shmerl 4y ago

What is the best replacement for X forwarding in the Wayland world these days? Is there a good quality remote desktop for Linux?