WEBVTT 00:00.000 --> 00:11.640 Okay, welcome everyone. I'm Stefan Agarzarella and today I will talk about what we are doing in 00:11.640 --> 00:19.120 Rustvmm. This talk was prepared together with Rohin and Patrick that I would like to thank, 00:19.120 --> 00:24.920 but unfortunately, they cannot be here, so I will try to cover also their part. So, before 00:25.000 --> 00:30.920 going into the details, let's start what is Rustvmm. I don't know if you know about it, but anyway, 00:31.800 --> 00:36.200 we are an open source project that would like to provide 00:38.600 --> 00:43.960 set of virtualization components that people can use to build custom virtual machine monitors or 00:43.960 --> 00:50.120 hypervisor. So, we don't provide any VMMams or hypervisor. We just provide the building blocks 00:50.200 --> 00:58.120 that people can use to build them. And why do Rustvmm? Because we want to reduce code 00:58.120 --> 01:03.720 duplication. We don't want to, for example, implement virtual device in every hypervisor. So, 01:03.720 --> 01:08.440 the idea is just to provide you, okay, this is the implementation of virtual device. You can use it 01:08.440 --> 01:15.320 as a, how you want. We also want to faster a bit the development. So, we are several people 01:15.320 --> 01:22.200 from different projects, from different companies, try to collaborate to provide this components. 01:22.200 --> 01:27.720 We are also trying to focus on security and stability. And, of course, we want to provide a clean 01:27.720 --> 01:32.440 interface because we want to, I mean, we are collaborating with different projects. 01:33.480 --> 01:37.560 I left here the links to our mailing list and Slack channel. If you want to join, 01:37.560 --> 01:44.280 you are really, really welcome. These are the set of repositories that contains Rustvm 01:44.360 --> 01:48.360 creates that we develop. So, essentially, we provide 01:48.360 --> 01:55.720 wrappers for KVM hypervxan. We provide a Linux loader. If your VMMm want to load Linux directly 01:56.360 --> 02:04.280 in your guest, we provide some resource management crates, VM allocator, mainly for MMI 02:04.280 --> 02:11.480 address, IDs, that kind of things. And VMMamory, which is one of our core crate, used by, for example, 02:11.560 --> 02:18.280 all the device emulation, because it is the abstraction of the VMMamory. So, we use that 02:18.280 --> 02:23.400 crate to access the memory in the device emulation, for example. And, about the device, we provide 02:24.200 --> 02:31.160 vertio, of course. We have set of crates for bird cues and also for some vertio devices. 02:31.960 --> 02:41.160 And, then, we also have crates for vhost, vhost user and vdpa. And, our, we also have a lot of 02:41.160 --> 02:51.240 vhost user devices. We will see later which one. We provide wrappers for vfiu and also a little 02:51.240 --> 03:00.360 set of legacy devices like serial port or real time clock. And, we have a couple of repo for our 03:00.360 --> 03:06.360 ecosystem like the CI, because we would like to keep our CI consistent by all of the repos. 03:06.440 --> 03:13.160 So, we have a crate, I mean, repo for our CI and the container that runs all of our tests. 03:14.760 --> 03:20.200 About adoption, we are our user. The first one I would like to mention is firecracker, because 03:20.200 --> 03:27.720 Roth VMMam essentially started with firecracker guys. And, firecracker is a lightweight VMMam 03:28.040 --> 03:35.880 that runs a very lightweight VMs called micro VMs. And, another one is cloud vapor 03:35.880 --> 03:42.840 vital, which is fully based on Rust VMMam crates. This is a more general VMMam that runs 03:42.840 --> 03:50.600 bigger workloads on cloud environment. Then, we have a Libkiran developed by Michael Lixergeur, 03:50.680 --> 03:59.000 which is also a lightweight VM, but extremely lightweight that you can even use in your application 03:59.880 --> 04:05.240 because it's a dynamic library that allows you to run custom process in a very lightweight 04:05.240 --> 04:11.480 VM inside a custom-minded Linux kernel. And, so, if you want to partially isolate a process, 04:11.480 --> 04:18.600 you can use this library in your application. Another user is the Dragon Bolt Sandbox provided 04:18.680 --> 04:24.040 by the Kata Container Community, which is also based on Rust VMMam crates. 04:24.840 --> 04:28.360 These are other projects, not really VMMams, but also in the virtualization 04:28.360 --> 04:35.320 component, virtualization workspace, via user devices. We have a lot of via user devices 04:35.320 --> 04:41.320 that we provide in Rust VMMam, but also others like Vertaier FSD, which is external project, 04:41.880 --> 04:49.880 but they use our crates. Another interesting tool is IMAGA, from Michael Lixergeur, 04:49.880 --> 04:57.880 which provide access to VM disk images, like Tukup2 images. Another one that I found is the VMMaxac, 04:59.080 --> 05:05.720 which it's a common line interface tool that should be able to run single common in a really 05:05.720 --> 05:11.960 draw-away VM. So, if you want to start something in a isolated environment, this could be 05:13.240 --> 05:19.000 the right tool to use. And, I found also this Dragonfly image service called Nages, 05:19.000 --> 05:25.960 that use the Providals, Vertaier FSD, Vertaier FSD protocol, and they do that using our crates, 05:25.960 --> 05:33.640 using Rust VMMam crates. Another two project I would like to mention, because they mentioned us 05:33.640 --> 05:40.200 in how are in there, read me. Essentially, one is Cross VM, and I'd like to say that 05:40.200 --> 05:45.480 part of our code is based on Cross VM, which is one of the first VMMam implemented in Rust. 05:45.480 --> 05:52.440 And now, they seem to open to use a Tukup3 in Rust VMMam, and we are also really open to 05:52.440 --> 05:58.040 welcome them. It could be nice to collaborate together. Another one is more recently 05:59.000 --> 06:05.480 VMMam from Microsoft, which is open VMMam, which is mainly for confidential computing, 06:06.200 --> 06:14.840 and they also mention our work on VMMam staff, and they hope to find a way to collaborate. 06:14.840 --> 06:18.920 We hope to say, maybe in the future, we will be able to collaborate. 06:20.440 --> 06:26.040 Okay, about our crates. So, what we support, what architecture we support? We mainly support 06:26.120 --> 06:34.520 86 and R64. We are working on risk-fi, and I have a couple of slides from Rohin, which did the 06:34.520 --> 06:42.680 great work on that. About operating system, of course, Linux and KVM. We also support Windows in 06:42.680 --> 06:51.000 some crates, and we started to, especially for VOS users, we started to extend the support on any 06:51.000 --> 06:57.320 other POS system. I talked about it last year, here in FOS them, where I have a slide later. 06:57.320 --> 07:03.800 So, yeah, about VOS users, if you're interested, I will talk more about VOS users in the next 07:03.800 --> 07:09.880 talk, in less than one hour, should be, yeah, where I talk more about VOS. But essentially, 07:09.880 --> 07:17.480 VOS users is a way to do device emulation in an external process. In another user space process, 07:17.480 --> 07:23.640 instead of the VMM, mainly for security, but also for flexibility. Because, for example, in KVM, 07:24.520 --> 07:29.720 which, I mean, the spec is in KVM, because the KVM community come up with the VOS user. 07:29.720 --> 07:36.120 But it's so generic that you can implement, in any way, in this case, in Rust VMM, 07:36.120 --> 07:42.120 we are implementing a lot of VOS user device, that you can use with KVM, with cloud vapor 07:42.840 --> 07:48.280 with any VMM that support a VOS user protocol, where we call front end the VM, 07:49.240 --> 07:55.000 which is the one that provide access to the birdcuse, and we call back end the device essentially. 07:55.000 --> 08:03.000 The one that consumes the birdcuse. And it's a bit generic. The only components that 08:03.000 --> 08:08.760 VOS user protocol use are a unique domain socket, because it's also able to move file 08:08.760 --> 08:13.560 descriptor around, and then we use the file descriptor passing feature of VOS user. Unix domains 08:13.560 --> 08:19.480 socket to share the memory, mainly the guest memory, and also to set up some 08:21.720 --> 08:28.920 notification system. We use a eventfD on Linux, for example, or pipes on other operating system. 08:30.760 --> 08:37.800 Yeah, about what we provide about VOS user, in Rust VMM, we have a VOS crate, 08:37.880 --> 08:44.440 which provides all the wrappers for VDPA, VOS, and VOS user. And then we have a VOS 08:44.440 --> 08:50.920 user back end trade, which is a framework to implement VOS user devices. And in this crate, 08:50.920 --> 08:57.560 we provide a demon control object to start and stop the device, essentially a trade to handle 08:57.560 --> 09:05.400 the VOS user control messages, and also a trade to access the birdcuse. And as I mentioned, 09:05.400 --> 09:11.320 in the Rust VMM project, we provide several devices, several birthday or devices, like 09:11.320 --> 09:18.760 can control scasysound, visoc, at least all of them here, and if you're interested in the 09:18.760 --> 09:26.840 Zeling. And also we have an external project called VirtiFSD, which is fully based on our Rust VMM 09:26.840 --> 09:34.680 crate and use exactly VOS user back end to implement a VOS device as a VOS user device. 09:36.280 --> 09:45.000 What we did in the last years, about VirtiFSD. So we started to support VOS 6, a bit more, 09:45.000 --> 09:51.240 I mean, we started with Linux, of course, and then we tried to support any VOS 6 system for Vhost. 09:53.080 --> 09:59.640 Last year we also started to do formal verification of VirtiFSD devices. VirtiFSD is an open 09:59.640 --> 10:05.640 specification, and with Google Summit of CodeProject, we started to put some kind of formal 10:05.640 --> 10:13.160 verification to check that our VirtiFSD devices follow the spec. And then we added a couple of 10:14.440 --> 10:22.360 new support for VOS user messages, some classes written writer to parse better the VirtiFSD 10:22.360 --> 10:31.800 descriptors. We started to support the VirtiFSD, which is another essentially VirtiO provides 10:31.800 --> 10:39.480 two VirtiFSD formats, split and part, and split is the, we can say the default one, the part 10:39.480 --> 10:45.720 that is the new one that we started to support recently. And we also started to support live 10:45.720 --> 10:54.760 migration for VOS user, and this is implemented in VirtiFSD right now. And also we added 10:54.760 --> 11:03.720 support for shared object and shared memory, which is mainly for devices like video, GPU, 11:03.720 --> 11:10.280 video, video, video, video, video, video, and I mentioned that a couple of these new features 11:10.360 --> 11:18.040 were developed by GSox student. So last year we did two successful project, one to support 11:18.040 --> 11:25.000 MacRasson BSD, essentially for VOS user in Rust VMM, and that was done by Wanyu Wang, 11:25.000 --> 11:34.120 mentor by Hermann Holywell and myself, and Matias, another microly, mentor to Zeta Priya to essentially 11:34.120 --> 11:43.240 put the formal verification in our devices using Kani. And this year Kimo will apply the 11:43.240 --> 11:49.720 already applied. I mean we are usually we do our Google summer code project under the Kimo umbrella, 11:49.720 --> 11:55.320 and they want to like to thanks the Kimo community for that. This year Kimo will apply again, 11:56.360 --> 12:01.960 Google will communicate, I don't know, I think in a couple of weeks, if it is accepted or not, 12:01.960 --> 12:07.240 if yes, one of the projects is also related to Rust VMM, which is this one to implement a 12:07.240 --> 12:14.040 virtual real-time cloud device as a VOS user device in Rust VMM, and if you are interested, 12:14.040 --> 12:19.800 feel free to contact Matias franchise, because we would like to do this new device. 12:22.840 --> 12:29.560 Other things we did in VMM, which is one of our core crate. This last year was to support 12:29.800 --> 12:38.200 VMM. We started to support VMM. There is also a working progress mainly by Patrick, 12:38.200 --> 12:45.240 to try to make our crate feature additive. Essentially, we have a feature to support exam, 12:45.240 --> 12:49.320 which is not really additive, so if you enable that feature in the crate, essentially your crate 12:49.320 --> 12:55.720 will work only on the exam, this is not really great for us, and we are trying to figure out how to 12:56.360 --> 13:03.240 fix this. And also about Kimo, Kimo now started to support Rust. I mean, you can write 13:03.240 --> 13:09.720 some devices, for example, in Rust into Kimo, and there is a thread about start to use our 13:09.720 --> 13:17.800 crates to in Kimo itself for the Rust part. And other couple of ideas, many from Patrick, to 13:18.760 --> 13:24.120 to sling down our volatized device to work better with virtual devices and to replace 13:24.120 --> 13:33.160 byte value with zero copy. Okay, another, I mean, an issue that we had in these years 13:34.360 --> 13:43.480 was related about our deep chain of dependency. So for example, Firecracker or VHOS device or 13:44.280 --> 13:57.640 VHOS device, or VHOS device or to implement VHOS user, and the VHOS crate itself depends on the 13:57.640 --> 14:03.160 VMBertio crate for the VHOS, that depends on VM memory to access the guest memory, that depends on 14:03.160 --> 14:10.200 VMMMC's YouTube. So we have a really deep chain of dependency, and every time we change something, 14:10.280 --> 14:15.800 for example, in VM memory, we need to be sure that we propagate the changes, and sometimes 14:15.800 --> 14:21.640 contributor for God about it, maintain results for God about it. So we try to find parts of 14:21.640 --> 14:28.920 solution, like try to automate the crates.io releases, but because we need to follow a strict 14:30.360 --> 14:36.440 sequence of releases. So we need to release VMMC's YouTube first, then VMMertio, VMMemory, and so on. 14:37.160 --> 14:49.640 So we try to automate crates.io. We try to use the dependency upgrade in a minor release, 14:49.640 --> 14:55.800 but this is tricky, and what we are thinking about is to use a mono repo for all of our crates. 14:56.600 --> 15:04.120 This should also answer the question on how to keep our configuration consistent. We try using 15:04.440 --> 15:11.640 some model for our CI, for example, and but yeah, we are thinking about the mono repo. 15:11.640 --> 15:16.440 We already did something for other crates. So essentially, when Rust VMMem started, 15:18.120 --> 15:26.040 we had one repo, one repo per crate, and that was not really amazing. So during the years, 15:26.040 --> 15:32.760 we tried to put crates together on the rough workspace, and for us every Rust workspace is a 15:32.760 --> 15:39.640 Git repo. So for example, we merge KVM bindings and KVM, IOCTL, under a single workspace. 15:39.640 --> 15:48.280 We did the same for VFIO, for VMVertio, and not for Vhost. And our next steps would be to put 15:48.280 --> 15:52.360 everything together. This should at least, when someone touch something in a crate, 15:54.040 --> 16:00.440 take care of the others. And so the idea is to put all the crates in Rust VMMem workspace, 16:00.600 --> 16:06.760 which will be a single Git repo, and we will use path dependency. Of course, this will bring 16:06.760 --> 16:15.640 up other issue. Like maybe we will need a stable branch and to avoid break stuff when we, 16:17.160 --> 16:23.880 I mean, to have fixes to go more faster and stuff like that. But we hope that we solve the other issue 16:23.960 --> 16:31.400 we find. So Ruhin started to work on that. We created the repo. We started to put the CIDER. 16:31.960 --> 16:38.280 We started to move the VMMemC's utils there. Still working progress. I mean, we need to merge 16:38.280 --> 16:47.160 the VMMemC's utils PR. But essentially, we hope to do that in the last few months. 16:48.120 --> 16:54.200 And last thing is about risk five. Also, this is the work done by Ruhin in the last two years. 16:54.920 --> 17:01.720 We started to support it. Mainly, we started for the CID. Now, we don't have hardware in our CID 17:01.720 --> 17:08.440 that run the TAR risk five. So for now, we are using H86 machine with VMMem to fully emulate 17:08.520 --> 17:18.040 the risk of risk five virtual machine. And inside that, we will run our container and our CID 17:18.040 --> 17:26.760 that will run in every crate that used the Rust VMMemCI sub module. And about the crates, 17:27.560 --> 17:33.800 the code that we saw that support risk five. You can see the one in the light orange 17:33.880 --> 17:38.760 are the one that done. I mean, we don't have support for risk five right now in that crate. 17:38.760 --> 17:45.000 But all the others should support it. So, future works. We hope to have some risk five 17:45.000 --> 17:53.320 order to put into our CID system this year, not sure. And about crates, we are working. 17:53.320 --> 17:57.880 I mean, many of our HIN is working to move also the rest of the crates. Like VHOS, 17:57.880 --> 18:07.720 VHOS, VHOS, VHOS, VHOS, VHOS, as well. And that is it. If you want to join our community, 18:07.720 --> 18:12.680 we will be really happy. This is the link that contains all the information. So, happy 18:12.680 --> 18:17.680 question. 18:17.680 --> 18:18.680 OK. 18:18.680 --> 18:19.680 So thank you. 18:19.680 --> 18:20.680 Really? 18:20.680 --> 18:21.680 Want to join us? 18:21.680 --> 18:22.680 There is a question? 18:22.680 --> 18:23.680 Yeah. 18:23.680 --> 18:27.680 Do you think it was so important that it would be visible 18:27.680 --> 18:30.680 to run into the Waza? 18:30.680 --> 18:32.680 WebAssembly, you mean? 18:32.680 --> 18:33.680 Yeah. 18:33.680 --> 18:37.680 The question was if we will run Rostia M.M. 18:37.680 --> 18:39.680 Crates one day in WebAssembly. 18:39.680 --> 18:40.680 Why not? 18:40.680 --> 18:41.680 I don't know. 18:41.680 --> 18:42.680 Maybe yes. 18:42.680 --> 18:45.680 If you are interested, let's talk about it. 18:45.680 --> 18:48.680 Or if you know someone interested would be cool. 18:48.680 --> 18:49.680 For sure. 18:49.680 --> 18:50.680 Thank you. 18:50.680 --> 18:51.680 Yeah. 18:51.680 --> 18:52.680 Welcome. 18:52.680 --> 18:53.680 Any other question? 18:53.680 --> 18:54.680 No. 18:54.680 --> 18:55.680 OK. 18:55.680 --> 18:56.680 Thank you.