On 12/29/22 08:06, Neal Gompa wrote: > On Thu, Dec 29, 2022 at 1:10 AM Peter Hutterer <peter.hutte...@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.hutte...@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 <schne...@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) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
