File operations on a Windows Driver (character device)

File operations on a Windows Driver (character device)

[Alessio Faina]

Hello everyone,

I'm developing a port of a FreeBSD/Linux application that consists of
two parts: a kernel and a user land part.
The kernel part is build as a WDM driver and is compiled with VS2013
and WDK 8.1: the userspace is going to
be compiled under Cygwin for compatibility with user land programs
already written for other OSs.

My problem is that the user space program invokes Open(), ioctl(),
mmap/munmap(), select() and poll().

I've build a test Win32 app to open with CreateFile the DosDevice with
the "\\\\.\\uniioctl" name and everything goes fine,
but I've tried to do the same thing with Open(...) with a lot of
variants (\\DosDevice\\uniioctl, \dev\uniioctl....) but I'm
unable to open the character device. There is some way to do this?

For the second main problem, I need to do an mmap/munmap; I was
thinking to emulate this mechanism with an IOCTL
in the kernel module but doing so, I wouldn't be able to use the mmap
provided by Cygwin if I've understood how the
things are working; so I'm wondering how to cope with this problem;
there's some way to explicitly tell Cygwin where
to find the memory that needs to be allocated in userspace? How can I
do this in the kernel module?

Thanks everyone,

          -Alessio

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Larry Hall (Cygwin)]

On 05/18/2015 05:42 AM, Alessio Faina wrote:
> Hello everyone,
>
> I'm developing a port of a FreeBSD/Linux application that consists of
> two parts: a kernel and a user land part.
> The kernel part is build as a WDM driver and is compiled with VS2013
> and WDK 8.1: the userspace is going to
> be compiled under Cygwin for compatibility with user land programs
> already written for other OSs.
>
> My problem is that the user space program invokes Open(), ioctl(),
> mmap/munmap(), select() and poll().
>
> I've build a test Win32 app to open with CreateFile the DosDevice with
> the "\\\\.\\uniioctl" name and everything goes fine,
> but I've tried to do the same thing with Open(...) with a lot of
> variants (\\DosDevice\\uniioctl, \dev\uniioctl....) but I'm
> unable to open the character device. There is some way to do this?

Sorry I can't help with allot of specifics on your questions but I can
say that when using Cygwin, you are best off if you stick to POSIX syntax
and semantics and don't mix in Windows code and Windowisms.  That includes
path separators (i.e. use '/', not '\').  See this page in the User's Guide
for information on how Cygwin handles device emulation too:

<https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices>



-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Alessio Faina]

Ok thanks, I've been able to find the character device under
"/proc/sys/DosDevices/Global/deviceName"; now I'm stuck with the mmap
implementation; when I do mmap in the userland program it returns me
errno 19 (#define ENODEV      19  /* No such device */) obviously because
I haven't set anything in the kernel module; there's a way to make visible a
portion of memory to be used by the mmap in the kernel? The memory is Non Paged
and allocated with a ExAllocatePoolWithTag in 'win terms'.

2015-05-18 16:47 GMT+02:00 Larry Hall (Cygwin)
<reply-to-list-only-lh@cygwin.com>:
> On 05/18/2015 05:42 AM, Alessio Faina wrote:
>>
>> Hello everyone,
>>
>> I'm developing a port of a FreeBSD/Linux application that consists of
>> two parts: a kernel and a user land part.
>> The kernel part is build as a WDM driver and is compiled with VS2013
>> and WDK 8.1: the userspace is going to
>> be compiled under Cygwin for compatibility with user land programs
>> already written for other OSs.
>>
>> My problem is that the user space program invokes Open(), ioctl(),
>> mmap/munmap(), select() and poll().
>>
>> I've build a test Win32 app to open with CreateFile the DosDevice with
>> the "\\\\.\\uniioctl" name and everything goes fine,
>> but I've tried to do the same thing with Open(...) with a lot of
>> variants (\\DosDevice\\uniioctl, \dev\uniioctl....) but I'm
>> unable to open the character device. There is some way to do this?
>
>
> Sorry I can't help with allot of specifics on your questions but I can
> say that when using Cygwin, you are best off if you stick to POSIX syntax
> and semantics and don't mix in Windows code and Windowisms.  That includes
> path separators (i.e. use '/', not '\').  See this page in the User's Guide
> for information on how Cygwin handles device emulation too:
>
> <https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-posixdevices>
>
>
>
> --
> Larry
>
> _____________________________________________________________________
>
> A: Yes.
>> Q: Are you sure?
>>> A: Because it reverses the logical flow of conversation.
>>>> Q: Why is top posting annoying in email?
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Mark Geisert]

Alessio Faina writes:
> Ok thanks, I've been able to find the character device under
> "/proc/sys/DosDevices/Global/deviceName"; now I'm stuck with the mmap
> implementation; when I do mmap in the userland program it returns me
> errno 19 (#define ENODEV      19  /* No such device */) obviously because
> I haven't set anything in the kernel module; there's a way to make visible a
> portion of memory to be used by the mmap in the kernel? The memory is Non
Paged
> and allocated with a ExAllocatePoolWithTag in 'win terms'.

Does
http://stackoverflow.com/questions/29938573/accessing-kernel-memory-from-user-mode-windows
help to answer your question?  If it does, you'll still have to decide
whether to translate the Windows calls there into Cygwin calls or instead
just localize the Windows calls in one user-level module and leave
everything else to Cygwin.

..mark


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Alessio Faina]

Well.....I wrote and answered myself the question you pointed out that
is residing on stackoverflow....
It was my first option I thought of to pass the pointer to the virtual
address to the userland application but
I've been asked to mantain the architecture using open(), ioctl(),
mmap() etc.... so I don't know, it's a kind of
jolly to be played in case I won't be able to use the posix
architecture....but reading on forums/mailing lists...
I think I will be forced to use the kind of implementation I've
described in the SO question.
It seems that no-one ever have got the need to do something like I'm
trying to do.

2015-05-19 9:52 GMT+02:00 Mark Geisert <mark@maxrnd.com>:
> Alessio Faina writes:
>> Ok thanks, I've been able to find the character device under
>> "/proc/sys/DosDevices/Global/deviceName"; now I'm stuck with the mmap
>> implementation; when I do mmap in the userland program it returns me
>> errno 19 (#define ENODEV      19  /* No such device */) obviously because
>> I haven't set anything in the kernel module; there's a way to make visible a
>> portion of memory to be used by the mmap in the kernel? The memory is Non
> Paged
>> and allocated with a ExAllocatePoolWithTag in 'win terms'.
>
> Does
> http://stackoverflow.com/questions/29938573/accessing-kernel-memory-from-user-mode-windows
> help to answer your question?  If it does, you'll still have to decide
> whether to translate the Windows calls there into Cygwin calls or instead
> just localize the Windows calls in one user-level module and leave
> everything else to Cygwin.
>
> ..mark
>
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Mark Geisert]

Alessio Faina writes:
> Well.....I wrote and answered myself the question you pointed out that
> is residing on stackoverflow....

Oh, small world :)

> It was my first option I thought of to pass the pointer to the virtual
> address to the userland application but
> I've been asked to mantain the architecture using open(), ioctl(),
> mmap() etc.... so I don't know, it's a kind of
> jolly to be played in case I won't be able to use the posix
> architecture....but reading on forums/mailing lists...
> I think I will be forced to use the kind of implementation I've
> described in the SO question.
> It seems that no-one ever have got the need to do something like I'm
> trying to do.
> 
> 2015-05-19 9:52 GMT+02:00 Mark Geisert <XXXX <at> XXXXXX.XXX>:
> > Does
> >
http://stackoverflow.com/questions/29938573/accessing-kernel-memory-from-user-mode-windows
> > help to answer your question?  If it does, you'll still have to decide
> > whether to translate the Windows calls there into Cygwin calls or instead
> > just localize the Windows calls in one user-level module and leave
> > everything else to Cygwin.

Cygwin is entirely and intentionally in user space.  Most of its users don't
even need programming access to Windows user space, let alone kernel space.
 So yes, you're likely to be forging a new path.

If you get it working with toy Windows test programs, we *might* be able to
tell you how to convert it to Cygwin, if it's possible.  But the actual
figuring it out for Windows is outside the scope of what Cygwin is intended
to provide.

..mark


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Alessio Faina]

Yes.....it's really a little world :)

I've got the kernelspace part on github (
https://github.com/PicMelter/uniioShd.git ).
It consists of sys (the kernel module), testExe (loads/unloads on the
fly the module
in the kernel) and secondExe that just interact with the first
executable and the kernel
module if it is loaded. With the buildAll.bat if the WDK7.1 is
present, all the applications
are builded automatically.
There is a Cyg.c that represent my effort to connect to the module,
sending an ioctl and doing
an mmap.

I think that, even if it's a semplification of the program I'm
porting, this little project
is very close to what I'm trying to do with the main project.

As I read somewhere else, cygwin doesn't support custom ioctl on
custom modules, have I
understood well? This may explain why I'm never able to send any ioctl
to my module.

For the mmap part, well, I've tried to follow with gdb what Cygwin is
doing but II must admit
that at some point I just lose track of what it's doing.

If it's too messy, I can polish the code a little bit; consider that
it's the environment where I'm
always doing tests so rarely I have the time to clean the code...

   -Alessio

2015-05-20 3:19 GMT+02:00 Mark Geisert <mark@maxrnd.com>:
> Alessio Faina writes:
>> Well.....I wrote and answered myself the question you pointed out that
>> is residing on stackoverflow....
>
> Oh, small world :)
>
>> It was my first option I thought of to pass the pointer to the virtual
>> address to the userland application but
>> I've been asked to mantain the architecture using open(), ioctl(),
>> mmap() etc.... so I don't know, it's a kind of
>> jolly to be played in case I won't be able to use the posix
>> architecture....but reading on forums/mailing lists...
>> I think I will be forced to use the kind of implementation I've
>> described in the SO question.
>> It seems that no-one ever have got the need to do something like I'm
>> trying to do.
>>
>> 2015-05-19 9:52 GMT+02:00 Mark Geisert <XXXX <at> XXXXXX.XXX>:
>> > Does
>> >
> http://stackoverflow.com/questions/29938573/accessing-kernel-memory-from-user-mode-windows
>> > help to answer your question?  If it does, you'll still have to decide
>> > whether to translate the Windows calls there into Cygwin calls or instead
>> > just localize the Windows calls in one user-level module and leave
>> > everything else to Cygwin.
>
> Cygwin is entirely and intentionally in user space.  Most of its users don't
> even need programming access to Windows user space, let alone kernel space.
>  So yes, you're likely to be forging a new path.
>
> If you get it working with toy Windows test programs, we *might* be able to
> tell you how to convert it to Cygwin, if it's possible.  But the actual
> figuring it out for Windows is outside the scope of what Cygwin is intended
> to provide.
>
> ..mark
>
>
> --
> Problem reports:       http://cygwin.com/problems.html
> FAQ:                   http://cygwin.com/faq/
> Documentation:         http://cygwin.com/docs.html
> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Mark Geisert]

Alessio Faina writes:
> I've got the kernelspace part on github (
> https://github.com/PicMelter/uniioShd.git ).
> It consists of sys (the kernel module), testExe (loads/unloads on the
> fly the module
> in the kernel) and secondExe that just interact with the first
> executable and the kernel
> module if it is loaded. With the buildAll.bat if the WDK7.1 is
> present, all the applications
> are builded automatically.
> There is a Cyg.c that represent my effort to connect to the module,
> sending an ioctl and doing
> an mmap.
> 
> I think that, even if it's a semplification of the program I'm
> porting, this little project
> is very close to what I'm trying to do with the main project.
> 
> As I read somewhere else, cygwin doesn't support custom ioctl on
> custom modules, have I
> understood well? This may explain why I'm never able to send any ioctl
> to my module.
> 
> For the mmap part, well, I've tried to follow with gdb what Cygwin is
> doing but II must admit
> that at some point I just lose track of what it's doing.
> 
> If it's too messy, I can polish the code a little bit; consider that
> it's the environment where I'm
> always doing tests so rarely I have the time to clean the code...

First, a belated welcome to the Cygwin mailing list.  Second, may I ask that
you please follow the list's posting conventions?  That means...

No <https://cygwin.com/acronyms/#TOFU>.
And also <https://cygwin.com/acronyms/#PCYMTNQREAIYR>.
Thanks!

I looked at your GitHub code.  I'm not at all experienced with Windows
kernel interfacing though.  Are you saying that that Windows native code
works properly for you?  If it doesn't, we're not likely able to help (and
it's off-topic for this list).

If it works, then you have two options.  You are trying the first option,
which is to recode your test program for Cygwin line-by-line.  You're using
Cygwin ioctl() and mmap().  I looked at the Cygwin source for its ioctl()
and found that it's not likely to work for you.  If I'm reading it
correctly, it only supports some of the TCxxx terminal control ioctls. 
That's a show-stopper, so I didn't even check whether your use of mmap()
could work.

The second option you could try, is this:  Compile your existing Windows
native test program with gcc, thus making it a Cygwin program that calls
Windows syscalls.  Cygwin doesn't prevent use of Windows syscalls.  You
don't want to overdo it and collide with Cygwin's own internals, but
localized Windows syscalls can be OK.  There's a <windows.h> in the Cygwin
distribution; it's in /usr/include/w32api.  You may have minor issues
compiling and linking but those can be asked about here and more folks will
have insight on them.
HTH,

..mark


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On May 18 17:33, Alessio Faina wrote:
> Ok thanks, I've been able to find the character device under
> "/proc/sys/DosDevices/Global/deviceName"; now I'm stuck with the mmap
> implementation; when I do mmap in the userland program it returns me
> errno 19 (#define ENODEV      19  /* No such device */) obviously because
> I haven't set anything in the kernel module; there's a way to make visible a
> portion of memory to be used by the mmap in the kernel? The memory is Non Paged
> and allocated with a ExAllocatePoolWithTag in 'win terms'.

The problem is that the /proc/sys interface is only implemented for
very basic operations.  There's no ioctl and mmap implemented for
arbitrary devices in Cygwin.

To get your device working, you have to either implement support for it
in Cygwin, or you have to use native W32 or NT calls to access your
device.

Alternatively: Since you can open the device, read/write should be
possible.  If you implement all interaction with your device (send
comands, request map address, etc) in the driver as specially crafted
read/write calls, you should be able to communicate with it from Cygwin
applications without having to implement a Cygwin file handler.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: File operations on a Windows Driver (character device)

[Alessio Faina]

Thanks Mark and Corinna.
I'm sorry for the
<https://cygwin.com/acronyms/#TOFU> and
<https://cygwin.com/acronyms/#PCYMTNQREAIYR>.,
I wont make those mistakes in the future, I promise.

Returning on the issue, I've decided to open the device with the
open() provided by Cygwin
and then intercept the IOCTLs and change them with the Win32
DeviceIoControl (using
_get_osfhandle() for the handle of the device).
At this point I can even implement the mmap with an IOCTL without
problems as I explained
in a previous mail.
I cannot use the read/write calls because I need to access the kernel
memory directly with
the mmap; in this way I can get better performances.

The last (and main) problem I'm facing is the poll()/select(); I've
seen that doing a poll() on
this kind of device always returns "1" because in
select.cc->select_stuff::poll() the function
pointer s->peek is NULL and in that way the counter "n" is always increased.

What I need to do is something that can be compiled under VS2013 and
under Cygwin
for compatibility with applications already written for linux OS; I
was thinking to open a
WSK socket and associate it with every new "open" made from userspace so that a
userspace program can use the poll indifferently if compiled under Cygwin or
under a native environment.
What I don't know is if this way is a smart one or if there is a
clever way to do this:
have you got something to suggest?

Thanks very much everyone for the help

         -Alessio Faina


2015-05-27 14:09 GMT+02:00 Corinna Vinschen <xxx@cygwin.com>:
> On May 18 17:33, Alessio Faina wrote:
>> Ok thanks, I've been able to find the character device under
>> "/proc/sys/DosDevices/Global/deviceName"; now I'm stuck with the mmap
>> implementation; when I do mmap in the userland program it returns me
>> errno 19 (#define ENODEV      19  /* No such device */) obviously because
>> I haven't set anything in the kernel module; there's a way to make visible a
>> portion of memory to be used by the mmap in the kernel? The memory is Non Paged
>> and allocated with a ExAllocatePoolWithTag in 'win terms'.
>
> The problem is that the /proc/sys interface is only implemented for
> very basic operations.  There's no ioctl and mmap implemented for
> arbitrary devices in Cygwin.
>
> To get your device working, you have to either implement support for it
> in Cygwin, or you have to use native W32 or NT calls to access your
> device.
>
> Alternatively: Since you can open the device, read/write should be
> possible.  If you implement all interaction with your device (send
> comands, request map address, etc) in the driver as specially crafted
> read/write calls, you should be able to communicate with it from Cygwin
> applications without having to implement a Cygwin file handler.
>
>
> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Maintainer                 cygwin AT cygwin DOT com
> Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: File operations on a Windows Driver (character device)

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 644 bytes --]

On 05/27/2015 09:56 AM, Alessio Faina wrote:
> Thanks Mark and Corinna.
> I'm sorry for the
> <https://cygwin.com/acronyms/#TOFU> and
> <https://cygwin.com/acronyms/#PCYMTNQREAIYR>.,
> I wont make those mistakes in the future, I promise.

And yet, you did...

> 2015-05-27 14:09 GMT+02:00 Corinna Vinschen <xxx@cygwin.com>:
>> On May 18 17:33, Alessio Faina wrote:
>>> Ok thanks, I've been able to find the character device under

The whole point of the TOFU complaint is to highlight the desire to
avoid top-posting.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

Re: File operations on a Windows Driver (character device)

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

On May 27 17:56, Alessio Faina wrote:
> Thanks Mark and Corinna.
> I'm sorry for the
> <https://cygwin.com/acronyms/#TOFU> and
> <https://cygwin.com/acronyms/#PCYMTNQREAIYR>.,
> I wont make those mistakes in the future, I promise.
> 
> Returning on the issue, I've decided to open the device with the
> open() provided by Cygwin
> and then intercept the IOCTLs and change them with the Win32
> DeviceIoControl (using
> _get_osfhandle() for the handle of the device).
> At this point I can even implement the mmap with an IOCTL without
> problems as I explained
> in a previous mail.
> I cannot use the read/write calls because I need to access the kernel
> memory directly with
> the mmap; in this way I can get better performances.
> 
> The last (and main) problem I'm facing is the poll()/select(); I've
> seen that doing a poll() on
> this kind of device always returns "1" because in
> select.cc->select_stuff::poll() the function
> pointer s->peek is NULL and in that way the counter "n" is always increased.
> 
> What I need to do is something that can be compiled under VS2013 and
> under Cygwin
> for compatibility with applications already written for linux OS;

That's a problem.  For Cygwin to recognize a device it needs support in
CYgwin itself.  What you probably need to write is some kind of
userspace access library which translates the required POSIX calls to
Windows calls when accessing your device.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]