Linux Developers Consider Retiring The x32 ABI (phoronix.com) 41
The Linux kernel mailing list has a new patch proposing the retirement of the x32 ABI, reports Phoronix:
The Linux x32 ABI for x86_64 processors allow making use of the full 64-bit register file and wide data path but retaining 32-bit pointers to provide for a smaller memory footprint when not needing 64-bit pointers. Linux x32 came to the party late and didn't enjoy much adoption over the years and is now looking at possible removal from the Linux kernel. The x32 code was a nice concept for helping lower memory footprint requirements while otherwise making use of the x86_64 capabilities, but with its limited adoption and x86_64 simply being the de facto standard these days, Linux kernel developers are looking at phasing out the x32 ABI. The x32 ABI was added in Linux 3.4 back in 2012 plus also required updated compiler support too.
The proposed patch argues "there is practically no real use for x32," noting that some Linux vendors (like Debian) already disable x32 by default to reduce attack surfaces. "Should nothing happen within the next half year, lets remove code bits around August after the summer break."
Discussions about dropping x32 support first started in 2018...
The proposed patch argues "there is practically no real use for x32," noting that some Linux vendors (like Debian) already disable x32 by default to reduce attack surfaces. "Should nothing happen within the next half year, lets remove code bits around August after the summer break."
Discussions about dropping x32 support first started in 2018...
Fine (Score:4, Informative)
Re: (Score:2)
Re: (Score:3)
Well, the use case is clearly to produce binaries with smaller memory footprint. But *I* didn't even notice that Debian had disabled it.
Re: (Score:2)
Producing smaller memory footprint binaries is not the use case. The use case would be the reason why you need them in the first place. I can conjure up a theoretical embedded x86_64 system that is severely memory limited, but I'm not sure such a thing exists in the wild. And even then the use case would have to require not only the smaller memory footprint, which you can achieve with good ol' regular 32-bit x86 binaries, but also that you need the extended x86_64 instruction set, which makes the whole orde
Re:Fine (Score:4, Informative)
Someone on the email list said it can give a 6-8% performance boost because the pointers are half the size so you get better cache utilization. For some uses that's going to be a noticeable win.
That said, I've never heard of any software using it rather than just requiring a faster CPU.
Re: (Score:2)
Re: (Score:3)
This isn't 32bit support as much as it is x64 support for a 32bit application. It has virtually no use case and wasn't really adopted for anything. Anyone wanting to use x64 instructions just compiled x64 binaries. There was a thought that maybe creating 32bit binaries with the ability to access features of x64 CPUs would improve performance, but ultimately it didn't.
Going forward you'll still be able to run 32bit software. i686 != x32 The latter is an ABI no one used and the former isn't being removed.
Re: (Score:3)
There's 27 Microchannel token rings cards in the kernel. Let that sink in for a minute.
Which one rules them all? Oh, wait, you said "token" rings. :-)
Re: (Score:2)
Can we keep the Rust team busy with porting them?
We can't allow this to stand having MCA token ring drivers in C.
Re: (Score:2)
Token ring support was removed a good while ago.
Re: (Score:2)
There's a difference in support for individual hardware, and providing support for a whole ABI. The potential attack surface and the related code is much larger for the latter.
Just like the previous announcement quite a few people focused on the loss of a HAM radio interface card, but buried the lead that the kernel actually removed a whole networking API that this card depended on instead.
Re: (Score:2)
If you want to use this, or 386 builds or whatnot, you can use an old distro. Download them (they're free), and you can keep them forever.
Sure, if you want to run a system with hundreds of known vulnerabilities. Better keep it airgapped.
Re: (Score:2)
686 is the minimum processor for an x86_32 now. This is just a 64-to-32 translation layer that wound up basically not being used. The x86_32 arch is still there.
Re: (Score:2)
So if people are using it, there's no real reason to remove it. If some people don't want it in their version of the kernel, a compile flag works fine.
Re: (Score:2)
If people are not using it, then remove it. If people are using it, leave it in. If somehow it still bothers you (I don't know why), then you can add a compile flag so it is not in your particular kernel.
This is an outrage (Score:1)
What about Wine? (Score:3)
Without a real ABI-32 Wine will have to use an emulation layer if the processor can't run natively as a 32 bit process.
Now that Linux is getting a growing game player quota, there are gonna destroy a functionality that make that works?
Re: (Score:3)
i386 arch will be around in some form approximately forever. This was a weird hybrid model for lowmem amd64 devices.
Re: (Score:2)
Without a real ABI-32 Wine will have to use an emulation layer if the processor can't run natively as a 32 bit process.
Now that Linux is getting a growing game player quota, there are gonna destroy a functionality that make that works?
Since Windows never supported this unusual 32/64-bit hybrid, it will have no impact on WINE.
It's actually kind of a cool idea, though. To someone like me who grew up on 8-bit and 16-bit architectures and is regularly taken aback at the size of data structures on 64-bit platforms -- 16 bytes just for a pointer and a length? -- being able to cut those down while still being able to run at full speed [*] on modern hardware sounds really useful.
[*] Assuming it's really full speed. I suspect there's some o
Re: (Score:2)
Yea it's almost as if there's a 5th column in linux determined to make it; worse, remove the gpl so 'one company' people can pull an apple, Or just otherwise make people use windows.
Re: (Score:2)
This doesn't remove the ability to run 32bit processes. It removes the ability for a 32bit process (with 32bit pointers) to pretend it's a 64bit process. Virtually no one used this. x86 != x32. I'll bet you've never come across an x32 ARCH in the wild. No one is removing the x86 ABIs (at least not i686, some of the earlier ones are gone).
Will this affect older peripheral devices? (Score:2)
This may be a stupid question, but I'm sure all of us here have asked one or two.
Will the removal of x32 support affect any older peripheral devices? I ask because I have an old HP printer that no longer works in Windows 10 or 11 because there is no driver, but still works just fine in Linux.
To anyone wondering what this x32 ABI is... (Score:5, Informative)
To anyone wondering what this ABI is about, let's use 3 examples: the system call behind the time function, the one behind lseek64, and the one behind mmap.
On a pure 32-bit system, it's simple: time_t is 32-bit, so you can only get time from -2147483648 to 2147483647, which is from 1901-12-13 20:45:52 UTC to 2038-01-19 03:14:07 UTC (that's the 32-bit timepocalypse that's coming up); lseek64 is on the stack as two 32-bit halves; and mmap returns 32-bit addresses from 0000_0000 to 7FFF_FFFF or BFFF_FFFF, giving the whole process up to 2 GiB or 3 GiB of addressable memory. Anything that would make a process go over that limit returns an error.
On a pure 64-bit system, it's also simple: time_t is 64-bit, so you can get time from millions of years ago to millions of years in the future; lseek64 is in a 64-bit register; and mmap returns 64-bit addresses, currently from 0000_0000_0000 to FFFF_FFFF_FFFF with sign extension.
This x32 system is a 64-bit system with a 32-bit virtual address space. Like in 64-bit, your time_t is 64-bit, so you can get time from millions of years ago to millions of years in the future; lseek64 is in a 64-bit register; but mmap returns 32-bit addresses from 0000_0000 to 7FFF_FFFF or BFFF_FFFF, giving the whole process up to 2 GiB or 3 GiB of addressable memory, just like on 32-bit.
This necessitates a new kernel system call interface to get the parameters from 64-bit registers properly and enforce the 32-bit limit for addresses only. And in return, you can keep your virtual pointers shorter and use less memory to store those. Depending on how much data and pointers a process holds, that can save anywhere from practically nothing to about 20% RAM.
Few people are using this x32 ABI (though at least one user on Phoronix reports they're using x32 right now on an old laptop with 4 GB of RAM) because most processes are using either the pure 32-bit ABI (with 32-bit time_t, lseek64 on the stack and mmap) or the pure 64-bit ABI (with 64-bit time_t, lseek64 in a register and mmap). Multilib, Wine/Proton, etc. would switch between those two rather than x32 and will stay compatible even if this ABI is removed.
Re: (Score:2)
Re: (Score:2)
Yeah, and then a separate system call for "time64" would have to return the proper 64-bit value, in the same style as lseek64.
Re: (Score:2)
Sadly the situation is a lot more messy, likely due to some people in charge of the API/ABI seemed to have assumed by the time of Y2038, all 32-bit systems would have been retired.
https://blogs.gentoo.org/mgorn... [gentoo.org]
https://blogs.gentoo.org/mgorn... [gentoo.org]
They didn't create a time64_t. They set time_t to be 64-bit if you compile for 64-bit target.
Re: (Score:1)
The 2GB or 3GB per process addressable memory was a thing in 32bit kernels, the rest was reserved for the kernel. With a 64bit kernels, each 32bit process can use up to 4GB.
Re: (Score:2)
Thanks for adding this. I didn't actually know what 64-bit kernels did to get their own mappings in kernel mode after being entered through a syscall from a 32-bit application. It makes sense that a syscall would return the CPU to 64-bit mode right away and the virtual address space of a process could go all the way to FFFF_FFFF, if supported. Maybe 7FFF_FFFF if not.
Re: (Score:2)
The real problem is not the lack of native 64-bit hardware, but that most of our infrastructure is built with languages that won't let you use 64-values on 32-bit hardware unless you do all the bit-twiddling manually.
I mean, I thought to whole point of a compiler was to do the grunt work for you. A lot of this could have been fixed decades ago.
Re: (Score:2)
On many compilers, you can always declare a uint64_t or the equivalent type name in some language, and the basic operations work as intended even on 32-bit systems using multiword arithmetic: subtraction on halves with borrow, addition on halves with carry, long multiplication, long division (often with a subroutine), split bitwise operations, propagated shifts and so on. It's not always implemented, though, especially on 16-bit microcontrollers for which 32-bit is already a lot.
Other than embedded, would 32 get much use? (Score:2)
Then again, even embedded microcontrollers are increasingly 64-bit.
Late to the party as usual. (Score:2)
Great news, but they should have already retired it 3 years ago when the final amd64 ISA patents became unencumbered.
What happened to "Don't break userspace" (Score:1)
Clearly that rule will be broken if the x32 ABI is removed...
Linux is starting to look like Microsoft, they have a verrrry long list of software they dropped support for.
Re: (Score:2)
Apparently even Debian is supporting it (despite the summary): https://lore.kernel.org/lkml/a... [kernel.org]