Announcement

Collapse
No announcement yet.

DOSBox 0.74-2 Released With Better Wine Compatibility, Linux OpenGL Fixes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by Weasel View Post
    Some people like oiaohm want to believe that it stops working, so they have an excuse to use when I tell them that Wine still supports 16-bit programs and it's not a CPU limitation (i.e. no need for emulation for 16-bit protected mode, only real mode). For the same reason he wants to believe that Microsoft APIs break their contracts left and right too. Just doesn't align with his beliefs, so he wants it to become true, but that's a different subject.
    No I have documentation on dx8 and other where microsoft breaks API/ABI. After 10 years of deprecated Microsoft does break compatibly. By the way UWP drops dx9 so it matter of time until windows 10 drops dx9.

    Originally posted by Weasel View Post
    Well, to not go into details, originally, they disabled 16-bit mode due to a vulnerability. It was just a temporary measure until the said vulnerability was fixed.
    Go into the fault. ESPFIX puts special handling around stack pointers when you context switch into protected mode 32 or 16 bit result was a information leak. At first it was only done for 32 bit. Please note ESPFIX was not required VIA x86-64 implementations because they don't have stack pointer miss handing in the cpu.. Both AMD and Intel have the fault. The stack fault causing information leak is related to why in long long mode on x86-64 cpu you don't have vm86 mode.

    If you had gone into effected cpus by the vulnerability you would have worked out that its a CPU defect. With Microsoft agreeing to drop win16 support ( so dropping need for 16 bit protected mode) at the same time they dropped dos support(vm86 mode) as well there was little pressure on Intel or Amd to fix the fault at CPU level.

    Yet you see attempts at microcode fix from Intel and AMD for espfix32 all the way back in 2002 that also shows the problem is not instruction set its cpu defect..

    By the way the 16 bit protected mode fix is more complex than the 32 bit version because it in fact patching more defects the 32 espfix is less complex because some of the defects around it are fixed by microcode in older cpus.

    Current LInux kernel runs on the presume on x86-64 that when switching to and from protected mode 16/32 that the cpu is broken and runs the software work around every single time so security flaw is sealed by software. /proc/sys/abi/ldt16 was a temporary stop gap while the information to exploit the protected mode 16 defect and a patch covering all the issues did not exist. Basically /proc/sys/abi/ldt16 allowed you to down grade your kernel security so you could still run like win16 applications in wine. .

    Really old x86-64 amd/intel cpus running without updated microcode will see that the 32 expfix is not complete. So sections of ESPFIX issue can still come back and bite you if you are using really old hardware due to being part microcode update and part software fix.

    Was the vulnerability in the cpu with protected mode 16 handling(espfix16) in long long mode in fact fixed the answer is no. Anyone writing a OS wishing to be 64 bit on x86 cpu in long long mode using 16 bit protected segments need to include full software fix for this. Was the vulnerability in cpu for protected mode 32(espfix32) in long long mode in fact part fixed half fixed by microcode/cpu silicon update. So anyone writing a OS wishing to be 64 bit on x86 running 32 bit protect mode need to check that update microcode is applied and software fix what the microcode does not. Yes protected mode 16 could have been half fixed by microcode as well.

    CPU faults operating systems learn to live with. But the number of faults in x86 is starting to get insane. Each software fix to a hardware fault is wasting cpu time that could be used on other things.
    Last edited by oiaohm; 15 September 2018, 10:27 PM.

    Comment


    • #32
      Originally posted by oiaohm View Post
      No I have documentation on dx8 and other where microsoft breaks API/ABI. After 10 years of deprecated Microsoft does break compatibly. By the way UWP drops dx9 so it matter of time until windows 10 drops dx9.
      At this point I'm completely sure that you really have no idea what binary compatibility actually means. The fact that you think UWP, a platform that requires recompilation and is a totally different set of APIs has anything to do with binary compatibility shows just how much of a joke your points are.

      And no user really gives a shit about source-code compatibility. That's stuff for (a subset of) developers.

      Originally posted by oiaohm View Post
      [snip]

      CPU faults operating systems learn to live with. But the number of faults in x86 is starting to get insane. Each software fix to a hardware fault is wasting cpu time that could be used on other things.
      Bugs exist everywhere. I don't see why you make a deal out of bugs in the past that have been fixed. The more bugs that existed, and got fixed, the better x86 is today.

      Years of bug fixing does accumulate to something good in the end. It may not be "pure" in design but it's been tried and worn down for decades unlike a "fresh new rewrite" bullshit by amateurs.

      Comment


      • #33
        Originally posted by Weasel View Post
        At this point I'm completely sure that you really have no idea what binary compatibility actually means. The fact that you think UWP, a platform that requires recompilation and is a totally different set of APIs has anything to do with binary compatibility shows just how much of a joke your points are.
        At Build 2016, we showed you how to use the Desktop App Converter to bring your existing desktop applications to the universal .appx packaging format as a first step to bringing your application to the Universal Windows Platform (UWP). Once on UWP, your apps are easier for users to manage and install, and you can

        Never made a UWP have you. UWP application containers take existing windows exe files that is within the UWP restricted ABI all you need to do package. Not a totally different set of API/ABI or any recompilation. Only restrictions is application must only use the subset of windows ABI that UWP provides. UWP also lists the API/ABI Microsoft has the plan to keep on maintaining at least for the next 10 years anything not on that list may disappear in the next 10 years.

        Really claiming UWP is a totally different set of APIs what have you been smoking you are clueless.

        Originally posted by Weasel View Post
        Bugs exist everywhere. I don't see why you make a deal out of bugs in the past that have been fixed. The more bugs that existed, and got fixed, the better x86 is today.
        If you asked what was the first bug to show there was a speculative execution problem and did digging you would find its ESPFIX set of bugs. ESPFIX set of bugs were not fixed at the hardware level. Side channel faults allowing access to memory and other things.


        Yes the ROP here depends on the ability to use invalid stack pointers. ESP issue depends on also using invalid stack pointers. The fact that ESPFIX16/32 are software fixes means if attacker gets to run what ever code they like in kernel space they can still use both.

        Kind of gets important to know what was fixed by fixing the hardware and what was just software patched over. What was just software patched over can be used to extend the capabilities of future bugs. If ESPFIX had been properly fixed at hardware level it may not have stopped speculative execution attacks but would have made them harder to exploit and limited the attack surface.

        You can think of software patches to hardware defects like ESPFIX as sweeping dirt under rug the problem is not gone it just out of sight for now. Sooner or latter another bug will lift up the rug and all that hidden dirt(bugs) turns up again.

        Comment


        • #34
          Originally posted by oiaohm View Post
          https://blogs.windows.com/buildingap...p-apps-to-uwp/
          Never made a UWP have you. UWP application containers take existing windows exe files that is within the UWP restricted ABI all you need to do package. Not a totally different set of API/ABI or any recompilation. Only restrictions is application must only use the subset of windows ABI that UWP provides. UWP also lists the API/ABI Microsoft has the plan to keep on maintaining at least for the next 10 years anything not on that list may disappear in the next 10 years.

          Really claiming UWP is a totally different set of APIs what have you been smoking you are clueless.
          No, I thought UWP was all-managed apps to begin with. Doesn't change the point if they're just containers of existing apps. Because nobody forces you to convert.

          Originally posted by oiaohm View Post
          The fact that ESPFIX16/32 are software fixes means if attacker gets to run what ever code they like in kernel space they can still use both.
          You have some serious issues if you think any vulnerability matters after malware managed to run arbitrary code in kernel space.

          "Look I broke in the house because door was unlocked, perfect, now it's time to open the windows and come in from them. Verdict: windows are unsafe in this house. Proof!"

          Comment


          • #35
            Originally posted by Weasel View Post
            No, I thought UWP was all-managed apps to begin with. Doesn't change the point if they're just containers of existing apps. Because nobody forces you to convert.
            oiaohm's point about DX9 and UWP is that Microsoft does eventually drop support for things, even if they're famous for preserving backwards compatibility for a long time.

            (eg. Dropping support for 16-bit apps in 64-bit Windows. Removing the headers and link libraries for DirectPlay from the DirectX SDK in 2007, removing DirectPlay Voice and DirectPlay NAT Helper in Windows Vista, and making the rest of DirectPlay an optional feature, not installed by default, in Windows 10, etc.).

            Comment


            • #36
              Originally posted by Weasel View Post
              No, I thought UWP was all-managed apps to begin with. Doesn't change the point if they're just containers of existing apps. Because nobody forces you to convert.
              Sorry Microsoft is forcing you to convert. Windows 10 S only supports UWP applications. So even by passing the store protection the dx9 ABI is not there.

              The ABI of UWP is the writing on the wall where home and pro 10 will go in time. UWP for Windows 7 had dx8 missing then Windows 10 release with dx8 broken. UWP is where Microsoft shows you what they are planning on dropping.

              Windwos ABI support is 10 years from when the ABI was first release when ABI gets to 10 years old Microsoft is free to decide to drop it. Its not infinity ABI support.

              Originally posted by Weasel View Post
              You have some serious issues if you think any vulnerability matters after malware managed to run arbitrary code in kernel space.
              Please look again the hardware defect of espfix ends up with speculative execution end up equal not just break kernel space but breaching the hypervisors.

              Its one thing to be able to run arbitrary code in kernel space is another it breach hypervisors.

              The problem with these hardware faults is its not always 1+1=2 is more like 1+1 magically equals 3. espfix issue by itself would not allow you to breach hypervisor most of the speculative execution faults without the esp issue would not be able to breach hypervisor either. But when you put the two classes of faults in one you have a hypervisor breach.

              So all these hardware faults that are software patched over when they are exposed by another fault and with the effects of another fault the result can be total amplification of effect.

              Sorry breaching the kernel space is not the worst that can happen. Breaching kernel space and hypervisor is the worst that can happen on shared hosting. Worst happen with most of the paths with the speculation execution was due to prior items like espfix that had been just swept under the rug with software fixes.

              Now here is the question how much is the next cpu exploit going to be amplified by what is sitting under the rug of software fixes. Maybe rewriting system firmware with malware?

              Comment


              • #37
                Originally posted by oiaohm View Post
                Sorry Microsoft is forcing you to convert. Windows 10 S only supports UWP applications.
                And nobody cares about it.

                Originally posted by oiaohm View Post
                The ABI of UWP is the writing on the wall where home and pro 10 will go in time.
                Baseless claim. Prove it.

                Win32 (the API ecosystem) is literally the reason people use Windows for, so... would be shooting themselves in the foot there.

                Originally posted by oiaohm View Post
                Please look again the hardware defect of espfix ends up with speculative execution end up equal not just break kernel space but breaching the hypervisors.

                Its one thing to be able to run arbitrary code in kernel space is another it breach hypervisors.

                The problem with these hardware faults is its not always 1+1=2 is more like 1+1 magically equals 3. espfix issue by itself would not allow you to breach hypervisor most of the speculative execution faults without the esp issue would not be able to breach hypervisor either. But when you put the two classes of faults in one you have a hypervisor breach.

                So all these hardware faults that are software patched over when they are exposed by another fault and with the effects of another fault the result can be total amplification of effect.

                Sorry breaching the kernel space is not the worst that can happen. Breaching kernel space and hypervisor is the worst that can happen on shared hosting. Worst happen with most of the paths with the speculation execution was due to prior items like espfix that had been just swept under the rug with software fixes.

                Now here is the question how much is the next cpu exploit going to be amplified by what is sitting under the rug of software fixes. Maybe rewriting system firmware with malware?
                If you have kernel space access, you have access to everything, so nothing else matters. Quite literally.

                Yes of course if it's a VM, then you should theoretically only have access to the VM. Barring hypervisor bugs (out of the scope of this context), speculative execution can leak data from outside the VM. And just that... leak data. That's Spectre's fault though.

                I don't know how you managed to bring your hatred against speculative execution yet again in another thread. Go fanboy RISC-V somewhere else.

                Comment


                • #38
                  Originally posted by ssokolow View Post
                  oiaohm's point about DX9 and UWP is that Microsoft does eventually drop support for things, even if they're famous for preserving backwards compatibility for a long time.

                  (eg. Dropping support for 16-bit apps in 64-bit Windows. Removing the headers and link libraries for DirectPlay from the DirectX SDK in 2007, removing DirectPlay Voice and DirectPlay NAT Helper in Windows Vista, and making the rest of DirectPlay an optional feature, not installed by default, in Windows 10, etc.).
                  Yeah, the 16-bit thing is indeed correct for 64-bit Windows but not for 32-bit Windows, but the DX9 isn't since Windows S is separate and frankly nobody cares about it, other than casuals who don't even know what Windows is in the first place, much less why they're using it (instead of another OS).

                  I do see Windows converting Home/Pro to S when Linux has like 50% market share or so, and stuff works better in Wine than on native Windows anymore, probably.

                  Comment


                  • #39
                    Originally posted by Weasel View Post
                    And nobody cares about it.

                    Baseless claim. Prove it.

                    Win32 (the API ecosystem) is literally the reason people use Windows for, so... would be shooting themselves in the foot there.

                    Its not a baseless claim that dx8 is broken. I said windows 10 I was wrong Microsoft broke it windows 8. Applications from the Microsoft Store for windows 8 can have dx9. Windows applications for 10 for in from Microsoft Store must have Dx10 or greater if using direct x.

                    Yes once its gone from the store supported applications when that API/ABI breaks microsoft will keep on shipping it and never fix it. Dx8 is dead for support from Microsoft. Dx9 on windows 10 is on borrowed time.

                    This is Microsoft they have shot themselves in the foot many times. Companies like Valve wanting to provide legacy dx8 and dx9 applications due to Microsoft lack of support for both now have to look else where.

                    Originally posted by Weasel View Post
                    Yes of course if it's a VM, then you should theoretically only have access to the VM. Barring hypervisor bugs (out of the scope of this context), speculative execution can leak data from outside the VM. And just that... leak data. That's Spectre's fault though.
                    The code to protect against espfix does not prevent speculative execution still going down the old unfixed path.

                    Espfix is fixing a data leak between userspace and kernelspace. The same exploit code for expfix to breach from user space to kernel space works slightly modified with Spectre fault except now to go from kernel space to ring -1(hypervisor).

                    Basically here is Weasel wanting to put all the problem on spectre ignoring that the fault is amplified by the older defect espfix that was only fixed in software.

                    Please note this bug stacking effect even happens in the number of bugs that make up espfix.


                    Originally posted by Weasel View Post
                    Yeah, the 16-bit thing is indeed correct for 64-bit Windows but not for 32-bit Windows, but the DX9 isn't since Windows S is separate and frankly nobody cares about it, other than casuals who don't even know what Windows is in the first place, much less why they're using it (instead of another OS).

                    Good fun right. Windows 10 on new cpus you cannot install the 32 bit version its not driver supported by Intel or Microsoft.


                    Spend some time reading expfix issue does effect windows 16 bit and dosvm in windows 32 bit versions. Microsoft fixes expfix issue by dropping win16 and dos support and only fix it 32 to 64 bit.

                    Yes a reason why a lot of old dos programs work in dosbox not windows 32 bit dos support is espfix fault with data leaks and all breaking the dos programs in the windows dos environment.

                    Weasel is right that windows 32bit has 16 bit support but that 16 bit support is not secure against espfix style attacks because it was never fixed. This is how Microsoft deprecates API/ABI they keep on shipping them for so called backwards compatibly and no longer fixing them against defects including security defects. Microsoft fix to espfix issues is use 64 bit version of windows and drop dos and win16 support.

                    I do like intel with espfix a feature that was not in i486 and before was written into the processor specification for Pentium and newer this is espfix so since its now a specification feature they never have to fix it. We are seeing the same thing with the current list of speculative execution bugs where intel is just writing it into the specification.

                    Originally posted by Weasel View Post
                    I do see Windows converting Home/Pro to S when Linux has like 50% market share or so, and stuff works better in Wine than on native Windows anymore, probably.
                    Wined3d from wine is being used on windows 10 to fix dx8 applications because Microsoft is not going to. Companies like valve will be needing these conversion systems to keep on selling old applications.



                    Comment


                    • #40
                      Originally posted by oiaohm View Post
                      Its not a baseless claim that dx8 is broken.
                      Nice try but that was not the baseless claim I quoted. Just stop.
                      Originally posted by oiaohm View Post
                      Applications from the Microsoft Store for windows 8 can have dx9. Windows applications for 10 for in from Microsoft Store must have Dx10 or greater if using direct x.
                      But nobody cares about Microsoft Store.

                      Originally posted by oiaohm View Post
                      The code to protect against espfix does not prevent speculative execution still going down the old unfixed path.

                      Espfix is fixing a data leak between userspace and kernelspace. The same exploit code for expfix to breach from user space to kernel space works slightly modified with Spectre fault except now to go from kernel space to ring -1(hypervisor).

                      Basically here is Weasel wanting to put all the problem on spectre ignoring that the fault is amplified by the older defect espfix that was only fixed in software.

                      Please note this bug stacking effect even happens in the number of bugs that make up espfix.
                      Stop repeating the same thing, that's not going to make your argument any more true. Nobody gives a shit what the problem is "amplified by". The cause of it is Spectre. This is just basics. Fix spectre and you fix "the problem" no matter how much it "amplifies" it, because even math says, multiply something by zero, you get zero.

                      Oh and this applies only for hypervisors with internet access running untrusted software. Otherwise it's a non issue.

                      Originally posted by oiaohm View Post
                      https://www.intel.com/content/www/us...rocessors.html
                      Good fun right. Windows 10 on new cpus you cannot install the 32 bit version its not driver supported by Intel or Microsoft.
                      I think that's for the integrated graphics. You don't need drivers to execute CPU instructions because drivers are CPU instructions in the first place.

                      Originally posted by oiaohm View Post
                      https://groups.google.com/forum/#!to...el/Zrs3t6LBjoo
                      Spend some time reading expfix issue does effect windows 16 bit and dosvm in windows 32 bit versions. Microsoft fixes expfix issue by dropping win16 and dos support and only fix it 32 to 64 bit.

                      Yes a reason why a lot of old dos programs work in dosbox not windows 32 bit dos support is espfix fault with data leaks and all breaking the dos programs in the windows dos environment.

                      Weasel is right that windows 32bit has 16 bit support but that 16 bit support is not secure against espfix style attacks because it was never fixed. This is how Microsoft deprecates API/ABI they keep on shipping them for so called backwards compatibly and no longer fixing them against defects including security defects. Microsoft fix to espfix issues is use 64 bit version of windows and drop dos and win16 support.

                      I do like intel with espfix a feature that was not in i486 and before was written into the processor specification for Pentium and newer this is espfix so since its now a specification feature they never have to fix it. We are seeing the same thing with the current list of speculative execution bugs where intel is just writing it into the specification.
                      I don't think you understand a single thing from the thread you linked but then you bring your beliefs into it.

                      Comment

                      Working...
                      X