 My name's Mike Bursell, I work for Red Hat and I'm one of the co-founders of the NARTS project with Nathaniel McCallum. He can't be with us here today, I'm afraid, so I'll be giving a talk. As you've just heard, I'll be answering questions at the end. Please do ask questions and I'm going to try and leave lots of time to answer them. It might make sense to record the number of the slide, if it's a slide, a particular question you have about a slide. Otherwise, I'm just going to carry on through. So welcome. So first a bit about NARTS, what is it, what's it for? So the first is it uses trusted execution environments. Trusted execution environments allow you to run processes, applications in memory without with confidentiality and integrity protection. In other words, it allows you to run workloads without the host being able to look in. Even if you have admin rights, kernel rights, hypervisor rights, they're still protected. So NARTS uses TEs and there's a number of those currently available, SGX and SEV from Intel and AMD respectively. TDX is from Intel not yet available but it's been announced. So these are chip level instructions and that's what we use. We aim to make it really easy to develop and to deploy workloads. A number of the approaches take an SDK route we don't, we see ourselves as a deployment framework rather than as a development framework. We have strong, very strong security design principles. If in doubt, we take the hard view. We want to make it difficult for people to do the wrong thing. You can't make it impossible. We want to make it easy for people to do the right thing. Absolutely a cloud native approach. Our intent is to integrate in the longer term with OpenShift and Kubernetes. And it's open source, of course, completely open source. And that's important and I'll come to why that's important later on. It is a project. It's not production ready at the moment. And it's part of the Confidential Computing Consortium, which is a Linux foundation project. So first of all, let's talk about isolation and about workloads in the host. So we all know about the cloud. We all know a bit about virtualization. So let's think of a situation here. We have a tenant on the right and they have a workload on a host OS and maybe by CSP. And there may be other workloads from other tenants on there. And of course the OS and all that sort of stuff sits around at the moment. So the first type of isolation that we care about generally is workload from workload isolation. So you don't want other workloads interfering with your workload. And frankly, we're pretty good at that by now. This is something that standard virtualization either hardware or sort of container based is pretty good at stopping. The second type is host from workload isolation. So you don't want a workload interfering with the host because if it can jump out of its VM or get out of its C groups containers, it can do bad things. And again, actually, we're pretty good at this. Hardware virtualization provides for this with hypervisors, but also C groups and SE Linux and set comp and all those sorts of things actually do a pretty good job of stopping this. But there's a third type. And that is workload from host isolation. And what if you do not fully trust the host? What if the host might itself be malicious or you're worried about compromise? How can you stop your workload from being interfered by with the host? Stop the host peeking inside it, looking at your confidential data, even changing that data. The problem is at the moment with standard virtualization techniques, you can't standard hypervisors, standard container models don't allow this because the way that they work is that the host is in charge of mapping. Mapping memory pages to the workload and it can look in. So we have a problem because there are lots of sensitive workloads, which really can't currently work on cloud or on Edge or IoT devices because of this problem. If you work in healthcare or finance or government or even in the enterprise, there's going to be workloads that you should not be putting on a standard cloud because you cannot trust or your regulator doesn't feel that you can trust the cloud provider. So this is what trusted execution environments attempt to fix. They do so in a variety of different ways, but the basic model is that they are new chip level instructions, which allow for the encryption of memory pages, which are associated with particular workloads and which the rest of the OS, the hypervisor, the kernel cannot look into. And they are provided by a set of variety of ways and the standard ones at the moment are Intel SGX and AMD's SEV. So these sound great, right? This is a great thing. Suddenly you can start running your workloads in a way which means they're protected. But, well the first thing is that if you're going to be doing this for SGX, which is the Intel version, you're going to have to design your application in a pretty much completely different way to how you're going to do it for an AMD version. And that's really painful. That's not how the cloud should work. We should just be able to deploy applications, we believe, and not care about the underlying hardware. So that's tricky for a start. And then most of the approaches for doing this require you to write your application to a particular SDK. And that restricts what languages you can be writing in. Most of them support C and C++. There's a bit of Java out there. But there's some real issues with that. Again, we don't want to be restricting what you write in. Now, this is a key one, different attestation model. So I haven't talked about attestation. Attestation is basically proving and checking that what you're running in is really what you think it is. So we're going to set up a trusted execution environment instance, a TE instance. But how can you be sure that what you're about to put your sensitive application into is really protected in the ways that you think it should be? Well, the answer to that is attestation. And there are cryptographic protocols to allow measurements to be made and checked. But the problem is that the different models for doing this, SGX, SEV, and some of the other things are completely different. So if you want to be putting your application into it, either you're going to have to design your entire application to understand that an application shouldn't need to, or you're going to have to rejuke how you deploy and do differently for each of the different types of TE you want to deploy into. And another thing, of course, is that if you have different vendors, what if vulnerabilities turn up? And they really have turned up. Quite a few of them. SGX is well known for having had some vulnerability issues. There have been some in SEV as well. And managing those is tricky as well. What if you just want to deploy workloads? We've become so used to sort of OpenShift and Kubernetes and OpenStack, just being able to deploy stuff. And that's what we wanted to help you with for NRX. So this is NRX. This is our logo, lovely logo. It's a shield. And here are the security principles. So the first thing that we care about is we take the security viewpoint that you should have the smallest trusted computing base that you can. The less you need to trust, the less there is to go wrong, the smaller the attack surface, the easier it is to audit. So we're trying to keep things nice and tight. The next thing is minimum trust relationships. So I said before, you know, you may not trust your host provider, your CFP. We don't feel you should need to. We should feel that a fewer number of trust relationships you can manage the easier it's going to be. We don't want you to have to recompile your app every time you want to deploy it onto a different platform. So we aim for deployment time portability. And we do that with WebAssembly. And I'm going to come to WebAssembly in a moment. We keep the network stack outside the TCP. It makes it easier and safer. We've known as a community and talked for a long time about security at rest. That's in storage security and transit and transit. That's on the network. But security in use is what T's are about and what confidential computing is about. But within our in arcs, we want to provide all three of those by default. Number six is auditability. If you're going to trust something, it needs to be auditable. And number seven open source helps with that significantly. But also things about how you design it, how you document your designs, how you allow people and encourage people to look at those is something that we really care about. So number seven open source, of course. And number eight open standards. I talked about SDKs. We don't want people to be having to compile to different standards. We have chosen some open standards, which we feel that makes a lot more sense. Memory safety, of course, because we want to make it difficult for things to go wrong. And we've committed as a project to know backdoors. Now, that's a lot easier, of course, because everything is open source. But we strongly believe that as soon as you start putting open doors and this sort of stuff, things fall apart. So let's talk a bit about some of the choices we've made in terms of technologies. So the first thing is we provide a runtime, which is WebAssembly. So there are a number of ways of doing this. You could do ELF binaries. You could do Java binaries. You could do something like a Docker container cryo type runtime. We've chosen WebAssembly for a variety of reasons, highlighted here. Firstly, that's a nice, we can keep it nice and tight and small. Not too many trust relationships. One of the key things is deployment time portability. So WebAssembly is supported on Intel, supported on AMD. There's good support coming from places like ARM and from IBM on some of their systems. And so that allows us to say, okay, you compile once and you deploy to wherever. It's also nice and jittable, so it's nice and fast. WebAssembly, we're using a completely open source implementation. All called wasm time is the runtime. So it's completely auditable. And WebAssembly is an open standard. In fact, there's two. There's the core WebAssembly open standard, which is W3C standard now. And there's the wazzy, which is the systems interface, kind of like headless, designed for server uses, which is going through W3C at the moment. So I'll show you a picture in a couple of slides of what our stat looks like and where WebAssembly fits in. We'll give you a bit more of a clue how that all fits together. We are writing almost everything in Rust. Next, there's a few lines of, there's a little bit of WebAssembly, sorry, of assembly language, I86 WebAssembly, X86 WebAssembly, sorry, assembly, X86 assembly in there as well, just for where we need to, because we're doing some pretty low level stuff like syscalls, which really needs to be written like that. But Rust gives us deployment time portability. Again, it's very well supported. And it gives us, again, auditability, all of Rust is open source, and it's great for memory safety. If you haven't started playing with Rust yet, I really encourage you to use this, a fantastic systems programming language. I came to it from Java, and it's, oh, it's lovely. Last one, I guess, shouldn't be too much of a surprise for most people attending this conference at least. But why open source? Well, minimum trusted computing base, we can make it as small as we can. Open source, it's auditable, open source, open standards. And also, as I said, allows us to show there are no backdoors because anyone can look at the source. So let's go to here. This is a picture of the runtime architecture. So what we do in NARCs is we deploy what we call a keep. And a keep is like in castles. The keep is the bit in the middle, which is the safest bit, the place you keep all the most important things. And a keep is basically a trusted execution environment instance, a TE instance with a bunch of stuff in it. So let's look at it from the bottom. As I said, at the beginning, there's a number of different ways of doing trusted execution environments. You can kind of split them into two main types. One is process-based, and the other is VM-based. And SGX is an example of process-based, and SEV is an example of a VM-based. But the key thing is, as I said, we don't think you should care when you're deploying workloads, which you're in. So we abstract all that away completely with these WebAssembly and WASI layers. So what you do is you get your application. And one of the nice things about WebAssembly is that there are lots of language bindings from WebAssembly. So it means you can compile two WebAssembly from lots of different languages, I should say. So if you're writing in C, C++, Java, Rust, Go, .NET, Haskell, whatever, you can just compile your application just once, and it will generate all the necessary language bindings. So what you're deploying is a .wazm file which sits on top of the WASI layer and just runs. So we're going to see that in a minute, in fact, in a demo. So just an architectural view of all the different pieces. It's very simplified, but this is what it looks like. On the left in the keep is what I just showed you. So the application sits on top of the NARTS runtime, and that's the WebAssembly and all those little bits and pieces. On the right we have the client. So we have something called the NARTS client agent. And that is what is going to be integrated with your CLI or with your orchestrator. And that's what deploys your application over onto the host. The host is untrusted. There's an NARTS host agent, which is actually an untrusted component. And I'm going to talk about how these fit together after the demo as well. But this is kind of what it looks like. On the right you've got your client, and on your left you've got your host. And basically what you want to do is to get your workload onto the host running in a keep without having to trust any of the bits of the host at all, apart from the CPU and firmware. Now, of course, you have to trust something because something's actually got to execute. And that is the CPU and firmware. And of course, those are cryptographically signed and we're checking those as we go. This is a rather more complex view. I'm not going to go into this right now. We may return to it a bit if we have questions. It just talks about all the different pieces. So let's show a demo. I think that's a good plan at this point. So let's see if we can make this work. OK, so this is something I recorded recently. And on the left we're going to deploy something. So first of all, we need a workload. We are going to take a Rust application. We'll just look at it. It's very simple. Yeah, there it goes. So what it does, it creates a random number, formats it, waits 20 seconds, and then prints it. Very, very simple. It's written in Rust. What we're going to do is we're going to build it. But we're going to build it as a Wasm application as a WebAssembly application. So there we've just compiled it. It was that simple. We just gave it a different target. Now what we want to do is to deploy this using the client. So we need to point the client at the file that we've just created. So this is the .wasm file. There we go. And we need to tell it what host it should run on. So the host it's going to run on is an AMD machine called Rome SEV. And what port it's going to be listening on. So, OK, we've started up. We're on Rome and we started on port 3030. So we're ready to listen. Right. We should deploy it. But before we do that, we need some way of getting the output. So we're going to use journal cuttle on Rome to see what's going on. Now the other thing we're going to do is we're going to do an evil thing. We're going to see if we can look inside and see what's going on. So we are just deploying the there and we have deployed it. Oh, it's created a secret. That's fantastic. Let's see if we can. Oh dear, we looked inside it. I'm just going to stop for a moment and explain what's going on here. So what we did is we deployed a WebAssembly application onto a host. And then we had a very simple little program on the bottom right called secret search, which looked for the PID of that application that was running it and did a search of the memory pages. And it looked for that formatted string, that formatted secret. And what's happened is it's found it. Now that's a bad thing. And let's just see if it was the correct one because we have to wait 20 seconds. It's going to show us. And there it is. Okay, so indeed it found the right string. This is a bad thing, but this is how computing generally works. So we did not put it in a keep. This is the key thing here. What we did is we did a nil keep. If you look at the top right, you'll see it's a nil keep. So it's running it just as a standard WebAssembly application. So let's start. Let's change something a bit. What we're going to do is going to use Emacs, the king of editors or the queen of editors and change it from nil to just a KVM. We're going to deploy a KVM workload, and we're going to do exactly the same thing again. Okay, it's created it. And this time we're going to see, yeah, that's a KVM one. We're going to see whether or not we can look inside it. We're running the same secret search thing. And it'll application see if we can look inside it. And let's see if we're any better with KVM. Oh dear, it's found something. And in fact, it's found the secret. So what this tells us is, as I explained at the beginning, standard virtualization does not protect us from the host. What we're looking at is not a privileged process either down the bottom right. It's just a standard process, which is looking at memory pages. Right. Let's carry on, see if we can do a better job of this. So this time we're going to say, we're going to deploy an SEV keep. So hopefully this should actually run it and run it in a T instance. So it's doing it. It's actually done a fully attested. It's encrypted the workload, sent the workload over the wire. Put it into an SEV keep, which should hopefully be encrypted. And hopefully this time on the bottom right, it will fail. Let's have a look, see if it's going to fail. It failed. Excellent. So the secret was never revealed. So what this means is that we've managed to avoid the malicious process looking inside. So and it shows that nRx has full end-to-end implementation. It's still early. It's still definitely proof of concept. We have a full end-to-end implementation of taking an application. You can compile it using standard language tools and then deploying it to a fully attested keep. So the process flow looks like this. So first of all, number one on the right, the CLI talk to the client agent. And it did an attestation. It asked the CPU and firmware via the nRx host agent, which just acts as a proxy to set up an application, to set up a TE. Once that was done, it checked the result of the measurement to check that it was true TE. Check that what we're putting inside it is what we expected. Use cryptographic checks to do that. It then took that WebAssembly binary, encrypted it with a one-off session key for that particular keep and sent it to the keep, which then ran it. So that's what's going on. For those of you who prefer this sort of view, there's this. We'll make these slides available to anyone who wants to look at them later on, of course. So let me talk just a bit about the project. Where are we have an end-to-end demo on SEV, the STX one is very close. We hope to have, well, it's now early February. So maybe it's a bit later than this. We hope to have a standalone POC so people can start playing with it, although the networking and storage will be restricted at this stage. And then we need to do some documentation. We've been running hard to get this demo ready for you folks. And we've skimped a little on the documentation, which I apologize. We are entirely open. The code is open. It's on GitHub. The wikis and the design and all issues and PRs are open all on GitHub. The chat is on rocket chat. I'll give you the link to that in a minute. All of our CICD is open to members of the project in good standing. We have our standouts are open and we've adopted a contributor covenant code of conduct. Oh, seen that already. So just to give you an idea of what we have and what we don't have, at least in POC is here's all the different pieces. And the pieces in gray are the pieces that we haven't started working on yet. We haven't started working on the attestation measurement database. We're doing a simple version in a contract file at the moment. The keep runtime repository, the contract manager, which is a piece for billing and those sorts of things. And on the bottom right, we haven't started working on Kubernetes or any other orchestrator integration yet. I'm going to stop. I think here this is just a brief description of the different components. If you're interested in looking at them and say, look, we really want you to get involved. Whether you want to be actually getting involved in, you know, using the project as an end user or writing the project. We'd love to love to get have you involved. Here are some of the tools get the tool skill sets that we're really looking for. The most important is just willingness to learn, frankly. But if you have particular skills at any of these, we would love, love to talk to you about it. We'd love to, love to talk to you about that. I will. This is the last last slide really. This is where to find us. Please come along over to chat.nx.dev. And you can you can talk to us there. Well, everything is under Apache 2.0 and everything's in Rust with a smattering of 886 assembly. Right. So what I'm going to do now is I'm going to stop, stop presenting if I can and take some questions. Right, folks. How are we doing? What have we got Q&A? I don't see any questions at the moment. So any questions from anyone? I see one question. What's the performance penalty for all this runtime plus teams seems like it could be a big hit. Yeah, interesting. So we don't have good figures for that yet, but not actually too high. So there's a number of places where it turns up. Firstly, the process based approach, the SGX approach currently has a significantly higher performance penalty than the VM based. So the VM based one we would expect an encryption penalty of between two and a fourth set. There's of course other hits that may turn up in terms of, you know, WebAssembly, etc. But that is heavily jitted. And we're not expecting things to be too bad, honestly, from what we're seeing at the moment. And the deployment time is really quick, really fast. We were very pleased about that, partly because we're keeping things very small. So I may not look in the wrong place for questions because I don't see any. So maybe a good thing to talk about a bit is how we're managing. Yeah. What we have is a framework which we decided to go with WebAssembly, as I said, for a variety of reasons. It gives us some interesting security and capability management. It doesn't leak things to the host. One of the questions we get asked a lot is, well, could I just run a container runtime in one of these? And the answer is you could, but the container, the expectations of container runtimes and execution environments generally is that actually there's a lot of interaction with the host. And that means that you're leaking information, quite a lot of information to the host every time you're running. So we made a decision that for security's sake, we wouldn't support standard container runtimes and we would go with WebAssembly instead. Now the intention is that we would do integrations with Kubernetes, for instance, an open shift in such a way that typically you'll be writing microservices to run in these things. You'll take your most sensitive data, your most sensitive workloads, write microservices and deploy them. And the intention is that we would provide a way of deploying keeps in the same way that Kubernetes knows how to deploy serverless and VMs and containers and we'd hope that keeps would be another way, another thing that it could do. So there's bits and pieces like the attestation is very important to get right as well. So, you know, the intention would be you have an application, you know, it's got three VMs, 15 containers, maybe a couple of keeps, you write an operator for how you deploy and manage all of those different pieces and how they fit together, and you deploy it like that. So it becomes actually very, very low, low maintenance and easy to run. That's a question comes up quite a lot. Any other questions from anyone. I either gave the perfect presentation and I explained everything perfectly or I did a very bad job and explained it so badly no one has any questions they don't understand. I suspect it's somewhere in the middle of those. How can you ask your CPU, because you know, for me as a software person, I sort of look at hardware with suspicion and if somebody says, Okay, the basis for all the infrastructure is essentially hidden in hardware. Well, I get suspicious. Yeah, absolutely. So it's a that's a very, very good and very difficult question. The answer is something needs to execute instructions. And that's got to be hardware. Right. Now, I would be overjoyed if that hardware were open sourced. And, you know, if you look at some of the work that IBM is doing with power, if you look at some of the work that's happening in risk five at the moment, actually we're getting closer to some of that. It's still a while away and let's not pretend that Intel or AMD are doing much of that. But you have to choose to trust something because something is going to be doing the execution. So we have to we will we want to reduce the number of things you trust and that's going to have to be one of them for now, until it's fully open. Entirely fair question. I wish I wish everything was open and more trustable, but at least we're reducing, you know, if you don't have to trust the host OS, the host, you know, host firmware apart from that one piece of firmware for the CPU. If you've reduced that your trust trusted compute base and your attack surface is so, so much smaller than it would be in other cases. And this is there is no perfect security. Right. It's just impossible. What we can do is make it as small as possible and to find as possible. And that's that's what we aim to do. Cool. So a few more minutes if anyone if anyone has anything. I tell you what, I'll go back to to my slides and I'll just show you the this one here to look at the different pieces that that we make up maybe give you a slightly better idea of what's going on. So this the the white thing here is basically what. What we deploy. And it's made up of a number of pieces, the pieces in the sort of pink color this light color here are untrusted the ones that sit in the green area are sitting in the in the keep in the trusted execution environment itself. We have a shim here and the shim is different for each implementation so SGX has a different shim to SEV when TDX comes out that'll have a different shim etc etc. We have a code layer with a wasm layer and the app loader so basically we bring this up. We perform the attestation which is done by the client over here, and then the app loader waits for the client to send the encrypted workload which is the application up here, which which it then runs. Before we have a different session key for every single keep instance so this keep here would have a different session key to this keep here for instance even if they're owned by the same by the same client by the same tenant. So this is the keep manager that's basically a daemon that waits for connections from clients and sets up these the keep loader, which then builds the rest of it. We may be changing this slightly so I won't talk about that. This is a repository of what you want to be deploying and this is what the client needs to check the attestation so the attestation will be different for each, but we will keep measurements to so that we can prove to ourselves have strong assurances to the client agent that what we're deploying to is cryptographically proven to be a true TE. That's just a bit more about about that. So the key repository which sits between the main environment and the client is that encrypted or it shares data. So variety of ways of doing that. So the answer is it can be it's basically it's similar to your container repository. So it may be that actually yes you want to encrypt that and we can we can support that absolutely. On the other hand it may just be a well known repository of standard standard things that you want to deploy and which don't need to be encrypted. So yes, if the algorithms, you know if the application itself are sensitive, you know, maybe you've got AI modeling or farmer stuff in there, whatever then that can indeed be encrypted. But otherwise, it may be it's a standard type of repo which you don't need to. So there's a variety of models that which frankly that was a complicated enough pictures that it was without trying to explain some of the different trust models that we support and we will be supporting. So I just a last thing is I want to really encourage people to get involved and we're currently not funded. We don't have engineering effort funded by Red Hat or anybody else. So this is very much a spare time project that funding finished at the end of January. So we really want to be getting this on we're looking for alternative ways of getting it funded. It's an open source project. It's part of the confidential computing consortium, which as I said before is the Linux Foundation project. It's very easy to get involved, come along and see us. We are we are here on the chat.nrx.dev and we would love to love to speak to you. So thanks very much indeed for your time. Thanks to Sumed and Jerry for sending this all up. It's great. We appreciate it. Have a great time in well not Brno wherever you are. Keep safe.