Hello there, I’m coding an antivirus and I wanted to share memory between my driver and my usermode program, however, I don’t want polling.(no infinite loop checking in usermode)
So I chose using Sections: https://pastebin.com/CpQHm6Jx
That’s the code I’m using, thanks anyways.
xxxxx@gmail.com wrote:
Hello there, I’m coding an antivirus and I wanted to share memory between my driver and my usermode program, however, I don’t want polling.(no infinite loop checking in usermode)
So I chose using Sections: https://pastebin.com/CpQHm6Jx
How does using sections solve that problem? There’s still no notification.
For this task, why not use the reliable, efficient, well-understood, and
well-supported mechanism, the so-call “inverted call”? Have your
user-mode app submit a series of ioctls, let the driver queue them up,
and have the app WaitForMultipleObjects. When something interesting
happens, the driver pops a request off the queue, fills it in, and
completes it. The completion wakes up the user-mode app.
I assume that ViewAddress is declared as PVOID and ViewProc is declared
as PSUSPICIOUS_PROCESS. Is it possible you forgot to copy it:
ViewProc = (PSUSPICIOUS_PROCESS)ViewAddress;
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Test most probably resides in the driver’s binary mapping and is therefore a kernel mode address accessible in arbitrary context.
ViewProc is accessible in the address space of the user app or the process that mapped the section.
ViewProc is a user mode address, so a __try/__except pair of blocks should solve the issue if ViewProc is not corrupted.
Note that you could map the section in the address space of the system process (during initialization or by means of a work item or worker thread), obtain an MDL for the mapping (IoAllocateMdl), lock down the pages (MmProbeAndLockPages), and finally obtain a system mapping with MmGetSystemAddressForMdlSafe. The driver can access the system mapping in arbitrary context (and at high IRQL if needed).
W. N.
The upper half of the address space is not the exclusive address space of the System process in Windows. It is shared by all processes by means of page table entries sharing. The OS that had an exclusive address space for the system process was 32 bit Mac OS X.
You can access a mapped view only in the context of a user process it was mapped in. If it happens that you are accessing it from another process you should do this inside
KeStackAttachProcess( P, A)
{
__try{
*uva = smth;
} __except (EXCEPTION_EXECUTE_HANDLER) {}
}
KeUnstackDetachProcess( A )
>The upper half of the address space is not the exclusive address space of the System process in Windows.
Using the system process is safer because you don’t have to worry about the PROCESS_HAS_LOCKED_PAGES bugcheck.
W. N.
I mapped my view into my driver’s current process so I guess it’s system process. Anyways I’m trying to change it’s contents inside of my driver. Later I would also pass it to the usermode app.
And @Tim Roberts but how would I make my driver “block” until it receives a signal from another routine(say CreateProcessNotifyEx) to make the driver continue to complete the IOCTL to let the usermode know about the process?
There is no “current process” for a kernel mode driver in Windows. But you can safely assume that driver’s DriverEntry is called in the System process context.
You driver is not equal to a process.
A user thread is blocked in the kernel mode on KeWaitForSingleObject by a driver in IRP_MJ_DEVICE_CONTROL routine.
See https://www.osr.com/nt-insider/2013-issue1/inverted-call-model-kmdf/ for
a description of the inverted call.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Thursday, May 25, 2017 2:29 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ZwMapViewOfSection’s BaseAddress is unaccessable
I mapped my view into my driver’s current process so I guess it’s system
process. Anyways I’m trying to change it’s contents inside of my driver.
Later I would also pass it to the usermode app.
And @Tim Roberts but how would I make my driver “block” until it receives a
signal from another routine(say CreateProcessNotifyEx) to make the driver
continue to complete the IOCTL to let the usermode know about the process?
—
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:>
xxxxx@gmail.com wrote:
And @Tim Roberts but how would I make my driver “block” until it receives a signal from another routine(say CreateProcessNotifyEx) to make the driver continue to complete the IOCTL to let the usermode know about the process?
You don’t block anything. You put the request in a queue, and then
return without completing it. When your event finally happens, you pop
the top request from the queue and complete it. The app’s completion
routine will get called, and off you go.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
@Don Burn But that article is meant for WDF, I’m using WDM…
It refers to an original article that is WDM. Also, the principals are the
same.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
Sent: Friday, May 26, 2017 3:55 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ZwMapViewOfSection’s BaseAddress is unaccessable
@Don Burn But that article is meant for WDF, I’m using WDM…
—
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:>
When you have a BSOD, report, at least, the BSOD code and its 4 parameters along with the call stack. There could be a lot of reasons why memcpy causes a bugchecks.
W. N.
Actually except in rare cases, anything less than the output of !analyze -v from WinDbg means any response to a question about a crash is just a wild ass guess.
Don Burn
Windows Driver Consulting
Website: http://www.windrvr.com
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@outlook.com
Sent: Friday, May 26, 2017 9:47 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] ZwMapViewOfSection’s BaseAddress is unaccessable
When you have a BSOD, report, at least, the BSOD code and its 4 parameters along with the call stack. There could be a lot of reasons why memcpy causes a bugchecks.
W. N.
—
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:>
> See https://www.osr.com/nt-insider/2013-issue1/inverted-call-model-kmdf/
for a description of the inverted call.
Please note that the “technology” that you are promoting is already sort of outdated - AFAIK, these days they’ve got a new one that is called 'big honking IRP". Basically, you just rely upon an IOCTL of METHOD_ DIRECT type that you never complete, effectively getting a shared memory buffer between an app and a driver. Ask Peter for more details.
Certainly, an access to it still has to be synchronised somehow, but this is already another story.
In fact, you can even use your beloved inverted calls for this purpose. However, beware - when I suggested something similar (in fact, exactly this very thing, but anyway) for the purpose of emulating SIGIO functionality under Windows 10 years ago Mr.Johnson from MSFT told me he could not see any advantage of using anything other than system-defined methods. What makes IRP completion " a system-undefined method" is just above me - you should ask Mr.Johnson about it…
In any case, I guess I can be proud of myself - after all,a trick that I suggested (and got bashed for at the time, of course) somehow turned into a “blessed technology” 10 years later. Funny,ugh…
Anton Bassov
You had a bugcheck most probably because you didn’t respect one of the most trivial rule in kernel developement: Never trust a user mode VA.
IIRC, like VirtualAlloc, ZwMapViewOfSection returns a 64k aligned user mode VA. The size of the struct is lower than PAGE_SIZE, so the mapping is one memory page large. Thus it’s size is PAGE_SIZE. Now you have all the needed informations to probe the memory region:
__try{
ProbeForWrite(ViewProc, PAGE_SIZE, 64K);
}
__except(EXCEPTION_EXECUTE_HANDLER){
// fail with
Status = GetExceptionCode();
}
Well wouldn’t it just fall into the except like everytime?
I think the problem is that I need to add the module base of the user mode application, I’ll try that and also probing for write when I get home.
Fascinating, as I certainly don’t recall working for Microsoft 10 years ago (nor specifics of the conversation or bashing of you on my behalf, though the latter details about the conversation I suppose I could have forgotten). Perhaps you mean someone else, or perhaps you have a reference (link) to the conversation in question?
Speaking generally, I don’t think that keeping a METHOD_DIRECT IRP pending is a “system-undefined method”, and it should work for some semblance of shared memory between a single app and a driver if correctly applied (which is the tricky part). All of the usual downsides of shared memory still apply - having to invent your own mechanism for signaling that the shared memory region needs to be examined, having to carefully capture the contents from the shared memory window, ensuring that nested notifications stack properly, ensuring that partially written data is not misinterpreted, ensuring that notifications are not lost when multiple become pending before the first is consumed (and that the proper memory barriers are in place for writes into the shared buffer), etc…
The inverted call mechanism has some nice attributes: It ensures that data attached to notifications from a driver to a user mode process are atomic with respect to the signal that there is data available to process, it can automatically leverage the completion port mechanism to distribute work user mode-side across a pool of worker threads, and consuming the resultant requests is simple and straightforward, and typically “safer”, with less to go wrong and less room for subtle problems that may only show up on stressed systems under load, and so on.
Now, while effort has taken to ensure that the underlying mechanisms are reasonably efficient from the system’s perspective, the niceties of a single pended IRP per request model do incur some amount of overhead. So too does the implementation of a shared memory window, which comes with a number of engineering trade-offs. Given the right specific circumstances, and with enough time spent implementing a shared memory mechanism to maximize performance while keeping it robust, I could certainly believe that it could perform better than the typical “inverted call” model. I can also believe that in many circumstances, the difference will be for all intents and purposes in the noise (or not substantially meaningful for the application), and the inverted call mechanism ends up being the more rational engineering choice due to simplicity of the model, with the engineering time to robustly implement a high performance shared memory mechanism being better spent on the unique capabilities of the driver.
So my advice would be to pick the best tool for the job, and to choose thoughtfully based on the situation. I would advise the simpler inverted call mechanism by default as a good enough “general purpose” choice, unless there are extenuating (hopefully data-backed) circumstances that show that it is inadequate. Just as with picking between TCP and UDP for an application’s network protocol, there is a greater freedom to specialize the implementation with UDP (as with a shared memory window), but in many (not all, but many) circumstances, this comes with substantial engineering costs to get the implementation right and properly tested under adverse conditions etc., and consequently, in many cases, not having to re-implement your own congestion control, sequencing, retransmit, etc. mechanisms is often well worth the potential lost performance of using TCP instead of UDP.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Saturday, May 27, 2017 3:38 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] ZwMapViewOfSection’s BaseAddress is unaccessable
> See https://www.osr.com/nt-insider/2013-issue1/inverted-call-model-kmdf/
> for a description of the inverted call.
Please note that the “technology” that you are promoting is already sort of outdated - AFAIK, these days they’ve got a new one that is called 'big honking IRP". Basically, you just rely upon an IOCTL of METHOD_ DIRECT type that you never complete, effectively getting a shared memory buffer between an app and a driver. Ask Peter for more details.
Certainly, an access to it still has to be synchronised somehow, but this is already another story.
In fact, you can even use your beloved inverted calls for this purpose. However, beware - when I suggested something similar (in fact, exactly this very thing, but anyway) for the purpose of emulating SIGIO functionality under Windows 10 years ago Mr.Johnson from MSFT told me he could not see any advantage of using anything other than system-defined methods. What makes IRP completion " a system-undefined method" is just above me - you should ask Mr.Johnson about it…
In any case, I guess I can be proud of myself - after all,a trick that I suggested (and got bashed for at the time, of course) somehow turned into a “blessed technology” 10 years later. Funny,ugh…
Anton Bassov
—
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:>
If the shared memory is structured as a ring buffer the mechanisms for
synchronization and data access are well known and understood and the
signalling can be entirely independent of the pended IRP. I don’t see
anything wrong with this approach.
Mark Roddy
On Tue, May 30, 2017 at 12:33 PM, Skywing
wrote:
> Fascinating, as I certainly don’t recall working for Microsoft 10 years
> ago (nor specifics of the conversation or bashing of you on my behalf,
> though the latter details about the conversation I suppose I could have
> forgotten). Perhaps you mean someone else, or perhaps you have a reference
> (link) to the conversation in question?
>
>
> Speaking generally, I don’t think that keeping a METHOD_DIRECT IRP pending
> is a “system-undefined method”, and it should work for some semblance of
> shared memory between a single app and a driver if correctly applied (which
> is the tricky part). All of the usual downsides of shared memory still
> apply - having to invent your own mechanism for signaling that the shared
> memory region needs to be examined, having to carefully capture the
> contents from the shared memory window, ensuring that nested notifications
> stack properly, ensuring that partially written data is not misinterpreted,
> ensuring that notifications are not lost when multiple become pending
> before the first is consumed (and that the proper memory barriers are in
> place for writes into the shared buffer), etc…
>
> The inverted call mechanism has some nice attributes: It ensures that
> data attached to notifications from a driver to a user mode process are
> atomic with respect to the signal that there is data available to process,
> it can automatically leverage the completion port mechanism to distribute
> work user mode-side across a pool of worker threads, and consuming the
> resultant requests is simple and straightforward, and typically “safer”,
> with less to go wrong and less room for subtle problems that may only show
> up on stressed systems under load, and so on.
>
> Now, while effort has taken to ensure that the underlying mechanisms are
> reasonably efficient from the system’s perspective, the niceties of a
> single pended IRP per request model do incur some amount of overhead. So
> too does the implementation of a shared memory window, which comes with a
> number of engineering trade-offs. Given the right specific circumstances,
> and with enough time spent implementing a shared memory mechanism to
> maximize performance while keeping it robust, I could certainly believe
> that it could perform better than the typical “inverted call” model. I can
> also believe that in many circumstances, the difference will be for all
> intents and purposes in the noise (or not substantially meaningful for the
> application), and the inverted call mechanism ends up being the more
> rational engineering choice due to simplicity of the model, with the
> engineering time to robustly implement a high performance shared memory
> mechanism being better spent on the unique capabilities of the driver.
>
> So my advice would be to pick the best tool for the job, and to choose
> thoughtfully based on the situation. I would advise the simpler inverted
> call mechanism by default as a good enough “general purpose” choice, unless
> there are extenuating (hopefully data-backed) circumstances that show that
> it is inadequate. Just as with picking between TCP and UDP for an
> application’s network protocol, there is a greater freedom to specialize
> the implementation with UDP (as with a shared memory window), but in many
> (not all, but many) circumstances, this comes with substantial engineering
> costs to get the implementation right and properly tested under adverse
> conditions etc., and consequently, in many cases, not having to
> re-implement your own congestion control, sequencing, retransmit, etc.
> mechanisms is often well worth the potential lost performance of using TCP
> instead of UDP.
>
> - S (Msft)
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:bounce-632080-39741@
> lists.osr.com] On Behalf Of xxxxx@hotmail.com
> Sent: Saturday, May 27, 2017 3:38 AM
> To: Windows System Software Devs Interest List
> Subject: RE:[ntdev] ZwMapViewOfSection’s BaseAddress is unaccessable
>
> > See https://www.osr.com/nt-insider/2013-issue1/inverted-call-model-kmdf/
> > for a description of the inverted call.
>
>
>
> Please note that the “technology” that you are promoting is already sort
> of outdated - AFAIK, these days they’ve got a new one that is called 'big
> honking IRP". Basically, you just rely upon an IOCTL of METHOD_ DIRECT type
> that you never complete, effectively getting a shared memory buffer between
> an app and a driver. Ask Peter for more details.
>
>
> Certainly, an access to it still has to be synchronised somehow, but this
> is already another story.
> In fact, you can even use your beloved inverted calls for this purpose.
> However, beware - when I suggested something similar (in fact, exactly this
> very thing, but anyway) for the purpose of emulating SIGIO functionality
> under Windows 10 years ago Mr.Johnson from MSFT told me he could not see
> any advantage of using anything other than system-defined methods. What
> makes IRP completion " a system-undefined method" is just above me - you
> should ask Mr.Johnson about it…
>
>
> In any case, I guess I can be proud of myself - after all,a trick that I
> suggested (and got bashed for at the time, of course) somehow turned into a
> “blessed technology” 10 years later. Funny,ugh…
>
>
>
> Anton Bassov
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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>
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: http:> 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:></http:></http:></http:>
Well, I don’t see anything wrong with this approach either. However, as we can see, some posters prefer to present their “Dr.Flounder -style” propaganda/hysteria as a sound technical analysis while blowing the existing minor issues totally out of the proportion…
Anton Bassov