https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == X server implementations (e.g. Xorg and Xwayland) will (by default) no longer allow clients with different endianess to connect. == Owner == * Name: [[User:whot| Peter Hutterer]] * Email: peter.hutterer(a)redhat.com == Detailed Description == <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> X server implementations (e.g. Xorg and Xwayland) allow clients with an endianess different to that of the server to connect. Protocol messages to and from these clients are byte-swapped by the X server. However, the code in the X server that does this is virtually untested, providing a large attack surface for malicious clients. One needs to only look at e.g. [https://www.x.org/wiki/Development/Security/Advisory-2014-12-09 this X.Org security advisory] and count the `SProc` mentions for an indication on how bad this is. A simple solution to remove this attack surface is to prohibit clients with a different endianess. These clients will simply fail, in a matter similar to failing to authenticate against an X server. The use-case for clients with different endianess is ''very'' niche. It was common in the 1980s when X was originally developed but at this point a vanishingly small number of users run clients and X servers on different machines, let alone on different machines with different endianess. I'd be surprised if Fedora had ''any'' users requiring this feature. Note: * this only affects use-cases where the server runs on a little endian host and the client on a Big Endian host (or vice versa). * this is a change in '''the default behavior''' only and can be changed via configuration options (for `Xorg`) and/or commandline arguments (all X servers). * this is a change in the upstream default behavior that Fedora will follow along with. This Change is primarily to increase the exposure. == Benefit to Fedora == This change removes a large potential attack surface that can be used by malicious clients to expose memory locations, crash the X server and/or do other entertaining things malicious programs like to do. == Scope == * Proposal owners: # Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 upstream PR] # Backport patch to Fedora's `xorg-x11-server` and `xorg-x11-server-Xwayland` packages * Other developers: This is labelled as system-wide change simply because it's a change in Xorg/Xwayland. It is otherwise self-contained in that no other packages need updating, '''unless''' they want to opt-out of this default. Which is better left to system-specific configuration anyway. * Release engineering: This feature does not require coordination with release engineering * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == For the ''extremely niche'' use-case of users that run X clients on a remote machine with a different endianess, these clients will no longer be able to connect '''by default'''. For Xorg, the following `xorg.conf.d` snippet will re-enable the old behavior: <pre> Section "ServerFlags" Option "AllowSwappedClients" "on" EndSection </pre> Wayland users (and thus Xwayland) need to employ compositor-specific configuration to pass the `+byteswappedclients` flag to Xwayland. At the time of writing, GNOME does not yet provide such a configuration. == How To Test == To test the impact of this change, you need: * an X server running on a little endian architecture and an X client running on a Big Endian architecture (or the other way around) * set up the X server to accept remote connections, either via TCP or through SSH * run the X client which will fail to connect Alternatively, a test client is available in [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the upstream PR]. This test client pretends to be BigEndian and will fail to connect when run against a little endian X server. == User Experience == For virtually all users, there is no change in behavior. Users with X server and client on two different machines must add the `xorg.conf.d` snippet shown above on affected systems. == Dependencies == No other RPMs depend on this change. == Contingency Plan == This change depends on whether upstream merges this new default behavior. If upstream does not merged the feature in time, this Change will be postponed until the next Fedora version to avoid potential incompatibilities between configurations or commandline options. * Contingency mechanism: keep current behavior, try again with next Fedora version * Contingency deadline: beta freeze * Blocks release? No == Documentation == == Release Notes ==

On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote: > > https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients > > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > X server implementations (e.g. Xorg and Xwayland) will (by default) no > longer allow clients with different endianess to connect. > > == Owner == > * Name: [[User:whot| Peter Hutterer]] > * Email: peter.hutterer(a)redhat.com > > > == Detailed Description == > <!-- Expand on the summary, if appropriate. A couple sentences > suffices to explain the goal, but the more details you can provide the > better. --> > > X server implementations (e.g. Xorg and Xwayland) allow clients with > an endianess different to that of the server to connect. Protocol > messages to and from these clients are byte-swapped by the X server. > However, the code in the X server that does this is virtually > untested, providing a large attack surface for malicious clients. One > needs to only look at e.g. > [https://www.x.org/wiki/Development/Security/Advisory-2014-12-09 this > X.Org security advisory] and count the `SProc` mentions for an > indication on how bad this is. A simple solution to remove this attack > surface is to prohibit clients with a different endianess. These > clients will simply fail, in a matter similar to failing to > authenticate against an X server. > > The use-case for clients with different endianess is ''very'' niche. > It was common in the 1980s when X was originally developed but at this > point a vanishingly small number of users run clients and X servers on > different machines, let alone on different machines with different > endianess. I'd be surprised if Fedora had ''any'' users requiring this > feature. > > Note: > * this only affects use-cases where the server runs on a little endian > host and the client on a Big Endian host (or vice versa). > * this is a change in '''the default behavior''' only and can be > changed via configuration options (for `Xorg`) and/or commandline > arguments (all X servers). > * this is a change in the upstream default behavior that Fedora will > follow along with. This Change is primarily to increase the exposure. > > > == Benefit to Fedora == > > This change removes a large potential attack surface that can be used > by malicious clients to expose memory locations, crash the X server > and/or do other entertaining things malicious programs like to do. > > == Scope == > * Proposal owners: > # Merge [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 > upstream PR] > # Backport patch to Fedora's `xorg-x11-server` and > `xorg-x11-server-Xwayland` packages > > * Other developers: This is labelled as system-wide change simply > because it's a change in Xorg/Xwayland. It is otherwise self-contained > in that no other packages need updating, '''unless''' they want to > opt-out of this default. Which is better left to system-specific > configuration anyway. > > * Release engineering: This feature does not require coordination with > release engineering > > * Policies and guidelines: N/A (not needed for this Change) > * Trademark approval: N/A (not needed for this Change) > * Alignment with Objectives: > > == Upgrade/compatibility impact == > For the ''extremely niche'' use-case of users that run X clients on a > remote machine with a different endianess, these clients will no > longer be able to connect '''by default'''. For Xorg, the following > `xorg.conf.d` snippet will re-enable the old behavior: > > <pre> > Section "ServerFlags" > Option "AllowSwappedClients" "on" > EndSection > </pre> > > Wayland users (and thus Xwayland) need to employ compositor-specific > configuration to pass the `+byteswappedclients` flag to Xwayland. At > the time of writing, GNOME does not yet provide such a configuration. > > == How To Test == > To test the impact of this change, you need: > > * an X server running on a little endian architecture and an X client > running on a Big Endian architecture (or the other way around) > * set up the X server to accept remote connections, either via TCP or > through SSH > * run the X client which will fail to connect > > Alternatively, a test client is available in > [https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029 the > upstream PR]. This test client pretends to be BigEndian and will fail > to connect when run against a little endian X server. > > > == User Experience == > For virtually all users, there is no change in behavior. > > Users with X server and client on two different machines must add the > `xorg.conf.d` snippet shown above on affected systems. > > == Dependencies == > No other RPMs depend on this change. > > > == Contingency Plan == > > This change depends on whether upstream merges this new default > behavior. If upstream does not merged the feature in time, this Change > will be postponed until the next Fedora version to avoid potential > incompatibilities between configurations or commandline options. > > * Contingency mechanism: keep current behavior, try again with next > Fedora version > * Contingency deadline: beta freeze > * Blocks release? No > > > == Documentation == > > == Release Notes == > So I guess this means no remoting into ppc64 or s390x machines from x86_64 or ppc64le machines without a configuration tweak?

Or do modern versions of X use consistent endianness regardless of architecture?

On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: [...] > > So I guess this means no remoting into ppc64 or s390x machines from > > x86_64 or ppc64le machines without a configuration tweak? > > We don't have ppc64 builds anymore and I don't know the last release we had > that was ppc64, but it was a long time ago now. All current POWER systems are > ppc64le. > > And everything else we have as primary or alternative architectures is little > endian, except s390x. I do view this as a risk for s390x because of all the > architectures we build for, this one is the most difficult to use graphically. > Exporting your display is still the convenient method for this platform. > > Given that this change proposal affects default behavior, I don't see a > problem with it. s390x users can drop the configuration change in xorg.conf.d > to regain the functionality. If that can be conditionally enabled for s390x > at package build time, that might make things easier (but wouldn't you need to > make the change on both the s390x host and your non-s390x workstation?). The X protocol works that the first byte of the connection request is a either 'l' or 'B', telling the server that the client is little or Big endian. The client has no information on the server's endianess. This means the configuration needs to be done wherever your X server runs, so the (little-endian) thing you're sitting in front of. Which is also why compile-time defaults are difficult, at compile time we cannot know that eventually you may want to connect from an s390x.

On Thu, 5 Jan 2023 at 08:20, David Cantrell <dcantrell(a)redhat.com&gt; wrote: > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > > [...] > > > > So I guess this means no remoting into ppc64 or s390x machines from > > > > x86_64 or ppc64le machines without a configuration tweak? > > > > > > We don't have ppc64 builds anymore and I don't know the last release > we had > > > that was ppc64, but it was a long time ago now. All current POWER > systems are > > > ppc64le. > > > > > > And everything else we have as primary or alternative architectures is > little > > > endian, except s390x. I do view this as a risk for s390x because of > all the > > > architectures we build for, this one is the most difficult to use > graphically. > > > Exporting your display is still the convenient method for this > platform. > > > > > > Given that this change proposal affects default behavior, I don't see a > > > problem with it. s390x users can drop the configuration change in > xorg.conf.d > > > to regain the functionality. If that can be conditionally enabled for > s390x > > > at package build time, that might make things easier (but wouldn't you > need to > > > make the change on both the s390x host and your non-s390x > workstation?). > > > > The X protocol works that the first byte of the connection request is a > > either 'l' or 'B', telling the server that the client is little or Big > > endian. The client has no information on the server's endianess. > > > > This means the configuration needs to be done wherever your X server > > runs, so the (little-endian) thing you're sitting in front of. Which is > > also why compile-time defaults are difficult, at compile time we cannot > > know that eventually you may want to connect from an s390x. > > Reasonable. The runtime configuration change I can make locally to allow > me > to run X programs on an s390x and display them locally is sufficient for > me. > Wasn't there a concern that you can do this if you are running a desktop with X, but if you are using Xwayland it isn't easy (or maybe possible) as the configuration to do that was either hardcoded or not fully documented on how to do that? From Peter Hutterer <peter.hutterer(a)who-t.net&gt; earlier: ``` but you don't necessarily have access to how Xwayland is started (mutter certainly is hard-coded). ```

On Fri, Jan 06, 2023 at 11:13:14AM +1000, Peter Hutterer wrote: > On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote: > > On Thu, 5 Jan 2023 at 08:20, David Cantrell <dcantrell(a)redhat.com&gt; wrote: > > > > > On Thu, Jan 05, 2023 at 11:10:20AM +1000, Peter Hutterer wrote: > > > > On Wed, Jan 04, 2023 at 03:19:57PM -0500, David Cantrell wrote: > > > > [...] > > > > > > So I guess this means no remoting into ppc64 or s390x machines from > > > > > > x86_64 or ppc64le machines without a configuration tweak? > > > > > > > > > > We don't have ppc64 builds anymore and I don't know the last release > > > we had > > > > > that was ppc64, but it was a long time ago now. All current POWER > > > systems are > > > > > ppc64le. > > > > > > > > > > And everything else we have as primary or alternative architectures is > > > little > > > > > endian, except s390x. I do view this as a risk for s390x because of > > > all the > > > > > architectures we build for, this one is the most difficult to use > > > graphically. > > > > > Exporting your display is still the convenient method for this > > > platform. > > > > > > > > > > Given that this change proposal affects default behavior, I don't see a > > > > > problem with it. s390x users can drop the configuration change in > > > xorg.conf.d > > > > > to regain the functionality. If that can be conditionally enabled for > > > s390x > > > > > at package build time, that might make things easier (but wouldn't you > > > need to > > > > > make the change on both the s390x host and your non-s390x > > > workstation?). > > > > > > > > The X protocol works that the first byte of the connection request is a > > > > either 'l' or 'B', telling the server that the client is little or Big > > > > endian. The client has no information on the server's endianess. > > > > > > > > This means the configuration needs to be done wherever your X server > > > > runs, so the (little-endian) thing you're sitting in front of. Which is > > > > also why compile-time defaults are difficult, at compile time we cannot > > > > know that eventually you may want to connect from an s390x. > > > > > > Reasonable. The runtime configuration change I can make locally to allow > > > me > > > to run X programs on an s390x and display them locally is sufficient for > > > me. > > > > > > > Wasn't there a concern that you can do this if you are running a desktop > > with X, but if you are using Xwayland it isn't easy (or maybe possible) as > > the configuration to do that was either hardcoded or not fully documented > > on how to do that? > > > > From Peter Hutterer <peter.hutterer(a)who-t.net&gt; earlier: > > ``` > > but you don't necessarily have > > access to how Xwayland is started (mutter certainly is hard-coded). > > ``` > > Correct, the Wayland compositor is responsible for starting up XWayland > and that's not always configurable. I've filed bugs for mutter, kwin and > wlroots so the developers are aware and that should cover the majority > of Wayland use-cases once fixed. just a minor follow-up: mutter has that feature merged now for GNOME 43 [1] so a once-off gsettings call should do the trick there: $ gsettings set org.gnome.mutter.wayland xwayland-allow-byte-swapped-clients true Cheers, Peter

Am 21.12.2022 um 22:49 schrieb Ben Cotton <bcotton(a)redhat.com&gt;: Users with X server and client on two different machines must add the `xorg.conf.d` snippet shown above on affected systems.

Hi On Thu, Dec 22, 2022 at 9:45 AM Peter Boy <pboy(a)uni-bremen.de&gt; wrote: > How should this be documented so that it can be found by users who want to connect to ppc64 (or s390x) a year from now, when no one has the change proposal in mind anymore? Is there at least a descriptive error message? When the connection fails, the Xserver returns a reason in plain text. In that case, the reason for the connection being rejected would be „Swapped clients prohibited“.

> (Unfortunately, we have too many undocumented (or at any rate factually invisibly documented) features in our distro ) Cheers Olivier _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Vít Ondruch wrote: > Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a): > > When the connection fails, the Xserver returns a reason in plain text. > > In that case, the reason for the connection being rejected would be > > „Swapped clients prohibited“. > > Appreciate that there is at least some explanation, but if I saw this > error, I would not be much smarter what is going on and how should I > proceed .... Yes, that's a really bad error message. My reaction would be "What nonsense is that? I haven't swapped any clients." If it had at least said "byte-swapped" it would probably have gotten me searching in the right direction, but if the X server wants to be helpful it should say "big/little-endian mismatch; the option AllowSwappedClients is off".

Am 29.12.2022 um 16:29 schrieb David Malcolm <dmalcolm(a)redhat.com&gt;: On Thu, 2022-12-29 at 13:03 +1000, Peter Hutterer wrote: > On Thu, Dec 22, 2022 at 09:17:28PM +0100, Björn Persson wrote: >> Vít Ondruch wrote: >>> Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a): >>>> When the connection fails, the Xserver returns a reason in >>>> plain text. >>>> In that case, the reason for the connection being rejected >>>> would be >>>> „Swapped clients prohibited“. >>> >>> Appreciate that there is at least some explanation, but if I saw >>> this >>> error, I would not be much smarter what is going on and how >>> should I >>> proceed .... >> >> Yes, that's a really bad error message. My reaction would be "What >> nonsense is that? I haven't swapped any clients." If it had at >> least >> said "byte-swapped" it would probably have gotten me searching in >> the >> right direction, but if the X server wants to be helpful it should >> say >> "big/little-endian mismatch; the option AllowSwappedClients is >> off". > > Thanks, I've changed the error message to say `byte-swapped`, it > hasn't > been merged upstream yet after all. This particular message is > handled > in the DDX-independent bits though (shared code for Xorg, Xwayland, > etc.), the option AllowSwappedClients only exists for Xorg since the > other X server don't have an xorg.conf. Could the error message include a URL to documentation about the config option? That would really help discoverability.

Hi All, This might not be as niche as you might think. I'm one of the Linux kernel maintainers for s390. Many of us do the vast majority of their development work natively on s390 systems via SSH from Fedora laptops. After all mainframes are pretty damn fast at compiling with plenty of memory and dog fooding is part of quality control. And I'm sure it's not just the teams working on the Linux kernel but also plenty of other people working with s390 Linux machines. These s390 machines mostly only host X servers via VNC and usually just for the installation but they do that too. There is also a hand full of X clients I run on s390 which are essential for my and many of my colleagues daily workflows. The most important one is defintely xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local system. Some people also use x3270 via SSH X forwarding from jumphosts, others use XEmacs. I also know essential internal tools that are run on s390 hosts via X forwarding. Sure people using X forwarding are capable of changing configuration defaults but if at all possible I would suggest to rethink this, as it will create significant hassle for anyone using their Fedora systems to SSH + X forward to s390 Linux hosts and it definitely sees more use and thus testing than the proposal makes it sound.

On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote: > On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle <schnelle(a)linux.ibm.com&gt; wrote: > > > > Hi All, > > > > This might not be as niche as you might think. I'm one of the > > Linux kernel maintainers for s390. Many of us do the vast majority of > > their development work natively on s390 systems via SSH from Fedora > > laptops. After all mainframes are pretty damn fast at compiling with > > plenty of memory and dog fooding is part of quality control. And I'm > > sure it's not just the teams working on the Linux kernel but also > > plenty of other people working with s390 Linux machines. These s390 > > machines mostly only host X servers via VNC and usually just for the > > installation but they do that too. There is also a hand full of X > > clients I run on s390 which are essential for my and many of my > > colleagues daily workflows. The most important one is defintely > > xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local > > system. Some people also use x3270 via SSH X forwarding from jumphosts, > > others use XEmacs. I also know essential internal tools that are run on > > s390 hosts via X forwarding. Sure people using X forwarding are capable > > of changing configuration defaults but if at all possible I would > > suggest to rethink this, as it will create significant hassle for > > anyone using their Fedora systems to SSH + X forward to s390 Linux > > hosts and it definitely sees more use and thus testing than the > > proposal makes it sound. > > > > How bad would it be to force little-endian for the X protocol > regardless of architecture? simply said - not realistic. It's a lot of effort, with zero visible benefit beyond the *potential* that we're slightly safer now. Which you won't know until you tested it all. The code works, at least for the bits that are executed. Swapped clients run on different hosts by definition so there are probably whole extensions that are never used at all and likely completely untested. And it's not a matter of "working" but "safe against a malicious client sending bad messages". That's a completely different ballpark. e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one ever noticed the issue - because it works as long as the client is nice. Forcing the server to little endian only means you'd need to do the swapping client-side. There is nothing in place right now to do this and while it's probably possible to automate this somewhat with xcb, you're still looking at a huge project. And once it all works, you need to ensure it works against malicious input data. You could *possibly* MITM the whole protocol-swapping into a separate process but, well, goto 10 :)

On Wed, Dec 28, 2022 at 10:16:45PM -0500, Neal Gompa wrote: > On Wed, Dec 28, 2022 at 10:13 PM Peter Hutterer > <peter.hutterer(a)who-t.net&gt; wrote: > > > > On Thu, Dec 22, 2022 at 05:41:06AM -0500, Neal Gompa wrote: > > > On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle <schnelle(a)linux.ibm.com&gt; wrote: > > > > > > > > Hi All, > > > > > > > > This might not be as niche as you might think. I'm one of the > > > > Linux kernel maintainers for s390. Many of us do the vast majority of > > > > their development work natively on s390 systems via SSH from Fedora > > > > laptops. After all mainframes are pretty damn fast at compiling with > > > > plenty of memory and dog fooding is part of quality control. And I'm > > > > sure it's not just the teams working on the Linux kernel but also > > > > plenty of other people working with s390 Linux machines. These s390 > > > > machines mostly only host X servers via VNC and usually just for the > > > > installation but they do that too. There is also a hand full of X > > > > clients I run on s390 which are essential for my and many of my > > > > colleagues daily workflows. The most important one is defintely > > > > xsel/xclip to copy from the (neo-)vim/tmux I use for coding to my local > > > > system. Some people also use x3270 via SSH X forwarding from jumphosts, > > > > others use XEmacs. I also know essential internal tools that are run on > > > > s390 hosts via X forwarding. Sure people using X forwarding are capable > > > > of changing configuration defaults but if at all possible I would > > > > suggest to rethink this, as it will create significant hassle for > > > > anyone using their Fedora systems to SSH + X forward to s390 Linux > > > > hosts and it definitely sees more use and thus testing than the > > > > proposal makes it sound. > > > > > > > > > > How bad would it be to force little-endian for the X protocol > > > regardless of architecture? > > > > simply said - not realistic. It's a lot of effort, with zero visible > > benefit beyond the *potential* that we're slightly safer now. Which you > > won't know until you tested it all. > > > > The code works, at least for the bits that are executed. Swapped clients > > run on different hosts by definition so there are probably whole > > extensions that are never used at all and likely completely untested. > > And it's not a matter of "working" but "safe against a malicious client > > sending bad messages". That's a completely different ballpark. > > e.g. the code for CVE-2022-46340 has been there since ~2008 but no-one > > ever noticed the issue - because it works as long as the client is nice. > > > > Forcing the server to little endian only means you'd need to do the > > swapping client-side. There is nothing in place right now to do this and > > while it's probably possible to automate this somewhat with xcb, you're > > still looking at a huge project. And once it all works, you need to > > ensure it works against malicious input data. You could *possibly* MITM > > the whole protocol-swapping into a separate process but, well, goto 10 > > :) > > > > Please tell me the Wayland protocol doesn't do this? 🙏 the wayland protocol doesn't to this :) Wayland integers must be encoded in the host's (read: compositor) byte order. Somewhat of an exception are the wl_shm image formats which are (apparently) always in little-endian [1].

This might not be as niche as you might think. I'm one of the Linux kernel maintainers for s390. Many of us do the vast majority of their development work natively on s390 systems via SSH from Fedora laptops.

> This might not be as niche as you might think. I'm one of the > Linux kernel maintainers for s390. Many of us do the vast majority of > their development work natively on s390 systems via SSH from Fedora > laptops. I first wanted to echo and confirm what Niklas says here. The crux of this issue seems to be "the code in the X server that does this is virtually untested" so would more attention being paid to this code help? I can't make any promises, but it would be valuable to know if this, or something else, is needed. I will also bring this to the attention of the Open Mainframe Project Linux Distributions Working Group, since all of the distros use this byte-swapped code.

https://fedoraproject.org/wiki/Changes/XServerProhibitsByteSwappedClients

X server implementations (e.g. Xorg and Xwayland) allow clients with an endianess different to that of the server to connect. Protocol messages to and from these clients are byte-swapped by the X server. However, the code in the X server that does this is virtually untested, providing a large attack surface for malicious clients.

A years-earlier "by-hand" example of related coding in plain-C is scripts/recordmcount.c  in the source code for Linux kernel.