Allocate huge amounts of continous physical memory for DMA /wo scatter gather

That is correct. But (and this is a big but)… when, where, and how do you do the unmap operation?

There are reasonably serious security complications involved in handling the UN-mapping. Ordinarily, you’d just do it in cleanup and be happy, because cleanup is called in the context of the process that’s calling close on the handle. But this raises the issue of what happens if the handle has been duplicated into another process. NOW, if the original process doesn’t happen to be the last to call CloseHandle, you’re screwed. At best the system crashes, at worst the offending process has access to a large chunk of what is now “random” memory.

You must deal with this somehow. Ten years ago, I used to argue (here in NTDEV, even) that this problem was so esoteric that it really wasn’t worth fixing. Now, in the 21st Century, where we have no end to cyber-attacks… you really cannot just ignore it.

All the ways to deal with this are beyond the scope of this post (I’ll write a proper article someday)… but you can either (alternative A) take a reference on the “original” mapping process. Then check in cleanup to see if it’s the original mapper is the one calling cleanup. If it’s not, call KeStackAttachProcess to get into the original mapper’s context and do the unmap there. Alternative B is to set a PsSetCreateProcessNotifyRoutine and do the unmap when the original process exits.

Either way you must handle this.

Peter

Ok thank you for your help and hints. I will try to implement a fully working composition with my FPGA guys to get a loopback design running. Will take some time, though. I wish I had more FPGA colleagues on my site. :wink: