 hardening your security subsystem, which is not an official Microsoft product. It's basically on a research estate for now. A bit about me. My background is mostly in systems and security. I got my PhD from University of Cambridge System Research Group, where I mostly worked on hard-resisted compartmentalization and confidential computing and basically systems abstractions for better defense in depth mechanisms. Currently at Microsoft LSE team, I'm working on security-related topics. Let's get this started. First, I will discuss the scope of the project. Basically, try to explain what is the actual problem we are trying to resolve here. Then I will explain some of the technical background for some of the components we rely on. Then I will discuss hardware shields abstractions, the abstractions that we are adding to the kernel with different like hardware or the hypervisor backends. They will conclude this talk with discussing some of the current limitations for the current prototype and the future work and some of the opportunities for collaborations. As you know, a secure operating system is essential for keeping the entire systems and all of our applications in a secure state. Yet or operating systems are still vulnerable to many, many different attack vectors. Because of their monolithic design, because of their complexity or because they're written in unsafe languages and so on. A recent paper actually that is cited here investigated existing attacks on Linux kernel. Their security analysis shows that most of these attacks, about more than 75% of attacks on the kernel, are related to memory safety issues and also lack of proper privilege separation. So this is actually the majority of attacks on the kernel. But this is a very hard problem. It's still an open problem on systems communities to enable proper privilege separations on the monolithic systems or like having the proper OS hardening. But we had amazing progress on control for integrity techniques and buzzing techniques, but these are still not enough. Good news is that the recent hardware features for like better, more efficient privilege separation for basically better like memory, better targeting memory safety issues, like pointer authentications, like tagged memory, introducing like memory protection domains. And these features are helping existing like privilege separation techniques to be more efficient. So we can like scale the security solutions on the kernel. Hypervisor based security is actually one of those like techniques that is very old. It's used for like all kinds of security checks and like operating system because well hypervisor is running on a higher privilege layer and it can be like really useful for deprivileging the actual operating system for enforcing like address space protections of the kernel for verifying image like integrity for UFI protections for even kernel module protection and all kind of like monitoring attacks from the kernel side. But since like they usually add a lot of they very usually adding a lot of like performance overhead and they're not used that much for like fine grain privilege separation on the kernel or for more dynamic kind of like security features. But recently we see that with like better hardware virtualization support, we see these kind of techniques are getting more attention that these are getting like more practical that can be even used for more dynamic sort of like monitoring or enforcing like security checks. So that's why like we see more progress on like different kind of hypervisor for example like Hyper-V like adding introducing like virtual trust levels that Windows VBS like support for all kind of like security features like create guard like device guard and all kind of this kind dynamic also security features through Hyper-V. We also like had Hickey introduced like by Mikhail recently and Zen for a long time like has this like more kind of dynamic memory protection features giving you like different view of like through the like address space. So you can have some sort of like better compartmentalization features on Zen through alt P2M feature that they have. So hypervisor based security is getting like more practical now because of better hardware that we have. On the other hand, we also see more fine-during like hardware memory isolation features, memory protection features to our platform. One of these cases are like ARM Morello architecture that is basically extending existing ARM 64 architecture like V8.2 with cherry hardware capabilities that are basically like adding hardware-based metadata to every pointer for assigning like permissions to that protected capabilities to assigning object types to making sure that like every region like bonds checking on like hardware base and these capabilities can be used for like scale level compartmentalization and the system from bottom up. So they extended the existing like architecture ARM architecture and all of the instructions like for example for load the store like execute all of these like there is also a capability base version like load capability like store capability with some additional like capability on the instruction for example for ceiling like making capability immutable and all these like extensions are also added in every privileged layer in ARM. So for example in the secure mode you can also have compartmentalization so for example the secure world that we already had like for example trust on architecture it was a one kind of one way trust between like the secure world and normal world now you have like kind of mutual this you can have the mutual distrust between the regions so there is a lot of like possibilities for better privilege separations on systems now. So both of these techniques this like approaches virtualization based security and these kinds of hardware based like finer grain like protection features these are like can complement each other and there are privileged separation solutions based on both of like these like solutions and for hardware shield abstraction we were looking at the state of the art for these two approaches and we want to like have the abstraction that is providing a minimal like security primitives that can be used like an extensible and like a scalable vary for hardening Linux scared as security subsystems such as like email like lsm's and like evpf and we were looking at like what are basically this these minimal primitives that can have a different back ends it can the enforcement and like isolation it can happen with like virtualization based security and when it's not efficient anymore when it's like like it's more useful and we have like a better hardware like finer grain hardware protection like chain or like memory like tagging features like mte pack like protein authentication we can then switch to like enforce the actual like isolation through those features and this way we can have like a scalable and more kind of practical solution that we can find the right balance between performance and like security so between these like primitives the main thing in common is like memory isolation like that is provided that can be provided with both of these approaches then there is code and data signing and authentication and then there is the concept of like a compartment the domain of like it isolated execution and the abstraction for managing these kind of domains so hardware shields are going to provide these abstractions a common abstractions but the enforcement the isolation can happen it can be provided by either like visualization based security or like finer grain like hardware protections like cherry or mte or pack so for early prototype and the first attempts to actually find out like what these abstractions is going to look like with target cherry abi for arm64 based kind of like a platform and heki like hypervisor based kernel integrative features on kvm for x86 and 64 there reason for these two completely different like designs and like different security architectures as shields back in is that well cherry on arm is providing us like with a kind of a scalable compartmentalization and privilege separation by design so we don't have like the like limitations for the number of like isolated like regions we don't have like for example the limitations that we have if we pick mte or pack pointer authentication on arm there are limited for example like tags available for coloring and here with cherry we have kind of like that environment that we can define what would be an ideal kind of estate for our privilege separation mechanism and on the other hand for like x86 between different kind of like hypervisor based securities unlike hyper v and like zen and heki we pick heki because like the difference between like zen based and hyper v based and heki is that zen and hyper v like they define like explicit like trust domain like doming dom zero based or like a vtl one for example secure kernel and hyper v that in those domains you can like basically those are your like secure kernel you define all of your security specific primitives there and like then you need to like interact with that kernel so it's it's a very explicit like trust like level between the hypervisor and that secure channel and your like operating system but heki since it's a kvm based like enforcement and it's kind of like it has a different architecture but still it provides like the memory protection and like marginal based like like isolation for the kernel and all of this feature so without like if we have a like if we can find like a better security interface that also works with heki it's going to definitely work with like other kind of like virtualization based security so these two can give us like a good way of like view from two different kind of architecture two different designs for coming up with like what are these like minimal security primitives that we can like implement on shields for like a scale level and extensible like a privilege separation that can be used for hardening like Linux security subsystems so the first like primitive that we need for children is memory protections like the abstraction to basically define like which parts of the kernel addresses space should have like which kind of permissions and the enforcement isolation should be protected by like the hardware or the hypervisor so this is easy like because both like hypervisor based security like heki and like marlo like cherry and this is the first like primitives that they all support so we just needed to provide a wrapper around like their functionality so we added like a wrapper of shield protect address that basically on kvm-based like platforms it uses heki protect memory like hypercal and on moral law it's basically using cherry instructions for like address set for font set and assigning the permissions then the region is protected by cherry capabilities so we need this like as the main building block for like the isolation of like the shields and this actually memory protection the first thing that is being used like when you have the memory protection be assigned like a specific like hashes like signatures like and software based kind of capabilities that I described later and all of these like security sensitive like metadata and things that we need for like other primitives for code signing data signings and these are like these are needed to to be protected by this memory protection feature so we first need this building block to store all of the security sensitive like metadata that we use for other primitives to be protected like as read only and protected by a hardware or the hypervisor the second like primitives that we need for shields are code and data signing and authentication because isolation itself is essential for example for selenux policies we want to isolate the policy but we also need an authentication mechanism to measure the integrity and make sure that like this policy is like not modified and provide the proof for that so shields like implement a very few set up like signing like authentication functions for pointers for values and for like code regions and all of these like functions are also tied to like a specific random context that we call it shield tag per like privileged task extract that is basically part of a part of a general task that is assigned when a task is actually using shields so this part is actually like may change in future if you have a better way of like having a authentication for like users user space tasks that they use shields but for now we're having like this tag per privileged tasks and internally these functionalities are also using like kernel cpash like a short input hash and the values that like measurements and all of these are like marked as read only true like the previous like memory protection like abstraction that we talked about so for kvm there is like new hypercalls for doing this operation and also marking the result as read only and for more law we actually have this ceiling capability for making the values in immutable and we also have signing and authentication like capabilities that's only with those capabilities you can do these operations and store basically the values to protected read only protected parts so the third like primitive is that the concept of an isolated execution unit or compartment or protection domain and all of the management abstractions for that is still going to be a future work it's not developed we don't have a prototype for that but even with the like memory protection and the authentication and signing like primitives we can start improving the security of our current like security subsystems like excel looks for example for excel looks we have this new security excel looks shield like option it's a mode of execution that when you are in that mode for example like shields are going to avoid any kind of like much excel looks execution mode for from enforcement to to permissive or disabling it it also using like shields memory protection and like also authentication to make sure that the policies like excel looks policies are read only with abc cache as well and all of like internal like basically sensitive data structures like excel looks policy map and hash all of these are also like protected to buy like shields that the back end can be like different back ends so for prototyping on like chariot that's basically our first like implementation we used more love android channel for that we extended like the android kernel for with these primitives shields primitives and because like for on android we could have more love is like compiled lib sd nooks they basically you need to like have a cross compile with a specific cherry like compiler and things like that and for now i haven't tested like anything on real arm like real arm with fvp like but it's a very good development environment it's a little bit slow with but on fvp for example like if you go to like more love project and you can you have a simple script with like initializing the fvp with android software stack and then you can have like a very kind of easy development environment for that so since this is a short talk i'm not going to more technical details now just note that there's a lot of things we need to do and this is like an early stage project especially from like user space api we haven't implemented that yet and it needs to be really secure because we don't want to open up new attack vectors for attackers to launch even stronger attacks like by misusing or privilege operation by misusing or like interactions with the hypervisor so we plan to implement that like on trust and also like make sure that all of like the intersections are like logically and also like from implementation perspectives are secure also we need to after we got feedback from the first patches we need to think about the integration with other linux security features like for hardening evpf for example or sitcom and things like that similarly there are other hardware security features that can be integrated to shields for example pks like protection domains on a supervisor mode for intel that basically intel actually has a prototype for using that for hardening evpf like verifier so integrating things like that or using like empty and packed on arm devices when there is no cherry available these are like important future words that we can like implement better privilege separation tools for linux gather with that i'm happy to take any question please contact me if you need more details and if you have any questions and thank you for your attention does anyone have any questions fantastic talk really really like the the material i work with the zanaut p2m subsystem a lot i'm practically a maintainer of it so i'm really happy to see this kind of work making it into the the linux kernel my question is about the potential with evpf would it is it envisioned to be able to run evpf programs within the kernel in kind of an isolated mode where they are running in execute and with only execute and read permissions without being able to actually modify the rest of the kernel kind of being isolated yes i actually like evpf it's so i picked first like a silinux because like it's like it's not easier but it's like kind of more like a straightforward and evpf and for for that actually it's actually like our next plan the verifier itself and also like the policies but it's a very large code base so the main thing like at first i want to make sure is that like these like small primitives are good enough you know for like because we also need like a lot of performance like evaluations like the current state i assume like it's going to like add maybe like up to 10 percent like overhead so if we come up with like an optimized version that is not going to like even make it evpf make it make evpf a slower than definitely and yeah we also need a lot of feedback from open source community i'm going to launch like basically make things open source probably in like by end of this month or so and then we can work on the optimization part but actually the Zen alp to premiums like a really has a really nice design so i would be really happy to catch up if we can have like integrated these two together fantastic and you answered my second question is whether you're going to be open sourcing your stuff i'm looking forward to it so yeah thank you any further questions okay thank you very much for joining us over zoom thank you