 Should we shut that door? No, no, people leave the door open so people walk in. So it is now 5.10, so we are going to get started. Folks are all encouraged to move towards the front, because this is primarily for you to ask questions. The presentation is really short, right? So if folks can't hear me, move forward, because I will mumble throughout the talk, and that is a threat. Oh, you've raised your hand already, sure. That is what the five slides I have will answer in not so great detail. My job is done. Your job is done. Thank you, Plant. I will hear you later. So we're just going to get started right now. I'm assuming folks here are mostly from the open-source summit side of things. Is anybody here from the security summit? Okay, all the ringers can leave now. But for the open-source summit people, were folks at the keynote, do you guys know what the confidential computing consortium stuff is? Do the words trusted, execution environment mean anything to any of you? Okay, good. Good number of hands. Ringers don't count. Ringers don't count. So, okay, we'll go through a bunch of that detail hopefully fairly quickly. So just to motivate a bunch of this stuff right, like before we even get to what the open-source SDK is, we should probably explain a little bit about the problem space it lives in. We should probably get to who we were as well. I'm Andy from Microsoft and this is Simon, my colleague. Sure. We're unimportant. We're just puppets for... Just so you know who you're talking to. Yes. So we can go back a slide. No, that... Yes, so Simon, Andy. Next slide. So again, we're just going to skip through a bunch of this stuff, right? So everybody knows security today. If you work in Linux environments, a lot of it is just around how to secure your data from sitting on someone's hard drive somewhere. Lots and lots of technologies available for that already. All variants of that technology are available. You can encrypt things on a block device basis. You can encrypt databases. You can encrypt on a file system basis. Pretty much a solve problem. Lots and lots of solutions for there for you to use, right? If you're talking about sort of microservices and how you actually deploy applications in the cloud today, the other thing you have to solve, of course, is how does your data get to this place? And we have lots and lots of solutions in that space as well. The facto standard, if you use Internet at all, that's going to be transport layer security, TLS or HTTPS. There are more esoteric protocols. You can also employ if you want to. That's also another place where it's sort of a buyer's market, right? Lots of things for you to be able to do. Sort of what we're talking about when we mention this magical term of confidential computing is what you do if you want to have secrets which are being computed on a machine that you don't own and you want those secrets to remain secret. So the obvious example of this is we now have these major cloud providers. We have Azure, we have Google, we have Amazon. You want to run your enterprise applications on these cloud providers, but the traditional model of security is if I own the machine, I can do lots of things to that machine. I own the operating system that you're running on. I may have admin rights. The operator has admin rights to this thing. I can dump your memory pages, right? Like your application may be running just fine. It may be malware free, but how do you trust that no one who has access to the device or the operating system has access to your data as well? And so there's this sort of new area where you actually want encryption, right? You kind of want your data to be encrypted so that even when it's running, even when it's being computed over, no one else should be able to see your data except presumably your application, right? And so this idea of being able to protect your data while it's in use is sort of this new space that we're trying to refer to. And there are other technologies, and there are a couple of different technologies in this space. Some of them are pretty nascent. Homomorphic encryption has been around for a really long time. Academia is about 20 years at this point, I think. It's not really taken off because there are lots of severe limitations on what it can do efficiently today. If you happen... I haven't had the vision yet. Seriously, that has been a problem. Yes, they can do division. So the set of operations, yeah. It's really about the set of operations, right? We're not even talking about algorithms yet. It's like the set of operations you can do efficiently on encrypted data is just very restricted today. So if you happen to have a problem that that can solve for you, congratulations. That's kind of the gold standard, but the vast majority of applications just don't have that benefit today. The other technology that's sort of been emergent over the last five to 10 years are these things we call trusted execution environments. And that's really the idea of using hardware. So you're sort of way below the site. You're below the hypervisor, you're below the kernel operating system. But that piece of hardware is going to give you a promise that while it's going to compute on all of your information in a decrypted form, which means that you can use all the regular operations that you expect to be able to do, the hardware is going to promise you that no one else can see your data. Not the kernel, not the hypervisor. It's that level of protection where it's effectively your data is only encrypted and only your application gets to see it. And so when we talk about these TEEs, there's really a sort of a set of primitives that they all kind of do. So if I have this trusted execution environment, the question becomes how do I run applications in this? Well, the assumption is you're going to have some magical way of basically calling functions that run in this environment. How do you do that? How do you set up and how do you create this environment? Well, you've got to tell someone to make this thing for you. There's a set of CPU instructions or hardware specific protocols that you run to be able to set up one of these things. Once you have this thing running, how do you know that it's running inside this environment? I could be running an emulator. If you are remoting into this piece of software, what do you do to figure out that you're actually running against a trusted execution environment, specifically running the code of your choice that you trust? So the notions of attestation are really important there. And if you use, for example, SE Linux before, the idea of being able to attest, like the set of hardware that you're running, the set of firmware that you're running machine, plus the set of software that you want to run on that, those become basically intrinsic operations to what you want to be able to do when you run an application inside one of these trusted execution environments. And finally, if you're familiar with TPMs, are anybody not familiar with what a TPM is in this room? Question? Trusted platform modules. So basically a small hardware module that provides you private keys which are hardware bound. And one of the major operations that you can do with these TPMs is basically to do identity, where you can say, I have a unique identifier and therefore I know this machine has this hardware bound identity. And also you can seal secrets to this because it has its own set of keys and so sealing is one of these interesting primitives that you want to be able to do with these trusted execution environments as well. So that's sort of trinity of things or rather four sort of operations, being able to create, being able to call functions, being able to attest a TEE and then being able to do sealing operations. Those are kind of things that we think are kind of fundamental to how you think about writing a program across all of these different trusted execution environments. And that's really the problem that this SDK, that we call the Open Enclave SDK, is trying to solve. So Enclave was kind of derived from Intel's implementation of this trusted execution environment technology today where you can think of the Enclave as a term for ATEE. The Open Enclave SDK itself though tries to generalize that. So Intel does have a very efficient and fully featured SDK for writing applications against the Intel SGX platform today. SGX stands for Software Guard Extensions. But we also expect that there are going to be a lot more of these platforms in the future, even software-based ones. I believe yesterday we had a similar talk, someone was asking about virtualization-based. You can think of trusted execution environments as being an application model where there is this notion that you will do some portion of your computation in this special memory space that's protected for you and there's the rest of the application. So if you're familiar with doing things like RPC, where you have something that's less trusted than something that you're RPC into for more trusted operation, that's a very similar kind of model. Specifically for the Open Enclave SDK, we care that it is going to deal with these different kinds of TEEs on your behalf. So imagine if there is a different platform in the future. Right now, for example, we are in the process of integrating ARM Trust Zone as one of the things that you can automatically take an application that's written for the Open Enclave SDK and run it against the Intel SGX SDK, sorry, the Intel SGX platform, as well as the ARM Trust Zone platform. Was that a question? Sorry, no. Okay. And so... Sorry. You touched on... So for... Clarify that boundary establishment in what sense? For two different models... So for example, are you thinking about the AMD SEV model? Right. So for this one, we're currently much more... It's a much lower level abstraction at this point. The AMD SEV model, I will point to NRX because that's something that they have explicitly tried to address. I think Asylum has also tried to address that space to a different extent. But the primary model that we're dealing with today, somebody because Trust Zone is one of the first other pieces that we're going for, is really for restricted very small applications. So imagine the memory model for Intel's SGX today, for example, is a single process, restricted memory address space that happens to live within the same process as the untrusted host process. And so you have a benefit there, potentially, where there's a shared memory model where you have a higher trust sort of application running inside the Enclave that has access to both memory spaces. The VM model has other benefits that we'll talk about. Like, you can basically... There's more of a lift-and-shift approach, right? Like, you're running a VM, and if you have the keys that basically allow you to encrypt the memory used by that VM, then you're trusting fewer things in that regard. We're trying to scope this down to something that's very, very low level right now. The SDK itself runs for C and C++, and it's primarily targeted at people who really care about reducing the trusted computing base for their application. So, again, you could take a whole application and run it inside an environment, but you still have a bunch of other security considerations there, right? Like, are you using memory in an appropriate way that doesn't involve side channels? Are you using a bunch of memory, you know, operations that then themselves become a side channel? So, the less things you have in this very constrained, protected memory space, the better. And so, at least in the current incarnation, the Open Enclave SDK is sort of optimized towards those sort of single process experiences. We'll talk a little bit more about where it's going, just in terms of building compatibility, building additional support for projects and these other things. So, that's the first piece. C++, low level SDK, primarily sort of focused on just doing that integration with the different hardware providers for TEs today. The other thing, of course, is we want to, we're at OSS Summit because it is a fully open source project, and that's really an important consideration, right? If you are going to be writing TEs in the future, you kind of want to know that all the code that goes in this application that you're running, someone has looked at, someone has a bit of audit every line of code that's in this thing that is handling your secrets supposedly in a trusted way. And so, there is definitely a dedication to this project will remain open source, it's fully transparent, and we now have a governance model that Andy will talk about in a bit where we are encouraging people to basically shape it, like what do you need these things to do for your applications. Finally, open enclave SDK is also a little bit unique in the sense that we're trying to support multiple operating systems as well. So, we are from Microsoft. So, in addition to supporting Linux, which is the primary operating system that's supported by this SDK, we will also try to support Windows as an operating system that you can run these kinds of applications on from the whole side. Specifically, we're also trying to support binary compatibility. So, for example, if you're running an application in Linux, or at least the trusted application portion of that, you can just take that and actually just run it on Windows without having to recompile it. So, these are kinds of things that we're thinking of that space, specifically for the arm trust zone side of things right now. It's running on a sort of specialized system for these kinds of trusted measurements called the OPTEOS. So, this is basically sort of the principles and I will turn it over to Andy. So, as Simon pointed out, today was the first day of the open source summit and I want to highlight the first part of the name of our SDK. It is the open enclave SDK. This has been publicly available since October last year. It's published out on GitHub under an MIT license. We're working really hard to build the community. We want this to be an SDK, not just by us for people to use, but by the users themselves to contribute with us and help us shape the future of this project. As of July, which means that these numbers are a little out of date, there were already over 2,000 commits for I think now at six releases since we published it. We've got 40 contributors, mostly at Microsoft, but they've been cross-team at least and we really would like that to expand to be cross-company and just across the industry. There's been activity. We've got 74x and 210 stars. I'm hoping that I can leave here tonight after two of these buffs and then we'll have a discussion of the fact that we'll be donating this to the Intended to Forum Confidential Computing Consortium and I want to see those numbers go up. I think that was pretty good considering we went pretty quietly last year and now here's the big loud announcement about these cool projects that are happening. This is a continuously active project. We've got lots of commits coming in. We have lots of people working on it. We've formed a community maintenance committee and we'll be having open community forums to speak in. There's a Gitter channel you can hop in on. We encourage people to open issues and pull requests with us. There's a suggested design review document if you have a feature that you'd like to discuss. You can fill out a pull request with a template of what you want it to look like and who it would be for and we want to do all of these decisions in the open with the community and that is the open part of the Open Enclave SDK here. So also to emphasize the fact that we are getting usage of the SDK just in terms of, again, starting off with Microsoft, so you'll see, for example, that there are other projects that have already taken dependency on the Open Enclave SDK. Another one that you can actually find on the public GitHub site is the confidential consortium framework. So if you go to github.com slash Microsoft slash CCF this is basically an application that allows you to build like open source consortium-based frameworks based on top of these trust execution environments and then you can use, for example, an Ethereum-based engine to build a blockchain application of your choice on top of these. So we really are positioning ourselves sort of as, this is not the solution that we will push onto you for building your kinds of applications. We're trying to enable people to build more interesting kinds of applications on top of this framework. And so we're really interested in the kinds of things that people do want to build on top of this and basically enabling you guys to be able to do that. So I'm just going to go very quickly over features if folks actually have specific interests in any one of these topics. We're just going to go and write in the QAN after this. Well, yeah, we can do the demo. We can also do multiple demos if you want. By the way, we have a very simple demo and we can do more complicated ones if you want. But as I've mentioned open-on play features basically we try and cover the basics of the four major operations we've talked about just in terms of what we think are essential for you to be able to write trust execution environment applications with just sort of as an enabler we come up with a set of basic libraries because you imagine if you're trying to keep your application safe from the operating system you don't really get a lot of functionality by default. You don't get your Linux system C library by default. So the open-on clave SDK basically ships with a bunch of these libraries that you can use right off the bat to compile the applications for these trusted execution environments. And for us, we've chosen to use the CLS which is also an open-source crypto library. It's nice because it has a very small tcp. It was optimized for embedded systems. We have a basically a cut-down variation of the Musil Lib C library and we also support basically the LLVM Lib C++ library up to the C++11 standard. We're trying to get it to C++14 with caveats that there are specific subsets of functionality that we don't support for security reasons. So if you want to write an application we're just not really going to support you opening sockets which will go out into the untrusted world that have to be managed by the operating system, for example. So some basic things like file.io those are not included in the box with the open-on clave SDK right off the bat. If you look at the next line, you'll see that one of the other things we're trying to do is to basically provide a set of politics primitives on top of that and sort of expand optionally. So one of the new modules that came up with the previous thought version release was essentially a file system and I.O. module that you can then link into your application if you want that functionality. So if you have application that really needs, for example, to write sealed data out to disk you can choose to compile that into your application knowing that if you didn't need that then that's not part of your PCB at all. So we expect to grow that as much as possible. We understand that's basically a continuum of people who we want to be super secure and we want the smallest possible footprint for this application through to we need quite a lot of politics for this application to work, right? And so we're sort of trying to phase in different pieces of politics support, potentially. There are lots of different ways we can go with this support and therefore community participation will be really helpful in that space. If you have specific things you guys are interested in you'll have to hear about that. This is called handling infrastructure. It's also kind of what we talked about. Primarily also we want to support people being able to deploy these things in containers, right? And so that's also working towards a piece of that. The last piece I've also spoken about already which is we want to be able to support this across the operating systems. The upcoming one will basically be our first release where we have full experimental support for you to just build the application and just run it as a host. So that's basically it. I'm going to turn it back to Andy now for a quick demo. So I'll question for the audience. How many of you are developers and would like to see what a simple application written against this SDK would look like? Yay! Awesome. Lots of hands there. So I'm going to go ahead and minimize this and find the exit button for the slide. There we go. Yep. Past, present, future, anyone who's interested. So, I'll start with just this is the GitHub project. GitHub.com There's a website if you're interested as well that kind of goes over the high level overview, most of which we covered in this talk. You're free to take a look at the website, at the GitHub. If you do go to the GitHub I hope that this is an easy to follow, read me. I'll walk you through what the SDK is, how you would get started if you have SGX capable hardware. If you don't have SGX capable hardware we have a couple of samples that do run in simulation mode, so you can still look at this and see what it would look like to write against it. You obviously wouldn't get any guarantees of encryption there. And if you actually did want to see the demo, let's maximize. Log back in. Live demo, by the way. Not recorded. That's me. Not part of the demo. I promise. I logged in before. It just timed out. So we have the hello world sample. It's a pretty simple sample. It's written in C. It's kind of just the minimum code you need to understand what an open enclave application is. I think the best place to start is to look at what is the enclave definition language file. It's EDL, the enclave definition language is like a declarative language. What does DSL stand for? Declarative? No. Domain specific language. Thank you. And so this just kind of gives you an overview of what your APIs look like. What are your trusted functions? What are your untrusted functions? And this file is real code. It gets processed through an edgerator that generates all like the marshaling code for your application. So let's look at the trusted side of this. It implements the function that you saw prototype there, enclave hello world. It prints out that we were saying hello world from the enclave. From the host side, it's another fairly simple C file. Most of this is, let me scroll back up here from the last demo. The first part here is at the top of the screen there. The implementation of the host side call out from like the call back from the enclave and the main function that is your host side application that you're running and inside you can see where you create an enclave using one of our APIs, the part that's generated for you, just go ahead and call it and you call into the enclave and you call the function that you described and compiled into an enclave. So that's all of the code. Let's see if it works. Being that we're targeting C and C++ code, we have both like package config files. If you use GNU make and package config, we also have a CMake package that's installed when you install like one of our pretty simple CMake file to actually look at how this would be built. You import our package and it provides you some targets that handle all of the very annoying compilation flags to build code targeted for an enclave. So you can dive into this. This sample is available in the GitHub, actually looking at that enclave build. It's not too bad, right? We generate our code by calling the editor. We create an executable called the enclave, given the source files that we generated in the source file we wrote, and we link it to open enclave libraries themselves. Does this all work? Let's find out. So I'm going to hop over to my shell here. I'm going to run and make clean just to prove that this is a live demo. We're going to look at it and see there is no files built yet. So praying to the demo gods, make hey, everything built, that's great. And we can go on it as well and see what happens. And we did actually run the enclave. We signed the enclave, we called into the enclave, it printed out hello world from the enclave, and then the enclave called back into the host to print hello world and our application exited. It really is, I want to say, as simple as that. There's obviously a lot that goes into using an SDK like this, but we are working hard to make it easy to use and easy to follow. So this demo, I've seen some cool demos that pretend that you have a key in the enclave memory and then you dump out the memory. That would be proving that the Intel side of this, like the SGX instructions are working and that you have the memory that you dump and oh look, you can't see the key and then you run it and say a simulation mode and go oh, there's a key. Those are some cool demos. We could hook up a debugger and see that there's no way to access into that memory. I could certainly try that. It would be fun to come after the session. If you want to hook up a debugger to this with me, I would be more than happy to. It would be fun. So I guess we don't really need to go to the end of the slideshow, but just to pull back up questions. Who's got questions for us? Yes. Questions? It's all, I think what you're asking is do we have to build any bridge code? So all based on existing? Correct. So for, well, I can't speak for the opt-t of that because opt-t is a little bit weird in that you have to recompile for a specific configuration that you need to do and I don't know whether they do anything special there. My understanding is that they don't because a lot of that is shimmed into the model that is on our side to adapt to that. So more or less that if you're taking the SDK, you basically got all the options. Apart from the fact that I'm not opting in, so you have all that specific patches from against right. So for example, we take what Intel provides in terms of here's the out-of-tree driver today and here's the set of libraries that you will use for attestation, for example, and we just take that as a dependency package. So we try as much as possible not to have to go and invasively modify existing projects or existing code just to make the framework work. It is Intel has a set of things that they provide and we can just make use of that. Similarly on Windows on the Windows side, it's because it is part of the kernel so we are a little bit more restricted in the sort of functionality that's provided there. Again, we don't try like we are an open source project, we have no say in what Windows kernel wants to do and so some features, for example, they're available on Linux are not available on Windows today. Like the Linux driver for Intel, for example, will do dynamic paging of EPC memory. So you can have technically unlimited memory space in your enclave because they will try and cage that out. Windows won't do that for you today. So there are also these differences that are just based on the platform that you're using. Is that answered the question? Yes. Other questions? Yes. So you need genes between untrusted and fragile running applications and you need to use your projects to delegate the strategy or execute something untrusted. What is the mechanism that you're using for serialization of this code because you can leak very sensitive information when you're crossing the boundaries? Yes. So we don't actually give you guarantees if you go across that boundary today. So it's basically a syscall it's a syscall trap layer, right? And so we one of the things that we had on our roadmap was basically to implement a secure file system and in that particular model and that would have everything would basically be pre-encrypted we would basically encrypt the file table as well, all those things come with that and another option was basically to make an adapter for Intel's secure file system as sort of an adapter piece, right? So sockets, sockets for example we don't do anything special to serialize the data packets to go across that. It's like you want a socket, you get a socket you're on your own here, right? We're certainly interested in sort of ways of making that, there have actually been more research projects that talk about well we could sandbox it you could have an enclave and then within the enclave there's a sandbox that handles essentially the rights out to untrusted memory space, right? That's still a little bit speculative for us so if folks are interested in that we would love to have deeper discussions about that as well but it's sort of a there's not been as compelling a use case for that in the sense that people tend to want to use that and want to use a TE we sort of expect that you kind of know that you're going to have to encrypt your information you're going to have to worry about these problems of serialization they're not going to try and do these interesting multi-threaded ways or someone can hijack your file descriptors, you come so things of that sort it's an optional module right now because there is clearly an elevated level of risk and developer knowledge for you to use that functionality you specifically would then you will talk about simply bringing reality to this conversation then you would have to face so reality because you would have to be in and out of your execution environment some guarantees have to be processed it's probably future work it is the magical bucket of future working backlog that the CCC will generate so those of you who have heard about the comprehension of computing it's really a consortium but in a lot of comp cons this morning there are other projects which are going to that one I'm from Red Hat, we have the LRT project which is better because you have stickers and they don't seem to I'm willing to bribe you with a sticker just to say this we've had some really interesting conversations but we take very different models of what we're trying to achieve and how we achieve it and the confidence of computing is trying to encourage people to address these and understand what the options are and I speak for Scott when we were looking for other companies who are interested in being involved in this I thought you were British not Australian I think very British but I have stickers so yeah I'm around tomorrow as well and you're around for a bit but Scott and Nicholas I just talked about the confidence CCC where we hope to have loads of these discussions we're already planning the next opportunity to do that so if you're interested please see your LF representative and me for a sticker stickers, get on that marketing advantage, it's just gone man but yes, I mean a lot of what we're trying to do with the Confidential Computing Consortium really is to bootstrap this for the industry we've seen what the CNCF has done just in terms of getting a bunch of this technology sort of up and coming for just industry to use in general and this is really on the cusp of that different projects trying to service the models right now and the hope that the exchange of all this information is going to make much better platforms for just everybody to be able to use in general one piece of software does not solve everyone's problems there should be a collaborative and open effort among all of us so, more questions oh nothing you're being too British man this guy has really done a full on plug sounds like a cocktail we should try okay do you have stickers? apparently it's true it's already a bad hat you trumped again so yes now for questions from the non-ringer section of the audience is it real or what? yes anybody like folks who showed up here either you're really tired and just really needed to close the seat or you're curious about something and happy to answer any questions you have doesn't have to be able to open up with SDK crickets? crickets? we asked a software there's so many levels of instructions if you're going please and so much code with your writing how, again, I am it's now clear to be able to validate that open up with SDK is not a unique leak in my secrets what is the mechanism for me to ensure that every single line of code that I'm relying on is executed exactly as it's intended and now the opening is those sockets and they're doing something called an open source so where's the guarantees that I can... because it's open source open source is solving everything around well, I mean it allows the to be solved yeah, but it's again open source talking about the code return it doesn't provide verification and in particular runs that verification of correctness of this code so there are a couple of different pieces to this problem so clearly open source is a major part of this because at the very least you need to audit the code that you expect to be in there now the next question that follows is okay I think this is the code it's now some binary do I know what's in there right and there are a bunch of other conversations happening in this space right now because we've seen the supply chain attacks against public open source projects where you really do care about things like how do you security build this how do I do like full end to end reproducible builds secure builds and I can... so when I do a build or we give you for example containerized environment like this is the source code these are the build tool chains right it's going to produce this binary with this particular hash you can validate that on your own right so if we give you a drop in a WN package and that package happens to have this hash and you don't trust us go take the source code they expect it to map to go build in this environment it should produce exactly the same hash and the assumption of course is you trust all the versions of the build chain tools in that one and all that and we're verified to form your trust and then verify exactly that's actually an interesting discussion I want to have you later because that has also been on our radar but there are a bunch of other runtime types of things that we're looking at as well essentially for example static analysis of sort of runtime problems like bugs are bugs right you want to basically flush as many of those out and you know visual audit it's supposed to make bugs shallow but you know open source projects still get hit with CVS all the time so static analysis is another thing that we're starting to invest a little bit more in just to be able to do like for example there are tool chains out there like SEMO a bunch of the decline verification tools so we've moved recently from the decline to be able to adopt for example wall of the static verifiers we're starting to look at different build environments where it's kind of hard to run existing tool chains on enclaves or these TEEs because by default you can't look into a TEE or you need a special debugger contract to understand how you actually read the information out of this memory space so we're looking at for example virtual enclaves or just software implementations of the enclaves so that you can run these tools and it will give you code coverage of that nature to get you the kind of assurance that you need for the quality of the code that is actually running inside the own TEE I really think that these questions are very good questions for the CCC to be investigating right? I think these are the same questions you'd ask about like NRX and ASILO as well right? It's the same question we haven't had that trying to see if we can have all answers I'm trying to assure customers that what we've done is as correct as possible and those are techniques and tools we should be working together on for that as well Questions? Yes what form those plans take right now are a little bit up in the air so containerization has been mentioned is one of the things that we want to be able to do so ultimately we understand sorry I'm an advocate of generating some Rust by saying that GoLang is something people ask about as well GoPython GoPython is actually the really big one I suspect C-sharp because Microsoft So the NRX is a very different model which is that a web assembly runs an environment so anything that you can compile down you can run Haskell Python, Rust, C, C C-sharp if it compiles down into web assembly you can run it so that's the approach we take again very different web looking at things So transpilation of one approach when I mentioned containerization for example one of the things we're looking at for example is from the bottom up we're looking at just supporting subsets of syscalls so to give you better compatibility from the top down approach we're looking basically for example unikernels library OSS I want to take a unikernel and put it inside so that I can just run my application as if it has an operating system to support it that's also something we're exploring right now and that will support a range of runtimes once that's available Does that answer your question? Sure Other questions?