This is the 405th issue of the World Wine News publication.
Its main goal is to inform you of what's going on around Wine. Wine is
an open source implementation of the Windows API on top of X and Unix.
Think of it as a Windows compatibility layer. Wine does not require
Microsoft Windows, as it is a completely alternative implementation
consisting of 100% Microsoft-free code, but it can optionally use native
system DLLs if they are available. Wine runs natively on #Linux #MacOS #FreeBSD and #Android operating systems.
Wine 2.0 Release Work
The past weeks have been relatively quiet without any fancy developments. Developers are focusing on bugfixes for the upcoming Wine 2.0 release. In late December Alexandre posted an update to the release plans to wine-devel :
Folks,
Since there was (understandably) very little activity this week, I'm going to skip today's release. I'll release rc4 next Friday; after that, there will probably be a couple more release candidates, since I'm hoping that we can make some more progress on bug fixing once people are back from the holidays. That will put the final 2.0 probably in the second half of January.
Happy New Year to everyone!
User mode instruction prevention
We were alerted to some potentially interesting development from the Linux Kernel developers: The Kernel will be making use of a new feature of Intel CPUs called User-Mode Instruction Prevention (UMIP) . It allows the kernel to disallow non-system code from using certain CPU instructions that expose low-level information that could be used in exploiting code execution vulnerabilities. With UMIP enabled these instructions will cause an exception, which the kernel can either forward to the application (which will then by default crash) or the kernel can handle it in more elaborate ways and e.g. return dummy values to the application.
Ricardo Neri asked which way Wine would prefer:
If running in protected mode, always propagate the GP fault to the user space via a sigsegv. If running in vm86 mode, trap the GP fault within the kernel and give the userspace fake values for the aforementioned resources (most likely zeros).
Also, UMIP will be able to be disabled via a kernel command-line parameter at boot.
I would like to inquire about the current use of these instructions and whether it would be catastrophic for wine to lose access to them.
Note: vm86 is what people would roughly call „DOS mode“. It is not used by Wine nowadays because we invoke DOSBox for real mode executables. It is used by DOSEMU to run DOS applications without CPU emulation. The Windows equivalent is called NT Virtual DOS Machine .
Alexandre said that there were Windows applications that called these instructions, and that Wine has the infrastructure to handle these new exceptions itself and give the applications approriate values. It would require users to update Wine when the feature is enabled in the kernel though.
Ricardo then proposed that the kernel itself could provide fake values. The most obvious value would be to set any returned pointer to NULL.
Alexandre was not entirely happy with this solution:
That wouldn't work, because we'd have no way of knowing that this was an attempted IDT access and not a normal null pointer. We rely on SIDT returning a unique address that we can recognize once we get an access violation fault for it.
Ricardo‘s then proposed a patch that returned the address of a dummy variable in the kernel. Wine could detect this is an access to the IDT and handle it as it saw fit. However, this would expose kernel information again :
Nak. This is a trivial KASLR bypass. Just give them hardcoded values. For x86_64, I would suggest 0xfffffffffffe0000 and 0xffffffffffff0000.
Using these hardcoded values that are guaranteed to point into kernel addresses and thus cause a recognizable fault when accessed that Wine can handle. From Wine‘s point of view it is as good as the real Interupt Descriptor Table address that the CPU would return without UMIP, so old Wine versions should continue to work with UMIP-enabled kernels.
Weekly AppDB/Bugzilla Status Changes
The past weeks have been relatively quiet without any fancy developments. Developers are focusing on bugfixes for the upcoming Wine 2.0 release. In late December Alexandre posted an update to the release plans to wine-devel :
Folks,
Since there was (understandably) very little activity this week, I'm going to skip today's release. I'll release rc4 next Friday; after that, there will probably be a couple more release candidates, since I'm hoping that we can make some more progress on bug fixing once people are back from the holidays. That will put the final 2.0 probably in the second half of January.
Happy New Year to everyone!
User mode instruction prevention
We were alerted to some potentially interesting development from the Linux Kernel developers: The Kernel will be making use of a new feature of Intel CPUs called User-Mode Instruction Prevention (UMIP) . It allows the kernel to disallow non-system code from using certain CPU instructions that expose low-level information that could be used in exploiting code execution vulnerabilities. With UMIP enabled these instructions will cause an exception, which the kernel can either forward to the application (which will then by default crash) or the kernel can handle it in more elaborate ways and e.g. return dummy values to the application.
Ricardo Neri asked which way Wine would prefer:
If running in protected mode, always propagate the GP fault to the user space via a sigsegv. If running in vm86 mode, trap the GP fault within the kernel and give the userspace fake values for the aforementioned resources (most likely zeros).
Also, UMIP will be able to be disabled via a kernel command-line parameter at boot.
I would like to inquire about the current use of these instructions and whether it would be catastrophic for wine to lose access to them.
Note: vm86 is what people would roughly call „DOS mode“. It is not used by Wine nowadays because we invoke DOSBox for real mode executables. It is used by DOSEMU to run DOS applications without CPU emulation. The Windows equivalent is called NT Virtual DOS Machine .
Alexandre said that there were Windows applications that called these instructions, and that Wine has the infrastructure to handle these new exceptions itself and give the applications approriate values. It would require users to update Wine when the feature is enabled in the kernel though.
Ricardo then proposed that the kernel itself could provide fake values. The most obvious value would be to set any returned pointer to NULL.
Alexandre was not entirely happy with this solution:
That wouldn't work, because we'd have no way of knowing that this was an attempted IDT access and not a normal null pointer. We rely on SIDT returning a unique address that we can recognize once we get an access violation fault for it.
Ricardo‘s then proposed a patch that returned the address of a dummy variable in the kernel. Wine could detect this is an access to the IDT and handle it as it saw fit. However, this would expose kernel information again :
Nak. This is a trivial KASLR bypass. Just give them hardcoded values. For x86_64, I would suggest 0xfffffffffffe0000 and 0xffffffffffff0000.
Using these hardcoded values that are guaranteed to point into kernel addresses and thus cause a recognizable fault when accessed that Wine can handle. From Wine‘s point of view it is as good as the real Interupt Descriptor Table address that the CPU would return without UMIP, so old Wine versions should continue to work with UMIP-enabled kernels.
Weekly AppDB/Bugzilla Status Changes
Full Article
Run Microsoft Windows Applications and Games on Mac, Linux or ChromeOS save up to 20% off CodeWeavers CrossOver+ today.
