http://bugs.winehq.org/show_bug.cgi?id=20098
Summary: Wine fails to run my Kernel Mode Driver in Kernel Mode Product: Wine Version: 1.1.29 Platform: PC URL: http://rh-software.com OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: ray@pobox.co.uk
When I run my Kernel mode driver under Wine it gets run in User Mode, rather then kernel mode. This causes the RDMSR instructions if uses to fail. I have tried to get roung this by using type 202 msr devices, but there is no easy way to call mknod to create them. I raised http://bugs.winehq.org/show_bug.cgi?id=20081 asking for a wine_mknod() to be added, but this has been dismissed on the grounds that mknod() is not a windows function and therefore should not be in Wine. Applications running a Kernel Mode driver is a standard windows function used by many windows application so should work with Wine.
http://bugs.winehq.org/show_bug.cgi?id=20098
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX Alias|Kernel_Mode | Severity|major |minor
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2009-09-21 01:45:37 --- Wine entirely runs in user mode, it can't run your driver in kernel mode, Wine is not an OS.
http://bugs.winehq.org/show_bug.cgi?id=20098
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #2 from Dmitry Timoshkov dmitry@codeweavers.com 2009-09-21 01:45:57 --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=20098
red-ray ray@pobox.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WONTFIX |
--- Comment #3 from red-ray ray@pobox.co.uk 2009-09-22 01:01:12 --- SIV runs entirly in user mode on windows and has no problem at all running it's kernel driver in kernel mode.
I expected this to be difficult for Wine. OK, given Wine does not run the kernel driver in kernel mode then it should make a reasonable effort to implement support for the kernel mode environment.
Given that the RDMSR would work in kernel mode Wine could catch the exception, get the thread affinity, use this to mknod/read the appropiate /dev/cpu/n/msr device and depending on the outcome either pass the exception onto the driver of pass the msr contents back.
Were Wine to do this then I would not need to work-a-round this my havivg Wine specific code to read MSRs and dould have no need use mknod.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #4 from Dmitry Timoshkov dmitry@codeweavers.com 2009-09-22 01:14:07 --- You could try adding the code to emulate what you need to dlls/kernel32/instr.c,__wine_emulate_instruction(), which is called by dlls/ntoskrnl.exe/ntoskrnl.c,vectored_handler().
Perhaps even simple emulation will help your application.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #5 from red-ray ray@pobox.co.uk 2009-09-22 01:56:58 --- (In reply to comment #4) Were I an experinced Wine/*nix developer I would do this.
I am not sure what you mean by "simple emmulation", any emmulation would need to return the actual contents of the MSR being read, further it should really be the one from the CPU the calling thread, in my case running SIV.exe, has set affinity to, which on Windows is the case as the driver code that does the RDMSR runs in the context and thefor with the affinity of the calling thread.
OK, given I do not currently have necessary Wine/*nix background to write the code myself how can this be acheived please ?
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2009-09-22 03:20:05 --- I just pointed out that Wine catches the exception and already has some instruction emulation support. So, what you would need to do is ...
Given that the RDMSR would work in kernel mode Wine could catch the exception, get the thread affinity, use this to mknod/read the appropiate /dev/cpu/n/msr device and depending on the outcome either pass the exception onto the driver of pass the msr contents back.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #7 from red-ray ray@pobox.co.uk 2009-09-22 05:43:08 --- (In reply to comment #6) Thank you for your reply. How much detial do you need to know, is this enough ? 1) get the thread affinity, so you know which CPU to read 2) ensure the appropiate /dev/cpu/<n>/msr exists, create with mknod() is needed 3) open the device for read 4) get the value of ECX and use that to position (SEEK_SET), needs to use _lseeki64() as could well be MSR 0xC0000080 5) read 8 bytes 6) close device 7) is read failed pass exception back (my code will catch this) 8) store the low order 4 bytes in EAX 9) store the high order 4 bytes in EDX 10) continue execution 11) on wine exit it's probably a good idea to remove any mknod created devices 12) it might be worth leaving the MSR devices open and closing them on exit 13) SIV will read a few MSRs from ALL the CPUs at regular 1 or 2 second intervals so it would be wise to leave ALL the MSR devices open 14) I looked in http://www.intel.com/Assets/PDF/manual/253667.pdf for detials of the RDMSR instruction operation. 15) Would you plan to just do the fixup just for "Kernel Drivers" ? If initially you did it for all I will hapilly write and supply source of a Windows Test program. I am also happy to implement an command similar to: siv -save=[wine-msrs]=stdout which would actually use my driver to read a standard set of MSRs and report the results. If you would like me to write both a driver and test program and give you the source this might be possible, but I doubt if I could port it to the Wine build environment.
http://bugs.winehq.org/show_bug.cgi?id=20098
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #8 from Juan Lang juan_lang@yahoo.com 2009-09-24 18:45:12 --- Unfortunately, most kernel-mode drivers can't be supported by Wine, are truly beyond its scope. So this argument doesn't convince me:
"Applications running a Kernel Mode driver is a standard windows function used by many windows application so should work with Wine."
Wine has no special privilege under Linux: it isn't kernel mode itself. In general, if you want to do something that requires kernel mode, you must write a device driver for the operating system you're running on. Wine has made some attempts to support some Windows drivers, but only because some of them don't actually require kernel mode. Those that do, Wine simply cannot support.
Windows is no different in this regard. See e.g. http://blogs.msdn.com/oldnewthing/archive/2009/09/24/9898728.aspx
http://bugs.winehq.org/show_bug.cgi?id=20098
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2009-09-24 18:47:03 --- Closing. By the way, you have enough knowledge to work around this yourself. Why not give it a go?
http://bugs.winehq.org/show_bug.cgi?id=20098
red-ray ray@pobox.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Resolution|WONTFIX | Summary|Wine fails to run my Kernel |Wine should, when possible, |Mode Driver in Kernel Mode |provide the kernel mode | |environment for kernel mode | |drivers Alias| |RDMSR
--- Comment #10 from red-ray ray@pobox.co.uk 2009-09-25 03:07:04 --- (In reply to comment #9)
Closing. By the way, you have enough knowledge to work around this yourself. Why not give it a go?
I have worked around this, but currently the work-a-round is messy as I have to send /bin/mknod and /bin/rm commands to the shell using _system(). I tried asking for wine_mknod() (http://bugs.winehq.org/show_bug.cgi?id=20081) and a fix for DeleteFile() (http://bugs.winehq.org/show_bug.cgi?id=20071) so I could do this tidly, but those were dismissed.
As regards security Wine reading /dev/cpu/<n>/msr is no different to SIV reading them.
I suspect what I really need is a "semi-linelib" app. What would be ideal for me is a winelib.dll that allowed me to load and call native *nix functions, but from a Windows .exe.
Currently I am tempted to simply stop bothering to fix SIV run well on Wine
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #11 from red-ray ray@pobox.co.uk 2009-09-25 03:22:20 --- Created an attachment (id=23739) --> (http://bugs.winehq.org/attachment.cgi?id=23739) Screen Caprure showing MSRs read using the messy work-a-round
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #12 from red-ray ray@pobox.co.uk 2009-09-25 06:00:20 --- (In reply to comment #8)
Windows is no different in this regard. See e.g. http://blogs.msdn.com/oldnewthing/archive/2009/09/24/9898728.aspx
Windows is different. On windows, with appropiate access rights, I can run my kernel driver in kernel mode and read the MSRs.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2009-09-25 06:34:21 --- If you want to run your kernel driver in kernel mode you need something like Linux unified kernel. If all you really want is to emulate RDMSR then sure, you can do that in user mode, but you'd most likely get much better results by forgetting about the kernel driver completely, and writing a Linux-specific piece of code to retrieve all the system information through /sys etc. (which you can do from inside Wine). The low-level info you get through kernel functions in Wine will never be accurate, because we have to fake a lot of things.
And forget about mknod, you'll only be creating security holes. If the device doesn't exist in /dev just consider that you are not supposed to access it.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #14 from red-ray ray@pobox.co.uk 2009-09-25 09:19:45 --- (In reply to comment #13)
And forget about mknod, you'll only be creating security holes. If the device doesn't exist in /dev just consider that you are not supposed to access it.
Reading MSRs is all I ever wanted to do, but seem to have spend the last couple of weeks basically being told I should not be doing this in one way or another. I could have a *nix kernel driver, but loading this from wine would be tricky and total overkill just to read MSRs.
I think this all really comes down to you think SIV should not be using mknod() and I know SIV should. Because you think SIV should not use mknod() you are basically not going to enable SIV to call mknod() in a tidy manor by exporting a function SIV can use. That is your decision and I will just have to live with it. I will however state me understanding that Wine is meant to be a layer to enable Windows programs to be run on *nix and to the best of my knowledge it is not meant to provide an extra security layer for *nix which now seems to be the main reason for refusing to add wine_mknod().
Currently the same SIV.exe binary runs on all of Windows 95 through to Windows Server 2008 R2. It has a set of Kernel Mode Drivers for x86, x64, ia64 and Alpha and loads the appropriate one enabling either MSRs to be read or the PAL to be queried along with PCI configuration space to be read using HalGetBusDataByOffset(). The SIV 4.02 beta also runs very well on Wine using work-a-rounds to read MSRs, PCI configuration space and /dev/mem. I would like to tidily create and remove /dev/cpu<n>/msr devices by using mknod() and unlink() function calls.
To simply read the MSRs then /dev/cpu/<n>/msr devices need to exist and telling SIV users that they need to issue mknod commands to create them before running SIV is a far from an ideal situation. Many will get the commands wrong, miss some of the CPUs and also fail to delete them after using SIV, so if a user chooses to run SIV as root then I see no good reason why I should not create these using mknod. This is much less of a risk in terms of security than loading my kernel driver on Windows which SIV has been doing successfully for several years. SIV will create the /dev/cpu/<n>/msr devices with mode 600 protection, thus only root can access them so is no extra security risk, further it will also remove these on exit.
My Decision is that SIV is going to use mknod. This will be either as I do currently by sending /bin/mknod and /bin/rm commands to the shell or by an mknod() type function being added and unlink() and/or DeleteFile() being fixed. I would much prefer using function calls as this is the "right" way to do this, which is why I asked for wine_mknod() in the first place. I strongly feel that the "right" solution is invariably the best solution. I am really quite surprised that wine_mknod() was not just implemented.
In my position what would you do ? Have SIV not able to read MSRs at all or send commands to the shell ?
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2009-09-25 10:22:46 --- The "right" solution is not to use mknod. On any decent distro the devices will be created automatically anyway, and running Windows apps as root is a bad idea.
Not exporting mknod is not because of security, but because it doesn't scale. Obviously mknod by itself is a small thing, but there are 300 system calls and 2000 libc functions for which you could make the same argument, many of which would actually be a lot more useful than mknod which is not something a normal app is supposed to use. There are many ways to address that issue, you can use system(), you can use direct syscalls, you can write a Winelib dll, you can add RDMSR emulation in Wine, or you can just do the right thing and not try to create the device at all. None of these require adding and maintaining Wine-specific exports.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #16 from red-ray ray@pobox.co.uk 2009-09-25 11:50:18 --- (In reply to comment #15)
OK, we need a general solution that will work for ALL of these and will not be an excessive burdon on Wine. How about having Wine export:
void *wine_dlopen(const char *filename, int flag); char *wine_dlerror(void); void *wine_dlsym(void *handle, const char *symbol); int Wine_dlclose(void *handle);
That way all the native *nix functions would be simply available to any Windows application that decided to use then.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #17 from red-ray ray@pobox.co.uk 2009-09-25 12:22:04 --- (In reply to comment #15)
you can add RDMSR emulation in Wine
Please will you clarify the sitwation on adding RDMSR emulation to Wine ? For this to be any better then my current work-a-round the emulation would need to call mknod(), I doubt if you would accept such a patch, but I feel I would ask.
http://bugs.winehq.org/show_bug.cgi?id=20098
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |WONTFIX
--- Comment #18 from Juan Lang juan_lang@yahoo.com 2009-09-25 12:43:37 --- (In reply to comment #12)
Windows is different. On windows, with appropiate access rights, I can run my kernel driver in kernel mode and read the MSRs.
Well, of course you can load a kernel driver in kernel mode in Windows. My point isn't that reading an MSR is security sensitive, but that loading any code in kernel mode is. Wine isn't any more privileged than any other *nix program, and can't do it for you. Loading a kernel driver in kernel mode is simply impossible for Wine to accomplish. Only the kernel can.
Emulating reading an MSR is a workaround to loading your driver in kernel mode. I hope you can find one that works for you, but loading a kernel driver in kernel mode isn't it.
http://bugs.winehq.org/show_bug.cgi?id=20098
red-ray ray@pobox.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |ABANDONED
--- Comment #19 from red-ray ray@pobox.co.uk 2009-09-25 14:42:01 --- (In reply to comment #18)
(In reply to comment #12)
This is goinf round and round in circles.
Lots of people are very keen on closing it but noone seems interested in actually finding a solution !
I give up !!!!!!!!!!!!!!!!!!!!!
http://bugs.winehq.org/show_bug.cgi?id=20098
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|ABANDONED |WONTFIX Alias|RDMSR |
--- Comment #20 from Jeff Zaroyko jeffz@jeffz.name 2009-09-25 14:52:41 --- Please leave the resolution alone, abandoned is for when it's not possible to reproduce the original bug because there is not enough information, software is unavailable for testing etc.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #21 from Alexandre Julliard julliard@winehq.org 2009-09-25 17:10:44 --- (In reply to comment #17)
(In reply to comment #15)
you can add RDMSR emulation in Wine
Please will you clarify the sitwation on adding RDMSR emulation to Wine ? For this to be any better then my current work-a-round the emulation would need to call mknod(), I doubt if you would accept such a patch, but I feel I would ask.
If you want to write a patch that opens /dev/cpu/msr if it exists, it might be accepted. Anything that calls mknod() wouldn't, because that's a silly thing to do. We don't call mknod() when opening disk or serial devices either, just like we don't call mount() when accessing /proc. These are part of the standard system setup, based on sysadmin policies, user apps have no business messing with that.
http://bugs.winehq.org/show_bug.cgi?id=20098
red-ray ray@pobox.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|WONTFIX |ABANDONED
--- Comment #22 from red-ray ray@pobox.co.uk 2009-09-25 18:02:58 --- (In reply to comment #20)
Please leave the resolution alone, abandoned is for when it's not possible to reproduce the original bug because there is not enough information, software is unavailable for testing etc.
OK, then you need a new option to express the hact there comes a time when I we have to agree to disagres and clode the bug. Currently ABANDONED is the best match to this.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #23 from red-ray ray@pobox.co.uk 2009-09-25 18:10:50 --- (In reply to comment #21)
(In reply to comment #17)
(In reply to comment #15)
you can add RDMSR emulation in Wine
Please will you clarify the sitwation on adding RDMSR emulation to Wine ? For this to be any better then my current work-a-round the emulation would need to call mknod(), I doubt if you would accept such a patch, but I feel I would ask.
If you want to write a patch that opens /dev/cpu/msr if it exists, it might be accepted. Anything that calls mknod() wouldn't, because that's a silly thing to do. We don't call mknod() when opening disk or serial devices either, just like we don't call mount() when accessing /proc. These are part of the standard system setup, based on sysadmin policies, user apps have no business messing with that.
You are rather good telling me what I should and should not be doing. Why not make a positive input, for a change, and tell me how I can read MSRs in some other way ? On Windows this is very easy, I load my kernel mode driver and it reads MSRs for me, surely this must be posile on Wine/*nix with equal ease.
http://bugs.winehq.org/show_bug.cgi?id=20098
--- Comment #24 from red-ray ray@pobox.co.uk 2009-09-25 18:13:40 --- (In reply to comment #18)
(In reply to comment #12)
Windows is different. On windows, with appropiate access rights, I can run my kernel driver in kernel mode and read the MSRs.
Well, of course you can load a kernel driver in kernel mode in Windows. My point isn't that reading an MSR is security sensitive, but that loading any code in kernel mode is. Wine isn't any more privileged than any other *nix program, and can't do it for you. Loading a kernel driver in kernel mode is simply impossible for Wine to accomplish. Only the kernel can. Emulating reading an MSR is a workaround to loading your driver in kernel mode. I hope you can find one that works for you, but loading a kernel driver in kernel mode isn't it.
I feel this simply shows you have now looked at how the request has progessed.
http://bugs.winehq.org/show_bug.cgi?id=20098
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Dmitry Timoshkov dmitry@codeweavers.com 2009-09-26 00:40:11 --- Let it be abandoned, although I already explained how it works in another bug.
Closing.
http://bugs.winehq.org/show_bug.cgi?id=20098
Saulius K. saulius2@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |saulius2@gmail.com
-
wine-bugs＠winehq.org