《吴超-Upcall_ Dragonball沙箱融合设计通信机制解读.pdf》由会员分享,可在线阅读,更多相关《吴超-Upcall_ Dragonball沙箱融合设计通信机制解读.pdf(13页珍藏版)》请在三个皮匠报告上搜索。
1、Upcall:Dragonball沙箱融合设计通信机制解读演讲人:吴超龙蜥社区云原生 SIG 成员Kata 社区 maintainer2023/03/26Lets talk from DragonballDragonball是专注于云原生安全容器场景的VMM解决方案当我们设计一个针对安全容器场景的VMM,我们在思考什么?Kata3.0 架构图容器上下游优化至快、至轻“够”用安全容器可配自定义Guest Kernel即拥有容器运行的OS定义权How to build a DragonballNEMUVMM CorevsockVirtio-balloonVirtio-netLegacy devic
2、essnapshotVirtio-blkPCIVFIO直通.ACPIVMM CorevsockVirtio-balloonVirtio-netLegacy devicessnapshotVirtio-blkPCIVFIO直通ACPI类能力是否可以实现能力更多 体积不变?CPU弹性CPU拓扑内存弹性Dragonball旨在针对安全容器做审慎的加减法Vsock-VM SocketDragonball采用hybrid vsock的设计赋予了Host与Guest沟通的渠道ACPI CPU热插链路ACPI CPU热插有着十分复杂的链路且与ACPI相关逻辑强耦合让我们看看一个CPU的一生CPU四种状态:P
3、ossible、Present、Online、ActivePossiblePresentOnlineActive未热插PossiblePresentOnlineActive热插中PossiblePresentOnlineActive热插结束PossiblePresentOnlineActive热拔中PossiblePresentOnlineActive热拔结束热插请求触发generic_processor_info()arch_register_cpu()cpu_up()/add_cpu()热拔请求触发arch_unregister_cpu()cpu_down()/cpu_remove()请求
4、热插注册CPUOnline CPU请求热拔清除CPU注册Offline CPU五种行为ACPI CPU热插链路识别出CPU热插主要链路,其余均为ACPI相关设置逻辑Upcall 由此诞生vsock+内核驱动沙箱边界融合,重思考传统虚拟化功能路径Host与Guest自定义通信成为可能重塑传统内核功能链路hostKVMruntime-rsDragonballKata-agentnamespace+cgroupContainersSyscallGuest KernelvsockupcallGuest OSUpcall 设计概要Upcall是一个建立在vsock上构建VMM和Guest直接通信的通道。
5、服务端是Guest Kernel内的一个驱动(需要一系列kernel patches),该驱动会在内核启动后服务来自客户端的请求。客户端则在VMM内,其是一个通过uds和vsock通信的线程。Upcall CPU热插工作路径hostKVMruntime-rsDragonballKata-agentnamespace+cgroupContainersSyscallUpcall Drivervsockupcall1122 3 4344556Guest OS677Upcall 开源现状1.Upcall相关的patch已完全在Kata Container社区开源。路径:kata-containers/
6、tools/packaging/kernel/patches/5.10.x/dragonball-experimental/2.目前社区Dragonball链路用的Guest Kernel自带upcall kernel,给到用户更完整的Dragonball安全容器体验。3.Dragonball代码同时有upcall弹性链路与ACPI弹性链路(待支持),供用户根据实际情况选择。Upcall 未来Keep InnovationUpstream rethinkUpcall打开了沙箱融合的想象空间如何利用这条路径安全、可靠地引入更多创新能力,减少沙箱损耗是我们和社区共同的命题。Upcall源于云原生安全容器场景我们希望和upstream共同打磨适合云原生的虚拟化解决方案与我们链接欢迎加入到龙蜥云原生SIG与我们进行更多有关Kata的讨论。