[Bug 20098] Wine should, when possible, provide the kernel mode environment for kernel mode drivers

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=20098





--- Comment #14 from red-ray <ray at 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 ?

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.