Re: [patch] x86: fix ESP corruption CPU bug
Hi, Linus Torvalds wrote:
Btw, Stas, one thing I'd really like to see is even a partial list of anything that actually cares about this. Ie, if there is some known Windows app where Wine works better or something like that, just adding I am not using Wine too much, but I've found this: http://cvs.winehq.org/cvsweb/~checkout~/wine/dlls/winedos/int31.c?rev=1.41&c...
/* due to a flaw in some CPUs (at least mine), it is best to mark stack segments as 32-bit if they can be used in 32-bit code. Otherwise, these CPUs may not set the high word of esp during a ring transition (from kernel code) to the 16-bit stack, and this causes trouble if executing 32-bit code using this stack. */ --- I added win-devel to CC, maybe people there can tell if that patch has any value for them or not. The reference to the original patch: http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.1/1794.html Dosemu looks a little better on that, the whole chapter of the docs is dedicated to that problem: http://dosemu.sourceforge.net/docs/EMUfailure/t1.html#AEN55 There you can find a (relatively small) list of the programs that are affected, but I personally have the old Microsoft linker that crashes, and a few more DOS games.
Another way of saying the same thing: I absolutely hate seeing patches that fix some theoretical issue that no Linux apps will ever care about. No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS.
So I'd like to have a bit more of a case for this patch, since I know what the case against it is ;) Yep, and the informational leak it closes, looks also rather minor. So it is only a matter of how do you care about the dosemu and the DOS games under linux. Considering the amount of the dosemu-related code in vm86.c, I guess you care:) And uhm, adding the list of the DOS games to the comments of the Linux kernel code, doesn't sound like a good idea to me:)
Stas Sergeev <stsp(a)aknet.ru> writes:
Another way of saying the same thing: I absolutely hate seeing patches that fix some theoretical issue that no Linux apps will ever care about. No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS.
How about you just run it in dosbox instead of dosemu ? -Andi
Andi Kleen wrote:
Stas Sergeev <stsp(a)aknet.ru> writes:
Another way of saying the same thing: I absolutely hate seeing patches that fix some theoretical issue that no Linux apps will ever care about.
No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS.
How about you just run it in dosbox instead of dosemu ?
Yes, that's a solution of course, but it is a bit like saying why not use Open Office instead of MS Word. A long term goal of wine is to support DOS apps to. Of course it's not a priority, but it's there. regards, Jakob
On Mon, 14 Mar 2005, Jakob Eriksson wrote:
Andi Kleen wrote:
Stas Sergeev <stsp(a)aknet.ru> writes:
Another way of saying the same thing: I absolutely hate seeing patches that fix some theoretical issue that no Linux apps will ever care about.
No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS.
How about you just run it in dosbox instead of dosemu ?
Yes, that's a solution of course, but it is a bit like saying why not use Open Office instead of MS Word.
A long term goal of wine is to support DOS apps to. Of course it's not a priority, but it's there.
regards, Jakob
Can you tell me how the invisible high-word (invisible in VM-86, and in real mode) could possibly harm something running in VM-86 or read-mode ??? I don't even think it's a BUG. If the transition into and out of VM-86 doesn't handle the fact that the high-word of the stack hasn't been used in VM-86, then that piece of code is bad (the SP isn't even the same stack, BTW). Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.
Hi!
Can you tell me how the invisible high-word (invisible in VM-86, and in real mode) could possibly harm something running in VM-86 or read-mode ??? I don't even think it's a BUG. If the transition
You can have protected-mode application running in dosemu with 16-bit stack segment. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
linux-os wrote:
On Mon, 14 Mar 2005, Jakob Eriksson wrote:
Andi Kleen wrote:
Stas Sergeev <stsp(a)aknet.ru> writes:
Another way of saying the same thing: I absolutely hate seeing patches that fix some theoretical issue that no Linux apps will ever care about.
No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS.
How about you just run it in dosbox instead of dosemu ?
Yes, that's a solution of course, but it is a bit like saying why not use Open Office instead of MS Word.
A long term goal of wine is to support DOS apps to. Of course it's not a priority, but it's there.
regards, Jakob
Can you tell me how the invisible high-word (invisible in VM-86, and in real mode) could possibly harm something running in VM-86 or read-mode ??? I don't even think it's a BUG. If the transition into and out of VM-86 doesn't handle the fact that the high-word of the stack hasn't been used in VM-86, then that piece of code is bad (the SP isn't even the same stack, BTW).
Because even in 16-bit mode (real, vm86 or 16-bit protected) you can use 32-bit instructions, with an operand and/or address size override prefix. Of course this only works on 386 or later. -- Brian Gerst
Hello. Brian Gerst wrote:
Can you tell me how the invisible high-word (invisible in VM-86, and in real mode) could possibly harm something running in VM-86 or read-mode ??? I don't even think it's a BUG. If the transition into and out of VM-86 doesn't handle the fact that the high-word of the stack hasn't been used in VM-86, then that piece of code is bad (the SP isn't even the same stack, BTW). Because even in 16-bit mode (real, vm86 or 16-bit protected) you can use 32-bit instructions, with an operand and/or address size override prefix. And the real problem is when the pure 32bit code is starting to use the 16bit stack for some strange reasons. Looks like the common technique for the early dos4gw -based apps...
Hi, Jakob Eriksson wrote:
A long term goal of wine is to support DOS apps to. Of course it's not a priority, but it's there. Yes, that's exactly what I was hoping for, thanks! Even if no Windows apps do such a thing (which wasn't confirmed yet), Wine may still need that fix for the DOS support in the future, and dosemu seems to be in need of that fix already and for long (that's where I am getting the use of it). And we haven't heard a word for a VMWare yet, and I think they may appreciate that too. Also, since the first version of the path, I've been contacted by a few people asking me to provide an updated version for 2.6.9 and 2.6.10. I don't know the reason, but I know it was used (I think they were more concerned about an aforementioned "information leak", rather than about the %esp corruption). So if the last problem with that patch was that it is not really needed, I think it no longer stays:)
participants (6)
-
Andi Kleen -
Brian Gerst -
Jakob Eriksson -
linux-os -
Pavel Machek -
Stas Sergeev