Re: Wine kernel acceleration module?
This issue has been discussed several times. If you dig in the WWN archives you'll find mentions of it going back a few years. Much more interesting was this post: http://www.winehq.com/hypermail/wine-devel/2002/12/0550.html The approach is a shared memory wineserver. --------------- Brian Vincent Copper Mountain Telecom vincentb(a)coppercolorado.com
Brian Vincent (C) wrote:
This issue has been discussed several times. If you dig in the WWN archives you'll find mentions of it going back a few years. Much more interesting was this post:
http://www.winehq.com/hypermail/wine-devel/2002/12/0550.html
The approach is a shared memory wineserver.
I beg to differ. IMHO the kernel module approach is the best. The PEACE team, for instance, is going this route in their implementation of win32 on BSD. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Dan Kegel wrote:
Brian Vincent (C) wrote:
This issue has been discussed several times. If you dig in the WWN archives you'll find mentions of it going back a few years. Much more interesting was this post:
http://www.winehq.com/hypermail/wine-devel/2002/12/0550.html
The approach is a shared memory wineserver.
I beg to differ. IMHO the kernel module approach is the best. The PEACE team, for instance, is going this route in their implementation of win32 on BSD.
Each approach has its own merits - you'll note in our paper that we also posted sources and design documentation for KWine, an alternative wineserver kernel module design that keeps Win32 HANDLE objects in a Linux file system. We spent some time on that as well before working on the ShmServer approach. With a kernel module approach, hosting multiple wineserver environments becomes more difficult. A kernel module also brings with it a number of packaging issues, and would require significant work to be moved to non-Linux OSes. Lastly, the kernel module approach requires an all-at-once rewrite of the wineserver interactions, whereas the ShmServer can be implemented on a call-by-call basis. About the only thing a kernel module would have over the ShmServer on the performance front would be the ability to do PE relocation fixups at page-in time, like Windows does. The value of that feature is limited, IMHO. A kernel module may also have some benefits from the security perspective. Regardless of which one is better, it would be nice to see more interest in this topic from other developers. If anyone else is interested in collaborating on the ShmServer or kernel module approaches, that would be great. Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. gav(a)transgaming.com http://www.transgaming.com/ Let the games begin
On Sat, 18 Jan 2003, Gavriel State wrote: [...]
A kernel module may also have some benefits from the security perspective.
I am not sure a kernel module would be inherently better from a security point of vue: after all, the same module would handle all the users on the system. So there would be more risk that a user gains access to data he should not have access to. On the other hand it may also make it possible to implement CreateProcessAsUser&co... not that they are used much though. Anyway, when compared to the shared memory server it seems to me that the main advantage of a kernel module is stability. It is my understanding (correct me if I'm wrong) that with the shared memory approach, a buggy (or malicious) Wine/Winelib application could crash all other Wine/Winelib applications using that server (at least only one user would be affected). That seems like a significant drawback. In either case though, to me it seems the two biggest obstacles are maintenance and compatibility: * if either approach requires duplicating (too much of) the server code, then the big question is whether there will be enough people interested for that alternate implementation to be maintained. * there are still signifcant changes in the server code. In my understanding there are still a number of things that are currently managed on a per-process basis and that should be managed by the server instead. Being able to easily switch from one implementation to another seems important to me. But this kind of compatibility requires that they remain in sync... that sort of brings us back to maintenance. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.
Francois Gouget wrote:
Anyway, when compared to the shared memory server it seems to me that the main advantage of a kernel module is stability. It is my understanding (correct me if I'm wrong) that with the shared memory approach, a buggy (or malicious) Wine/Winelib application could crash all other Wine/Winelib applications using that server (at least only one user would be affected).
Whereas with the kernel module, it could panic the entire machine. Yepee!! Shachar
On Sun, 19 Jan 2003, Shachar Shemesh wrote:
Francois Gouget wrote:
Anyway, when compared to the shared memory server it seems to me that the main advantage of a kernel module is stability. It is my understanding (correct me if I'm wrong) that with the shared memory approach, a buggy (or malicious) Wine/Winelib application could crash all other Wine/Winelib applications using that server (at least only one user would be affected).
Whereas with the kernel module, it could panic the entire machine. Yepee!!
But of course that's true only if the kernel module has a bug. With the shared memory server any Windows application can crash all the others (but not the machine). To sum up, here's a table of what crashes based on the source of the bug: | Current | Kernel | Shm ------------------+---------------+----------------+-------------------- Bug in the server | Wine | Machine | Wine ------------------+---------------+----------------+-------------------- Bug in a Windows | Process | Process | Wine application | | | So you're better of with the kernel module if the bug is in the application, and you're better of with shm if the bug is in the server. Then it's a matter of which one is more likely. It's also a good argument for having the option to keep using the current server so that you can make the trade-off between speed and stability yourself. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service
Francois Gouget wrote:
So you're better of with the kernel module if the bug is in the application, and you're better of with shm if the bug is in the server. Then it's a matter of which one is more likely.
I'm not in front of the sources at the moment. How big is the wineserver at the moment? If it's rather big (and I rather suspect it is), then it seems obvious which one is more likely. The windows apps are released apps that were working on Windows NT. The wineserver, on the other hand, is a piece of Alpha software that has not seen too much pounding into. I think that a bug in the server is MUCH MUCH MUCH more likely to happen. I think the best approach is a hybrid one. We have a kernel module that does only the bare minimum required in the kernel. Everything else is done using user-mode processes. This has several important advantages: 1. Bugs are much less likely to happen in the kernel area - less chances of blowing the entire machine away. 2. It becomes much easier to port the kernel to other platforms. 3. You can still, basically, do everything you did with a full fledged kernel wineserver. 4. Rebooting wine does not require rebooting the kernel (machine), or even unloading and reloading the kernel module. It is even, theoretically, possible to run several wineservers this way, though I'm not sure enough of the fine details to say that for sure. Shachar
On Sun, 19 Jan 2003, Shachar Shemesh wrote:
Francois Gouget wrote:
So you're better of with the kernel module if the bug is in the application, and you're better of with shm if the bug is in the server. Then it's a matter of which one is more likely.
I'm not in front of the sources at the moment. How big is the wineserver at the moment?
If it's rather big (and I rather suspect it is), then it seems obvious which one is more likely.
$ find server -name "*.[ch]" | xargs cat | wc -l 22452 $ find . -name "*.[ch]" | xargs cat | wc -l 1237362 $ find dlls files graphics if1632 library loader memory misc miscemu msdos objects ole relay32 scheduler win32 windows -name "*.[ch]" | xargs cat | wc -l 861271 So depending how you count the server represents between 1.8% and 2.6% of the Wine code. That's far from being a big portion of Wine.
The windows apps are released apps that were working on Windows NT. The wineserver, on the other hand, is a piece of Alpha software that has not seen too much pounding into. I think that a bug in the server is MUCH MUCH MUCH more likely to happen.
That's not supported by the above, and especially not by experience. How often have you seen applications crash in Wine? Me i see them crash every day (but of course being a Wine developper I am only interested by applications that crash). But most of the time it is the application that crashed, not the Wine server. In fact, I have not had a Wine server crash in at least a month. The thing is that yes, applications may be stable when they run on Windows NT, but they are running in Wine and make heavy use of the Wine libraries (~70% of the code). And in fact, I forgot the most important line in my table. Here it is duely corrected: | Current | Kernel | Shm ------------------+---------------+----------------+-------------------- Bug in a Wine | Process | Process | Wine library | | | ------------------+---------------+----------------+-------------------- Bug in a Windows | Process | Process | Wine application | | | ------------------+---------------+----------------+-------------------- Bug in the server | Wine | Machine | Wine
I think the best approach is a hybrid one. We have a kernel module that does only the bare minimum required in the kernel. Everything else is done using user-mode processes.
There I completely agree with you. Only the speed-critical items should be handled by the kernel module. Ideally it would only provide a couple of concepts (e.g. HANDLE <-> fd mapping) that would allow us to have good performance while only doing a minimum in the kernel (e.g. not doing the Windows <-> Unix path conversions). But that's probably easier said than done and the above handle and file descriptor example should be taken more as an illustration than as a hard and fast recommendation on the way to do it :-) [...]
4. Rebooting wine does not require rebooting the kernel (machine), or even unloading and reloading the kernel module.
Whatever the scenario I am not sure there is anything forcing us to restart the Wine server for 'rebooting' the Wine environment. The only thing requiring a Wine server restart would be upgrades. But even a with a kernel module, unloading and reloading the module should be enough. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Francois Gouget wrote:
But of course that's true only if the kernel module has a bug. With the shared memory server any Windows application can crash all the others (but not the machine).
To sum up, here's a table of what crashes based on the source of the bug:
| Current | Kernel | Shm ------------------+---------------+----------------+-------------------- Bug in the server | Wine | Machine | Wine ------------------+---------------+----------------+-------------------- Bug in a Windows | Process | Process | Wine application | | |
So you're better of with the kernel module if the bug is in the application, and you're better of with shm if the bug is in the server. Then it's a matter of which one is more likely. It's also a good argument for having the option to keep using the current server so that you can make the trade-off between speed and stability yourself.
The ShmServer is designed with that in mind. The server code has been moved into a shared library, and the wineserver process still exists in the ShmServer model. While it's not actually available in the current code, it would be trivial to restrict access to the shm area to specific trusted processes and force other processes to go through the normal wineserver route. Additionally, the ShmServer is designed so that the actual shared memory area can be write-locked until a server call is made. Thus it becomes very difficult, though not completely impossible, for an individual process to scribble over the server memory by accident. So the bottom right entry in your table should perhaps be changed to read '99% Process / 1% Wine' What it does *not* prevent is a deliberately malicious app scribbling over server memory - certainly a problem, but for many uses of Wine, not a significant one. Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-) Take care, -Gav -- Gavriel State, CEO & CTO TransGaming Technologies Inc. gav(a)transgaming.com http://www.transgaming.com/ Let the games begin
Gavriel State wrote:
Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-)
That's a real advantage: it works, right now! All those who prefer another approach, put your code where your mouth is :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Tom Wickline wrote:
Gavriel State wrote:
Another key factor in favour of the ShmServer is that we've got a working prototype available right now that runs several real-world apps. 8-)
May I ask for a list of Apps ?
Well the paper that we posted with the donation announcement (http://www.transgaming.com/papers/shmserver.html) provides a certain list. We were of course concerned with games that we knew had this problem (American McGee's Alice and Quake3). As for a complete list I don't think that we have one but it has been tried, without any observed issues, on several other games that reside in my blurry & hazy memory. Guess that doesn't help much. The paper does also mention some of the toy applications in the program directory that were used. Perhaps people could post their success and failure stories? Ciao, Peter
Tom
Take care -Gav
On Sunday 19 January 2003 20:26, Shachar Shemesh wrote:
Francois Gouget wrote:
Anyway, when compared to the shared memory server it seems to me that the main advantage of a kernel module is stability. It is my understanding (correct me if I'm wrong) that with the shared memory approach, a buggy (or malicious) Wine/Winelib application could crash all other Wine/Winelib applications using that server (at least only one user would be affected).
Whereas with the kernel module, it could panic the entire machine. Yepee!! Sure about that?. I've been able to lock the entire machine simply by running a DirectX game under Wine on the back of faulty X drivers! (would a kernel module allow debugging of such problems via Kernel debugging features?)
Shachar
-- Mathew McBride matt(a)mcbridematt.dhs.org http://mcbridematt.dhs.org Jabber: mcbridematt on the jabber.org server
Mathew McBride wrote:
I've been able to lock the entire machine simply by running a DirectX game under Wine on the back of faulty X drivers!
I can't recall if that's happened to me, but I know I've had X lock up so badly I had to telnet in and kill it. X drivers run with root privs :-(
(would a kernel module allow debugging of such problems via Kernel debugging features?)
IMHO none of our graphics stuff should be moved to the kernel; I don't think any of it's in wineserver anyway, is it? Shades of NT4.0 :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Shachar Shemesh wrote:
Francois Gouget wrote:
Anyway, when compared to the shared memory server it seems to me that the main advantage of a kernel module is stability. It is my understanding (correct me if I'm wrong) that with the shared memory approach, a buggy (or malicious) Wine/Winelib application could crash all other Wine/Winelib applications using that server (at least only one user would be affected).
Whereas with the kernel module, it could panic the entire machine. Yepee!!
That's only possible if there's a bug in the kernel module, whereas with the shared memory approach, it's possible even if the wineserver code is flawless. You are arguing against putting any code in the kernel. That would put you in the Mach camp, I think :-) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
Gavriel State wrote:
Each approach has its own merits - you'll note in our paper that we also posted sources and design documentation for KWine, an alternative wineserver kernel module design that keeps Win32 HANDLE objects in a Linux file system.
Yeah, thanks for posting that. I didn't have a chance to read the code, but I hope to sometime.
With a kernel module approach, hosting multiple wineserver environments becomes more difficult.
Yes, but I think that's a red herring. We don't need multiple wineserver environments, really, except in the same way that we need multiple linux environments (e.g. with chroot jails).
A kernel module also brings with it a number of packaging issues, and would require significant work to be moved to non-Linux OSes.
Very much so.
Lastly, the kernel module approach requires an all-at-once rewrite of the wineserver interactions, whereas the ShmServer can be implemented on a call-by-call basis.
Is that really true? There might be some way of bringing in the kernel module incrementally. You'd know better than me, but still...
About the only thing a kernel module would have over the ShmServer on the performance front would be the ability to do PE relocation fixups at page-in time, like Windows does. The value of that feature is limited, IMHO. A kernel module may also have some benefits from the security perspective.
I suspect the kernel module would be better protected from wild memory accesses by the user processes as well.
Regardless of which one is better, it would be nice to see more interest in this topic from other developers. If anyone else is interested in collaborating on the ShmServer or kernel module approaches, that would be great.
Indeed. Thanks for your great work! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
participants (8)
-
Brian Vincent (C) -
Dan Kegel -
Francois Gouget -
Gavriel State -
Mathew McBride -
Peter Hunnisett -
Shachar Shemesh -
Tom Wickline