Hello,
In my device driver, upon IOCTL request I have to start DMA from hardware into RAM.
The RAM address passed in the request is a physical address of a continuous buffer allocated by another device driver.
This is a customer requirement. I’m aware it’s not by the book.
The “EvtProgramReadDma” routine passed to WdfDmaTransactionInitializeusingRequest get the paramater:
PSCATTER_GATHER_LIST SgList
But in my case, there is no SG list created by the framework.
Should I use any WdfDma calls at all ?
Thank you,
Zvika
xxxxx@gmail.com wrote:
In my device driver, upon IOCTL request I have to start DMA from hardware into RAM.
The RAM address passed in the request is a physical address of a continuous buffer allocated by another device driver.
There is NO WAY you should allow this information to be passed in from
user-mode. There’s nothing wrong with using a common buffer allocated
by another driver (with appropriate synchronization), but you need to
get the address from the driver directly. User-mode code is untrusted
code. It is an enormous security hole to accept and use a physical
address from user mode.
This is a customer requirement. I’m aware it’s not by the book.
The concept of using a physical address from another driver is fine.Â
The concept of passing that information through user-mode is absolutely
no go, and as a professional driver writer, you have a responsibility to
tell your client that it is not acceptable. There are other ways to
accomplish this, securely and reliably.
The “EvtProgramReadDma” routine passed to WdfDmaTransactionInitializeusingRequest get the paramater:
PSCATTER_GATHER_LIST SgList
But in my case, there is no SG list created by the framework.
Should I use any WdfDma calls at all ?
Not in this case, no. I don’t think it gains you anything. I have one
driver that has both common buffer DMA for a circular buffer, and
one-shot DMA for user requests. The one-shot stuff goes through the
WdfDma abstraction, but the common buffer transactions are handled directly.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Hi Tim,
Thank you very much for the detailed answer.
Best regards,
Zvika