Hi everyone,
I am developing a virtual audio driver which sends audio data using a
kernel socket to a user space application which will stream the audio
data to a remote playback device.
At startup, the user space streaming application sends the socket port
number to which the kernel socket must connect to. From kernel, I
create a socket, bind it to a local transport address and connect it
using the socket port number sent from user space. I first send the
audio data format to configure the remote playback device, then I send
the audio data untill a new audio data format is set or the streaming
session is stopped.
During a streaming session, with WASAPI, audio format can be changed
from a third party application. In such case, the WskClose, WskSocket,
WskBind and WskConnect calls return STATUS_SUCCESS except for
WskConnect which returns STATUS_ACCESS_DENIED. When this sequence is
initiated from the same process who first created the socket, all calls
return STATUS_SUCCESS.
I guess I am passing incorrect parameters to WskSocket.
Should I store the PID of my user space streaming application and
always use this PID when calling WskSocket ?
Should I use the current process and set a specific SecurityDescriptor
when calling WskSocket ?
Thanks in advance for any tips !
Best regards.
Matth
> I am developing a virtual audio driver which sends audio data using a
kernel socket to a user space application which will stream the audio
data to a remote playback device.
Never, ever use this.
Do you want the firewall settings to break the internal communication mechanism in your app?
Use custom IOCTLs with inverted calls instead. It is also much simpler then Wsk.
–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
On 2016-06-28 11:47:21 +0000, Maxim S. Shatskih said:
> I am developing a virtual audio driver which sends audio data using
a> kernel socket to a user space application which will stream the
audio> data to a remote playback device.
Never, ever use this.
Do you want the firewall settings to break the internal communication
mechanism in your app?
I have not experienced such problems at the moment, could you tell me
more about that ?
Use custom IOCTLs with inverted calls instead. It is also much simpler
then Wsk.
Simpler or not, I have implement the whole mechanism using Wsk and I
won’t have enough time to do it from scratch again, maybe in a future
version but now, I have to keep this mechanism.
Thanks for your answers
Matthieu Collette wrote:
On 2016-06-28 11:47:21 +0000, Maxim S. Shatskih said:
>> I am developing a virtual audio driver which sends audio data using
> a> kernel socket to a user space application which will stream the
> audio> data to a remote playback device.
>
> Never, ever use this.
>
> Do you want the firewall settings to break the internal communication
> mechanism in your app?
I have not experienced such problems at the moment, could you tell me
more about that ?
Surely you can see how this happens. The Windows Firewall applies to
all UDP/TCP sockets, including those managed in kernel mode. If your
user decides to tighten up his firewall settings by closing off unknown
ports, your communication scheme is blocked.
> Use custom IOCTLs with inverted calls instead. It is also much simpler
> then Wsk.
Simpler or not, I have implement the whole mechanism using Wsk and I
won’t have enough time to do it from scratch again, maybe in a future
version but now, I have to keep this mechanism.
That’s not a very good reason to stay with a fundamentally flawed
design. If you had checked on user/kernel communication schemes before
you began, you would have known that it was a bad idea to begin with.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
On 2016-06-28 16:28:18 +0000, Tim Roberts said:
Hi Tim!
Matthieu Collette wrote:
> On 2016-06-28 11:47:21 +0000, Maxim S. Shatskih said:
>
>>> I am developing a virtual audio driver which sends audio data using
>> a> kernel socket to a user space application which will stream the
>> audio> data to a remote playback device.
>>
>> Never, ever use this.
>>
>> Do you want the firewall settings to break the internal communication
>> mechanism in your app?
> I have not experienced such problems at the moment, could you tell me
> more about that ?
Surely you can see how this happens. The Windows Firewall applies to
all UDP/TCP sockets, including those managed in kernel mode. If your
user decides to tighten up his firewall settings by closing off unknown
ports, your communication scheme is blocked.
Ok, I understand. I guess it is also true if I stay within a local network ?
>> Use custom IOCTLs with inverted calls instead. It is also much simpler
>> then Wsk.
> Simpler or not, I have implement the whole mechanism using Wsk and I
> won’t have enough time to do it from scratch again, maybe in a future
> version but now, I have to keep this mechanism.
That’s not a very good reason to stay with a fundamentally flawed
design. If you had checked on user/kernel communication schemes before
you began, you would have known that it was a bad idea to begin with.
I totally agree with you, and I am really grateful to be able to get a
lot of feedback from all the super experts you are here !
Knowing that the design is not good is a good reason for me to push for
a next iteration of the project I am working on.
At the moment I just can’t make such deep changes and even if it is not
perfect and has some limitations, it works.
So what process contexts are used for the successful case vs the failure
case?
Also did you pay close attention to this:
I*f a WSK application applies a security descriptor to a socket, the cached
copy of the security descriptor that is specified in the call toWskSocket
https:,
WskSocketConnect
https:,
or WskControlSocket
https:
is
not released when the socket is closed. A WSK application must release the
cached copy of the security descriptor by using the WSK_RELEASE_SD
https:
client
control operation when the security descriptor is no longer needed.*
https://msdn.microsoft.com/en-us/library/windows/hardware/ff571124(v=vs.85).aspx
Mark Roddy
On Tue, Jun 28, 2016 at 5:45 AM, Matthieu Collette <
xxxxx@free.fr> wrote:
> Hi everyone,
>
> I am developing a virtual audio driver which sends audio data using a
> kernel socket to a user space application which will stream the audio data
> to a remote playback device.
>
> At startup, the user space streaming application sends the socket port
> number to which the kernel socket must connect to. From kernel, I create a
> socket, bind it to a local transport address and connect it using the
> socket port number sent from user space. I first send the audio data format
> to configure the remote playback device, then I send the audio data untill
> a new audio data format is set or the streaming session is stopped.
>
> During a streaming session, with WASAPI, audio format can be changed from
> a third party application. In such case, the WskClose, WskSocket, WskBind
> and WskConnect calls return STATUS_SUCCESS except for WskConnect which
> returns STATUS_ACCESS_DENIED. When this sequence is initiated from the same
> process who first created the socket, all calls return STATUS_SUCCESS.
>
> I guess I am passing incorrect parameters to WskSocket.
>
> Should I store the PID of my user space streaming application and always
> use this PID when calling WskSocket ?
> Should I use the current process and set a specific SecurityDescriptor
> when calling WskSocket ?
>
> Thanks in advance for any tips !
>
> Best regards.
>
> Matth
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer>
></http:></https:></https:></https:></https:>
Hi Mark!
On 2016-06-28 17:53:15 +0000, Mark Roddy said:
So what process contexts are used for the successful case vs the failure case?Â
When I am in my streaming user space application process, everything
works as expected. Any other context will lead to an issue.
Also did you pay close attention to this:
If a WSK application applies a security descriptor to a socket, the
cached copy of the security descriptor that is specified in the call
toWskSocket, WskSocketConnect, or WskControlSocket is not released when
the socket is closed. A WSK application must release the cached copy of
the security descriptor by using the WSK_RELEASE_SD client control
operation when the security descriptor is no longer needed.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff571124(v=vs.85).aspx
Mark Roddy
On Tue, Jun 28, 2016 at 5:45 AM, Matthieu Collette
wrote:
> Hi everyone,
>
> I am developing a virtual audio driver which sends audio data using a
> kernel socket to a user space application which will stream the audio
> data to a remote playback device.
>
> At startup, the user space streaming application sends the socket port
> number to which the kernel socket must connect to. From kernel, I
> create a socket, bind it to a local transport address and connect it
> using the socket port number sent from user space. I first send the
> audio data format to configure the remote playback device, then I send
> the audio data untill a new audio data format is set or the streaming
> session is stopped.
>
> During a streaming session, with WASAPI, audio format can be changed
> from a third party application. In such case, the WskClose, WskSocket,
> WskBind and WskConnect calls return STATUS_SUCCESS except for
> WskConnect which returns STATUS_ACCESS_DENIED. When this sequence is
> initiated from the same process who first created the socket, all calls
> return STATUS_SUCCESS.
>
> I guess I am passing incorrect parameters to WskSocket.
>
> Should I store the PID of my user space streaming application and
> always use this PID when calling WskSocket ?
> Should I use the current process and set a specific SecurityDescriptor
> when calling WskSocket ?
>
> Thanks in advance for any tips !
>
> Best regards.
>
> Matth
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at
> http:</http:></http:></http:>
Hi guys,
I finally solved the problem.
I know for sure when I am called from my user space streaming
application. In this case I keep track of its EPROCESS structure and
use it when calling WskSocket.
I also add some logic to distinguish when I am called from another
process context and when my application is gone.
It works as expected so far.
Next step, get rid of the socket mechanism as you suggested me.