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@xxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
