Introduction

I recently developed a lot of interest in ACPI programming. By Googling, I found Intel’s ACPICA open source library. Of course, to make it work (such as read ACPI tables, evaluate ACPI methods), I must implement some functions to access physical memory, port and PCI configuration space, even install ISR.

It’s quite easy to implement these functions in kernel mode. But I don't want to put the whole ACPICA library in a “.sys” which will make it very hard to debug. Debugging is important for me because I always want to find out what really happens. So the only solution is to access these resources in user mode.

At first I used WinIO and it works. Yet after reading the source code, I found it used too many “undocumented” and “obsolete” functions. I decided to make a more elegant solution, and add the function of accessing PCI configuration space.

Background

1. The Architecture

I borrow the software architecture from WinIO: a kernel mode driver “phymem.sys” and a user mode DLL “pmdll.dll”. Applications can easily access physical memory using the functions exported by pmdll.dll, which will talk to the phymem.sys by standard “DeviceIoControl”.

To access PCI configuration space in a DDK recommended method, I wrote a PCI bus upper filter driver “PCIFlt.sys”. With this filter driver, we can find the unnamed PCI bus driver which lies under our named filter driver. Then we use “Driver Interface” to directly read and write PCI configuration space.

2. Access Physical Port

IA based PC uses separated port and memory address spaces. In kernel mode, we can read and write port with functions named like WRITE_PORT_UCHAR, READ_PORT_UCHAR.

3. Access Physical Memory

To access physical memory in user mode, we must map this memory region to the user process’ address space. One implementation is through the \Device\PhysicalMemory section object. This is first introduced in the old NT DDK samples. It uses obsolete functions which are not recommended; also the code is really hard to understand.

A better implementation can be found in MSDN. Only three steps are required:

Use MmMapIoSpace to map physical address to kernel mode virtual address, driver can access this virtual address, but it’s not accessible in user mode.

Use IoAllocateMdl and MmBuildMdlForNonPagedPool to build an MDL for the mapped physical address.

Use MmMapLockedPages to map the physical pages described by MDL to user mode virtual address. Since our driver will always be the topmost driver, and run in the context of the current process, this user mode virtual address is valid to the caller.

4. Access PCI Configuration Space

Windows XP bus drivers must implement “Driver Interface” which can be acquired by sending it an IRP with major code IRP_MN_QUERY_INTERFACE. After acquiring “Driver Interface”, we can access the bus address space by calling the interface provided ReadConfig and WriteConfig routines.

The trouble is that the PCI bus driver has no name, that is, we can't find its device object. Without the PCI bus driver’s device object, we have no way to query its “Driver Interface”. The solution is providing a PCI bus upper filter driver, which will be layered above the actual function bus driver.

Using the Code

All source code is built under Visual C++ 6.0, XP DDK 2600, and Windows XP SP3. To build driver (.sys) in Visual C++ IDE, follow the next two steps:

Set environment variable $DDKROOT to DDK installation directory, such as "D:\WINDDK\2600”.

In VC++ IDE, Tools->Options->Directories->Show directories for, choose “Executable files”, add DDK bin directory and move to the first line, such as “D:\WINDDK\2600\BIN\X86”.

I found the driver had already recorded in registry key but the program can't use it.The problem is the driver I build doesn't have any signature so win 7 x64 can't use this driver.After I disable driver signature enforcement on win 7 x64, the program execute normally.

I only test the Access Physical Memory function so the other function I can't sure work fine.