Linux Patches Posted That Would Allow Boot-Time Disabling Of x86 32-bit Processes

[avis]

Are you sure? It seems a secondary nickname of someone that is another Apple fanboy.

Does not having a single Apple device in my entire life count as being a fanboy?

Or is admitting that the company has two freaking billion client devices (which is a hundred times more than the number of desktop Linux users combined) an important thing to maybe give light to?

Hey, aren't you here to support Open Source standards? Then what about Google rejecting to support JPEG-XL? How does it feel to you? And maybe Apple supporting it will finally persuade Google to support it as well? Didn't that occur to you, no? Nah, what am I thinking. That's too difficult to think through.

Phoronix and grave insults from Open Source fans. Name a more iconic duo.

[PluMGMK]

So wait a sec… Disabling 32-bit syscalls is a separate change from disallowing 32-bit code segments? So what happens if someone loads a 32-bit process successfully but syscalls are unavailable? :/

[oiaohm]

There is plenty of legacy software which will never be recompiled for 64-bit architectures. What will we do if this becomes the default? Run them through a 32-bit emulator? Probably this won't be the default for end-user desktops. Workstations and servers would be fine.

https://lore.kernel.org/lkml/87a5xbjpk2.ffs@tglx/

Fact is that today a 64bit application can do a far jump of far call
into a 32bit code segment based on the default descriptors or by setting
them up via LDT. That 32bit code obviously can't do compat syscalls if
IA32_EMULATION is disabled, but other than that it just works.

This is not as straight forwards and one would think.

Winehq work with hangover/PE could see wine get to the point it not using any 32 bit syscalls but is using 32 bit segments.

[oiaohm]

So wait a sec… Disabling 32-bit syscalls is a separate change from disallowing 32-bit code segments? So what happens if someone loads a 32-bit process successfully but syscalls are unavailable? :/

Its more complex than that. Nothing say you cannot have a 64 bit loader loading 32 bit application that is thunking to 64 bit libc and other libraries.

Very few programs in fact use linux syscalls directly most use syscalls by glibc/other libc wrappers.

Yes you are right 32 bit segments and 32 bit syscalls are different things. 32 bit process loaded by a 64 bit loader that able to setup thunking to 64 bit syscalls and 64 bit libraries could be outcome long term. Of course research into doing stuff like this will not be done while the simple route of 32-bit syscalls exist all the time.

[qlum]

I don't buy this as "attack surface reduction" in this particular form. But I do believe it's a good switch to use on fleet test machines to make sure an enterprise's software deployments are truly 64 bit clean, and not just pseudo-64 bit. It's the case in some commercial software offerings that the main program is 64 bit, but some of the subordinate programs may not be for whatever reason. It's a first baby step towards removing obsolete technology, but by itself doesn't really move the needle on reducing attack surface.

The reason I don't believe simply flipping a switch at boot will have a practical effect on security surface is because attackers won't really care if you have 32 bit process support or not. There's already a lot of low lying fruit to exploit on most Linux boxes to begin with, starting with a company's own staff. Much Unix malware uses installed onboard interpreters (Python, shell: Bash on Linux, zsh on Mac, Perl, the three interpreters nearly guaranteed to exist on any Unix-like box) anyway so neither endianess nor 32 v. 64 bit environment really matter. If it does matter, then they'll be using stand-alone targeted environment pre-compiled packages. Once one has account access it's trivial to tailor attacks by just checking version numbers versus available features. "Living off the land" is already a big thing with Linux exploitation.

All of that said, there's also no reason not to give admins another tool for whatever reason they see fit to use it for. It won't have a practical effect on security posture in either direction, imo. But it may have an effect on resource utilization, especially in an academic environment where students often bring their own games to play where they aren't supposed to. Disabling 32 bit support entirely will block students from playing old commercial games on school hardware in which they bring their own support libraries with them. Course, it won't do a thing to stop modern games that are already 64 bit clean. I remember Doom, RoTT, Duke Nukem 3D, and Roger Wilco being installed on nearly every computer that could support it in college back in the day, including Doom and cbzone (a Battle Zone Unix clone) being on several high end Unix workstations back in the day. Big time waster! I imagine most students will just pull out their own personal laptop or phone and play whatever, but there's always that alure to try to see what the experience of playing $GAME on a $10k workstation or a $200 million HPC cluster with visualization console. "Yes... but does it run QuakeRTX?!"

I feel like it does have potential to reduce the attack surface, sure a lot of systems may have easier entry points, but since attention moved away from 32bit with less maintenance bugs may slip in or are never noticed, so being able to shut down a vector for a potential future zeroday definitely has benefits for the more security aware applications. Especially if non of it's software benefits from having 32bit enabled.

[caligula]

does this means that x32 programs won't run at all with this option?

You probably mean x86. x32 is a special abi. Clueless Windows users typically think x32 must be the name of the old stuff because x64 exists.

[tildearrow]

Wow, so rude. avis is a newcomer, has never been here at all prior to December 2022, doesn't even know anything about our commenting style, or how to troll on this forum.

Old timers like you and me need to be more welcoming to complete newbies like avis

You do realize avis is birdie, right?

[partcyborg]

The same as with disabling the benzine engine on a hybrid car: you get less functionality at the cost of flipping a switch. Next step: disable x86_64 functionality and get even less attack surface and functionality.

What hybrid car has a benzine engine? That would be REALLY dangerous to fill at the pump!

[ferry]

Wow, so rude. avis is a newcomer, has never been here at all prior to December 2022, doesn't even know anything about our commenting style, or how to troll on this forum.

Old timers like you and me need to be more welcoming to complete newbies like avis

In that case: my sincere apologies.

[Anux]

You do realize avis is birdie, right?

I thought it was pure sarcasm. There are not too many Linux and open source hating trolls on this forum and the style of his "arguments" is pretty unique.