How to verify that an address can be analyzed using the--mmisaddressvalid function

It is also a post of kernel function analysis, I personally think that the Windows kernel is the best teacher, when you want to implement a function can see how the Windows kernel is done, perhaps there is inspiration:)

First, take a look at the official comment notes:

/* ++routine Description:    For a given virtual address this function returns TRUE if no page fault would    occur for a read operation on the address , FALSE otherwise.    Note that after this routine is called, if appropriate locks is not    held, a non-faulting address could fault. Arguments:    virtualaddress-supplies The virtual address to check. Return Value:    TRUE If no page fault would be generated reading the virtual address,    FALSE otherwise. Environment:    Kernel mode.--* *

The function descriptions given in the WDK documentation are: The Mmisaddressvalid routine checks whether a page fault would occur for a read or write operation at a G Iven virtual Address. According to the description of the function is to check whether read and write operations will trigger a page fault, but as a common function, we often use this function to check the address of the law, this time in the source to see the specific process, the main purpose is to find out how this function is to determine whether a function will trigger the page error.

1 BOOLEAN2 Miisaddressvalid (3 in PVOID virtualaddress,4 In LOGICAL useforceifpossible5     )6 {7 pmmpte Pointerpte;8 9 Ten     // One     //If The address is not canonical then return FALSE as the caller (which A     //May be the kernel debugger) are not expecting to get a unimplemented -     //address bit fault. -     // the  -     if(mi_reserved_bits_canonical (virtualaddress) = =FALSE) { -         returnFALSE; -     } +  -  +  A  atPointerpte = migetpdeaddress (virtualaddress); -     if(Pointerpte->u.hard.valid = =0) { -         returnFALSE; -     } -  -     if(Mi_pde_maps_large_page (pointerpte)) { in         returnTRUE; -     } to    +Pointerpte =migetpteaddress (virtualaddress); -     if(Pointerpte->u.hard.valid = =0) { the         returnFALSE; *     } $ Panax Notoginseng     // -     //Make sure we ' re not treating a page directory as a page table the     //The case where the page directory is mapping a large page. this is +     //because the large page bit is valid in PDE formats, but reserved in A     //PTE formats and would cause a trap. A virtual address like c0200000 ( on the     //x86) triggers this case. +     // -  $     if(Mi_pde_maps_large_page (pointerpte)) { $         returnFALSE; -     } -  the     returnTRUE; -}

The code surprisingly simple, it is obvious that this is the use of paging mechanism to query. Check to see if the page Catalog item is empty, and then look at the page table entry if it is empty. As for 28, 29 lines should be judged whether to use Pde directly as a first-class table, but it should not be so used now.

if (Mi_pde_maps_large_page (pointerpte)) {        return  TRUE;}

As above is a judgment.

and migetpdeaddress and migetpteaddress is actually two macros, this macro we can also use.

#define Migetpdeaddress (VA)  \    & virtual_address_mask) >> pdi_shift) << pte_shift) + Pde_ BASE))

#define migetpteaddress (VA) \    & virtual_address_mask) >> pti_shift) << pte_shift) + pte_base))

#define Virtual_address_bits#define Virtual_address_mask (((((ULONG_PTR) 1) << virtual_address_bits)-1)

Note that each process has its own Process page table and page directory, but the kernel copies the PD to the address space of a process for easy access.

How to verify that an address can be analyzed using the--mmisaddressvalid function