Feature Request: map_ptr_x64 - Prototype and Transition Bits

[carter-yagemann]

As discussed with Tamas and outlined in this paper, there are cases where PDE and PTE entries can be marked invalid but the data they point to are still in memory. To give an example from the paper:

When the T bit in an entry is one and the P bit is zero, the page is said to be in Transition... Even though a page [is] in transition, the page [is] still in active memory and can therefore be retrieved by an examiner. Just like a valid entry, the page frame number is given in bits 12-31 and can be used to continue the address translation process.

Currently map_ptr_x64.h fails as soon as it sees an invalid entry. It would be useful if we could increase its robustness by leveraging the transition and prototype bits.

[rianquinn]

@carter-yagemann Sounds like (based on the description), we simple need to relax the expects to look for either present, or in transition. Is that your assumption as well? Do you know which bits are the transition and prototype bits, and do you have a description for the prototype bit?

[rianquinn]

@carter-yagemann From what I can tell after reading the paper, it appears that a page in Transition (bit 11 in the PTE) should be as simple as relaxing the expects contract and continuing on (and I guess this applies to the PDE as well). Prototype pages become more complicated as the actual PTE is located somewhere else, and this becomes far more Windows specific. I'm open to suggestions on how we handle that as this code is also used on Linux, and they don't play these same tricks.

@tklengyel thoughts?

[carter-yagemann]

@rianquinn I agree with your conclusion, but one slight distinction. I believe we have to check that the Transition bit is set and the Prototype bit is not set. I believe the paper says that if the prototype bit is set, the transition bit becomes apart of something else so it could be set for a different reason.

I agree that handling prototypes will be a harder task because of the dependency on OS implementation. That's probably something that should be set aside until Bareflank's extended API is further down the introspection road (where distinguishing between OS implementation specifics is unavoidable).

One point I want to raise because the paper isn't clear about it is if a page is "in transition" will proceeding with the mapping produce a race condition? Specifically because Bareflank doesn't "pause" the VM while this mapping is happening. There's already a danger of race conditions because Bareflank isn't pausing (correct me if I'm wrong), but this could be particularly dangerous.

[rianquinn]

@carter-yagemann Yes, a race condition is possible. In general, the mapping code that you have linked is meant to map code that you intend to use, not memory that you plan on spying on. Once we have LibVMI support, this task should be a lot easier as LibVMI handles all of this crap for you, including pausing the VM, which we will support (the main reason we need guest support because you cannot pause the VM if your running LibVMI in it 😄 ).

So that begs the question... should we change anything? or simply wait for LibVMI support which addresses this issue, and basically just state that the VMM mapping code is only meant to map memory you intend to leave paged in.

[tklengyel]

@carter-yagemann correct, !present (bit 0) && !prototype (bit 10) and transition (bit 11) is the key combo. This is only on Windows (bit 10 & 11 are both software programmable).

@rianquinn Indeed, mapping memory of a running process/kernel without pausing will inevitably be racy. Of course you can have issues even if you pause at some random time too as the process might be in the in the middle of writing to memory or the OS updating its pagetables. There is no clear-cut way to do this other then reversing the OS you are spying on as much as possible to identify "safe" tap points ;)

If this API was intended to map memory the user has control over then leaving things the way should be fine and just have the user allocate memory that won't get paged (ie non-paged pool in case of a Windows kernel driver). If that's not the case you would have to keep an eye out with EPT for when the PTE changes to not-present not-in-transition to kick the OS to bring the page back.

[rianquinn]

@tklengyel The original intent of this mapping code was just for memory the user intends to share with the VMM. Does the LibVMI->Bareflank API that we will have to implement here soon require this code? Or does LibVMI handle this behind the scenes using more primitive functions? In other words, when we add support for LibVMI, are you expecting this issue to be handled on our end?

[tklengyel]

In LibVMI we implement our own pagetable parsing functions for a variety of targets (x86 and ARM) so we only need access to the physical memory of the target. Nuances like whether the page is in transition are also handled accordingly there. Knowing when to pause the target VM is up to the user. So to answer your question, no, we would not be using this API in LibVMI or in a LibVMI app.

[rianquinn]

@carter-yagemann Ok, I have an idea on how to satisfy this in a way that should keep things clean for Bareflank, but still provide domain specific implementations.

The following code is what handles the guest CR3 + virt -> phys:

integer_pointer from;
integer_pointer phys;
integer_pointer pati;
integer_pointer current_virt = virt + offset;

while (true)
{
    from = x64::page_table::pml4::from;
    auto &&pml4_idx = x64::page_table::index(current_virt, from);
    auto &&pml4_map = bfn::make_unique_map_x64<uintptr_t>(cr3);
    auto &&pml4_pte = page_table_entry_x64{&pml4_map.get()[pml4_idx]};

    expects(pml4_pte.present());
    expects(pml4_pte.phys_addr() != 0);

    from = x64::page_table::pdpt::from;
    auto &&pdpt_idx = x64::page_table::index(current_virt, from);
    auto &&pdpt_map = bfn::make_unique_map_x64<uintptr_t>(pml4_pte.phys_addr());
    auto &&pdpt_pte = page_table_entry_x64{&pdpt_map.get()[pdpt_idx]};

    expects(pdpt_pte.present());
    expects(pdpt_pte.phys_addr() != 0);

    if (pdpt_pte.ps())
    {
        phys = pdpt_pte.phys_addr();
        pati = pdpt_pte.pat_index_large();
        break;
    }

    from = x64::page_table::pd::from;
    auto &&pd_idx = x64::page_table::index(current_virt, from);
    auto &&pd_map = bfn::make_unique_map_x64<uintptr_t>(pdpt_pte.phys_addr());
    auto &&pd_pte = page_table_entry_x64{&pd_map.get()[pd_idx]};

    expects(pd_pte.present());
    expects(pd_pte.phys_addr() != 0);

    if (pd_pte.ps())
    {
        phys = pd_pte.phys_addr();
        pati = pd_pte.pat_index_large();
        break;
    }

    from = x64::page_table::pt::from;
    auto &&pt_idx = x64::page_table::index(current_virt, from);
    auto &&pt_map = bfn::make_unique_map_x64<uintptr_t>(pd_pte.phys_addr());
    auto &&pt_pte = page_table_entry_x64{&pt_map.get()[pt_idx]};

    expects(pt_pte.present());
    expects(pt_pte.phys_addr() != 0);

    phys = pt_pte.phys_addr();
    pati = pt_pte.pat_index_4k();
    break;
}

If I move this code to a separate function, and mark this function "weak" a user could provide their own version of this function in their own extension, implementing this Transition / Prototype logic. This way, if you want to do the mapping in the VMM instead of leveraging LibVMI, you can without having to re-write the mapping code (which is obviously another option).

Thoughts?

[rianquinn]

@carter-yagemann this has been completed.