On 12/29/22 08:06, Neal Gompa wrote:
On Thu, Dec 29, 2022 at 1:10 AM Peter Hutterer
<peter.hutterer(a)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(a)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(a)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.
--
Sincerely,
Demi Marie Obenour (she/her/hers)