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

[lowflyer]

I think you should remove the network drivers too.

Attack surface is much lower with no internet connection.

Correct!

[Weasel]

You keep on mentioning wine throughout all your posts. Wouldn't it be even a much bigger step in the direction of "reducing the attack surface" to remove wine? Even in combination with removing the 32-bit translation layer?

I think you should remove the network drivers too.

Attack surface is much lower with no internet connection.

[oiaohm]

You keep on mentioning wine throughout all your posts. Wouldn't it be even a much bigger step in the direction of "reducing the attack surface" to remove wine? Even in combination with removing the 32-bit translation layer?

I keep on mentioning wine because those developers have done the most research in this area on what is possible.

https://github.com/AndreRH/hangover

hangover development using emulator to do 32 bit and 16 bit means even if the 32 bit translation layer is removed wine in future will still be able to work. Would this improve security stopping doing 32 bit and 16 bit protected mode with OS kernel yes it would.

Also hangover is interesting because you have 32 bit and 16 bit applications using native 64 bit libraries. Yes this 32 bit and 16 bit use 64 bit libraries is worked on being done in mainline wine using 32 bit and 16 bit kernel provided protected mode as well.

There are lot of special code in the Linux kernel to prevent the 16 bit protected mode ESP issue so wine can use 16 bit protected mode. There are other works around like this for 32 bit on 64 bit as well.

1)Remember old 32 bit games can find new CPU too fast so emulation to slow old games and old software down could be a good thing or they need Odd cpu instructions that are missing from modern CPUs for some reason..
2)Wine route not needing to duplicate as much of the runtime due to allowing 32 and 16 bit to use parts of the 64 bit runtime instead of having their own 32 and 16 bit runtime.

lowflyer there is a serous question we need to answer.
Going forwards do we need 32 bit support in the 64 bit Linux kernel?

Part of answering the question is working out what 32 bit applications users are really using and seeing if they will run better in emulation with the emulation replacing 32 bit library usage with 64 bit libraries.

Remember saying no 32 bit support in the Linux kernel does not mean you cannot use emulation or other means to restore 32 bit support while remaining in user-space.

lowflyer basically we are at the start of this problem. There is known security problems doing bridges in kernel space.

Hangover on x86_64 bit with wine is seeing how far with emulation of 32 bit windows applications with 64 bit library replacement can go. Of course nothing says something like wine hangover cannot be made for 32 bit Linux applications.

32 bit Linux applications in most cases are likely to be poorly maintained as well so lower the privilege you can get away to run them the better..

[lowflyer]

No that describes you. The write up is wrong. LKML patch disabled 32 bit syscalls in kernel did not disable 32 bit protected mode so it half disables 32 bit processes not totally. Did it disable all the 32 bit layer answer is no it did not. This is also why your counter argument makes no sense because you are talking about disabling more than what was. You have been stuck inside the box of what Micheal wrote not what has in fact been done in the Linux kernel.

Also you have overlooked that you can implement Linux syscalls in userspace. So it fully possible to reverse the current patch with a user space program on Linux just no body has written that yet. There is a debate if option to be added to fully disable 32 bit protected mode.

lowflyer it simple to forget wine gets into 16 bit protected mode under LInux with the wine loader. The syscalls wine uses to setup protected modes is little different to your normal Linux ELF loaders. Turn off the normal way ELF loaders get to 32 bit under Linux does not mean you have turned it all off.

There is another question of course that has not been explored X32 ABI that has 32 bit addressing while in 64 bit protected mode. This is another area that has not been explored fully is loading 32 bit ELF inside 64 bit ELF programs.

Next thing note that the write up said disable of x86 32 bit processors at boot time. Has it been possible to build a 64 bit Linux kernel with no 32 bit support since the first 64 bit Linux kernel the answer is yes "CONFIG_IA32_EMULATION" disabled does it you cannot change that with a boot loader flag. The change is allowing to change the "CONFIG_IA32_EMULATION" state in the linux kernel command line you can alter at the boot loader.

You keep on mentioning wine throughout all your posts. Wouldn't it be even a much bigger step in the direction of "reducing the attack surface" to remove wine? Even in combination with removing the 32-bit translation layer?

[oiaohm]

I see that you have a *VERY STRONG* opinion on a detail and that literally nothing on this planet can convince you to think a little bit outside of that box.

No that describes you. The write up is wrong. LKML patch disabled 32 bit syscalls in kernel did not disable 32 bit protected mode so it half disables 32 bit processes not totally. Did it disable all the 32 bit layer answer is no it did not. This is also why your counter argument makes no sense because you are talking about disabling more than what was. You have been stuck inside the box of what Micheal wrote not what has in fact been done in the Linux kernel.

Also you have overlooked that you can implement Linux syscalls in userspace. So it fully possible to reverse the current patch with a user space program on Linux just no body has written that yet. There is a debate if option to be added to fully disable 32 bit protected mode.

lowflyer it simple to forget wine gets into 16 bit protected mode under LInux with the wine loader. The syscalls wine uses to setup protected modes is little different to your normal Linux ELF loaders. Turn off the normal way ELF loaders get to 32 bit under Linux does not mean you have turned it all off.

There is another question of course that has not been explored X32 ABI that has 32 bit addressing while in 64 bit protected mode. This is another area that has not been explored fully is loading 32 bit ELF inside 64 bit ELF programs.

Next thing note that the write up said disable of x86 32 bit processors at boot time. Has it been possible to build a 64 bit Linux kernel with no 32 bit support since the first 64 bit Linux kernel the answer is yes "CONFIG_IA32_EMULATION" disabled does it you cannot change that with a boot loader flag. The change is allowing to change the "CONFIG_IA32_EMULATION" state in the linux kernel command line you can alter at the boot loader.

[lowflyer]

lowflyer your counter argument makes no sense ...

Your overflowing argumentation made me provide a very cynical argument.

I see that you have a *VERY STRONG* opinion on a detail and that literally nothing on this planet can convince you to think a little bit outside of that box.

[oiaohm]

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

The bridging issue is why Intel is proposing x86-S to have start up in 64 bit mode. Yes remember you x86 start up goes. 16 bit to 32 bit to 64 bit or 16 bit to 64 bit and possible back again quite a few times this has been the source of quite a few x86 firmware issues.

If the system has started up in 128 bit it kind of impossible to boot with 128 bit layer disabled. Yes 128bit risc-v start-up in 128bit. Modern 64 bit arm cores start up in 64 bit.

Remember when I said when you bridge between bit widths 99% of the problems remain the same.

Here a question do syscalls have to be implemented in the Linux kernel?

https://www.kernel.org/doc/html/latest/admin-guide/syscall-user-dispatch.html

The answer is no they don't have to be implemented in the Linux kernel.

Yes the framework exists for linux userspace code to put back 32 bit syscalls.

lowflyer your counter argument makes no sense. The Linux kernel only having the platform native bit-width syscalls in kernel space makes sense. Particularly since the Linux kernel support implementing non native to kernel syscalls in userspace. Yes you can implemented windows syscalls on Linux using user space code that syscall-user dispatch does not care if the syscalls are Linux or not. There is a little bit of overhead using the syscall user dispatch over having in kernel bridge but there is security advantage.

Think about if it the syscall bridge is implemented in the elf loader of the executable the syscall bridge is running at the same privilege as the application so a bug in the syscall bridge cannot access kernel memory and cannot cause a privilege exploit to allow the application to run with higher privilege.

lowflyer the question "where should syscall bridge be implemented?" Linux kernel gives you two options where it can be implemented. Kernel space and User space we have only ever fully implemented out the kernel space bridge stuff and had on going issues.

Please note the wine split between PE and ELF work is so that the PE section can seen windows syscalls and the ELF section sees Linux syscalls and that closes off a historic way to detect wine that some malware used.

[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.

[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]

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.