I have read teh article in OSR about Kernel mode DLLs.
I have the following questions…
Thanks in advance.
–
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, September 07, 2005 10:26 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Kernel Mode Vs User mode DLLs
I have read teh article in OSR about Kernel mode DLLs.
I have the following questions…
Thanks in advance.
–
Thanks for the quick response arlie. But I am convinced there should be a
better way of accomplishing this task.
lets take the example of an antivirus utility that attaches itself to the
FSD, so all calls for the FSD goes through it and it can use it’s kernel
mode DLL (or what ever) to scan.
But what about email attachments that it doesn’t (lets assume) filter and
uses the same scan algo to do it, if this happens in user mode, is ther an
elegant approach for the same?
This has been addressed hundreds of times. Read the list archives, use
Google.
Most of the solutions take this approach: The filtering algorithm runs in
user-mode, *always*. The kernel-mode component intercepts interesting FSD
calls, and routes them to the user-mode app. This lets you do whatever
crazy validation logic you want in user-mode, and keeps the kernel-mode
component as simple as possible. The kernel-mode component implements
mechanism; the user-mode component implements policy.
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, September 07, 2005 10:45 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Mode Vs User mode DLLs
Thanks for the quick response arlie. But I am convinced there should be a
better way of accomplishing this task.
lets take the example of an antivirus utility that attaches itself to the
FSD, so all calls for the FSD goes through it and it can use it’s kernel
mode DLL (or what ever) to scan.
But what about email attachments that it doesn’t (lets assume) filter and
uses the same scan algo to do it, if this happens in user mode, is ther an
elegant approach for the same?
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
to xxxxx@lists.osr.com
You are assuming that you will write a piece of code that has no functions
outside of its own. While doable this is not easy. For most of us, the
approach is to put the code into a user space service if possible and then
have the kernel do an inverted call for those services. Or the inverse
where the kernel code can be called by an IOCTL from the user code.
The odds of getting this code right so it can be shared, and keeping it
right as changes are needed, is exceedingly small.
–
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Remove StopSpam from the email to reply
“Developer” wrote in message news:xxxxx@ntdev…
Thanks for the quick response arlie. But I am convinced there should be a
better way of accomplishing this task.
lets take the example of an antivirus utility that attaches itself to the
FSD, so all calls for the FSD goes through it and it can use it’s kernel
mode DLL (or what ever) to scan.
But what about email attachments that it doesn’t (lets assume) filter and
uses the same scan algo to do it, if this happens in user mode, is ther an
elegant approach for the same?
Well I figure you’d have to use one of the call models… either normal
IOCTLs down or “inverted” to go between the user/kernel mode.
BR,
Rob Linegar
Software Engineer
Data Encryption Systems Limited
www.des.co.uk | www.deslock.com
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: 07 September 2005 15:45
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Mode Vs User mode DLLs
Thanks for the quick response arlie. But I am convinced there should be
a better way of accomplishing this task.
lets take the example of an antivirus utility that attaches itself to
the FSD, so all calls for the FSD goes through it and it can use it’s
kernel mode DLL (or what ever) to scan.
But what about email attachments that it doesn’t (lets assume) filter
and uses the same scan algo to do it, if this happens in user mode, is
ther an elegant approach for the same?
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed
to ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com
>Most of the solutions take this approach: The filtering algorithm runs in
user-mode, *always*. The kernel-mode component intercepts interesting FSD
calls, and routes them to the user-mode app.
Yes I know, I have rad it, the inverted call approach, right? But for a
system that is performance crytical, is this a good solution? Every time
shifting from kernel mode to user getting the job done and coming back…
This lets you do whatever
crazy validation logic you want in user-mode, and keeps the kernel-mode
component as simple as possible. The kernel-mode component implements
mechanism; the user-mode component implements policy.
You can remove the context switches by implementing it as a shared memory
region instead of context passed through Irps.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, September 07, 2005 9:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Mode Vs User mode DLLs
Most of the solutions take this approach: The filtering algorithm runs in
user-mode, *always*. The kernel-mode component intercepts interesting FSD
calls, and routes them to the user-mode app.
Yes I know, I have rad it, the inverted call approach, right? But for a
system that is performance crytical, is this a good solution? Every time
shifting from kernel mode to user getting the job done and coming back…
This lets you do whatever
crazy validation logic you want in user-mode, and keeps the kernel-mode
component as simple as possible. The kernel-mode component implements
mechanism; the user-mode component implements policy.
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
to xxxxx@lists.osr.com
as always, pete has come to end my woes, thanks pete, you are probably
referring toShared Memory Object Method right? As far as my knowledge goes
(and it is very limited), there are two ways to share memory between user
mode an kernel mode, one being IOCTL and the other using shared mmeory
obejcts like a named memory object (section object). Or we can use a named
memory object in user mode with *CreateFileMapping*. A driver can open the
same memory object, get a pointer to it.
Because the object is always mapped in the user address space (below
0x80000000) of a process (regardless of whether the object is created in
kernel mode or user mode) the address is valid only if it is accessed in the
context of the process. Every call to *MapViewOfFile* or to *
ZwMapViewOfSection* on the same memory object returns a different memory
address even for the same process. However microsoft doesnt recommended this
method because the scope of the address is limited to the process in which
the object is mapped, and it cannot be accessed in a DPC or ISR. Also, the
API to create a memory object in kernel mode is not documented in the DDK.
(This is MS text)
Also, to use the address at raised IRQL, such as in DPC or ISR, we have to
probe and lock the buffer pages and get a system virtual address
MmGetSystemAddressForMdl
So which one is the most optimesed???
This method is simple and easy only if the memory is going to be shared
between two or more user processes and one or more device drivers.
Otherwise, it is much easier and more efficient to use the IOCTL technique
for sharing memory between a user process and a device driver.
Don’t assume you have a performance problem with a design until you have
observed one. I don’t mean “design bad code,” I mean “performance is
complicated, and only empirical testing can prove a perf problem”. Too
often, people make a priori assumptions about performance that turn out to
be totally unconnected with reality.
Yes, context switches *can* be expensive. It depends on how much TLB
activity occurs on both sides of the swap. For example, if you switch to
your virus filtering process, and cause TLB misses on a handful of pages,
run your algorithm, and swap back, the overhead is not serious. But if you
fault in a large number of the pages in your process, then your overhead
increases significantly. Basically, locality of reference, as applied to L2
cache and TLB, dominates the expense of context swaps.
Get a profiler, and use it. Measure, measure, measure.
Also, consider the development time you will spend, building (and debugging)
one component twice. I guarantee that the pain of doing everything in
kernel-mode will be considerable, compared to the pain of debugging a
user-mode app.
Also, keep in mind that the cost of a transition from user-mode to
kernel-mode, or vice-versa, is negligible compared to the cost of switching
from one process to another (user-mode to kernel-mode, scheduling
transition, TLB flush, kernel-mode to user-mode).
– arlie
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, September 07, 2005 9:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Mode Vs User mode DLLs
Most of the solutions take this approach: The filtering algorithm runs in
user-mode, *always*. The kernel-mode component intercepts interesting FSD
calls, and routes them to the user-mode app.
Yes I know, I have rad it, the inverted call approach, right? But for a
system that is performance crytical, is this a good solution? Every time
shifting from kernel mode to user getting the job done and coming back…
This lets you do whatever
crazy validation logic you want in user-mode, and keeps the kernel-mode
component as simple as possible. The kernel-mode component implements
mechanism; the user-mode component implements policy.
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
i can see how that might get rid of the cost of moving the data to and
from user-mode to process it, but how would it remove the cost of
context switches? If you’re in kernel and you want user-mode code to
run you need to switch to a thread that’s in user-mode (costing you a
context switch).
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Wednesday, September 07, 2005 8:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Kernel Mode Vs User mode DLLs
You can remove the context switches by implementing it as a shared
memory region instead of context passed through Irps.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, September 07, 2005 9:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Mode Vs User mode DLLs
Most of the solutions take this approach: The filtering algorithm runs
in
user-mode, *always*. The kernel-mode component intercepts interesting
FSD
calls, and routes them to the user-mode app.
Yes I know, I have rad it, the inverted call approach, right? But for a
system that is performance crytical, is this a good solution? Every time
shifting from kernel mode to user getting the job done and coming
back…
This lets you do whatever
crazy validation logic you want in user-mode, and keeps the kernel-mode
component as simple as possible. The kernel-mode component implements
mechanism; the user-mode component implements policy.
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed
to ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a
blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
Developer wrote:
>Most of the solutions take this approach: The filtering algorithm runs in
>user-mode, *always*. The kernel-mode component intercepts
interesting FSD
>calls, and routes them to the user-mode app.
Yes I know, I have rad it, the inverted call approach, right? But for
a system that is performance crytical, is this a good solution? Every
time shifting from kernel mode to user getting the job done and coming
back…
Everyone believes their system is “performance critical”. The fact is,
almost none are.
The time spent filtering the packets will FAR overwhelm the kernel/user
transition time. This is a corollary of Amdahl’s Law. If the
kernel/user transition is taking 2% of your execution time, then even if
you completely eliminate the transition, you cannot improve your
performance more than 2%.
In return, leaving the filtering in user mode improves the
debuggability, reliability, and survivability of the resulting code. If
your solution saves 2% of execution time, but costs the user 45 minutes
of lost productivity because of one crash per week, you have resulted in
a net loss for the user.
I wish more programmers would learn this lesson. There ARE
considerations that are more important than raw performance.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Peter,
Yes, you are correct. In any method you are incurring a context switch
because initially you run in an arbitrary kernel thread context, which
blocks, waiting for a user mode thread to perform work for it then back
again. So, yes, there is always this context switch.
The approach I am referring to will only eliminate the Irp processing
incurred in both directions, the IOCtl calls along with the Irp completion
from kernel mode, when a request is to be processed in user mode. As many
have pointed out, most implementations suffer greater performance loss
because of what they are doing in user mode with the request, compared to
the actual mechanism used to communicate the request to user mode. I am
referring here to a well written interface.
I have found that implementing the communication layer using the well known
inverted call model along with a shared memory region for processing large,
for varying sizes of large, buffers is architecturally the least complex
while minimizing buffer copies.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Wieland
Sent: Wednesday, September 07, 2005 10:34 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Kernel Mode Vs User mode DLLs
i can see how that might get rid of the cost of moving the data to and from
user-mode to process it, but how would it remove the cost of context
switches? If you’re in kernel and you want user-mode code to run you need
to switch to a thread that’s in user-mode (costing you a context switch).
-p
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Scott
Sent: Wednesday, September 07, 2005 8:49 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Kernel Mode Vs User mode DLLs
You can remove the context switches by implementing it as a shared memory
region instead of context passed through Irps.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, September 07, 2005 9:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Mode Vs User mode DLLs
Most of the solutions take this approach: The filtering algorithm runs in
user-mode, *always*. The kernel-mode component intercepts interesting FSD
calls, and routes them to the user-mode app.
Yes I know, I have rad it, the inverted call approach, right? But for a
system that is performance crytical, is this a good solution? Every time
shifting from kernel mode to user getting the job done and coming back…
This lets you do whatever
crazy validation logic you want in user-mode, and keeps the kernel-mode
component as simple as possible. The kernel-mode component implements
mechanism; the user-mode component implements policy.
— Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256 You are currently subscribed to
ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email
to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com
You cannot. Yes, recompile the code (this is usually something algorithmic).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Developer
To: Windows System Software Devs Interest List
Sent: Wednesday, September 07, 2005 6:26 PM
Subject: [ntdev] Kernel Mode Vs User mode DLLs
I have read teh article in OSR about Kernel mode DLLs.
I have the following questions…
Thanks in advance.
–
This is lesser stable. The app can fill the shared region with junk and thus crash the kernel.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From: Peter Scott
To: Windows System Software Devs Interest List
Sent: Wednesday, September 07, 2005 7:49 PM
Subject: RE: [ntdev] Kernel Mode Vs User mode DLLs
You can remove the context switches by implementing it as a shared memory region instead of context passed through Irps.
Pete
Kernel Drivers
Windows Filesystem and Device Driver Consulting
www.KernelDrivers.com
(303)546-0300
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, September 07, 2005 9:04 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Kernel Mode Vs User mode DLLs
Most of the solutions take this approach: The filtering algorithm runs in
>user-mode, *always*. The kernel-mode component intercepts interesting FSD
>calls, and routes them to the user-mode app.
Yes I know, I have rad it, the inverted call approach, right? But for a system that is performance crytical, is this a good solution? Every time shifting from kernel mode to user getting the job done and coming back…
This lets you do whatever
>crazy validation logic you want in user-mode, and keeps the kernel-mode
>component as simple as possible. The kernel-mode component implements
>mechanism; the user-mode component implements policy.
— Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256 You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’ To unsubscribe send a blank email to xxxxx@lists.osr.com
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com