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

[loganj]

oiaohm thank you for explanation. the reason i ask about that is becuase there are a few older native games on steam that use 32b libs. so all those games will become unplayable.

[caligula]

oiaohm thank you for explanation. the reason i ask about that is becuase there are a few older native games on steam that use 32b libs. so all those games will become unplayable.

Not necessarily. You can always do full system emulation if the game is not too demanding. Also this mainly affects booting the system / host OS. Some games might be using some weird legacy features and might break.

[lowflyer]

Basically, the same rationale as when they disabled 16-bit LDT because they found an exploitable vulnerability in it,

So, what rationale exactly? "we do the same as last time" and then claim "we have reduced the attack surface" is window-dressing. Removing a 32bit function that calls a vulnerable kernel routine does not reduce the attack surface if the 64bit call to that function is still in the kernel. Well, you have perhaps reduced the number of clicks on CVE - but not improved anything.
Don't get me wrong. I'm all for simplifying code, lessen the maintenance burden and removal of complete subsystems if they are no longer in use. But calling this a "reduction of attack surface" is misleading at best.

[oiaohm]

oiaohm thank you for explanation. the reason i ask about that is becuase there are a few older native games on steam that use 32b libs. so all those games will become unplayable.

That could be short term issue. Take people using winevdm under windows to run 16 bit applications. Wine hangover is able to run 32 bit applications on 64 bit system without using any 32 bit syscalls.

[oiaohm]

So, what rationale exactly? "we do the same as last time" and then claim "we have reduced the attack surface" is window-dressing. Removing a 32bit function that calls a vulnerable kernel routine does not reduce the attack surface if the 64bit call to that function is still in the kernel. Well, you have perhaps reduced the number of clicks on CVE - but not improved anything.
Don't get me wrong. I'm all for simplifying code, lessen the maintenance burden and removal of complete subsystems if they are no longer in use. But calling this a "reduction of attack surface" is misleading at best.

No there is a good question that need to be asked.
Where should translation be done from 32 bit to 64 bit?
Yes we have 32 bit syscalls on 64 bit system that has 32bit to 64 bit done in kernel space. This conversion is a attack surface.

Is it possible to cross from 32 bit to 64 bit and back in linux userspace the answer is yes it is wine has been doing this from 32 bit protected mode to 16 bit protected mode and back for win16 application support. Same method can in fact been used from 64 bit mode to 32 bit mode. Wine implemented the 16 to 32 bit conversion in userspace. As much as possible PE work of wine in wine will also allow wine do do 32 to 64 bit and back so removing wine from needing 32 bit Linux libraries to run win16/win32 applications.

So 32bit to 64bit conversion where should it be.
Kernel space=errors can equal privilege exploits and other major problems due to possible allowing in kernel space memory alterations.
User space=truly less issues.

Like it or not disabling 32 bit syscalls as the current patch does is a attack surface in kernel space reduction with a major functionality drop.

For majority of 32 bit Linux applications out there they could be kept working with the 32bit syscalls turned off if someone makes up a new glibc that does the 32 bit to 64 bit syscall conversion in userspace. This could also be used to run X32 applications that don't run on most distribution kernels because the X32 syscalls are missing as well. Of course implemented syscall conversion in userspace will cost developer time.

Yes wacky would be allowing 16 bit Linux binaries as implementing conversion in user-space would allow..

[lowflyer]

Yes we have 32 bit syscalls on 64 bit system that has 32bit to 64 bit done in kernel space. This conversion is a attack surface.

While I'm completely on-board with your explanations about moving more code to user space, I think I did not explain myself good enough with the "attack surface".

As long as you define *everything that is in the kernel* as attack surface, your explanation is correct. But this is a very superficial view. A better definition of "attack surface" is "the sum of all exploitable code visible to the outside" (similar to this definition here: https://www.upguard.com/blog/attack-surface)

I expect the conversion layer within the kernel to be "thin". Meaning: "very little code". Removing this layer will only remove very little code and therefore only marginally reduce the attack surface. I'm not a kernel expert, so it would be interesting if somebody can come up with some actual numbers. To call that little gain a "reduction of the kernel attack surface" is a sham. It's like Bill Clinton saying: "I did not have sex with that women".

Some analogies to superficial attack surface reduction:
* Lock the door to the house but leave the garage door open.
* Block port 8080 but allow access to port 443.

One additional remark to moving code to user space: While it is good practice to do so, this is not a reduction of the attack surface. It is a reduction of the impact (gravity) - but the original attack surface is unchanged. It just reduces the risk by reducing the impact.

[oiaohm]

I expect the conversion layer within the kernel to be "thin". Meaning: "very little code". Removing this layer will only remove very little code and therefore only marginally reduce the attack surface.

https://bugzilla.redhat.com/show_bug.cgi?id=487255

https://lwn.net/Articles/406466/

This are just the ones I can find quickly. But there have been others.

Yes the conversion layer code in kernel is not that large. Yes that seccomp one is a good one person secured the 64 bit syscall number misses the 32 bit syscall number and now attacker can go straight around the intended restriction with a 32 bit application or a 64 bit application using 32 bit syscall.

lowflyer the issues with 32 bit syscalls and privillage exploits on 64bit kernels all go away for good by getting rid of 32 bit syscalls and doing the conversion in userspace. Yes this is the security filtering problem because the number of syscall to filter reduce removing the 32 bit syscalls or the memory translation issues.

32 bit to 64 bit wrapper in Linux kernel has been showing up in different CVE and different security exploits as repeating bad penny.

"the sum of all exploitable code visible to the outside"<< there are real world examples where privillage exploits have been possible all the ways cross the network because 32 bit to 64 bit conversion in Linux kernel is wrong. I was not using smaller define of attack surface reduction.

Moving from kernel space to userspace 32 bit call conversion does reduce the attack surface. Most attack surface reductions are what seam like marginal changes.

Big thing here is kernel code is very high privilege for what it can access. We do need to think about what needs to be in kernel particularly on items like 32 bit syscalls to 64 bit in kernel that have had CVEs. Yes trying the route without them 32 bit syscalls to evaluate what the cost is happens to be valid because there is attack surface reduction to be explored.

Of course the interesting point is when you are aware that 32 bit syscalls don't exist on all operating systems with 64 bit kernels that support 32 bit applications. So 32 bit syscalls is a optional feature to support 32 bit binaries. On Linux the other route of using userspace bridge from 32 bit to 64 bit has not been explored on how bad the cost is.

I can understand SUSE being behind adding a disable 32 bit syscalls there are enough historic CVE about problems in 32 to 64 with syscalls to justify looking for attack surface reduction here. Then add in userspace 32 to 64 bit has not been fully explored even that the functionality is in the Linux kernel.

https://sys.readthedocs.io/en/latest/doc/07_calling_system_calls.html

This next one is when you start going this is absolutely not great. Do note the manual assemble replication to the syscall function in glibc end up syscalling the Linux kernel twice instead of once using glibc and other Linux supporting libc solutions. This is another one that you have to raise the question should we break that. Also why it would be kind of useful to find out how programs are using the raw syscall function in the kernel.

[lowflyer]

This are just the ones I can find quickly. But there have been others.

These two issues are both older than 13 years.

The first issue is an issue with "syscall filtering" - not the conversion layer per se. A comment even states: "The impact is very limited because of the limited number of syscalls which can abuse this mix up.[...]".

The second issue goes back to a version 2.6 kernel.

You did you not find more recent issues because they have been fixed since.

Read both reports carefully. It's not always the wrapper to blame when "32 bit to 64" shows up in a CVE description. What you seem to refuse to do is an in-depth study of the given issue at hand. You unequivocally call for the removal of the 32-bit layer - and call that a huge reduction in attack surface.

Given your stubborn black-or-white approach, I suggest removing the 64-bit layer as well as this even removes a bigger attack surface.

[oiaohm]

These two issues are both older than 13 years.

https://nvd.nist.gov/vuln/detail/CVE-2018-1068

This is in 4.x kernel this.

This is another case of a glitch forming in the 64 bit to 32 bit leading to privilege exploit. There are many CVE like this lot take finding because description are not clear most of the when it the 32 to 64 bit wrapper layer. Yes there is a more recent one than 2018 in 2020 I cannot find at the moment. This has been a bad penny issue turning up ever 2 to 3 years..

The problem is Issues in the 32 bit to 64 bit wrapper having been turning up as CVE over and over again. Automated testing is not being able to find them before they get into the wild..

https://lwn.net/Articles/406466/

This write up in 2010 what are the hazards 32 bit to 64 bit syscalls conversion in kernel is still absolute true.

What you seem to refuse to do is an in-depth study of the given issue at hand.

No there was a very in-depth study in this area in 2010 it was decided to basically attempt to ignore it. Yes the LVM 2010 write up is the tip of it.

Then the same flaws as warned about by that 2010 write up have been turning up since.

lowflyer you are wanting to ignore this is not a new problem. At some point with a repeating problem something different has to be tried. Add option to disable 32 bit syscalls and do 32 bit syscalls to 64 bit syscalls stuff libc or the like(so its userspace of the process) was put forwards in 2010 on the linux kernel mailing list then it was not done.

The write up on Phoronix is wrong that it disables 32 bit processors the flag only disabled 32 bit syscalls. This does not prevent 32 bit protected memory segments from being made or used. So after the SUSE change 32 bit applications is possible but will require altered glibc to work again..

Given your stubborn black-or-white approach, I suggest removing the 64-bit layer as well as this even removes a bigger attack surface.

Maybe in future I would be suggesting the 64 bit syscall removal.

https://github.com/sysprog21/riscv-emu

riscv does have a 128 bit instruction set that you can use in fpga and emulator. Remember the bridging issue from 16 to 32, 32 to 64 and 64 to 128 have 99% the same set of issues.

lowflyer like it not someone need to try out the different solution for how to do bridging. Wine project with it userspace bridging of 16 to 32 and 32 to 64 has not had privilege exploits coming from the bridging instead they have had DOS as in program crashed. So there is a functional example that suggests attack surface can be reduced just we have not tried this route.

[lowflyer]

riscv does have a 128 bit instruction set that you can use in fpga and emulator. Remember the bridging issue from 16 to 32, 32 to 64 and 64 to 128 have 99% the same set of issues.

So it would be best if you already call for the removal of the 128-bit layer preemptively.