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
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.
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 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
# Backport patch to Fedora's `xorg-x11-server` and
* 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
opt-out of this default. Which is better left to system-specific
* Release engineering: This feature does not require coordination with
* 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
`xorg.conf.d` snippet will re-enable the old behavior:
Option "AllowSwappedClients" "on"
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
* run the X client which will fail to connect
Alternatively, a test client is available in
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
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
== Release Notes ==
He / Him / His
Fedora Program Manager