All Posts

The LIST command shows the events and global vars. If anything , curprocname would be a global var (second list), but I think it is user defined and not part of the default variables... What is your plan for Vprobes?

UPDATE Well, I tried this out on another Linux box I have around running Ubuntu 8.10. I have no problems on that machine at all. I'm guessing there is something missing from the Red Hat system, but I have no idea what it is. I am going to reload my main system as Ubuntu to continue testing VProbes instead of fighting with Red Hat. Thanks

Thanks for the reply. I am running this on Redhat ES Linux. I'm not seeing a command for vProbeList, but I ran vmrun vprobeListProbes and got a list of items.... I do not have internet access from the system in question so I'll just summarize. Total probes: 42 In HW_Exit SMM_RSMPost ... .. VMXUnload VMM10Hz I do not see curprocname in the list.

So cool... now what parameter do I need to adjust for more as 24 hours in a day? :smileygrin: -- Wil _____________________________________________________ Visit the new VMware developers wiki at http://www.vi-toolkit.com

The processor manuals, of course, are for reference, not for reading cover-to-cover, though perhaps the protected mode memory management chapters of Intel vol. 3 are worth a thorough read. I think books about concrete operating systems are more useful than the academic texts, which tend to spend too much real estate on ideas that turned out to be dead ends. Solomon and Russinovich's Inside Windows 200X series are excellent, providing broad, deep, well-written insight into the most commercially important operating system out there. I haven't seen anything quite as great in the Linux world, but Love's Linux Kernel Development is just fine.

Doing this stuff from outside the VM has some big pluses, and some big minuses. On the pro side: Most importantly, VProbes is safe. Using a kernel debugger or something from within a guest provides some very dangerous opportunities: e.g., you could poke a hole in a critical guest memory structure. Also, kernel debuggers usually stop the target program to allow inspection. VProbes keeps things moving along while data is harvested, so it can be used even on mission-critical, highly available systems. VProbes doesn't rely on any in-guest tools. If the target is, for instance, an appliance that doesn't even have a login shell, let alone /usr/bin/top, VProbes works no better or worse. It doesn't care what state the guest is in. If the guest is hard hung, or is swapping too hard for a shell to come up, or whatever, VProbes can be a "tool of last resort" to try to harvest information. VProbes is also immune to guest attempts to fool it. For instance, malware often tries to change in-guest instrumentation tools to make itself undetectable. Since the VM/hypervisor trust boundary protects vprobes, it is immune to this weirdness. VProbes is neutral as to the identity of the guest; since it's machine-level, you can use the same tools for Windows, Linux, Solaris, FreeBSD, MacOS, etc. To the extent the preload scripts work, even some common, but OS-specific, notions, like processes, can be captured. The big negatives all boil down to the same fundamental problem: the machine abstraction level is sometimes very far away from the application abstraction level. If it's a java application running, for instance, VProbes will sit there telling you: "java.exe is running!" Well, no kidding; you probably wanted to know, e.g., which method invocation it was in. We're thinking about ways to bridge that gap, but alas, have very little to offer for serious discussion at this time.

Keith, I guess looking over my post I did not really have a question... The above works ok for loading Emmett Vprobes on Windows so far. I do have a question though... What are we probing? The hypervisor? The VM? Why not just debug the VM from the inside? What is the theory behind this magical madness? PS. Post more videos!

User-level is a bit rough, but still possible. dwarffrob.py is, tragically, a work in progress, but it's more aimed at finding structure offsets than symbol names. If you are looking for a particular user-level binary, you can harvest symbols in the guest (either via windbg.exe or /usr/bin/nm), and append the symbols in the binary to the file specified in vprobe.guestSyms. Next, you need to make sure that you're hitting the right process. This is best achieved by setting up one of the preloads for your guest and manually checking curprocname; e.g.: GUEST:UserLevelSym if (!strcmp(curprocname(), "targetBinary")) {...} You can also test curpid() if you like, etc. Unfortunately, this is all very manual. It would be nice both to automate the symbol harvesting, and to provide nicer notation for probing particular processes. There is also some difficulty with accessing linear addresses that the guest happens to have paged out: since VProbes is nervous about perturbing the state of the guest, we don't inject page faults on such accesses. So the probe fire will simply fail, leaving a warning in your vmware.log. Thanks, Keith

> $startinfo = new-object System.Diagnostics.ProcessStartInfo > $startinfo.FileName = $execBinary > $startinfo.Arguments = $connectParams + $commandParam + $vmxParam + $vpParam > $startinfo.UseShellExecute = $false > $startinfo.RedirectStandardOutput = $true > $process = [http://System.Diagnostics.Process|http://System.Diagnostics.Process]::Start($startinfo) > $process.WaitForExit() > $process.StandardOutput.ReadToEnd() > I'm not sure based on that, but this style of running vmrun seems a bit over the top. You can run it directly like you would from a command prompt. Is there a reason you didn't do that? I assume it's because of the path. Still you could run it sort of like this: $vmrun = Get-Command "C:\Program Files\VMware\VMware Server\vmrun.exe" . $vmrun $arg1 $arg2 $arg3 And this might be a bit easier to diagnose.

I would love to see more real life examples too... Think about this, when you re debugging C# code using Visual Studio, you re only stepping through your code. What if your code is good, but the CLR is JITTING it all wrong! In this case you will need to go lower and debug the CLRs interaction with the operating system. The way I understand it, is that you could launch a debugger like softIce in the guest and everything might look OK, but until you launch a debugger a lower layer and point it at the hypervisor , you will never find out that the way the hypervisor is handling Intels and AMDs virtual helper instructions differently, possibly causing the awry behavior.