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@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@redhat.com 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@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 12/21/22 21:08, Neal Gompa wrote:
On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton bcotton@redhat.com 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@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?
No X11 forwarding, correct. Other protocols like VNC will continue to work. I am honestly surprised that this is a use-case that arises frequently in practice; I would expect ppc64 and especially s390x machines to be managed via SSH or dedicated configuration management software such as Ansible or Salt.
Or do modern versions of X use consistent endianness regardless of architecture?
Sadly no.
On Wed, Dec 21, 2022 at 09:08:54PM -0500, Neal Gompa wrote:
On Wed, Dec 21, 2022 at 4:49 PM Ben Cotton bcotton@redhat.com 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@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?
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?).
Or do modern versions of X use consistent endianness regardless of architecture?
Thanks,
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.
Cheers, Peter
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.
Thanks,
On Thu, 5 Jan 2023 at 08:20, David Cantrell dcantrell@redhat.com 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@who-t.net earlier: ``` but you don't necessarily have access to how Xwayland is started (mutter certainly is hard-coded). ```
On Thu, Jan 05, 2023 at 08:24:21AM -0500, Stephen Smoogen wrote:
On Thu, 5 Jan 2023 at 08:20, David Cantrell dcantrell@redhat.com 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@who-t.net 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.
Cheers, Peter
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@redhat.com 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@who-t.net 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
[1] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/2785
On Thu, 2023-01-19 at 19:46 +1000, Peter Hutterer wrote:
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@redhat.com 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@who-t.net 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
Thanks for opening the BZs and creating these settings. So, this means at least our use case of SSH terminals with the occasional X client and/or copy & paste via X at least has a workaround. I'm still skeptical of the cost to benefit ratio here though. On the LWN article about this someone mentioned that there are also Big Endian oscilloscopes that are used with X remoting and I suspect there are other industrial appliances too. Personally I think with X11 more or less in maintenance mode for decades to come the likelihood of new bugs in this area is somewhat low even with few users. Together with X and especially X remoting becoming more and more a niche thing itself keeping those niches where it is still needed working out of the box is a worthwhile effort. But in the end I'm not an expert on this and I'll trust the judgement of the experts.
Thanks, Niklas
On Tue, 31 Jan 2023 at 03:37, Niklas Schnelle schnelle@linux.ibm.com wrote:
On Thu, 2023-01-19 at 19:46 +1000, Peter Hutterer wrote:
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@redhat.com
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@who-t.net 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
Thanks for opening the BZs and creating these settings. So, this means at least our use case of SSH terminals with the occasional X client and/or copy & paste via X at least has a workaround. I'm still skeptical of the cost to benefit ratio here though. On the LWN article about this someone mentioned that there are also Big Endian oscilloscopes that are used with X remoting and I suspect there are
I expect there is a 'lot(*1*)' of industrial hardware with a 40-50 year lifetime built from Sparc, Power and similar big-endian chips. The majority of them are usually tied into a system which is also running a 10+ year old OS because various associated binaries were last built in 2009 or so. The code even if it is available will end up being 'uncompilable(*2*)' because it is built around K&R C, Prolog, or some other language which isn't seeing a lot of work these days.
*1* A lot is probably in the order of a couple thousand or so around the world. There are at least 150k Fedora workstations in use around the world at any time. There are at least an equivalent number of Ubuntu desktop users. The people who need to talk to those industrial systems can make it work. *2* without some amount of work by someone who knows the language and tasks the code was meant to follow.
other industrial appliances too. Personally I think with X11 more or less in maintenance mode for decades to come the likelihood of new bugs
The issue isn't that there are 'new' bugs but existing ones which we have papered over or just assumed were part and parcel of the system. There are a lot of 'well it just causes the X server to crash so just firewall it' which have for years accepted only to become a firebomb when a compiler or associated library change makes it a 'oh you don't crash anymore but now give root access to the user's system.'
The issue is also because it is in 'maintenance' mode. Due to people retiring, dieing, etc we are going to have less and less programmers who know the code in order to fix it if it turns out there is an issue. Just like you should turn off a nuclear reactor before you leave, you shouldn't leave code which you no longer trust blindly open.
in this area is somewhat low even with few users. Together with X and especially X remoting becoming more and more a niche thing itself keeping those niches where it is still needed working out of the box is a worthwhile effort. But in the end I'm not an expert on this and I'll trust the judgement of the experts.
Thanks, Niklas
Am 21.12.2022 um 22:49 schrieb Ben Cotton bcotton@redhat.com:
Users with X server and client on two different machines must add the `xorg.conf.d` snippet shown above on affected systems.
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?
(Unfortunately, we have too many undocumented (or at any rate factually invisibly documented) features in our distro )
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy pboy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora docs team contributor and board member Java developer and enthusiast
Hi
On Thu, Dec 22, 2022 at 9:45 AM Peter Boy pboy@uni-bremen.de 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
Dne 22. 12. 22 v 9:56 Olivier Fourdan napsal(a):
Hi
On Thu, Dec 22, 2022 at 9:45 AM Peter Boy pboy@uni-bremen.de 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“.
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 ....
Just saying. I don't think there is a chance I'll hit this in real life.
Vít
(Unfortunately, we have too many undocumented (or at any rate factually invisibly documented) features in our distro )
Cheers Olivier _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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".
Björn Persson
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.
Cheers, Peter
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.
Dave
Am 29.12.2022 um 16:29 schrieb David Malcolm dmalcolm@redhat.com:
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.
I would also strongly advocate / asking to make the (error) message more detailed. So don't just make it "byte-swapped" but refer to the configurability , even if it's just a "see <file>.conf“.
Especially if something has worked before, this is very important.
-- Peter Boy https://fedoraproject.org/wiki/User:Pboy pboy@fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member Fedora docs team contributor Java developer and enthusiast
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.
Thanks, Niklas Schnelle
On Thu, Dec 22, 2022 at 5:30 AM Niklas Schnelle schnelle@linux.ibm.com 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?
regardless of architecture?
-- 真実はいつも一つ！/ Always, there's only one truth!
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@linux.ibm.com 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 :)
Cheers, Peter
On Wed, Dec 28, 2022 at 10:13 PM Peter Hutterer peter.hutterer@who-t.net 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@linux.ibm.com 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? 🙏
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@who-t.net 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@linux.ibm.com 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].
Cheers, Peter
On Thu, Dec 29, 2022 at 1:10 AM Peter Hutterer peter.hutterer@who-t.net wrote:
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@who-t.net 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@linux.ibm.com 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].
So in effect we do this, because things like waypipe won't function properly when transmitting across systems of differing endianness?
On 12/29/22 08:06, Neal Gompa wrote:
On Thu, Dec 29, 2022 at 1:10 AM Peter Hutterer peter.hutterer@who-t.net wrote:
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@who-t.net 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@linux.ibm.com 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].
So in effect we do this, because things like waypipe won't function properly when transmitting across systems of differing endianness?
Waypipe would need to translate the endianness of messages as needed.
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.
On 12/22/22 10:24, Elizabeth K. Joseph wrote:
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?
It certainly would, but there is another factor: Input validation bugs that would only be out-of-bounds reads with swapping disabled can easily turn into out-of-bounds writes with swapping enabled. The former is an information leak, but the latter can be exploited for code execution.
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.
Fuzzing the X server’s byte-swapping and input validation routines would be a good place to start.
On Thu, 22 Dec 2022 at 10:24, Elizabeth K. Joseph lyz@princessleia.com wrote:
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.
The people I learned coding and how to break code in the 80's always looked at byte-swapping in any project for problems. Most of the code was usually cargo culted from other projects or some sci.comp newsgroup. It might work but it would usually then be plastered in with fragile code or you would find that something 3 or 4 layers up broke.
Currently there is only one byte-swapped architecture which Fedora runs on. There are about 82 Fedora instances on it and ~900 instances using EPEL. However, I think this request is coming more from the current maintainers of X. They also do not have ready access to byte-swapped systems so have no way to say 'oh this works' or not. I think X and other code fixed to deal with byte-swapping is going to need focus as I expect this change will 'filter' into other operating systems over time.
On Thu, Dec 22, 2022 at 11:30:33AM +0100, Niklas Schnelle 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.
One main question here is: how many of you use Wayland already? Right now the biggest issue with this change is IMO the inability to configure this for Wayland compositors until they add the respective option. Xorg is easy to fix with an xorg.conf snippet, but you don't necessarily have access to how Xwayland is started (mutter certainly is hard-coded).
Cheers, Peter
On 12/21/22 13:49, Ben Cotton wrote:
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.
There is a technological solution which eradicates the byte-swapped attack surface. All existing byte-swapping bugs (known and unknown) are fixed, and all future byte-swapping bugs are prevented.
In C++, re-code each 'struct' by using a typedef for each member that can suffer byte-swapping. Create a template for each struct containing such members, where the typedefs for members are template parameters for the templated struct. Create a template for each function which uses such structs, again with the typedefs as template parameters (possibly subsumed inside other templated objects.) When the X server accepts a connection from a client of different endian-ness, then automatic template instantiation and matching by the C++ compiler will invoke the correct top-level function(s), which will invoke the correct lower-level functions.
An example is https://github.com/upx/upx/blob/devel/src/p_mach.h and p_mach.cpp, which handles both width (32 vs 64) and endian-ness for processing any Mach-O executable by the UPX program compressor running on any machine (same or different width and endian-ness).
A years-earlier "by-hand" example of related coding in plain-C is scripts/recordmcount.c in the source code for Linux kernel.
On Thu, Dec 29, 2022 at 11:27:01AM -0800, John Reiser wrote:
On 12/21/22 13:49, Ben Cotton wrote:
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.
There is a technological solution which eradicates the byte-swapped attack surface. All existing byte-swapping bugs (known and unknown) are fixed, and all future byte-swapping bugs are prevented.
In C++, re-code each 'struct' by using a typedef for each member that can suffer byte-swapping. Create a template for each struct containing such members, where the typedefs for members are template parameters for the templated struct. Create a template for each function which uses such structs, again with the typedefs as template parameters (possibly subsumed inside other templated objects.) When the X server accepts a connection from a client of different endian-ness, then automatic template instantiation and matching by the C++ compiler will invoke the correct top-level function(s), which will invoke the correct lower-level functions.
An example is https://github.com/upx/upx/blob/devel/src/p_mach.h and p_mach.cpp, which handles both width (32 vs 64) and endian-ness for processing any Mach-O executable by the UPX program compressor running on any machine (same or different width and endian-ness).
A years-earlier "by-hand" example of related coding in plain-C is scripts/recordmcount.c in the source code for Linux kernel.
Interesting approach, but the X server is written in C, introducing C++ is not going to happen in a project that's in maintenance mode. Even if anyone could find the time to do it and figure out how to test all the changes afterwards.
It's not all structs either (and there's *a lot* of thos, probably well over 1000), sometimes it's something like this:
struct XSomething *foo; uint32_t len = (uint32_t*)(foo + 1);
and other similar approaches. Which means not every 16/32 bit number is part of a struct.
Cheers, Peter
On 12/29/22 20:27, John Reiser wrote:
A years-earlier "by-hand" example of related coding in plain-C is scripts/recordmcount.c in the source code for Linux kernel.
Yep, functions like htonl have been in use in C for decades. It is sad to see this standardization to little-endian (e.g. ppc64->ppc64le), which weakens the ability to code things right because everything works in the majority of the machines. I would have personally preferred the world to go to big-endian, since it makes memory dumps much more readable and int size errors very fatally evident. Instead, I would expect somebody to soon propose switching the IP protocol to little endian "because, hey, the rest of the world is little-endian, right?".
regards. Best
On Wed, Dec 21, 2022 at 04:49:17PM -0500, Ben Cotton wrote:
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,
I doubt this part is true. Have you measured it? Anyway I use this all the time (though not with different endianness).
- 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).
I guess this affects something like x86 server running a client on s390x (which is very rare indeed).
Rich.
-
Ben Cotton -
Björn Persson -
David Cantrell -
David Malcolm -
Demi Marie Obenour -
Elizabeth K. Joseph -
John Reiser -
Neal Gompa -
Niklas Schnelle -
Olivier Fourdan -
Peter Boy -
Peter Hutterer -
Richard W.M. Jones -
Roberto Ragusa -
Stephen Smoogen -
Vít Ondruch