Marking RAM physical pages as read-only

Hey there!

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,
Roman

PS
OS: Windows 10, version 21H2 (OS Build 19044)

The short answer is you can’t do that. However, once you have allocated physical memory using e.g. MmAllocateContiguousMemorySpecifyCache, no other well behaved software can get a virtual address for that section of memory, you ‘own’ it. So in a controlled environment, it is very likely your software that is corrupting your memory.

Have the driver get a pointer to the buffer using MdlMappingNoWrite

Mark is right. You can’t do that - its physically not supported by the hardware or the OS

if your memory corruption happens because of writes from the host side, it is either your software or malware. It is hard to say much from your description, but it seems more likely that the corruption happens from the device side

Thanks Mark and MBond2 for your answers.

As was tested driver didn’t write to that memory while the original issue with HW is happened. MmProtectMdlSystemAddress was used to make the kernel virtual memory read-only. Also checked that on any write to this virtual memory Bugcheck 0xBE was raised.
Will focus on HW direction.

Rourke,
Thanks for checking. Yes, the MdlMappingNoWrite flag was also tested with the MmMapLockedPagesSpecifyCache function and with same results. Looks like this flag protects the virtual memory, without impact on physical.

Regards,
Roman