It would be better to create a memory buffer in the application and pass it to the kernel driver. If you do that as the second buffer of a METHOD_IN_DIRECT or METHOD_OUT_DIRECT ioctl, the I/O system will handle all of the locking for you.
This is a very common question/topic, and has been discussed to death on this forum. Take a look through the archives, please.
Peter
this is a classic mistake. there are ligitimate uses for a design with shared memory, but this should never be the first choice. search this list for extensive discussions on the topic
Hello,
Unfortunately I cannot do any modifications in the application. Only in the device driver.
So I cannot use METHOD_IN_DIRECT or METHOD_OUT_DIRECT ioctl as Tim suggested.
Is there an alternative ?
The size of the buffer is 4KB.
It is not used for DMA.
The driver writes data to the buffer and the application reads it.
Thank you,
Zvika
how do you expect it will be possible to produce anything that works if you cannot modify the application at all from a not working code base?
Mr. Bond is correct. Your design is flawed. It is nearly impossible for me to believe that you have an employer or a client who is willing to pay the price for kernel work but is not willing to consider application changes to correct a design flaw. That is a software product that deserves to die.
How do you communicate the address to user-mode? Surely they must already be making driver request. The modifications required to do the right way are nearly trivial.
Hi Tim, Mr.Bond,
I’m aware it’s sounds impossible but this is the client’s requirement.
The modifications required in the application are indeed trivial, but my client refuses to do them.
In the kernel I’m allocating a 32MB common buffer with the attached code (Allocated.txt)
This buffer is used for DMA initiated by FPGA into the physical address of this buffer.
It works fine. This buffer is fully mapped to user space.
My question:
If FPGA uses only 30MB out of 32MB, can I write data from kernel, not by DMA, in the upper 2MB ?
For example:
(UINT32)devExt->KernelCommonBuffer[0] = 0xCAFE2DAD;
Thank you,
Zvika
It is nearly impossible for me to believe that you have an employer or a client who is willing to pay the price for kernel work
but is not willing to consider application changes to correct a design flaw.
Consider the scenario of the OP’s client/employer using some third-party software, i.e of simply having no access to the source code of the program that they are using. Seems to be the usual case in the world of proprietary software, don’t you think…
That is a software product that deserves to die.
It may well be the case…
It is entirely possible that the authors of the software in question just went out of business, so that the OP’s clients/employers are using “abandonware”. This kind of scenario is not THAT uncommon in the world of proprietary software either, is it…
Anton Bassov
Anton, is correct about this. I’ve encountered situations where:
- The original source was lost for the application and the driver needed to be upgraded.
- The driver was for a specific piece of hardware, and the application was generic. The hardware needed and upgrade and the supplier of the original application did not want to change things so was going to charge an arm and a leg.
- The firm uses the same driver and has a large suite of applications that it runs.
It happens, you try to convince the client to be smart and fix the interface, but at times it is not possible.
Don Burn
yes, but he is asking about adding new functionallity - not just keeping an existing interface contract for compatibility, but writing some new data into some ‘unused’ portion of the buffer.
the trivial answer to this question is yes, if the buffer is not being used for anthing else, you can write data into it. but if that data is going to be useful, someone has to read it. And to read it, the application will have to be modified in some way to know how or what to do with it.
I never saw anything that he is doing more than taking an old crufty WDM driver and upgrading it to WDF. I’ve done this at least a half dozen times for clients, and many of them did not want to change anything. A common case was a 32-bit only driver that now needs to support 64-bit systems, but is at least for the short term going to use the old application.
Don Burn
My question:
If FPGA uses only 30MB out of 32MB, can I write data from kernel, not by DMA, in the upper 2MB
I am curious to know why you might think you couldn’t. It’s just memory. Neither side knows who wrote it.
It happens, you try to convince the client to be smart and fix the interface, but at times it is not possible.
Well, in some cases they may simply lack the technical knowledge for even understanding what you are actually saying…
For example, consider some CPU-intense financial app that gets developed by some financial institution for its in-house use.
Let’s say that this app either does all calculations by the CPU, or offloads this part to some special-purpose hardware
(i.e., most likely, to FPGA) whenever this option is available.
The probability of encountering someone who knows C or C++ in such an institution’s IT department is critically close to zero.
Therefore, there is a good chance that everything that deals with the driver is going to be encapsulated in some third-party UM component that their toy .NET-based app accesses as an in-process or out-of-process COM server (or whatever it is a “recommended” way of doing things these days). There is a good chance that a driver and a component that actually makes use of it are a tightly-coupled pair that gets developed by the software house that provides the component.
Needless to say that such an app is heavily dependent on both software component and a special-purpose hardware that it deals with, so that changing anything on this side may be “rather problematic”, so to say. Now consider what happens if this institution is forced, for some reason, to change the hardware. It is pretty obvious to us that replacing the target component (i.e. rewriting the entire component-driver stack from the scratch) is the easiest and the most reasonable way to go in this situation, but go and try to explain it to someone
with the technical “knowledge” limited to .NET languages…
Anton Bassov
You know, I think I said somewhere:
This is a very common question/topic, and has been discussed to death on this forum. Take a look through the archives, please.
And your attached text file (please post code as a code segment here in the forum in the future, and don’t make people download a potentially suspicious file) just shows you know how to call WdfCreateCommonBuffer… it doesn’t actually DO the part that’s worrisome, and about which you enquired, which is map the buffer back to user space.
Peter
Notwithstanding Anton’s unnecessary editorial on the competence or lack thereof of many decision makers (something that I am all too familiar with)
Tim has it right – he asked about to possibility of writing into an otherwise unused portion of memory. Sure, no problem, why would anyone think it would be? But for that action to be useful in any way, someone has to read that memory. Now if there is some established protocol between hardware, driver and application where the hardware / driver somehow indicate that a certain region of memory now contains valid data of a certain kind, and the application should now to X with it, and he wants to piggyback on that protocol without changing the application, well sure – that can be done. But I read none of those pre-conditions in any of the questions from the OP. Perhaps I am wrong and have missed these signs, but it sounds to me like there is an existing interface with shared memory that has, for some reason, a memory ‘hole’ that he is looking to exploit for some purpose. If that’s true, it can’t be for the purpose of legacy compatibility, so something has to change and as Peter repeats, the concept of shared memory have been discussed in this form and others ad nausium so before we repeat them all again, OP please search the archives
Sure, no problem, why would anyone think it would be?
To be honest, all 3 posts that the OP made in so far seem to contradict one another - first he claims to have allocated 1K that he maps to the userland; then he “extends” this buffer to 4K; and,finally, he claims to be writing to the unused part of 32M buffer he has allocated before.
But for that action to be useful in any way, someone has to read that memory
Indeed, the app has to be modified in some way in any case. Certainly,it does not necessarily imply modifying its binary - for example, you can simply inject a DLL into its address space
it sounds to me like there is an existing interface with shared memory that has, for some reason, a memory ‘hole’ that he is
looking to exploit for some purpose. If that’s true, it can’t be for the purpose of legacy compatibility,
Taking into consideration that the OP happens to be the author of the KM driver that the target app sends its requests to, a vulnerability exploitation attempt seems to be on the list of least likely scenarios ever…
Notwithstanding Anton’s unnecessary editorial on the competence or lack thereof
I am going to make one more, probably,“unnecessary” comment on the subject, but I believe that in this particular case it makes sense to recall Occam’s razor, and not to suspect the malicious intentions if everything can be attributed simply to the lack of competence and understanding…
Anton Bassov
When I say ‘exploit’ I mean use because it is there; but not in a malicious way. Probably a poor choice of words by me given that it usually implies malware of some kind
Hi MBond2,
You are right. There is a contradiction in my posts.
The buffer allocated by WdfCommonBufferCreate is 32MB.
The lower 30MB are used for DMA from FPGA to RAM.
The upper 2MB are used for status report.
Kernel driver only writes data to this area:
*(UINT32*)(char*)devExt->KernelCommonBuffer[0]+30*1024*1024) = 0xCAFE2DAD;
Application only reads from this area.
Thank you,
Zvika
Hello Tim, Peter, Don, MBond2, anton_bassov,
Thank you very much for your help !
Best regards,
Zvika
soooooo, given that i am right, what are your tryig to do? i don’t think any of us know