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

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

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]

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]

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]

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

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

[lowflyer]

I think you should remove the network drivers too.

Attack surface is much lower with no internet connection.

Correct!