Rustifying the Virtual Machine Introspection ecosystem
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Tarral, Mathieu
Eikenberg, Dorian
TLDR: Even though VM Introspection has lots of applicable areas, it has not gained it's full potential yet, due to a fragmented ecosystem. This talk will quickly review the state of the technology and we will present our solution: a Rust library aiming at solving the issue mentionned before, in order to make VMI a commodity in the future for apps developers, enabling them to do: Advanced Malware Analysis Live-Memory Analysis Complex debugging OS Hardening Snapshot-based fuzzing Targeting any VMI compatible hypervisor or emulator. From stealth malware analysis to OS hardening through fuzzing, virtual machine introspection is expanding the possibilities offered by our hypervisors, shifting our view of virtual machines, from opaques containers to fully transparent and instrumentable systems. Today the VMI ecosystem is made of a multitude of applications, targeting one hypervisor or emulator, with their own semantic library. (Examples includes Drakvuf, PANDA, PyREBox, icebox, etc...). If we want to make the most out of VMI in the future, we need to build the libraries that will unify this ecosystem and let the developers focus on what matters: building quality VMI apps. This is where libmicrovmi comes into play. It aims to solve this problem, by providing a core, foundation library, written in Rust, to be cross-platform, hypervisor-agnostic and emulator-agnostic, on top of which higher-level libraries and apps can rebase. Rust makes a lot of sense for VMI for 2 main reasons: Rust is safe: considering that we are processing untrusted input from virtual machines, we cannot allow any crash or exploitation in the introspection agent. Also one of our use case is OS hardening, which needs an excellent level of trust Rust is fast: processing an event requires to pause the VCPU. The longer the pause, the more delayed the guest execution will be, and when scaling to thousands of events per second this can dramatically influence how many breakpoints you are willing to put, especially on production systems. Speed matters. Therefore Rust is the de facto choice for VMI apps in the future, and we are building it today, by providing libmicrovmi, a new foundation for VMI. Libmicrovmi has drivers for: Xen KVM Hyper-V (in progress) What is VMI ? Vrtual Machine Introspection is a concept born in a 2003 research paper titled "A Virtual Machine Introspection Based Architecture for Intrusion Detection". The idea resides in inspecting and understanding the real-time high-level state of a virtual machine, based on the hardware layer, for security purposes. Since then the technology has made its way, from research and academic developments to being fully integrated and supported into mainstream hypervisors, like Xen. What are the use-cases ? The initial population who adopted VMI has been malware sandbox providers. Since common malware had a tendency to hide from debuggers, the level of stealth reached with this technology made it perfectly suited for this job, alongside the full system view. Today VMI has grown to be applied in various domains: Debugging Malware Analysis Live Memory Analysis OS Hardening Fuzzing What is the state of the technology today ? As of today, Xen is the leading hypevisor, haivng VMI APIs since 2011. And since 2017, both KVM and VirtualBox have patches available, and even reviewed on the mailing list for KVM. Regarding the libraries available, LibVMI stands out, as it provides a unified, hypervisor-agnostic, VMI API to applications, and a well-known malware analysis framework (Drakvuf) is based on it. However, most of VMI applications today do not share the same common set of core libraries, which makes the ecosystem fragmented and hard to deal with, where a lot of efforts is spent solving the same problems everyone has, isolated by their own stacks. Why Rust ? This is where Rust comes into play. The language itself combines 3 important features: Safety: new VMI applications have a focus on OS hardening, rebasing your trust on an introspection agent to avoid a kernel compromise is a huge deal, especially when the agent has high-privileges. Speed: the amount of hardware events that can you can handle per second will define how much impact your agent has on the guest execution. This has to be kept as low as possible, otherwise the technology's adoption won't go further than private malware analysis systems. Cross-platform: Rust's build system and standard library allow to effortlessly build a cross-plaform library, which is a requirements to bring developers using KVM, Hyper-V or even VirtualBox to share the same library. Building this core library that will unify the ecosystem is the goal of libmicrovmi. Related work I have been building a hypervisor-level debugger, based on LibVMI. It can introspect a Windows guest and debug a specific process, while providing a GDB stub to be plugged into your favorite GDB fronted
 Hi everyone, thank you for being here today. My name is Mathieu Tarral, I'm here with Dario Hackenberg. And our talk is Rustifying the VM Introspection Ecosystem. So I know you are all tired from the fast them because it's afternoon and it's Sunday already, but I have a quick poll to do. Raise your hand if you have already heard about VM introspection. That's interesting. Okay. Sorry? Which VM introspection? Visual machine introspection in general, the technology. So today we're going in this talk to talk about VM introspection and the goal of the plantation is to present why we believe it's a valuable technology, why it has changed already or some areas like marine analysis and why we think that it has some unmet potential yet in areas like debugging, OS hardening or fuzzing for example. And we use Rust to go to this, to explore these areas and try to met the potential of VM introspection. So first disclaimer, we are not like expert Rust developers. I'm not going to learn anything new about Rust in this talk. It's just a project we made with Rust. So that's the agenda. First presenting VM introspection in general, presenting the VM ecosystem today and then presenting why we build a library in Rust to do VM introspection. I'm heading to, I always do, loyal. Yeah. Interesting. Yeah. So, hi, since Rust 1.0 came out in 2015, a number of projects around virtualization have emerged. You may know Firecracker for example, because it's one of the biggest projects written in Rust. Rust is a system of a programming language that promises to be memory safe. So actually, it's a perfect fit for the virtualization community. Yeah. Mathieu has accumulated some information about virtualization in general. So different projects, papers, not only Rust of course, but everything virtualization related. So yeah, go check it out. Yeah. So what is VM introspection? Briefly said, it's deriving the execution context of a virtual machine from the hypervisor by querying its hardware state. So, but handful, so what do we mean by that? Well, this you may know. You have your virtual machine here, around the virtualization layer, and underneath the hypervisor. So, this is where our introspection agent comes into play. It's actually on the host, and it talks to the hypervisor via an API. So, what can you do? Well, you can register for hardware events. For example, access to a certain area of memory, interrupt events, register, change events, and when one of these events happen, the VM is halted, the execution flow is transferred, the control flow is transferred to your application, and you can do whatever you can read memory, write memory, read registers, or write registers, and so on and so forth. So, yeah, what are the cost strengths of VM introspection? Well, for once, you have a full hardware view, so you can see the kernel space, and you can see the user space as well. Also you're operating at hypervisor level privilege. And so, between the hardware and the VM, you're also able to modify what the operating system itself should be able to see of itself. Yeah, so, in which scenarios is this useful? Well, nowadays, the main application for virtual machine introspection is dynamic malware analysis, if you want to be stealthy. But you can also, for example, use it for debugging scenarios, like maybe if you want to debug a nested hypervisor, or maybe you have a compromised operating system that you want so you can't trust the information you're receiving from the kernel. So now that I've talked about where you can apply it, let's talk about what you have to implement in order to be able to introspect a guest. So on a high level view, we have our introspection agent, and let's say maybe I want to break on a function, for example, kernel32.write file, and of course, we don't want to do this for every process, so let's say cargo.exe. And when this function call happens, we want to simply lock its parameters. So since you're outside of the VM, from outside, it's just a bunch of bytes. So you have to have a semantic engine that is able to derive the context for you, so where are some kernel distructs, or where is kernel32 actually located. So with this, you're able to retrieve the address of write file, and then you have your breakpoint manager who actually inserts a debug interrupt into the function and then sends a callback, so interrupt callback for you. This is where the event dispatcher comes into play, so the event dispatcher delivers your actually registers the event with your hypervisor, and it makes sure that the response, if the interrupt event is hit, that the response is funneled back to your breakpoint manager. So last but not least, you have your virtual address translation because the hypervisor itself has no knowledge of how the virtual memory is organized inside the VM, so you have to identify and walk the page structures by yourself. So you may see that there's a lot of complexity in there, so yeah, I'm going to head over to Mathieu to talk about where VMI is today. Okay, thank you. Thank you Dorian. Now let's talk about the VMI ecosystem, and by ecosystem, I mean application and libraries that exist today, because VMI transmission is here since a while, and things have, and the values have been developed since that time. You have seen before the complexity, so you are dealing with a lot of moving parts, and it's hard to come to a nutrification agent that works for many machines, many different systems, and that's part of the problems that we're going to see right now. First we need to talk about the hypervisor support, because if you want to listen to hardware events, you need the hypervisor to support them, you need to have the hypervisor to provide you a VMI API to query the events and to listen to other events, right? So that's the state of hypervisor support today. You have Xen, which has been the leading hypervisor on this technology, since 10 years, it has supported VMI APIs, and today if you just do the apiticate and install Xen, you already have it built in, you can just use the API right away. And for the rest of the hypervisors here, you can see that we have, let's say, a trend like two or three years ago, people started to build projects because they were interested by VMI on either VirtualBox, HyperV, KVM, QM. So that's really interesting. So community projects. And now on the state of VMI projects themselves, these are some of the most popular projects in the community that I tried to reference here. And the thing that I want to demonstrate here is that they are working in silos. The reason for that is that because most of them target only one hypervisor. And there is like a historical reason, or a reason for that is because sometimes there are academics, they want to write a thesis, so they rush to write something that works, and then there's an abstraction layer behind to adapt to multiple hypervisors, right? So we end up in this situation where projects are adopted, but they're not sharing the work they have been doing on their own. So you have silos and you have a lot of duplicated work between each other. So our goal today is to break these silos and to make the communities work together and solve the same problems together to build better VMI apps, right? So our idea is basically to unify this ecosystem. What we want is to insert a library here that will have this abstraction layer, enough abstraction to deal with any hypervisor or emulator behind it, and to be compatible enough to be linked with any of the projects already existing. That's the general idea that we want to build in Rust. So we have constraints for this to work. First we need to have speed because this abstraction layer will have a cost. And if you come to one of these projects and say, hey, we have this abstraction layer, you can talk to any hypervisor now, but yeah, it's a bit slower. As you have seen, VMI will have an impact on the guest, and the more time you spend processing your events, the more impact there is on the guest. So your library needs to be really fast to be convincing. So our first constraint is speed. The next one is compatibility. If you want to write this layer, we need to provide a C API, of course, because all of these are project in CRC++. So they need to link to our library, and so we need to provide C compatibility. And then we need to be cross-platform. We have some projects for Linux, some projects for Windows, and some projects for both. We need to be easy to maintain on Windows Linux, or even Mac OS in the future. So it needs to be easy to maintain, easy to work on. That's another constraint. Because if I have a library on Linux that is not portable to Windows, it's not going to be usable. And then we have a desire quality today to be memory safe. If you think about another use case for this introspection agent, let's say we want to monitor an entire cloud with thousands of VMs. We want to be memory safe because otherwise we would just introduce a new attack surface. Before an attack surface was hypervisors and the emulated devices. But now you have the introspection agent because it's processing inputs and untrusted inputs from the guest. So I don't want to process these inputs in C, right? So yeah, we have REST. REST gave us speed, C compatibility, easy to write a cross-platform library, and it is memory safe. So that's why we decided to write it in REST. And the objective that we want to achieve is a bit like this. We have on the left the VMI apps that are already existing, or the future VMI apps for dynamic analysis, live memory analysis, OS hardening, or even fuzzing. And we want to adapt them on any hypervisor or emulator, give this flexibility. And for that we started with this library, lib microVMI, which is just a unified low-level VMI API to read memory, listen to hardware events. And then later on to build these new crates to perform this task of semantic engine, retro-dress transition, and breakpoint manager. That's the end goal of this project. So what is the state of lib microVMI? What have you achieved today? We can read the physical memory. That's all the VMI API you can see on the left, pretty much. We can partially read the VCP registers. And we started to work on listening on CR3 events. And on the right you can see that we have a C API thanks to Dorian. And also a libVMI integration. We started working on that, to integrate into existing tools and libraries. And regarding the drivers, we have drivers for Xen, KVM, and VirtualBox. We have this compatibility. So what does it look like? I have a small demo. So now I wanted to increase the quality, but it shouldn't be increased automatically. This is a memory dump example. So I'm running Windows XP here. And I'm running a memory dump example on the left. So I'm dumping the memory of Windows XP. And then I'm displaying the state of the registers. And then I'm going to do the same thing for Xen. This is KVM. And I'm doing the same thing with the same API, that's what we want. On KVM, so memory dump, connecting to KVM, VMI API, and dumping the domain, and printing the registers. And then we're going to do the same for VirtualBox. We do the same API, because it's unified. And that's it. We dump the domain on these three hypervisors. That's what we wanted to achieve in the first place. And we have, okay, what do you do that? No? Okay. This is a demo about catching CR-free events, because we want to show how we catch when there is a context switch in the scheduler. And when you do a context switch, you switch your CR-free registers, because it contains the physical address of the page directory, right? So when you have a context switch, you change the CR-free registers, and you can catch that as a hardware event. So on this Windows XP, I will generate some noise or some activity by animating what's left on the disk, and on the right, I'm going to catch plenty of CR-free events here. That's it. And it's really fast, because you can see, or I will tell you, that I actually catch... The font is not big enough, but okay, I actually catch 4,000 events per second, 4,000 context switches per second. So that's quite fast, fast enough, right? So what we want to do in the future for VM introspection, we want to build this OS independent hooking framework, because it has unexplored areas where it can be applicable for intrusion detections, for debuggers, if you want to debug a kernel or have the full state of the system to view the entire system from the host, or just build a new layer of hardening. You can watch some critical kernel areas in your introspection agent and kill the process when they are being corrupted, right? Or you can also do snapshot-based fuzzing to fuzz from the hypervisor. All of this enabled by VM introspection and by having a unified API. And of course, at the end, making VM introspection a commodity, usable by everyone. And one last thing, we will propose the macroVMI for the GSOC this year. So if you're a student and you're interested by VM introspection and virtualization and building interesting apps, you can propose your application. You are part of the Honelect organization. And you can either improve an existing driver, Xen KVM VirtualBox, or even Hyper-V. You can add support for emulators, KMU, Box, or even Unicorn. You can propose a stealth RedBone implementation based on the EPT, the Extendant Page Tables. Or you can serve this little issue on Bygen, adding support for libloading. So you can generate the bindings that are using libloading to load the library at runtime. That would be really great. So as a conclusion, we would like to improve VM introspection and by improving the ecosystem and to let this technology exploit its full capabilities. Thanks to the Reddit community on Reddit because they helped me a lot building this talk. Thank you for your attention. That was it. Thank you. So we do have time for questions? Yes? Because this work on the Linux Null x86.com. For the moment, it's only x86. Yes, it's hardcoded. But because it's really small projects, but later on we will add support for other architectures. So there is some provision in the API that we could also support. Yes, yes. Can you repeat the question, please? Yes? There is also support for VMware. VMware doesn't provide a VMI API. So is there support for VMware? The problem is that VMware doesn't provide this VMI API. There is no support for them. They don't provide you like the haters and they don't open an API for you to work on it. But in the future, they will use the Windows hypervisor platform, right? Because like tomorrow everyone has to use Hyper-V. And if in the future this Windows hypervisor platform provides a VMI API, you can plug into it and become compatible with Hyper-V, VMware, and VirtualBox on Windows Windows 10. Yes? So I was wondering for embedded system development whether there was any possibility of using this against hardware debugging tools that the CPU provides. So to actually debug and remote, you have the host on your desk with a high-speed link to it using the hardware interfaces. So presumably you would just treat it like a different virtual machine system. But so you could debug a real machine. Yes, or if you have an embedded system which is virtualized. For a non-virtualized one, so you have two machines. You have your target, which is a real machine with a hardware debug facility provided by the architecture like ARM does and Intel does as well. Well, with VMI you need virtualization to enable debugging more to happen. You need the same facilities for stop and... Okay. Yeah. Well, I think that's another topic or it's another project separated from VMI, I believe. Okay. But it could be possible to have an abstraction layer on both. Any other questions? So do we come down here, please? One. Two, two, three, two, one. No, thanks. Thank you. Thank you.
 Hi everyone, thank you for being here today.  My name is Mathieu Tarral, I'm here with Dario Hackenberg.  And our talk is Rustifying the VM Introspection Ecosystem.  So I know you are all tired from the fast them because it's afternoon and it's Sunday  already, but I have a quick poll to do.  Raise your hand if you have already heard about VM introspection.  That's interesting.  Okay.  Sorry?  Which VM introspection?  Visual machine introspection in general, the technology.  So today we're going in this talk to talk about VM introspection and the goal of the  plantation is to present why we believe it's a valuable technology, why it has changed already  or some areas like marine analysis and why we think that it has some unmet potential  yet in areas like debugging, OS hardening or fuzzing for example.  And we use Rust to go to this, to explore these areas and try to met the potential of  VM introspection.  So first disclaimer, we are not like expert Rust developers.  I'm not going to learn anything new about Rust in this talk.  It's just a project we made with Rust.  So that's the agenda.  First presenting VM introspection in general, presenting the VM ecosystem today and then  presenting why we build a library in Rust to do VM introspection.  I'm heading to, I always do, loyal.  Yeah.  Interesting.  Yeah.  So, hi, since Rust 1.0 came out in 2015, a number of projects around virtualization  have emerged.  You may know Firecracker for example, because it's one of the biggest projects written in  Rust.  Rust is a system of a programming language that promises to be memory safe.  So actually, it's a perfect fit for the virtualization community.  Yeah.  Mathieu has accumulated some information about virtualization in general.  So different projects, papers, not only Rust of course, but everything virtualization related.  So yeah, go check it out.  Yeah.  So what is VM introspection?  Briefly said, it's deriving the execution context of a virtual machine from the hypervisor  by querying its hardware state.  So, but handful, so what do we mean by that?  Well, this you may know.  You have your virtual machine here, around the virtualization layer, and underneath the  hypervisor.  So, this is where our introspection agent comes into play.  It's actually on the host, and it talks to the hypervisor via an API.  So, what can you do?  Well, you can register for hardware events.  For example, access to a certain area of memory, interrupt events, register, change events,  and when one of these events happen, the VM is halted, the execution flow is transferred,  the control flow is transferred to your application, and you can do whatever you can read memory,  write memory, read registers, or write registers, and so on and so forth.  So, yeah, what are the cost strengths of VM introspection?  Well, for once, you have a full hardware view, so you can see the kernel space, and you can  see the user space as well.  Also you're operating at hypervisor level privilege.  And so, between the hardware and the VM, you're also able to modify what the operating system  itself should be able to see of itself.  Yeah, so, in which scenarios is this useful?  Well, nowadays, the main application for virtual machine introspection is dynamic malware analysis,  if you want to be stealthy.  But you can also, for example, use it for debugging scenarios, like maybe if you want  to debug a nested hypervisor, or maybe you have a compromised operating system that you  want so you can't trust the information you're receiving from the kernel.  So now that I've talked about where you can apply it, let's talk about what you have to  implement in order to be able to introspect a guest.  So on a high level view, we have our introspection agent, and let's say maybe I want to break  on a function, for example, kernel32.write file, and of course, we don't want to do this  for every process, so let's say cargo.exe.  And when this function call happens, we want to simply lock its parameters.  So since you're outside of the VM, from outside, it's just a bunch of bytes.  So you have to have a semantic engine that is able to derive the context for you, so  where are some kernel distructs, or where is kernel32 actually located.  So with this, you're able to retrieve the address of write file, and then you have your  breakpoint manager who actually inserts a debug interrupt into the function and then  sends a callback, so interrupt callback for you.  This is where the event dispatcher comes into play, so the event dispatcher delivers your  actually registers the event with your hypervisor, and it makes sure that the response, if the  interrupt event is hit, that the response is funneled back to your breakpoint manager.  So last but not least, you have your virtual address translation because the hypervisor  itself has no knowledge of how the virtual memory is organized inside the VM, so you  have to identify and walk the page structures by yourself.  So you may see that there's a lot of complexity in there, so yeah, I'm going to head over  to Mathieu to talk about where VMI is today.  Okay, thank you.  Thank you Dorian.  Now let's talk about the VMI ecosystem, and by ecosystem, I mean application and libraries  that exist today, because VMI transmission is here since a while, and things have, and  the values have been developed since that time.  You have seen before the complexity, so you are dealing with a lot of moving parts, and  it's hard to come to a nutrification agent that works for many machines, many different  systems, and that's part of the problems that we're going to see right now.  First we need to talk about the hypervisor support, because if you want to listen to hardware  events, you need the hypervisor to support them, you need to have the hypervisor to provide  you a VMI API to query the events and to listen to other events, right?  So that's the state of hypervisor support today.  You have Xen, which has been the leading hypervisor on this technology, since 10 years,  it has supported VMI APIs, and today if you just do the apiticate and install Xen, you  already have it built in, you can just use the API right away.  And for the rest of the hypervisors here, you can see that we have, let's say, a trend  like two or three years ago, people started to build projects because they were interested  by VMI on either VirtualBox, HyperV, KVM, QM.  So that's really interesting.  So community projects.  And now on the state of VMI projects themselves, these are some of the most popular projects  in the community that I tried to reference here.  And the thing that I want to demonstrate here is that they are working in silos.  The reason for that is that because most of them target only one hypervisor.  And there is like a historical reason, or a reason for that is because sometimes there  are academics, they want to write a thesis, so they rush to write something that works,  and then there's an abstraction layer behind to adapt to multiple hypervisors, right?  So we end up in this situation where projects are adopted, but they're not sharing the work  they have been doing on their own.  So you have silos and you have a lot of duplicated work between each other.  So our goal today is to break these silos and to make the communities work together and  solve the same problems together to build better VMI apps, right?  So our idea is basically to unify this ecosystem.  What we want is to insert a library here that will have this abstraction layer, enough  abstraction to deal with any hypervisor or emulator behind it, and to be compatible  enough to be linked with any of the projects already existing.  That's the general idea that we want to build in Rust.  So we have constraints for this to work.  First we need to have speed because this abstraction layer will have a cost.  And if you come to one of these projects and say, hey, we have this abstraction layer,  you can talk to any hypervisor now, but yeah, it's a bit slower.  As you have seen, VMI will have an impact on the guest, and the more time you spend  processing your events, the more impact there is on the guest.  So your library needs to be really fast to be convincing.  So our first constraint is speed.  The next one is compatibility.  If you want to write this layer, we need to provide a C API, of course, because all of  these are project in CRC++.  So they need to link to our library, and so we need to provide C compatibility.  And then we need to be cross-platform.  We have some projects for Linux, some projects for Windows, and some projects for both.  We need to be easy to maintain on Windows Linux, or even Mac OS in the future.  So it needs to be easy to maintain, easy to work on.  That's another constraint.  Because if I have a library on Linux that is not portable to Windows, it's not going  to be usable.  And then we have a desire quality today to be memory safe.  If you think about another use case for this introspection agent, let's say we want to  monitor an entire cloud with thousands of VMs.  We want to be memory safe because otherwise we would just introduce a new attack surface.  Before an attack surface was hypervisors and the emulated devices.  But now you have the introspection agent because it's processing inputs and untrusted inputs  from the guest.  So I don't want to process these inputs in C, right?  So yeah, we have REST.  REST gave us speed, C compatibility, easy to write a cross-platform library, and it is  memory safe.  So that's why we decided to write it in REST.  And the objective that we want to achieve is a bit like this.  We have on the left the VMI apps that are already existing, or the future VMI apps for  dynamic analysis, live memory analysis, OS hardening, or even fuzzing.  And we want to adapt them on any hypervisor or emulator, give this flexibility.  And for that we started with this library, lib microVMI, which is just a unified low-level  VMI API to read memory, listen to hardware events.  And then later on to build these new crates to perform this task of semantic engine, retro-dress  transition, and breakpoint manager.  That's the end goal of this project.  So what is the state of lib microVMI?  What have you achieved today?  We can read the physical memory.  That's all the VMI API you can see on the left, pretty much.  We can partially read the VCP registers.  And we started to work on listening on CR3 events.  And on the right you can see that we have a C API thanks to Dorian.  And also a libVMI integration.  We started working on that, to integrate into existing tools and libraries.  And regarding the drivers, we have drivers for Xen, KVM, and VirtualBox.  We have this compatibility.  So what does it look like?  I have a small demo.  So now I wanted to increase the quality, but it shouldn't be increased automatically.  This is a memory dump example.  So I'm running Windows XP here.  And I'm running a memory dump example on the left.  So I'm dumping the memory of Windows XP.  And then I'm displaying the state of the registers.  And then I'm going to do the same thing for Xen.  This is KVM.  And I'm doing the same thing with the same API, that's what we want.  On KVM, so memory dump, connecting to KVM, VMI API, and dumping the domain, and printing  the registers.  And then we're going to do the same for VirtualBox.  We do the same API, because it's unified.  And that's it.  We dump the domain on these three hypervisors.  That's what we wanted to achieve in the first place.  And we have, okay, what do you do that?  No?  Okay.  This is a demo about catching CR-free events, because we want to show how we catch when  there is a context switch in the scheduler.  And when you do a context switch, you switch your CR-free registers, because it contains  the physical address of the page directory, right?  So when you have a context switch, you change the CR-free registers, and you can catch that  as a hardware event.  So on this Windows XP, I will generate some noise or some activity by animating what's  left on the disk, and on the right, I'm going to catch plenty of CR-free events here.  That's it.  And it's really fast, because you can see, or I will tell you, that I actually catch ... The font is not big enough, but okay, I actually catch 4,000 events per second,  4,000 context switches per second.  So that's quite fast, fast enough, right?  So what we want to do in the future for VM introspection, we want to build this OS independent  hooking framework, because it has unexplored areas where it can be applicable for intrusion  detections, for debuggers, if you want to debug a kernel or have the full state of the  system to view the entire system from the host, or just build a new layer of hardening.  You can watch some critical kernel areas in your introspection agent and kill the process  when they are being corrupted, right?  Or you can also do snapshot-based fuzzing to fuzz from the hypervisor.  All of this enabled by VM introspection and by having a unified API.  And of course, at the end, making VM introspection a commodity, usable by everyone.  And one last thing, we will propose the macroVMI for the GSOC this year.  So if you're a student and you're interested by VM introspection and virtualization and  building interesting apps, you can propose your application.  You are part of the Honelect organization.  And you can either improve an existing driver, Xen KVM VirtualBox, or even Hyper-V.  You can add support for emulators, KMU, Box, or even Unicorn.  You can propose a stealth RedBone implementation based on the EPT, the Extendant Page Tables.  Or you can serve this little issue on Bygen, adding support for libloading.  So you can generate the bindings that are using libloading to load the library at runtime.  That would be really great.  So as a conclusion, we would like to improve VM introspection and by improving the ecosystem  and to let this technology exploit its full capabilities.  Thanks to the Reddit community on Reddit because they helped me a lot building this talk.  Thank you for your attention.  That was it.  Thank you.  So we do have time for questions?  Yes?  Because this work on the Linux Null x86.com.  For the moment, it's only x86.  Yes, it's hardcoded.  But because it's really small projects, but later on we will add support for other architectures.  So there is some provision in the API that we could also support.  Yes, yes.  Can you repeat the question, please?  Yes?  There is also support for VMware.  VMware doesn't provide a VMI API.  So is there support for VMware?  The problem is that VMware doesn't provide this VMI API.  There is no support for them.  They don't provide you like the haters and they don't open an API for you to work on it.  But in the future, they will use the Windows hypervisor platform, right?  Because like tomorrow everyone has to use Hyper-V.  And if in the future this Windows hypervisor platform provides a VMI API,  you can plug into it and become compatible with Hyper-V, VMware, and VirtualBox on Windows Windows 10.  Yes?  So I was wondering for embedded system development whether there was any possibility of using this  against hardware debugging tools that the CPU provides.  So to actually debug and remote, you have the host on your desk with a high-speed link to it using the hardware interfaces.  So presumably you would just treat it like a different virtual machine system.  But so you could debug a real machine.  Yes, or if you have an embedded system which is virtualized.  For a non-virtualized one, so you have two machines.  You have your target, which is a real machine with a hardware debug facility provided by the architecture like ARM does and Intel does as well.  Well, with VMI you need virtualization to enable debugging more to happen.  You need the same facilities for stop and...  Okay.  Yeah.  Well, I think that's another topic or it's another project separated from VMI, I believe.  Okay.  But it could be possible to have an abstraction layer on both.  Any other questions?  So do we come down here, please?  One.  Two, two, three, two, one.  No, thanks.  Thank you.  Thank you.
rust_vm_introspection_0_131.png rust_vm_introspection_132_2291.png rust_vm_introspection_2292_4619.png rust_vm_introspection_4620_6431.png rust_vm_introspection_6432_11723.png rust_vm_introspection_11724_12959.png rust_vm_introspection_12960_14243.png rust_vm_introspection_14244_15815.png rust_vm_introspection_15816_15935.png rust_vm_introspection_15936_18371.png rust_vm_introspection_18372_19631.png rust_vm_introspection_19632_20771.png rust_vm_introspection_20772_20879.png rust_vm_introspection_20880_21923.png rust_vm_introspection_21924_21983.png rust_vm_introspection_21984_22031.png rust_vm_introspection_22032_22115.png rust_vm_introspection_22116_22331.png rust_vm_introspection_22332_23099.png rust_vm_introspection_23100_23183.png rust_vm_introspection_23184_23411.png rust_vm_introspection_23412_23459.png rust_vm_introspection_23460_23519.png rust_vm_introspection_23520_23651.png rust_vm_introspection_23652_23795.png rust_vm_introspection_23796_23855.png rust_vm_introspection_23856_24011.png rust_vm_introspection_24012_24887.png rust_vm_introspection_24888_24935.png rust_vm_introspection_24936_25283.png rust_vm_introspection_25284_25451.png rust_vm_introspection_25452_32231.png rust_vm_introspection_32232_32354.png