[HN Gopher] X servers no longer allow byte-swapped clients
___________________________________________________________________
X servers no longer allow byte-swapped clients
Author : pabs3
Score : 51 points
Date : 2023-01-06 05:24 UTC (1 days ago)
(HTM) web link (who-t.blogspot.com)
(TXT) w3m dump (who-t.blogspot.com)
| mannyv wrote:
| This is amusing because network byte order is big endian.
|
| The title should say 'no longer allows big endian clients.' Or
| does it deny all byte swapped clients ie if the server is big
| endian it disallows little endian clients?
| Gibbon1 wrote:
| Only legacy protocols should be big endian at this point
| though.
| mjg59 wrote:
| The latter.
| Karellen wrote:
| As it says in TFA:
|
| > So to this day whenever a client connects, the first byte it
| sends is a literal "l" or "B" to inform the server of the
| client's byte order. Where the byte order doesn't match the X
| server's byte order, the client is a "swapped client" in X
| server terminology
|
| So it's wherever the client doesn't match the server, which
| ever way around that is.
| hulitu wrote:
| It is a bug in Xwayland. Theoretically the rest of the world is
| not affected. Apparently some people think that breaking
| compatibilty is the way to go.
| jmclnx wrote:
| Yes, seems these days nothing exists but Linux. Almost like the
| old Microsoft days. Being on a BSD this annoys me. Seems this
| could be yet another thing that will prevent Wayland from
| running on anything but Linux on x86 type systems.
|
| But I have no plans to ever use Wayland until they get Network
| Transparency anyway, so as far as I am concerned it is not a
| huge deal for me (yet). So I will annoy the developers :)
|
| Yes, I do understand the Wayland people are working hard and I
| appreciate their work, but I wish they would make Wayland
| easily portable to other UN*X Systems.
| bitwize wrote:
| Waypipe is a thing.
| bitwize wrote:
| No one wants to maintain backward compatibility for decades
| with computer architectures no one actually uses anymore. There
| are more innovative, exciting things to work on.
|
| Big endian is so dead, you can literally design a binary
| network protocol that has all fields 64-bit aligned, little
| endian, slurp the packets into a buffer, cast the buffer to a
| struct, and be fine across ALL architectures you'll likely run
| in production.
|
| This, by the way, is why X11 itself is slowly bit-rotting into
| irrelevance also: no one wants to maintain it. Most of the
| protocol exists strictly for legacy applications -- modern ones
| use the X server as a framebuffer compositor and that's it.
| CJefferson wrote:
| It's really hard to test big-endian software -- because almost
| no-one (and in particular no devs) really run big-endian CPUs
| anymore.
|
| There are a few programs I work on where we "officially"
| disabled big-endian support, because it's just impossible to
| find devs to work on it. It's also hard to test, you can't test
| it on github actions for example.
|
| I'd be happy to see some people step up for testing big-endian,
| but at the moment it would be a huge time-sink for many
| projects, when it's not even clear if there are any users.
| tyingq wrote:
| ARM has selectable endianess, but it's difficult to find an
| OS that will run big endian ARM in any sort of out-of-the-box
| way.
|
| The simplest one I could find is netbsd, which can run big-
| endian on an Rpi3 and some other boards.
|
| https://wiki.netbsd.org/ports/evbarm/ (see the earmv7hfeb
| note)
| josefx wrote:
| > because almost no-one (and in particular no devs) really
| run big-endian CPUs anymore
|
| It is a network protocol, just put a proxy between client and
| server that byte swaps the affected fields and changes the
| endian flag. No need for hardware.
| cbmuser wrote:
| Debian and Gentoo still provide current installation images
| for various big-endian architectures such as hppa, m68k,
| ppc32, ppc64 and sparc64.
| chupasaurus wrote:
| > hppa, m68k, ppc32, ppc64 and sparc64
|
| None of which are supported officially by Debian, with
| notable exception of ppc64el (POWER8/9 little-endian). The
| only official port with big-endian is s390x. [0]
|
| [0] https://wiki.debian.org/SupportedArchitectures
| asveikau wrote:
| One approach I've seen to writing big endian safe software is
| to not load integers directly, and apply the same logic
| regardless of endianness.
|
| Eg. Instead of: uint16_t x;
| #ifdef BIG_ENDIAN x = swap(*p); #else
| x = *p; #endif
|
| You can write: uint16_t x;
| unsigned char *q = (unsigned char*)p; x = q[0] |
| (((uint16_t)q[1]) << 8);
|
| (Pardon the rushed job of writing C in an HN form on mobile.)
|
| This exercises the same deserialization from little endian
| regardless of the hardware representation of integers. This
| means you are testing how it will act on big endian even when
| running on little endian.
| uluyol wrote:
| This works when your serialization format is designed to be
| either big or little endian. But for some programs, the
| serialization format is memcpy the structure to disk. This
| isn't a good strategy, but unfortunately it can be
| difficult to undo historical choices.
|
| So the padding, alignment, endianness, all leak. And it
| sounds like X does something like this: clients expect the
| endianness of serialized data to match the local machine
| and the server can optionally account for this.
| zzo38computer wrote:
| Code like that second one (using shifts) is generally what
| I do always (dealing with small-endian, big-endian, or PDP-
| endian data), anyways. Hopefully, the compiler will be able
| to optimize the code so that it works like the first one.
| (I don't know if the compiler actually does optimize it or
| not, though. However, it seems to me that a code like that
| should be common enough that it would make sense to
| implement such an optimization.)
| plorkyeran wrote:
| The problem is that it's hard to be certain that you
| actually did it correctly everywhere if you aren't testing
| it. Writing endian-neutral code isn't terribly difficult,
| but you can easily accidentally write endian-dependent code
| here and there.
| nine_k wrote:
| What big-endian hardware worth mentioning exists now, if we
| exclude historical hardware which we maybe want to keep up,
| but which is not produced any more?
|
| Asking unironically.
| TillE wrote:
| It's annoying that some file formats (and of course
| protocols) are still using big endian. Otherwise yes, the
| world has effectively standardized on little endian, it's
| fine to let big endian die outside of some weird niches.
| throw0101c wrote:
| QEMU?
| asveikau wrote:
| The article suggests it's Xorg server too, not just XWayland.
| Can anyone confirm?
| erlkonig wrote:
| At more centrally-administered sites, a user might not even
| have the ability to change an X server option. The idea of
| making a toggle via xset sort-of makes sense, but seriously,
| isn't the idea generally that you trust the apps you're running
| anyway. And doesn't a _vastly_ different wrong number in some X
| call at least produce an effect that makes you aware of the
| problem (I know, that doesn 't make a X server more stable...).
| It's just baffling to make something near-universally available
| less so. The next new CPU thing _could_ be bigendian - or
| quantum, but who knows what byte order _that_ would prefer.
| eikenberry wrote:
| > but seriously, isn't the idea generally that you trust the
| apps you're running anyway
|
| Yes, and it is a bad idea. Trusting your apps is how we've
| gotten in the state we are today with virus scanners and the
| like. Generally you want to trust as little as possible (at
| least in tech).
| sprash wrote:
| > the state we are today with virus scanners and the like.
| Generally you want to trust as little as possible
|
| This is only true if you run closed source software on non-
| free systems. I honestly can't remember that I ever had to
| use a virus scanner on Linux or UNIX.
| Karellen wrote:
| ...by default.
|
| It's still available as a setting in `xorg.conf`, or on the
| command line.
___________________________________________________________________
(page generated 2023-01-07 23:01 UTC)