The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
I am involved in the project where the KMDF driver communicates with the HW via the shared system RAM. Driver allocates the physically contiguous, nonpaged memory chunk using the MmAllocateContiguousMemorySpecifyCache API and provides its physical address to the HW. HW writes data into this memory and notifies the driver by raising interrupt. Upon ISR driver reads the data from the above memory and makes decisions accordingly, and doesn't change the memory. So, HW access is write-only and driver read-only.
Recently, with new HW, and very rarely, driver started reading corrupted data from this memory.
First assumption was that the new HW writes corrupt data. Unfortunately, there is no evidence from the HW that such happened. We are also trying to capture the PCIe traffic within the issue using PCIe Analyzer but have some issues.
In parallel, as an additional direction, I check the possibility of memory corruption by the host SW.
The method that I thought about is to mark allocated RAM pages as read-only and to let Windows to raise the Bugcheck if any SW tried to change these pages. Marking using MmMapIoSpaceEx and MmProtectMdlSystemAddress didn't help much because in this case only write to the mapped virtual ranges returned by these functions will be caught by OS. Any other mapping of the same RAM chunk will allow writing to the physical memory without BSOD.
The question is how physical RAM pages can be marked as read-only, so, any write to these pages, from any mapped memory, will end up with BSOD?
Thanks in advance,
OS: Windows 10, version 21H2 (OS Build 19044)
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Kernel Debugging||30 January 2023||Live, Online|
|Developing Minifilters||20 March 2023||Live, Online|
|Internals & Software Drivers||17 April 2023||Live, Online|
|Writing WDF Drivers||22 May 2023||Live, Online|