The SwapBuffers example driver states that if your driver will be modifying the data in the buffers, that you must allocate your own buffers, copy and modify the data, and call FltSetCallbackDataDirty(). They do this even on IRP_MJ_READ.
My question is: Is it true that you should not directly modify the read buffers in the post op?
Just to give this a context, say that I am doing a simple xor decryption on the data.
It adds a lot of overhead, especially to IRP_NOCACHE requests, to allocate a buffer in the pre-op and pass it down to lower drivers, and then copy those contents back to the original buffer in the post op, rather than just modifying the original buffer in place in the post op.
I’m thinking the advice of this example was only specifically aimed at IRP_MJ_WRITE requests, where you would obviously not want to walk on the incoming buffer to be written, but their example nor their comments make this stipulation.
_Ron
I’m pretty sure this won’t work I have my head deeply inside something else right now so I cannot produce the reason, but I’ll note that if once you have real encryption in the loop allocating a buffer won’t even register on your performance.
Also if you doing encryption anywhere but on NONCACHED io it is going to end badly when you start mapping sections.
There’s a ton of inherent complexity hidden in this area, so… be careful.
Consider… do you need to allow some accesses to result in the ciphertext being delivered and others the plaintext? How about memory-mapped accesses?
Peter
@Peter_Viscarola said:
There’s a ton of inherent complexity hidden in this area, so… be careful.
Consider… do you need to allow some accesses to result in the ciphertext being delivered and others the plaintext? How about memory-mapped accesses?
Peter
Yeah, I’ve read a lot about various concerns of encryption filters and the complexities they give rise to, including the memory mapped issue @rod_widdowson mentioned above.
My only concern at this time is “since the requestor of the IRP (or someone above us) provided Iopb->Parameters.Read.ReadBuffer/MdlAddress for the data to be read into, what possible reason could there be for not being able to modify the data that was passed up from a lower filter?”
It’s not that you shouldn’t modify what you are given. Its whether you should pass what you are given and then modify it in situ.
You make a compelling case but right now I just don’t have the interrupt stack available to reconstruct why its a bad idea.
Because of dummy pages. Very old (but still useful) post here:
https://blogs.msmvps.com/kernelmustard/2005/05/04/dummy-pages/
@Scott_Noone, I can’t say that I fully understand the information in that post, but it does seem to clearly say that I should send my own buffer down, so I will head that warning. Thanks for your time.
@rod_widdowson, I appreciate the advice. I know what it is like to have a tight schedule.
_Ron
I think I figured out what that post is warning about. Can you confirm:
A dummy page that the Mm throws in is not reserved exclusively for that IO request, so it could be modified between the time the data is read from the file, and the IRP reaches your driver on the post op, so things like decryption may fail?
@rstruempf that is correct.