Re: Re: [ntdev] How to shoot a process from kernel driver

NTDEV
1

> This is all rather harsh for an OP who tells us that he is porting a

broken by design interface from Linux to Windows. He is not using Windows
terminology, but his intent is clear: there are concepts in my interface
that do not correspond to concepts in Linux or Windows IO models, so what
do I do when there are protocol violations in my interface model that
aren’t detected by the OS? In Linux, the answer was terminate the process
with a memory dump. In Windows, the answer is likely the same, but the
mechanism is different. In Windows, the best way to do this is to suspend
all threads of the process in question, inject a new one and have it raise
an untangled exception. This will invoke the default handler - it used to
be called Dr. Watson, but I have no idea what it might be called now - and
will generate a memory dump

My comments dealt with killing the process or thread using the
ZwTerminate… class of operations.

What you are proposing is reasonable, because it is a user-level solution.
I generally do not consider DLL injection to be a robust mechanism. But
it would be substantially more robust than killing the thread or process
from the kernel.

But how can a piece of code call I/O operations from two or more threads
if this is known to be erroneous? Solutions like this merely enable the
incompetent app writer to continue writing bad code “without
consequences”. In the psychobabble world, this is called “abusive
co-dependency”.

At some point, someone has to weigh the costs of supporting buggy code
against the costs of fixing that code.
joe

Sent from Surface Pro

From: xxxxx@flounder.com
Sent: ‎Monday‎, ‎May‎ ‎05‎, ‎2014 ‎5‎:‎58‎ ‎PM
To: Windows System Software Devs Interest List

The reasons for not doing this are technical. The moral decision is
whether or not to risk the inevitable technical failures that will
follow,
and weighing the risks of these consequences against the consequences of
not killing the threAd or pro ess.

As far as leaving a lock set that will deadlock the app…well, the app
is
buggy anyway. Screw it. And note that terminating a process has the same
effect on other processes. And what sort of fool would set a lock and do
a blocking or non-blocking I/O operation inside the lock? This already
would be less than Best Practice. You can, if you are careful, get away
with this; it happens a lot in the kernel. Observe the use of the word
“careful” in that sentence.

The “terminate” call of operations has very simple behavior: it places a
block of C4 in the control block and rubs like hell. When the C4
detonates, bits fly everywhere. And that’s the end of the thread or
process. No DLL_THREAD_DETACH notifications. No DLL_PROCESS_DETACH
notifications. No OnExit chains. Buffers which have not been flushed
are
lost. Pending. IRPs are. cancelled. How is this better than leaving a
buggy process still running?

Did you ever read the “fine print” when you try to terminate a process
via
Task Manager? The part a out “may cause system instability”? THAT’S the
technical reason. The rest is just deciding to avoid technical disasters
by not engaging in activities that can cause them.

The reason many of us say “I would not do that” is because we know the
potential consequences; the ones who say “I do that all the time, and it
always works” are really saying “I do that all the time, but either have
't experienced the failure modes, or I’ve ignored them” and they rarely
mean “I have been extremely careful to guarantee that Bad Things Cannot
Possibly Happen”. And what that usually translates is “For the N
possible
things that could go wrong. I am aware of, and provided for the N - k
things I am aware of”. As k approaches N, things get much dicier.
Joe

> On 05/05/2014 09:58 PM, Tracy Camp wrote:
>
>> I always find it a bit irritating when various folks claim something
>> can’t or shouldn’t be done simply because they wouldn’t themselves do
>> such a thing. Try and separate the moral viewpoint from the technical
>> viewpoint…
>
> Done.
>
>> Anyways, I think you might find that obtaining a handle to the process
>> object will enable you to call ZwTerminateProcess(). Pay careful
>> attention to the MSDN notes for the API about using a kernel handle if
>> you are going to do this.
>
> What I learn here is that there is no *easy* way, so I tend to simply
> not do it. Being blown off my stack does not sound like being easy.
>
> Thanks for the advice,
> Joerg
>
>>
>> t.
>>
>>
>> On Mon, May 5, 2014 at 12:53 PM, Jörg Faschingbauer
>> >
>>> wrote:
>>>
>>> On 05/05/2014 09:12 PM, Don Burn wrote:
>>>
>>> > There is no safe way to terminate a process from a driver, and
>>> this should
>>> > be avoided. Why would you want to kill the process, instead of
>>> just
>>> > rejecting the request?
>>>
>>> This is a valid option, no doubt.
>>>
>>> “Workflow ownership” violation, as it happens with their
>>> user/kernel
>>> interface, is an application bug. Killing has the advantage (in
>>> Linux)
>>> that I can load the resulting core dump into the debugger and
>>> immediately see what went wrong. Anyhow, if there is no safe way,
>>> then
>>> … well … I don’t mind so much.
>>>
>>> Can you give me pointers () where I can read up on why there’s no
>>> safe
>>> way? The project will keep me busy for some more time, and I feel
>>> better
>>> when I understand things.
>>>
>>> > Also, you state the driver will always be the top driver in the
>>> stack, why
>>> > do you think that? Also, that the request always comes from
>>> user
>>> mode.
>>> > While these are both likely conditions they certainly cannot be
>>> guaranteed,
>>> > and if this is important to you, you should be checking the
>>> requestor’s
>>> > mode.
>>>
>>> Later on, I’ll have to DMA into user allocated memory. As I
>>> understand
>>> this is only possible in a top level driver. Is this correct?
>>>
>>> () Is there a “The Book on Driver Programming”? I’ve read Helen
>>> Custer’s “Inside Windows NT” ages ago. I see there’s “Inside
>>> Windows
>>> 2000” (3rd Edition I believe), but that one is rather old too.
>>>
>>> Thank you,
>>> Joerg
>>>
>>> —
>>> NTDEV is sponsored by OSR
>>>
>>> Visit the list at:
>>> http://www.osronline.com/showlists.cfm?list=ntdev
>>>
>>> OSR is HIRING!! See http://www.osr.com/careers
>>>
>>> For our schedule of WDF, WDM, debugging and other seminars visit:
>>> http://www.osr.com/seminars
>>>
>>> To unsubscribe, visit the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>>
>>>
>>> — NTDEV is sponsored by OSR Visit the list at:
>>> http://www.osronline.com/showlists.cfm?list=ntdev OSR is HIRING!! See
>>> http://www.osr.com/careers For our schedule of WDF, WDM, debugging and
>>> other seminars visit: http://www.osr.com/seminars To unsubscribe,
>>> visit
>>> the List Server section of OSR Online at
>>> http://www.osronline.com/page.cfm?name=ListServer
>>
>>
>> —
>> NTDEV is sponsored by OSR
>>
>> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>>
>> OSR is HIRING!! See http://www.osr.com/careers
>>
>> For our schedule of WDF, WDM, debugging and other seminars visit:
>> http://www.osr.com/seminars
>>
>> To unsubscribe, visit the List Server section of OSR Online at
>> http://www.osronline.com/page.cfm?name=ListServer
>>
>
>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> —
> NTDEV is sponsored by OSR
>
> Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
> OSR is HIRING!! See http://www.osr.com/careers
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer