A step in the wrong direction, in an ocean of steps in the right direction (try 3)
Hi Dimitry, Thank you very much for bringing this explanation to my knowledge. As you name came over and over through wine-devel list, I am aware that you are an experimented and influential member within wine community (which make a huge difference with me, as this is the first time I try to bring a contribution to wine(1) ), so I will consider this explanation as the way most involved wine people are considering things up. The most interesting part in your answer is indeed this word of "Behaviour" you used. Indeed, in my understanding (but maybe "I am hoping" is more correct here) wine's goal is to provide the same functionalities as Windows API, not to implement those functionalities C statement for C statement with respect to Window's ones. Two reason comes to my mind : 1 - Just copycatting Windows implementation would brought wine very close to plagiarism, thus legally threaten is mere existence 2 - Obviously, Windows implementation is not always the most efficient nor the most secure, due to commercial stakes (release schedule, financial arbitrations...) Regarding the part of your mail where you wrote : "that's actually good that applications crash when they pass invalid data", I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back. Don't misunderstand me here, I'm not insulting you neither I'm not saying that I am better than you nor I'm not trying to start a flaming thread. I respect the assertion you stated, but honestly and deeply fail to understand why is it correct. Guillaume (1) Talking openly and honestly about a subject that may be considered a problem is a way of contributing, less concrete than patches, but real too.
On Sun, Jan 25, 2009 at 1:53 PM, Guillaume SH <gsh.debianlists(a)gmail.com> wrote:
The most interesting part in your answer is indeed this word of "Behaviour" you used. Indeed, in my understanding (but maybe "I am hoping" is more correct here) wine's goal is to provide the same functionalities as Windows API, not to implement those functionalities C statement for C statement with respect to Window's ones.
Two reason comes to my mind : 1 - Just copycatting Windows implementation would brought wine very close to plagiarism, thus legally threaten is mere existence
Legal problems aside, copycatting Windows is exactly what has to happen for Wine to function like it should. It can't be a 'better' version of Windows, because many programs depend on the quirks and faults of the Windows API/ABI. And I don't think there are any legal problems. Wine developers don't look at reverse-engineered Windows code, so Wine's code will inevitably differ a great deal. Implementing quirks the same way will make the code more similar than before, but there are still things like coding style and implementation details that differ a great deal. Probably not even 1% of the C statements in Wine is an exact match to a statement in Windows.
2 - Obviously, Windows implementation is not always the most efficient nor the most secure, due to commercial stakes (release schedule, financial arbitrations...)
Well, the implementation can differ from Windows, as long as it has the same effect on the API/ABI level. Some applications actually do run faster because of this. And some run much slower because of this.
Regarding the part of your mail where you wrote : "that's actually good that applications crash when they pass invalid data", I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back.
A while back there was some case where a buggy Windows program would run in Wine, while it didn't run in any version of Windows. After Wine became better, the buggy program stopped working. Of course it also meant that a lot of other programs started working. At some point you have to stop making bad programs work, and implement the API as close to Windows itself as possible. The buggy program can still be made to work with a custom patch. Remco
Remco wrote:
A while back there was some case where a buggy Windows program would run in Wine, while it didn't run in any version of Windows. After Wine became better, the buggy program stopped working. Of course it also meant that a lot of other programs started working. At some point you have to stop making bad programs work, and implement the API as close to Windows itself as possible. The buggy program can still be made to work with a custom patch.
Windows has an application compatibility layer that loads with specific (pre-configured and user configured) applications to provide backward compatible behavior for buggy applications by intercepting exported system DLL functions. Wine should have this as well that would enable more applications on Wine, possibly even more than on Windows. Kornél
2009/1/25 Remco <remco47(a)gmail.com>:
Well, the implementation can differ from Windows, as long as it has the same effect on the API/ABI level. Some applications actually do run faster because of this. And some run much slower because of this.
What apps run faster in Wine than in Windows? (What Win32 functions run faster and better in Wine than in Windows?) Is this documented e.g. on the wiki? - d.
It's all been said, by myself and others. I just want something clarified. 2009/1/25 Guillaume SH <gsh.debianlists(a)gmail.com>:
Regarding the part of your mail where you wrote : "that's actually good that applications crash when they pass invalid data", I must admit I don't understand your point at all. It seems to me a dogma, not the result of some thought or stand back.
If an application ends up with invalid data (possibly due to a bug in the app, possibly due to corrupt data files, possibly due to user input without proper checking in the app), a call to the function in question (or any other function, for that matter) could easily end up with invalid data. In the case of invalid data crashing the application, the application stops functioning, and no (further) damage can be caused. In the case where Wine does something that win32/Windows doesn't, which is to allow the program to continue with its invalid data, there is potential for your system to become compromised by the application continuing. What you describe as a potential exploit by crashing an app with invalid data in this case could easily be used as an exploit the other way, and something that specifically targets Wine, since the behaviour is different in Windows, where the app crashes on invalid data. It's possible. It's potential. It's theoretical. It's something that could be implemented as a proof-of-concept. It should be fixed, and doing what the other guy does, when there are only two in the field, makes sense when you're already trying to do what the other guy does (which is run Windows applications). It doesn't even need to be exactly the same code, as long as it has the same effect. There's already been a suggestion for an alternative way to do the same thing.
participants (5)
-
Ben Klein -
David Gerard -
Guillaume SH -
Kornél Pál -
Remco