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 ?