Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


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/


Marking RAM physical pages as read-only

Roman_GoldshteinRoman_Goldshtein Member Posts: 4

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)

Comments

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,588

    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.

  • RourkeRourke Member Posts: 72
    edited December 2022

    Have the driver get a pointer to the buffer using MdlMappingNoWrite

  • MBond2MBond2 Member Posts: 515

    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

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

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