Klaus, Thank you for your prompt responses. I have tried to address your questions below.
On Mon, Oct 22, 2012 at 4:45 AM, Klaus Espenlaub <[email protected]> wrote: > On 22.10.2012 07:02, Adam Pridgen wrote: >> I am trying to monitor page writes that happen on in VM's physical >> memory. After a few weeks of digging, I think I have found the 3 API's >> that might be helpful for this task, but I am not sure if these APIs are what >> I should be looking at. I guess the two questions I have are: >> >> 1) What is the best way to register a write handler over a guest's >> physical RAM? >> Here are the APIs I have identified: >> >> include/VBox/vmm/pgm.h:522:PGMR3HandlerVirtualRegister >> include/VBox/vmm/pgm.h:518:PGMR3HandlerPhysicalRegister >> include/VBox/vmm/pgm.h:349:PGMHandlerPhysicalRegisterEx > > Impossible to tell without context. "trying to monitor page writes" is > much too vague to tell what you really need. Especially as you ask for > "best way". Also keep in mind that monitoring large areas will kill > performance, no matter how little you do in reaction to each write. > Sorry for the ambiguity. Right now, I am trying to implement data taint tracking in VirtualBox. Initially, I am just trying to track and record the dirty page frames when they are moved out of memory after a page fault, but eventually, I would like to monitor and record all the writes for specific page locations in RAM or processes. My approach is using a VBoxManage command to start and stop this activity. This command will call back into my exposed COM-API, which then performs some "voodoo" on the VM that starts or stops the logic. I am trying to sort out some of the "voodoo" right now. As an aside in the beginning, I was attempting to modify the (PFNPGMRCPHYSHANDLER, PFNPGMR0PHYSHANDLER, PFNPGMR3PHYSHANDLER) in the PGMPOOL pPoolR3 structure in the PGM structure. The goal was simply to hook the handler functions, and then log each time the functions were called. I learned pretty quickly that I can't really make this modification directly because the different contexts (e.g. Ring-0, Ring-3, Guest, Host) may not be able to access the function pointers I replaced. I know that this approach is wrong, but I was just experimenting with the code to figure out what I can and cannot do. (Side-question) What does RC stand for, if R3 and R0 are Ring-3 and Ring-0 respectively? >> 2) Can I register a page handler from something like a COM handler? > > Depends what you mean by "a COM handler". It has to be in a VM process, > so only the COM API methods which live on the client side are candidates > (i.e. not part of VBoxSVC). > Ok. I am not completely sure about the appropriate vocabulary here. The code I wrote exposes a COM client via a very basic API. This basic API I wrote will call some backend code in the client and then access the internals of the VM. One example feature that I have implemented is: 1) obtain a pointer the VM in the R3 context 2) obtain the VMs PAGEMAPPING structure in the R3 context 3) Count the page mappings and PTs for a given virtual machine in the R3 context (Side Question) Does the code in the COM-client run in the R3 context, and is this context synonymous with the Guest Context? I am still trying to figure which context code is executing in, and when it is executing in that context. My next goal is to register one of my functions in the COM-client as a write monitor, and then each time a dirty page frame is flushed out of the VMs physical RAM, log a basic message. Rather than performing primitivie hacks, I would like to use the established/exposed (internal of external) PGM and VMM APIs to complete this task. > However from the above it looks like you want some new virtualization > core feature, which often cannot be done by simply adding/extending COM > API methods. > Yes. I am trying to implement this feature as part of my graduate research. I understand that extending COM is not going to help me achieve these goals, but I am using the COM API to help me activate, the feature, debug and run code as a regular user. Thanks again for your correspondence. This is all very helpful. -- Adam _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
