 So before jumping into the topic just a quick survey, how many of you are familiar with using containers in production? Like, how many of you have services running in containers? So this topic is about how to secure or how to make container environment more safer, considering that containers share the same kernel on the server. So this is one attempt or method to make those containers run in a safe or run safely. So today the containers, as I said before, they share the same kernel on the host or they're on the same VM, they basically they share the same kernel. There are these technologies, namespaces, say comp and app armor and few others, technologies provided by the kernel. They provide a barrier protection between the containers. But container isolation is actually, we can say that is as strong as the kernel. And if, for example, the kernel is compromised and the barriers between the boundaries between the containers can disappear, meaning we lose the isolation between containers as soon as the kernel is compromised. So this concept or this talk is about how we can make the kernel safe or how we can protect the kernel and make it safer. So this is like kernel protect itself. Yeah, we can do that and I'll talk about it now. What is it about? So this kernel protection is the idea is to protect kernel resources, like, for example, Intra Biscuit tables or any other kernel resource that needs to be, that should not be modified or need to be tampered with. We can protect those resources by making those, for example, some kernel resources are only read-only, maybe like something like const or IDT or system descriptor tables. And also processor state, for example, with Intra, there is something called control registers. So once the kernel sets the control register during its init, then those registers should not be tampered with or manipulated again. So with this method or idea, we can help monitor any changes to the kernel resources or processor state. And how this one helps, as I said, this helps monitor and protect the system resources. And for that matter, any range of kernel memory, if it deems to be protected, we can protect or monitor that resource. And with this idea, also, we can extend the CPU features. For example, older platforms will not have the newer security features. So we can provide those newer features on older platforms using this concept. And all this we can achieve without any minimal modifications to the kernel. These are examples of system resources. So now we'll come to how it is done. So this idea revolves around using VTX, using virtualization technology. In terms of Intel, it is VTX. So the idea is to run the Linux or the host OS in guest mode so that we can leverage the advantages, meaning isolation and security features available in virtualization for Linux, that is host OS. We specify policies for protecting the resources, meaning I'll go over it in the next slide. The idea is to use a thin hypervisor, possibly an extension to KVM, to handle this protection kernel protection. So this is about the policies. So we can mention the asset, meaning, for example, let's say IDT. We can say IDT to be monitored and how we want to protect the IDT. It should not be written to, so we can say read only. And for example, if there is an attempt by some malicious software or some exploit in the kernel, changing the IDT, we can monitor it and we can terminate that attempt. So concluding where we are now, we have a functional POC to switch the Linux into guest mode, running Linux into guest mode. And right now we are adding code for implementing the policies that I mentioned in the previous slide. And we are planning to submit patches into the community sooner. I'm well ahead of time. So if there are any questions, I can take them. Anything that has virtualization? I think a lot, VTX. Do you use VTX for Intel, yeah? Let me just show you, yeah. No, the patches, this is not public yet. So we are planning to make them soon. So guest mode, specifically in Intel terms, we are using non-root mode in VTX. So when you run a processor in non-root mode, you get to take, you can basically use the features like EPD or VMCS. If you are aware of VMCS in Intel VTX, if a processor is executing certain instructions, you can trap them and check them whether it is valid or not. It's pretty much the same because we are making the interrupts and IO instructions, all of them pass through. So if there are any interrupts or if there are any IO instructions, they kind of run without being trapped into root mode. KVM is just, the idea is to use KVM as an extend KVM to implement the operations that needs to be done in root mode. We kind of use extend KVM module to handle those operations. It can be any other hypervisor. KVM is just one way to do it. Well, we need something, some module, kernel module to intercept those operations in the root mode. So we need something that executes in root mode. Yeah, a module in the host operating system. Any other questions? This is like done once after init. For example, once the boot is complete. Oh, it's kernel init, not the processor init. Once the kernel is booted and once, for example, before you start running any application, you can switch, make this active and then you are done. And then the only thing you can do at runtime is specifying policies. Like what you need to protect, how you want to protect. That can be done at runtime.