MmMapIoSpace的幻数 [英] Magic number with MmMapIoSpace

问题描述

因此，在使用MmMapIoSpace映射内存空间时，我注意到经过某一点后，数据在写入时就被丢弃了.没有引发任何错误，断点甚至错误检查.一切正常，没有任何不良影响.

So upon mapping a memory space with MmMapIoSpace, I noticed that past a certain point, the data was just being discarded when written to. No errors, breakpoints, or even bugchecks were thrown. Everything worked as normal, just without any adverse effects.

我决定进行写/读测试(驱动程序将在预期大小的长度上向每个字节写入1)，而读取器(用户态)模式将读取并报告1的位置结束.

I decided to do a write/read test (the driver would write 1's to every byte for the length of the intended size) and the reader (userland) mode would read and report where the 1's ended.

计算出的数字是3208，这是一个看起来不错的整数(/8 = 401，/256 = 12等)

The number it came up with was 3208, which is a seemingly nice, round number (/8=401, /256=12, etc.)

这是怎么回事?为什么无法映射完整的缓冲区空间?

What's up with this? How come I can't map the full buffer space?

编辑，在64位中，该数字降为2492.

EDIT And in 64-bit it drops to 2492.

推荐答案

我不是专家，但是我看不到如何依靠MmMapIoSpace来完成您的要求，因为无法保证用户空间缓冲区在物理内存中是连续的.

I'm no expert, but I don't see how MmMapIoSpace can be relied upon to do what you're asking it to, because there's no guarantee that the user-space buffer is contiguous in physical memory.

相反，我认为您应该使用 MmProbeAndLockPages 锁定用户缓冲区，然后在此处描述.

Instead, I think you should be using IoAllocateMdl and MmProbeAndLockPages to lock down the user buffer and then MmGetSystemAddressForMdlSafe to map it into the system address space. This process is described here.

如前所述，我认为映射失败的点(进入缓冲区3208/2492字节)可能只是页面的结尾，但这足以让您轻松验证:获取用户空间应用程序报告未写入的第一个字节的(虚拟)地址而不是偏移量，并检查其是否为4096的倍数.

As previous stated, I think that the point at which the mapping is failing (3208/2492 bytes into the buffer) is probably just the end of the page, but that's easy enough for you to verify: get the user-space application to report the (virtual) address of the first byte that didn't get written rather than the offset, and check whether it is a multiple of 4096 or not.

这篇关于MmMapIoSpace的幻数的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！