KeUserModeCallback
Andrey Valik
Are anybody use function KeUserModeCallback(...) ?
Pls, send description for me.
Bye and thanks
--
Andrey Valik, Papillon Systems.
mailto:v...@papillon.ru
Vadim V. Smirnov
Regards,
Vadim
"Andrey Valik" <v...@papillon.ru> wrote in message
news:10337073...@fionika.papillon.ru...
Maxim S. Shatskih
> Are anybody use function KeUserModeCallback(...) ?
The answer is - "tell me the name of your company and I will never use
your products" :-))
Such a solution is violation of fundamental OS design principles
described in any classic book, and thus cannot be welcomed. OK for lab
testing, unacceptable in commercial software.
The correct way is to write a kernel mode driver for a piece of
hardware where you need to handle interrupts. User mode code touching
hardware is not acceptable in serious (commercial or open source, but
not freeware, shareware or lab) products.
Max
Andrey Valik
>
> > Hi. I need to make fast interrupt handling in user mode.
> > Are anybody use function KeUserModeCallback(...) ?
>
> The answer is - "tell me the name of your company and I will never use
> your products" :-))
I d'nt want to force you use our product, it's your choice.
The name of my company at the end of letter.
>
> Such a solution is violation of fundamental OS design principles
> described in any classic book, and thus cannot be welcomed. OK for lab
> testing, unacceptable in commercial software.
>
> The correct way is to write a kernel mode driver for a piece of
> hardware where you need to handle interrupts. User mode code touching
> hardware is not acceptable in serious (commercial or open source, but
> not freeware, shareware or lab) products.
I've driver(writed by myself), but it will be better for me and other hihg-level programmers
to do anythink
in user-mode after interrupt as soon, as possible (independent of system overload).
If you do'nt have the answer - you do not need to make answer :).
--
+----------------------+
| Andrey V. Valik |
| Papillon Systems |
|Mailto:v...@papillon.ru|
+----------------------+
Walter Oney
> I've driver(writed by myself), but it will be better for me and other hihg-level programmers
> to do anythink
> in user-mode after interrupt as soon, as possible (independent of system overload).
> If you do'nt have the answer - you do not need to make answer :).
I can't speak for Max, but we see lots of similar requests by novice
programmers in these newsgroups, and they tend to become repetitive. The
NT line of operating systems is intended to provide a high level of
security and integrity. One of the design principles for the system is
that hardware should be handled entirely in kernel mode, and in response
to a limited set of user-mode API calls (ReadFile, WriteFile, and
DeviceIoControl).
Handling hardware interrupts in user mode is simply not something the NT
designers intended to let you do, and that's why you're having a hard
time figuring out how to do it. So don't. Take Max's advice and build or
buy a kernel-mode driver.
--
Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com
Michael S
> "Maxim S. Shatskih" wrote:
> >
> > > Hi. I need to make fast interrupt handling in user mode.
> > > Are anybody use function KeUserModeCallback(...) ?
> >
> > The answer is - "tell me the name of your company and I will never use
> > your products" :-))
>
> I d'nt want to force you use our product, it's your choice.
> The name of my company at the end of letter.
>
> >
> > Such a solution is violation of fundamental OS design principles
> > described in any classic book, and thus cannot be welcomed. OK for lab
> > testing, unacceptable in commercial software.
> >
> > The correct way is to write a kernel mode driver for a piece of
> > hardware where you need to handle interrupts. User mode code touching
> > hardware is not acceptable in serious (commercial or open source, but
> > not freeware, shareware or lab) products.
>
> I've driver(writed by myself), but it will be better for me and other hihg-level programmers
> to do anythink
> in user-mode after interrupt as soon, as possible (independent of system overload).
> If you do'nt have the answer - you do not need to make answer :).
Sorry, Andrey, but Max is absolutely right.
As the article posted above shows, you can't do anything useful with
this undocumented call.
Do you want to do anything in user-mode after interrupt as soon, as
possible ? Try the normal strategy:
On the Win32 side: create dedicated process with real-time priority
class, raise the thread priority to the maximum, issue ReadFileEx()
with completion routine and wait for completion with SleepEx() or
similar call.
On the device driver side: In the ISR prevent hardware from father
interrupting and issue DPC. In the DPC complete your IRP_MJ_READ.
That's all.
You would get very fast user mode interrupt response most of the time
(probably < 100us) and the worst case response of 10 to 30 ms, depends
on your CPU/memory, workload and installed device drivers. Plus you
callback is executed in the well-defined context !
By use of undocumented calls you may be (only may be) can improve
average interrupt response, but the worst case remains the same or
worse. Plus you know nothing about the context, so probably you can't
do anything more useful than profiling anyway and would resort to
PostMessage or SetEvent for the real work.
Do you want better performance ? Do more work in the kernel mode
(DPC).
Now let's talk about undocumented system calls in general.
Undocumented calls are fun. Sometimes they are good for development
type of products or in-house testing. But you have to avoid
undocumented system calls in any production system which is supposed
to be shipped to innocent customers. The same applies to the knowledge
about undocumented fields in the system data structures.
Michael S
>
> Such a solution is violation of fundamental OS design principles
> described in any classic book, and thus cannot be welcomed. OK for lab
> testing, unacceptable in commercial software.
>
> The correct way is to write a kernel mode driver for a piece of
> hardware where you need to handle interrupts. User mode code touching
> hardware is not acceptable in serious (commercial or open source, but
> not freeware, shareware or lab) products.
>
> Max
Not a big fan of JUNGO, aren't you ? :)
Andrey Valik
?????????: news:f881b862.02100...@posting.google.com...
I'm sorry, it was incorrect question about interrupt handling,
I'm already have my WDM with ISR and DPC routines and notification
with kernel-mode event. I was try notification with user-mode APC,
but other programmer (who will use my WDM and DLL) may call Sleep(...),
in this case APC will not be running (is it true ?). And in some document I
see than KeUserModeCallback "much quicker than the APC, named event or
pending IRP mechanisms allow". I did not try raise thread ptiority. 1ms
will do enough for me.
Thanks for help.
Andrey Valik
?????????: news:f881b862.02100...@posting.google.com...
I'm too.
Maxim S. Shatskih
> but other programmer (who will use my WDM and DLL) may call
Sleep(...),
And who will allow him doing this? :-))) Not an experienced lead
developer for sure.
The correct way is to send an overlapped DeviceIoControl call, which
will be completed by the driver when something will occur. SERIAL does
this, for instance.
You can then wait on OVERLAPPED.hEvent or use IO completion port - up
to your tastes.
This practice is the best since you will be able not only to signal,
but also to transfer some bytes from driver to the app which will
accompany the signal.
> in this case APC will not be running (is it true ?).
SleepEx(...TRUE) will be interrupted by the APC, as it is explicitly
documented on MSDN.
Max
nucleus
>"Michael S" <already...@yahoo.com> ???????/???????? ? ????????
>?????????: news:f881b862.02100...@posting.google.com...
>> "Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
>news:<ann5u6$k24$7...@gavrilo.mtu.ru>...
>> >
>> > Such a solution is violation of fundamental OS design principles
>> > described in any classic book, and thus cannot be welcomed. OK for lab
>> > testing, unacceptable in commercial software.
>> >
>> > The correct way is to write a kernel mode driver for a piece of
>> > hardware where you need to handle interrupts. User mode code touching
>> > hardware is not acceptable in serious (commercial or open source, but
>> > not freeware, shareware or lab) products.
Does it mean you are changing your position
on "ndis hooking driver" as reflected on OSR
durning december 2001?
I recall you were a proponent of the most blatant
hacking going as far, as to patch the executable
on the fly in order to "hook" the jump vector
tables.
Microsoft's representative clearly stated that these
techniques, based on reverse engineering of some
existing products are not recomended by ANY means.
Their recomendation was to use the passthru approach,
which is intermediate driver instead of hacking into
various kernel structures and stomping on routine
vectors.
nucleus
>?????????: news:f881b862.02100...@posting.google.com...
>> "Maxim S. Shatskih" <ma...@storagecraft.com> wrote in message
>news:<ann5u6$k24$7...@gavrilo.mtu.ru>...
>> >
>> > Such a solution is violation of fundamental OS design principles
>> > described in any classic book, and thus cannot be welcomed. OK for lab
>> > testing, unacceptable in commercial software.
Max, do you have two faces?
One more time:
You were a proponent of the worst kernel hacking
imaginable with your support for "NDIS Hooking Filter Driver"
approach, on OSR ntdev groups during december 2001,
which violates the most fundamental O/S principles
imaginable including consistency issue and the very
idea of O/S being the controlling system.
Once YOU start "controlling" some O/S aspects
and interfering with the principles of overall
O/S operation and implied principles,
you can no longer assume the stability of O/S.
The very idea of "hooking" the NDIS wrapper
is violation of some of the most fundamental
criterias in O/S operation.
Some of the "solutions" to the inherent problem
of patching the image in memory is memory protection
issue. Manipulating the CPU bits and disabling
the memory protection is probably one of the most
insane ideas imaginable.
Furthermore, "hooking" the NDIS can produce
nothing but the most severe consequences.
NDIS has never been designed with assumptions
that it is not in control.
Once some external agent takes control of the
NDIS subsystem, no one can guarantee ANYTHING.
ANY application may break and any other consequences
imaginable may result.
We are not talking about the issues of these
kind of programs completely breaking with the
next release of Windows service packs conting
different versions of the undocumented kernel
structures.
The reasons some kernel structures are not
documented is because they are not meant
to be manipulated directly.
Max, you better answer this quesion.
You have ignored the original post.
But the issue is not going to go away.
It will hunt you.
Maxim S. Shatskih
principles
> >> > described in any classic book, and thus cannot be welcomed. OK
for lab
> >> > testing, unacceptable in commercial software.
>
> Max, do you have two faces?
>
> One more time:
>
> You were a proponent of the worst kernel hacking
> imaginable with your support for "NDIS Hooking Filter Driver"
> approach, on OSR ntdev groups during december 2001,
> which violates the most fundamental O/S principles
> imaginable including consistency issue and the very
> idea of O/S being the controlling system.
First of all, NDIS hooking (which I consider to be a good idea, but
only if there is ABSOLUTELY no other ways) is not mine idea.
Second - can you compare hooking somewhere inside the kernel-only
structures - to making holes in kernel/user boundary just due to
"speed" (aka laziness)?
> The very idea of "hooking" the NDIS wrapper
> is violation of some of the most fundamental
> criterias in O/S operation.
Please note what _fundamental_ criterias are violated. Kernel-user
boundary is not violated, and DLPORTIO and such do violate it.
DLPORTIO muzdie. As must Kei386xxxIoAccessBitmap syscall. Let the
lazybones and script kiddies write real kernel mode drivers.
I can even suggest syscalls hooking for some tasks - like "block some
EXEs from running" - but surely not DLPORTIO.
Max
nucleus
>> >> > Such a solution is violation of fundamental OS design
>principles
>> >> > described in any classic book, and thus cannot be welcomed. OK
>for lab
>> >> > testing, unacceptable in commercial software.
>>
>> Max, do you have two faces?
>>
>> One more time:
>>
>> You were a proponent of the worst kernel hacking
>> imaginable with your support for "NDIS Hooking Filter Driver"
>> approach, on OSR ntdev groups during december 2001,
>> which violates the most fundamental O/S principles
>> imaginable including consistency issue and the very
>> idea of O/S being the controlling system.
>
>First of all, NDIS hooking (which I consider to be a good idea,
This looks not far from insane.
Can you prove that NDIS hooking will not
impact system stability at the very least?
Can you prove that NDIS and all the programs,
drivers, using it, will function as expected?
Where is it in Microsoft documentation
do you have a reference supporting your claim?
Are you talking about hacking or professional
product development?
>but
>only if there is ABSOLUTELY no other ways) is not mine idea.
It does not matter if "there is no other way".
By the same token, you may justify modifications
of the CPU registers to support all sorts of hacks.
Secondly, there IS a clearly stated way of doing it,
as expressed by the Microsoft representative,
and that is Intermediate driver approach.
It all works fine. Not a single problem with it,
at least from the standpoint of compatibility,
stability, consistency or violations of the
principles of the O/S as such.
Yes, there are some unpleasant side effects
in Microsoft's approach and I am not here to
argue any of it.
But...
There are some KEY issues in O/S design and
operation. Once you ignore them, prepair to
face the consequences.
Secondly, it does not matter whose idea it was.
There is no claim that it was YOUR idea.
There is only a claim you were supporting it.
Now, supporting these kinds of most blatant hacks
constitutes the most blatant violations of the
very core issues of the O/S design.
Are you going to argue this case?
>Second - can you compare hooking somewhere inside the kernel-only
>structures - to making holes in kernel/user boundary just due to
>"speed" (aka laziness)?
You are not to hook the kernel unless you are
but a hacker.
No professional product may violate this principle
unless they are but insane.
You'll sooner go out of business,
than you succeed with your product.
Simple as it gets.
Microsoft is not but a bunch of idiots
that have no clue of what they are talking about.
So far, you are not on Microsoft team.
One more time: You are not to "hook: the kernel
unless you are but a hacker.
You can not violate the most fundamental issues
of the O/S design becase, first of all, I doubt
you have the necessary competence to prove
the kernel will have the same stability
and consistency.
I hope you understand the issue of consistency
even though you seem to comment on nearly every
single issue related to kernel design.
CAN you prove the modifications you were supporting
with this "hooking" NDIS wrapper approach
will not impact the O/S in the most profound ways?
I'd LOVE to see that proof.
I doubt you have enough intelligence to prove
that hooking the NDIS wrapper is but insane,
or DO you?
I have personally seen the ZonaAlarm product
crashing the kernel. I did not look up at what
they are doing specifically, but I can guarantee
you they are doing something you are supporting.
Once ZoneAlarm was deinstalled, the kernel had
no crashes. Now, the system configuration had
no problems of ANY kind and the ONLY product
that would cause kernel to crash was ZoneAlarm.
Their so called pattent is nothing but a hack.
Because it does not utilize the interfaces exposed
with the O/S documentation.
Any fool can hack the kernel and find some way
of achieving his goals, whatever they are.
But that does not imply that these things may
be utilized by the professional products.
>> The very idea of "hooking" the NDIS wrapper
>> is violation of some of the most fundamental
>> criterias in O/S operation.
>Please note what _fundamental_ criterias are violated. Kernel-user
>boundary is not violated, and DLPORTIO and such do violate it.
The most fundamental criteria that was violated
is using the kernel in the way it was not designed.
In order for the kernel to remain stable,
there needs to be an equivalent of mathematical
proof of consistency of operations, which requires
a proof of some sort. You need to PROOVE that what
you are suggesting is not going to break the whole
underlying logic and principles.
It is but impossible to prove that hooking the
NDIS wrapper or ANY component of NDIS subsystem
in the way not documented will assure the consistency
and stability of an overall system and the programs
using that kernel.
NDIS has NEVER been meant to be taken control of
by some external driver or application.
I can just guarantee you that not a single person
from Microsoft or ANY developers of NDIS
will support you on this issue.
It is but one of the MOST fundamental violations.
Poking into internal kernel structures,
unless supported by design, is basically
invalidating the entire kernel.
Not a single kernel designer person in the whole world
will support you on this, in principle,
unless they are merely trying to hack the kernel.
In that case, no argument is valid,
because the principle "as long, as it 'works" applies".
>DLPORTIO muzdie. As must Kei386xxxIoAccessBitmap syscall. Let the
>lazybones and script kiddies write real kernel mode drivers.
Is this supposed to be an argument?
>I can even suggest syscalls hooking for some tasks - like "block some
>EXEs from running" - but surely not DLPORTIO.
You can suggest ANYTHING.
But ALL it is but a hack,
unless it is explicitly authorized by
the kernel designers.
First of all, there are portability issues.
Even if your hack seems to work with the present
version, it can not be guaranteed to work with
the very next service pack.
That is why those kernel structures were not
documented on the first place.
Kernel utilizes so many structures that may
potentially be hacked, it is but ming boggling.
Nevertheless, only certain structures and
interfaces are exposed and documented.
Even in Linux, that is not a commercial product,
you better understand what you are trying to
peek and poke.
No operating system can be totally protected
from hacks. Nevertheless, the hacks are just
that, the hacks, and may not be utilized by
any professional product unless you are willing
to face the consequences, some of which may be
your company is going out of business.
The Microsoft representative made his point
as clear, as it gets:
If you are a PROFESSIONAL developer, working
on a product to be released to public,
and you intend to SUPPORT that product,
the way to do it is an Intermediate driver
approacth.
You suggesions to Microsoft seem to be a result
of your misundestanding of what is what.
Yes, there ARE issues with NDIS
and the present approach as proposed by
Microsoft, may not be what all developers
would like to see, and I am not argue against
that, but the way you proposed to solve these
issues merely indicate your inability to
comprehend the issues.
And on this thread you are totally contradicting
your earlier position.
So, the question remains:
Do you have two faces?
Are you talking to hackers when you make
comments on O/S related issues,
or you are talking to the professional product
developers that have to take into account
some fundamental O/S and customer support
issues?
> Max
Jan Houska
I don't want to engage in the discussion who's the bigger hacker around
here, but this has caught my eye:
> DLPORTIO muzdie. As must Kei386xxxIoAccessBitmap syscall. Let the
> lazybones and script kiddies write real kernel mode drivers.
So, whats's wrong with a kernel-mode driver that detects an I/O mapped
device via PnP, then shows its I/O space to the application by
Ke386SetIoAccessMap and returns its I/O base address? Especially when
there's no way to kill the OS by directly accessing the device, like in
the case of a data acquisition board?
I think it may be more useful to write a device driver like this if the
device is very versatile and complex and you don't want to write zillion
kernel-mode functions (and forget to write a few but exactly those some
user will require soon). I don't say there's nothing wrong with this
approach but I don't see what it is. Could you please elaborate?
Thanks, Jan
====================================================================
Jan Houska HUMUSOFT s.r.o.
hou...@humusoft.com Novakovych 6
http://www.humusoft.com 180 00 Praha 8
tel: ++ 420 2 84011730 Czech Republic
fax: ++ 420 2 84011740
====================================================================
Tomas Whitlock
into NDIS drivers - but it seems rather silly to hound Max over this, and
ask him if he is "two-faced".
The advice he dispenses in this newsgroup is usually delivered in a
non-patronising manner :-) and although I lack experience, I haven't yet
been able to find major faults in anything he has said (that I understand).
If you think he is wrong or giving bad advice, then you could say so
politely and allow people to make up their minds on the matter. At the end
of the day, people come to this newsgroup with a problem and they get some
advice - it's their problem to decide whether it's good or bad!
regards
Tomas
"nucleus" <nuc...@invalid.you.are> wrote in message
news:ao4vko$bv2$1...@toster.Te.NeT.UA...
Maxim S. Shatskih
to NDIS hooking and ZoneAlarm was not by me, but by people who have
NDIS experience better then mine.
> I think it may be more useful to write a device driver like this if
the
> device is very versatile and complex
Divide it to subdevices :-)
>and you don't want to write zillion
> kernel-mode functions (and forget to write a few but exactly those
some
> user will require soon). I don't say there's nothing wrong with this
> approach but I don't see what it is. Could you please elaborate?
This will easily add to other apps having all access to all IN/OUT
instructions. A crash.
Max
nucleus
>Hi Max,
>
>I don't want to engage in the discussion who's the bigger hacker around
>here, but this has caught my eye:
>
>> DLPORTIO muzdie. As must Kei386xxxIoAccessBitmap syscall. Let the
>> lazybones and script kiddies write real kernel mode drivers.
This is one of the most arrogant ways to say something.
Again, the kernel was designed by the people,
who have their lives depending on it being a reliable
system.
There are reasons those people do not expose certain things
to the "mortals" and those reasons are most profound.
If we talk about kernel, we are talking, first of all,
about the very notion of a system.
The quesion naturally arises: What IS the system
and what are the most critical criterias?
Well, without going into details about what constitutes
a system as such, because the issue is complex and has
multitude of aspects and issues.
Nevertheless, we can state with certainty that certain
principles override all otheres.
The primary principle in ANY system, no matter what it
is is a principle of stability. It does not matter what
kind of system do you have if it crashes, or in technical
terms comes to a point of destruction.
Now, the principle of stability can not be assured
unless there is CONSISTENCY. This issue has been studies
to sufficient degree in the database design and theory.
The principle of consistency reduces essentially
to an issue of having multiple copies of the same data
accessible at the same time to different processes,
clients or threads.
Basically, you have the original and correct data in
a database. Once that data is used, it is copied to some
routine as some kind of argument. The problem arises
when that routine modifies the data and now we have
two different copies of the same data. It may happen
that some other process or routine may take the same
original data and modify some of it to update some
parameters. Now we have 3 different copies of the same
data and it is not clear which one is correct.
That is why there are synchronization primitives
in any multitasking operating system.
So, what we are dealing with here is the notion of
inconsistency, and, if there is inconsistency in the
system, the stability can not be assured.
That is the bare bone essense of the problem.
Once you start hacking around in the kernel,
not a single kernel designer will be able to guarantee
the original design and stability criterias.
No system can be 100% protected against any kind of
external interference.
That is the most profound definition of a kernel
being a system as such. In order for the system to
maintain its stability, no external influences may
exist.
You can not just hack the kernel in the ways it was
not designed to operate.
Period.
As far as "script kiddies" go, it is but the most
arrogant and elitist insult.
Pure disgrace.
nucleus
>I would not pretend to understand much of this as I've never needed to go
>into NDIS drivers - but it seems rather silly to hound Max over this, and
>ask him if he is "two-faced".
Because you do not know all the issues involved.
Just give you a hint, once you own stomach gets on line,
you'll get the idea of what is reality.
Right now, it appears you want a free lunch.
Little did you know it is but a poison.
>The advice he dispenses in this newsgroup is usually delivered in a
>non-patronising manner :-)
Not.
Just the other way around.
From what I have seen, the "advice" he provides
is delivered in the most cryptic and patronizing manner,
full of arrogance of "holier then thou".
True advice has to take into account the level of experience
of the person who is seeking that advice. The person has to
be able to digest that advice and go to the next level
with the minimal amount of pain. Otherwise, it is but an
excersize in sado-masochism.
But instead, what I have seen, is some kind of "word of god",
obviously being on a "higher" level then the seeker of that
advice, which merely translates into an issue of that seeker
getting some hint, but unable to proceed unless he suffers
further, going through the piles of often useless documentation
and wasting some major time before he can comprehend the
meaning and the essence of that "advice".
Merely typing a couple more sentences of either further
description, clarification, references to documentation,
or making any attempt to bridge the level of questioneer
with "how it is in the 'real world'" would make that
advice trully and genuinely supportive.
Why do you give any "advice"?
Just to spit into someone's face and show how "great"
you are?
Well, fine. You are great enough to provide that "advice".
But...
You are but a hacker essentially, giving not only "advice",
but spreading misinformation about the most fundamental
and critical issues in the very notion of operating system,
and, when your so called advice starts hurting the stomachs
of those, who make a genuine effort to stay in compliance
with the most fundamental principles of O/S as such,
beware.
One more time: beware.
I, personally, will do my best to expose your face
for what it trully is, and that picture isn't pretty.
Not pretty at all.
Ok, enough.
nucleus
<ma...@storagecraft.com> wrote:
>NDIS hooking does not open holes in kernel/user boundary. The praise
>to NDIS hooking and ZoneAlarm was not by me, but by people who have
>NDIS experience better then mine.
Praise?
About NDIS "hooking"?
By the people that are MORE experienced in NDIS
issues than you?
I can not believe what I am seeing here.
One more time: NDIS "hooking" is one of the most blatant
hacks imaginable. It will not be supported by the designers
of either kernel or NDIS.
Ask Microsoft's opinion on this,
and that opinion is ALREADY on the record.
I quote:
Thu, 27 Dec 2001 13:34:24 -0800
Author: "Bryan Burgin" <bbu...@microsoft.com>
Subject: RE: hook ndis under win2k like under Win9x
Brucie,
The hooking scheme in Windows 9x, as you pointed out, uses the VMM call
Hook_Device_Service to hook VxDCalls. This was never supported or
recommended -- but was a common solution that many vendors used.
And it failed to work without hooking additional services in
Windows ME because the Windows ME TCPIP stack, as a Windows
2000-based driver, doesn't use VxDCalls.
There is not a similar mechanism in Windows 2000/XP.
The proper model, even for Windows 98 and ME, is to use a
NDIS Intermediate Driver based off of the Windows XP DDK
sample PASSTHRU or MUX.
Hope this helps.
Bryan S. Burgin
bbu...@microsoft.com
bburgin x58049 40/2153
-----Original Message-----
From: brucie [mailto:bru...@263.net]
Sent: Thursday, December 27, 2001 5:48 AM
To: NT Developers Interest List
Subject: [ntdev] hook ndis under win2k like under Win9x
Hi, all
Under Win9x, we can use hook_device_service to implement
a pseudo-intermediate driver to filtering the ethernet packets.
How can it be done under win2k?
Please help me. Thanks
best regards
yours brucie
>> I think it may be more useful to write a device driver like this
>> if the device is very versatile and complex
>Divide it to subdevices :-)
>> and you don't want to write zillion
>> kernel-mode functions (and forget to write a few but exactly
>> those some user will require soon). I don't say there's nothing
>> wrong with this
>> approach but I don't see what it is. Could you please elaborate?
>This will easily add to other apps having all access to all IN/OUT
>instructions. A crash.
So will the NDIS "hooking" ugly hack,
no matter how many manufacturers resort to it
beause "there is no other way to do it".
The principles of O/S state:
If there is "no other way to do it",
then...
Well, then do not do it.
Simple, isn't it?
Oh, you want to add some "feature" that has not
underlying support in the kernel?
Too bad.
Your "feature" will be relying on a hack
and that will INEVITABLY cause the problems
with the kernel.
I have seen it with my own eyes
and I can GUARANTEE you the reason
for that blue screen was the "NDIS hooking".
"Hooking" NDIS involves what?
Well, you patch the executable on the fly,
modifying some jump vector tables,
which is TOTALLY illegal and that is PRECISELY
why do you have a protection, meant to invalidate
this very trick.
Otherwise, any trojan or virus may do just the same
and expose your system to insecurities you can not
even begin to imagine.
Starting with Win2k the Windows kernel was made
more ptotected against patching of system executables.
Furthermore, it has been commonly known at least
since Win95 that patching of instructions is a
bad, bad idea. Patching instructions was a common
practice during the age of 4 and 8 bit O/S,
which is stone age in terms of O/S theory.
You can not "hook" NDIS without effectively
doing patching.
Another issue is using the kernel internal data
structures that are not documented. The reason
they are not documented or exposed is that they
may change ANY time the O/S designer decides,
because they are not part of the interface
specification. They are not meant to be modified.
Kernel relies on these structures being totally
under exclusive control of the kernel. Once you
bring in some external influence, the kernel
stability can not and will not be guaranteed.
The consequences of modifications of those structure
could be, and in most cases, are the most dire,
and that is blue screen, kernel crash,
which is the worst thing imaginable.
As it has been already stated, the very principle
of consistency of data structures is violated.
Because the O/S may be using the copies of these
structures in some of its subsystems under assumption
they are not going to be modified by ANY external
process. These assumptions no longer hold.
Therefore, ALL sorts of problems may result,
leading INEVITABLY to breaking the kernel stability.
> Max
nucleus
Subject: Re: KeUserModeCallback
In article <ao6tbb$1u51$1...@gavrilo.mtu.ru>, "Maxim S. Shatskih"
<ma...@storagecraft.com> wrote:
>NDIS hooking does not open holes in kernel/user boundary. The praise
>to NDIS hooking and ZoneAlarm was not by me, but by people who have
>NDIS experience better then mine.
Praise?
I quote:
Brucie,
Hope this helps.
best regards
yours brucie
>> I think it may be more useful to write a device driver like this
>> if the device is very versatile and complex
>Divide it to subdevices :-)
>> and you don't want to write zillion
>> kernel-mode functions (and forget to write a few but exactly
>> those some user will require soon). I don't say there's nothing
>> wrong with this
>> approach but I don't see what it is. Could you please elaborate?
>This will easily add to other apps having all access to all IN/OUT
>instructions. A crash.
So will the NDIS "hooking" ugly hack,
Ralf Buschmann
wrote:
>Redirected from:
>Subject: Re: KeUserModeCallback
>
>In article <ao6tbb$1u51$1...@gavrilo.mtu.ru>, "Maxim S. Shatskih"
><ma...@storagecraft.com> wrote:
Can you please just shut up? You can have the flame war you are
obviously trying to create in private mails with Max. OTOH, if I were
Max, I'd just put you in my killfile.
*plonk*
Ralf.
Ian Bennetts
accessing o/s services. Anyone who critizes it is lacking o/s design
understanding and maybe brain washed by MS. Anyone who talks down to others
is a fool. Microsoft doesnt like it because they lose control of their bug
free o/s(ha ha). Linux has extensive call back hooks and it has not
suffered.
Ian Bennetts
It may be critizednews:ao6tbb$1u51$1...@gavrilo.mtu.ru...
Walter Oney
> Microsoft doesnt like it because they lose control of their bug
> free o/s(ha ha).
I doubt that it's a control issue. I think it's tolerably difficult to
setup a general mechanism for kernel-to-user callbacks that wouldn't
have bad performance or memory usage characteristics if widely used.
Among the problems I can see in just 30 seconds of thinking about it:
(1) Do we abandon the concept of having separate user-mode and
kernel-mode stacks for a given thread, which leaves the kernel at the
mercy of a bad app that uses most of the stack just before calling into
the kernel? Do we instead reserve several stacks to allow for callbacks,
recursive service calls, etc.? If so, how many, and what do we do when
we run out? Maybe we should thread through two stacks, which opens up
the possibility again that a service call will find insufficient room in
the kernel stack.
(2) Do we allow a callback from a privileged context, such as exists
when a driver is servicing a ZwXxx call from a trusted caller?
(3) How do we cope with the relatively high cost of ring transitions?
(4) How do we unwind errors? I.e., if an error occurs in a user-mode
callback, how do we prevent the user-mode program from unwinding past
the kernel-mode caller with a longjmp or something?
(5) Speaking of user-mode callbacks not returning, what do we do when a
user-mode callback simply decides to calculate pi exactly instead of
returning back to the kernel?
These problems can clearly be solved, but the Microsoft designers may
have deemed them too hard given the likely payback. Or they may have
found some show-stopper after thinking about the problem for longer than
30 seconds. Anyway, since my wife of 32 years and I can't read each
others' minds very well, I wouldn't want to be too categorical about
what was on the collective mind of a very large corporation.
Maxim S. Shatskih
or/and
> accessing o/s services. Anyone who critizes it is lacking o/s design
> understanding and maybe brain washed by MS. Anyone who talks down to
others
> is a fool. Microsoft doesnt like it because they lose control of
their bug
> free o/s(ha ha). Linux has extensive call back hooks and it has not
> suffered.
Callback hooks inside the kernel are more or less OK, but _callbacks
from kernel to user_ are evil, they are the main cause why "small"
Windows was so bad. Note our original subject is KeUserModeCallback.
It would be good for Windows world if MS would stop exporting such
functions from the kernel.
As about NDIS hooks. They are intended for Win9x platforms with their
poor IM support, and were very powerful. Surely, for w2k+ it is more
correct to write an IM, due to lesser issues with surrounding drivers,
and not due to any kinds of sacred cows.
As about Linux "not being suffered" - only due to Linus who is a good
enough manager to incorporate only the _really good_ code to official
kernel.
The number of hacks, patches and buggy software on Linux platform is
enormous, and they do not spoil the picture only because they are not
incorporated in the main distro used by the majority.
I would not be so untrue if I will say that _all_ GUI software on
Linux is buggy and unstable - all these KDEs and Gnomes. I have hit 2
or 3 of them in 5 minutes operating these IDEs.
Linux guys just do not loudcry on their bugs. The fact that Linux - up
to 2000 - could be crashed by setsockopt(SO_SNDBUF) with too large a
buffer size, since all their kmalloc() allocations were "must succeed"
and caused panic on failure - is amazing. Contemporary NT kernel was
much, much more stable, and "must succeed" pool allocations were long
ago unrecommended and finally deprecated in XP.
When Linux guys have found a bug - they silently fix it and make a new
release, when a bug is found in NT - then all of the world is
notified. But just read the Linux bug tracking forums - and you will
be amazed in how many bugs are in Linux.
For me, NT is just better engineered.
As about Linux "callback hooks" - maybe they exist in some mythology
only (the whole Linux thing is most mass-attitude- , mythology- and
religion- based, not technically based), the source code comments for
Linux USB stack tells us - "callbacks are evil". :-)
Max
Maxim S. Shatskih
> have bad performance or memory usage characteristics if widely used.
> Among the problems I can see in just 30 seconds of thinking about
it:
>
> (1) Do we abandon the concept of having separate user-mode and
It's really funny, but win32k often uses _these_ callbacks to call
WndProcs, which is easily recognizeable in WinDbg.
I can even understand why. WndProc can be called a) as a result of
DispatchMessage for incoming human-initiated event b) explicitly by
SendMessage c) as a side effect of some stuff in the window being
modified - like WM_SETTEXT, parent notifications and numerous other
cases.
For a) and b) cases, all can be done in user, and no kernel-mode work
is necessary for this. Not so with c) case. In this case, win32k calls
user-mode WndProc as a callback.
Surely all these issues do arise in this case too, and I think they
were solved one way or another. Anyway win32k is a bit special. It is
the window manager, and all callbacks it uses have some relation to
window management and cannot originate in ways beyound it.
Walter's item 1), for win32k, can be easily solved by win32k making a
callback only with very low kernel stack usage.
Item 2) - by always targeting the callback to the thread which owns
the window.
Beyound win32k, in just a general purpose driver, such mechanisms are
really dangerous. So, things like named event signaling (as for CD
insert) can be good. Things like pending IOCTL can be good if there
must be some message transferred with the indication, not just the
mere fact of indication itself. There are also user APCs, which is
similar by ancient UNIX's signals, but much more flexible. Too bad MS
did not document LPC ports for user-kernel communication. Can MS
people understand that forcing people to use KeUserModeCallback is
much worser then not opening LPC?
As about _callbacks_ (contrary to APCs, events or IOCTL completions),
where the following behaviour of the driver is put to dependency on
what the user app will do - they are just plain evil.
Driver -> app flow can only be as a stream of event notifications,
each with some piece of data possibly, but not the general call
mechanism.
Max