 Well, welcome. Good morning and apologies for not being there in person and I've just lost my slides. Okay, can you see the slide again? As long as I don't hear anything, I assume it's a yes. So, pleasure to be here even though I'm not in person and thanks for getting up early to listen to this. It's four years since I last gave a talk at Foster and at that time SEO4 had just been open source and a lot has happened in the meantime so I'll give you a bit of an update and in the end talk about where the community is at. So, this thing represents one of the more exciting things that has happened with SEO4. We don't see your slides. Is this intended? No, it's not. Oh God. Okay. Okay, for some reason, stop sharing. I'll share again. Your screen sharing. Yeah, yeah, no, we see it. You should see something. Yeah. And no, you should see the slide. Yeah, fine. Your screen. Yeah. So, I did raise my hand again. Okay. Okay. This is one of the things that happened recently. What you see here is a Boeing helicopter flying and it's not just flying. It's flying autonomously. There's a pilot on board for safety reasons because they don't get FAA approval to flying it without but it's actually flying totally autonomously. This is a round Arizona and of course the exciting thing about it is flying on SEO4. What's even more interesting is some of the history here. So, this is a military grade system. It's actually a defense system and you should think it's reasonably secure but turns out that professional pen testers took about two weeks to complete the audit and they could completely control the fly. They could have crashed it or diverted it or whatever. And this was the starting point in the Dalba Hackens program which started, which ran for about five years, finished about a year ago. And what we did with our colleagues there is convert the system to SEO4 and make it secure. So, in total there were four vehicles. There were two ground vehicles and two air vehicles. Each of them had a research platform like this drone where we ripped out all the electronics and replaced all the software. And this US Army Robotics Reference Platform and then the military vehicles which is this following autonomous helicopter and autonomous trucks. And what we did with our partners were retrofitting these systems for security by putting them on SEO4 and doing some re-architecting of the system. Then in the end, we kept the hackers out. There was a demo where they did a in-flight attack that in the past would have completely compromised the system and it was completely protected. Specifically, we gave them route access to a virtual machine running Linux on the system. The original system had everything running on Linux. And the attacker could completely compromise the Linux VM but it couldn't break out and affect the rest of the system. So that's so much as motivation. A rough outline of my talk is a quick intro to SEO4. A technical update on a number of the things that happened in the last few years. And this is the bulk of the talk. And then at the end, I'll talk about the status of the community and the whole ecosystem. So for those who haven't heard about SEO4, it's a microkernel and it's arguably the world's most secure and safe operating system. One is particularly unique about it. It has provable security enforcement. And I'll talk about in the next slide what that means. It's also, at least as far as the open literature is concerned, the only protected mode operating system with a complete and sound analysis of worst-case timing behavior. So that's the prerequisite for doing half real-time. And in particular, it makes criticality real-time where there's trusted and untrusted components. Besides all that, it's the world's fastest microkernel. We never compromise with performance. And of course, that's the reason I'm here. It's open source. And it's been open source for about four and a half years ago. So the security story is summarized in this slide, where it's a proof here. This means mathematical, formal mathematical proof that is checked by a machine check. So we have high level security properties, confidentiality, integrity, and availability enforcement. And we have proof that an abstract model of the kernel, which is formulated in a mathematical logic, is able to enforce these security properties. And then we have further proof that the C code that implements the kernel is what's called a refinement of this abstract model. So it's correct implementation of this model. So specifically, this means under the semantics of the C language, the kernel cannot behave in a way that's not captured by the model. And then there's a further step that shows that the binary code that runs on the actual silicon is a correct translation of the C. So that means if we don't have the trust to C compiler, we can just use standard untrusted and untrust through a VGCC to compile and then run the tool chain that says, yes, the translation is correct. For prudent advertising, there's a few exclusions. All are work in progress. We're working on fixing all of them. Current initialization is not verified. Some privilege saved in particular MMUs are not yet verified at the same degree of detail as everything else. That's very close to being fixed. We have a high performance multicore version that's not verified and we don't have any verification story about time and channels at the moment. Like any high security oriented operating system, SEO voice uses capabilities to represent access lights in the system. And so these are basically opaque pointers that reference an object and the lights convey to it. And any current operation you try to develop needs to be authorized by having such a capability. So these are capabilities in the classical object capability form as the computing literature has known that for 40 years, they're quite different from what the Linux folks call capabilities, which are, okay, we've got this and, oh, shit, it just leaves us stuffed up. Accidentally hit, actually eventually hit the power cord. Okay, okay, okay, I'm just eating, I think. Hopefully you can see the slides again full screen if not for you here. Okay, good. So this is a very high level core view of SEO4. There's much more to it, in particular its resource management model, which is quite unique. But that's all established. So I'll give you that now a summary of recent things we've done with it. And one of the most significant ones is support for mixed criticality real-time scheduling. What does that mean? So in many particular cyber physical systems, any sort of real-time system where you have non-trivial complexity, you have this integration challenge of mixed criticality that some components are highly critical and you need to be sure that they get to or that they operate correctly under all circumstances. And then there's untrustworthy components. So a very high abstracted view of this UAV has a control loop, which is highly critical because that's what keeps the thing flying and stops it from crashing. And then there's other components. For example, there's networks. And so there's a network driver that talks to the ground station, for example, or other communication. And obviously, that one is not critical. If the communication starts working, then the thing will just fly to a late point, to a late point, probably has some failsafe logic to fly home or something. The challenge here is the control loop is really slow. It runs on human time scale, so order of 10 to 100 bits. The network driver, of course, is really fast. If the networks like to be serviced within sort of microsecond time scales. And that means that this network driver needs to be able to interrupt the control loop. We just can't wait for the control loop to finish its 20 millisecond execution because you'd lose a lot of network packets. So you have to be able for these less critical components to grant the critical ones, but still guarantee enough time for the critical components to do its job for the safety of the overall system. So that's the core idea of mixed critical resistance. What makes it challenging is that there's sharing involved. So typically, in our UAV, there is the legal control. It tells the legal word to fly to us, so it has to access waypoints. These waypoints, they get updated by the navigation system, for example, based on what the media processing tells the system or updated from the ground station. And so the true, the trusted and young, less trusted parts, share this critical data. And the legal control needs to be accessed. Please be able to access data that is consistent even while the navigation system may update it. And you need to do that on the same system. A simple way to implement something like that is by what's called a resource server. So we have the two components that use this waypoint data to control the critical control loop and the less critical navigation system. And the waypoint data is encapsulated in a server which can be invoked from those slides. The navigation system might invoke the client to update waypoints and the control system may invoke the server to repeat the waypoints. So that's all fine. And as long as the server is simple enough and fast enough, that may be not a big deal. The problem is, particularly if the server has some longer running operations, then we need to count the time properly because otherwise the navigation system, which as I argued before, might be running at higher priority, can just toss the critical system by sending lots of requests to the server. So we need to ensure that time is accounted properly. And in the new version of ACO4, we use capabilities. Like for every access controller in the system, we introduce capabilities for the right to use process of time. So a classical threat will have a priority in the time slice. In the new ACO4, we have a priority in the scheduling context capability, which is this capability to a scheduling object, which is it capsulates the rights to access the CPU. So it has a period and a budget and the semantics is that over any time of T, you cannot use more than C of the processor. So the ratio of C to T is the bandwidth of CPU. This process is allowed to consume. And there can be, for example, short terms once. So in this case, in three time units, it may use up to two. So two thirds of the bandwidth or something that runs for a longer time, like our control loop has 15,000 time units. It's allowed to use 250. And if things are right, you can see that you can combine those and you'll both get that time. The system, the whole point is the system enforces that something is not allowed to run over its budget. And that way we can guarantee time to lower priority processes, which is exactly what we need for this next critical system. So and the way this is done is by being able to borrow scheduling context. So in the case of our resource server, if a client invokes a server, it passes along its scheduling context. The server is then running on the client scheduling context and the server time gets charged to the client. When the server finishes its job, the scheduling context returns to the client and it now has the server time charged to it. And therefore we can prevent this client to adopt the server and force something else to miss its deadline. Joseph Haber was in Eurosis last year and together this makes SEO4 the first ever real-time system with capabilities for time. There's concurrent work at George Washington University, but there hasn't been a system like that before. So the first time we integrated CPU time with a capability system. Second thing I want to talk about is what we call security enforcement by architecture and this is supposed to be used on this Boeing helicopter. The idea here is that in SEO4, like other micro kernels, they have a very low-level interface. SEO4 is particularly low-level. And you need to deal with a lot of these objects and capabilities in order to do anything. This here is a representation of the second most trivial example you can build on SEO4. So the most trivial one would be a Hello World program that just says Hello World and then stops. The second most trivial thing is you have two processes and they communicate by sending messages between. And just to represent this really trivial example, we have over 50 kernel objects that we need to worry about. And that's just for this trivial example. This is a simple system but no longer quite as trivial. Each point represents an object and the capability and you can see there's hundreds of thousands of that just for where the DPC system. So that's not a good abstraction level to reason about in the system. So instead we have a component middleware called campus. That's not particularly unique. For example, G node is in many ways much more general component middleware. But campus has some assurance story which you don't get with others. So in this case, we have in this campus world, we have components that are represented by boxes and connectors that are represented by lines between those boxes. And there's three different types depending on whether you have synchronous message parsing, semaphore like signaling or shared data. And sort of the top two boxes and the RPC connector between basically represents this second most trivial example I talked about before. So a much more high level representation. And the beauty of this and this campus system is that we can provably reason about the system behavior on this campus representation and it gets correctly mapped onto SEO4. So the way this happens is demonstrate that this is example. This is a highly abstracted view of our UAV architecture. And it has some untrusted stuff in a Linux virtual machine. And the one of the core security properties of the system is that Linux is only able to talk to the rest of the system by using encrypted traffic. So only by this crypto library. And we can do that by saying, okay, it's not connected to anything else in the system except this one line that goes to crypto. Therefore, we know that if we can trust this crypto component, then we can assure that Linux can't interfere with the rest of the system. So this is our highly simplified chemistry of the system. And in order to build the actual system, of course, we have implementations of these components. So each of these boxes has a implementation that's TPNC. So there's a driver, multiple drivers, the virtual machine, etc. And of course, I guess all compile and lead together. What is missing here is the so-called glue code, which is the operating system calls that enable these communications. So do the message parsing specifically. And what this glue code needs to look like, it's completely specified by this architecture view. So we can generate this glue code, which is again, that's not particularly new. That's what any IDL compiler does. They've been around for centuries. But in our case, we have proved that the glue code that's generated is correct in the sense that if you invoke a function in the component, then this is semantic the equivalent of just directly invoking this function in the same address space. So that's sort of a very strong correctness property of this glue code. What we also get is from this campus representation, we can generate the low-level SEO4 representation. So in terms of SEO4 objects and capabilities, that's represented in a formalism called CAPDL, capability description language. And again, we generate this automatically from the campus view. And again, this generation is provably correct. And that means when we have the system in this low-level, if this low-level diagram represents the actual SEO4 system, then we know that we can reason about the system according to this high-level depth diagram by these boxes and lines represented at campus, campus formless. And the final step is how do we get the system in this state. We also generate the initialization code that gets the system into that shape. So we have a automatically generated code, which is the init task in the system, which will create all these objects, distributed capabilities, and then we know the system is in a state that's correctly represented by this campus representation on top. And that means we can now do all the reasoning about the properties of the system in this campus formulation. There's some limitations at the moment. Not all the proof stories are complete yet, but this is ongoing work that's funded by another DARPA program. And it will be finished within the next few years. And if you're interested, there was an article in communication of the ACM just last October that describes that. And then there's also tools where this gets tied to a formalism called architecture analysis and description language, which is an international standard. And that's used a lot in the avionics industry. And there's a quick space tools, et cetera, and the whole language is designed for doing safety cases. And there's analysis tools and all those stuff. And you can use that framework and generate the campus representation from that one, although that generation is not proven to be correct. And it's unlikely to happen in the future. And these tools are provided by Rockville College. They're all open source. So that was the second thing that's sort of relevant for SCL4 in recent developments. And the third one is, okay, we have a verified kernel. But of course, the whole system is more than a kernel. Even the trusted computing base of the system is much more than a kernel. So typically, you have some critical components. There may be some devices you need to, where you need to trust the drivers, you may need to have a trusted file system. You have your control code, et cetera. And all these, if they need to be trusted, ideally, they really should be verified. And of course, 11 prison years was what we invested in verifying the kernel. All these components are for the order of 1,000 to 10,000 of lines of code. And 11 prison years for 10,000 lines of code. And it scales tragically. That doesn't sound like a particular attractive way of doing things. It was okay for the kernel, but for doing things on top, you won't be able to do it. And this is where we developed being the coaching framework. So coaching stands for code and code generation. And it is a language framework for building high assurance components on top of a CO4. And it is a programming language. It's a functional programming language that's type and memory safe, but not managed. And it's got a linear type system. Think Rust. It's very similar to Rust in many ways. But unlike Rust, it's got a formally well-defined semantics. And we compile it into C, which is not particularly exciting. But the more interesting part is when we compile it to C, the compiler speeds out, prove that the C is correct against a component stake, which the compiler also generates. And then we know, okay, we have a correct implementation of this coach in the C, which means that as long as we trust compiler at least can reason about the correctness of our code at the level of the coaches semantics. And we know that the C translation will maintain that semantics. Like across the language is restricted that you can't program everything in it. It's intentionally too incomplete. So we need to complement it with abstract data types. So these are things like for file systems, we have abstract data ties for demanding red factories, et cetera. And the idea is these need to be manually verified. So in the end, you have an overall high level abstract specification of the complete functionality of this component. You have these abstract data types, which can be verified independently. And the idea is they're highly reusable. And then you're left manually verifying the coaching code, which is much easier than verifying C code because of the properties of coaching language, the fact that it's type and memory save, that it's pretty functional. And so that's the key for increasing the productivity of verification. And we've done some case studies and a number of file systems. And there's a tape out there that's about three years old now. That describes it. And what we found is that, okay, the productivity story is not too bad. So we get a cost of verified code in terms of dollars per line of code. That's about the fact of two less than what our cost was for AC of four. Now, the cost for the complete verification story for AC of four was about three or four times as expensive as the earlier pistachio microkernel, which was an earlier L4 microkernel that was developed in a very similar context by people, university folks who sort of had experience with microkernels, et cetera. So it's quite a comparable system. So AC of four with its complete verification was about the fact of four more expensive than this earlier system that had no verification story at all. So that means if we get the cost down by a fact of two, we are competitive with non-assured traditional engineered code. And it seems like with our coaching approach, we already got half of that gap. We got a fact of two. And the fact that the reason it's not more has a lot to do with the way the initial version of coaching was done. It was fairly restrictive that you forced to do a lot of boring repetitive stuff, et cetera. And this is what we're working on at the moment. And so with the ultimate game of having something that really allows you to write systems components and verify them at a cost that's comparable to classical under file C code. So another interesting aspect is that, okay, when you have this coach and implementation, presumably ideally you want to verify that, but you can actually play a tradeoff of dependability versus cost. We could, for example, say, okay, it's safe language. And therefore, that reduces the number of bucks already significantly. And maybe for something that's not out of critical, that might actually be enough. And then you have, you just need to write a code and you have already code that, you know, it's going to be better than the C code if it was made to do it. And then you can do automatic testing, in particular, this called property-based testing, which is something that comes out of the Haskell world, where you have a formal specification of your functionality and it generates cases automatically from that. And in particular, it exercises the interesting bits of cases, et cetera. And that has been, it turns out is a very effective tool for getting code pretty much correct very quickly. And of course, you can do model checking. And then finally, you can do the full functional correctness work by theorem proving as we done it with SCO4. So there's a hierarchy of increasing assurance, but also increasing cost that you can pick your point. But one of the interesting aspects of that is that this property-based testing has an interesting compatibility with our full functional correctness proofs in the sense that it uses, it requires a formal specification. And a formal specification can be reused with the full functional correctness proof. So that means you can use quick checking for property-based testing for actually developing and debugging your spec, because specs have bugs as well. And it's much easier to verify against a correct spec than an incorrect one, because any bug in the spec will send you down some red hole, which you need to dig out after a while. So starting with a more or less correct spec is a big win. But also verifying correct code is much easier than verifying buggy code. And so eliminating most of the bugs with quality-based testing before you start verification also reduces cost. So there's a whole bunch of trade-offs that can be played, and this is all only at the beginning. But we've already made a lot of progress in the last two years, particularly over the last year in increasing the expressiveness of the language to make it easier to use, reduce the number of times of code you need to write for implementing some functionality. We put in some of this boilerplate code into our syntactic sugar and language. And we are applying it to other components. In the past, we used it for implementing file systems. We're now starting to use CodeGen for device drivers and network stacks. And that's, by the way, all supported by industry funding. So quite happy to see that there's a fair amount of interest in industry for using this technology. But one particular application area is autonomous cars. But this has nothing to do with DARPA. It's a California-based company doing autonomous driving kits. And they're working with us for using this CodeGen technology to get some of their critical components verified. So they have a pretty crumby system with eight, four RMA cores that run the machine learning and sensor fusion and all that stuff. And then they have, and that's running in the SNP Linux. And then underneath it, there's SEO4. And then the critical components are pulled out running natively on SEO4. And with a minimal trusted computing base, with the idea of verifying that trusted computing base, in particular, verifying, writing the drivers in CodeGen and verifying them. And of course, the system has redundancy as well. So this is some of the, I think, relatively exciting developments that have been happening around or are happening around SEO4. It's sort of, I guess the main takeaway here is SEO4 really is the cutting edge of operating system design and development. It's really driving innovation. And there's more and more deployments that help us supporting real-world cases and driving innovation through it all. Okay, now to what many of you folks are probably quite interested is sort of what's the story about the ecosystem and the channel SEO4 community. And there's some good and some bad news. So the good news is the community is growing. The development of main English is very active. There's heavy support from the US government. They set up a US SEO4 center of excellence, which is basically an organization where companies can go and get help with developing systems on top of SEO4. Obviously, DARPA does that to support particular defense work, but it's not the only defense. This SEO4-based system has gone through high assurance evaluation and it's been certified for defense use and is actually in use in the UK and Australia defense. But it's also, to me, a particularly important aspect is we're getting out of just the defense space into our safety critical systems. And this is reflected in the amount of commercial funding we're getting for SEO4. So these are companies, some big, some small, some very big, putting real dollar on the table to help us develop the SEO4 open source system and the frameworks around it. And pretty much all this work that we take funding for is open source work. Occasionally, we would buy, for example, a proprietary driver for a specific purpose for a customer. But the bulk of the money that comes to us goes straight into developing the open source system SEO4 itself, as well as things that run on top. And it's moving into a number of areas. So there are some of the companies we're talking to are building things for industrial control system to protect them from cyber attacks. What Thomas Kama has already mentioned, and there's people building frameworks for high assurance medical devices. So a lot of safety critical systems work. So that's a good news. The bad news is really the present state of the ecosystem, which is not where I would really like to see it. And I really thought this would develop faster. At the moment, the whole system is very specific. You have not a lot of actually usable components. So unlike L4E, for example, which has a fairly mature and rich ecosystem, the SEO4 one is still very much in its beginning. There's more components around that people are aware of, but it's poorly documented how to find some of them are supported most are not. And this is something we really need to change. There's definitely a shortage of tools. So we would like to see people developing more tools. The center of excellence is doing some of that, but we really like to see an open source community doing this. And part of that is really because we have to blame for that. Our community engagement is just insufficient. We're generally very responsive to people putting issues, asking questions on the mailing list, but we're not really proactive. And the main reason is not real world. It's just we've been too busy. We've been always very stretched with our people. Hiring really good kernel voice developers is hard. And we've been recruiting for years. And with very success just recently, it's been pretty good. We hired a number of people, but basically just getting enough people in as a bottleneck. And it creates a chicken and egg problem. If we can make more use of the community, then obviously that's also part of these problems. But in order to bootstrap that, we need to invest and engage with the community, etc. And we've just been too busy in the past to do that. But that's really changing. So this is a high priority thing for us. We just held the last two months, added two full-time OS engineers and a bunch of student casuals. And you will see in the next few months, a real change there happening with the way we engage with the community and becoming more proactive, etc. The COE is, of course, one important bit of the community because their job is to contribute tools, etc. But we want to have a real sort of open source developer community around that. And we will take steps to help that developing much better. And that includes, of course, on our side, really just documenting much more what's there. And use that as a way to encourage community members to just adopt components, and support them, etc., by contributing once, of course. And part of that, of course, is giving the developer the contributors more visibility, etc. So we're working all of that and we're open to suggestions. And we're definitely taking steps to improving the transparency of the whole thing. It's been noted a few times that the whole SEO4 development is not very transparent, and that's unfortunately true, but we're really changing that. So one step we've already taken, if you're following the developer mailing list, you would have seen that we started an RFC project process. So in future, any major changes will be going through this community consultation process. And it's a way for the community, obviously, to engage as well and make suggestions. So that's already in place. And a few other things that are not yet in place, but we are working on them, is opening up our Tira for current platform issues. That's a bit of a tricky one because there's lots of stuff in there from some of them, 10 years old, some of the stuff in there is refers to projects that are underlying this. Yeah, I'm on my last slide. So yeah, so that needs some cleanup because there's confidential stuff in there and some stuff that could be embarrassing, etc. So that will take a bit to get through what is happening. We also created a discourse group, which will be opened up very soon. It already exists, but it's not yet announced and it will announce it probably in the next month or so. And there actually is a public roadmap, but it's horribly outdated about three years. We'll update that and be more active in making this. So please talk to us if you're interested and we really want to engage in with the community much better in the future that we have in the past. And that's my last slide. Thank you. Let me share so I can hopefully see. Yeah, okay. I got that certified hardware. Well, it's not our space, right? We are software experts not hardware experts. Obviously hardware is the thing that keeps me alive at night, awake at night. We understand how to make software secure. We don't, we can't be no control of the hardware and we know the hardware is bad. There's a lot of activities happening in that space, particularly around risk five, which of course, the open architecture encourages that. And there is probably three or four projects around the world that are working on verifying risk five process of implementations, which is really exciting. But it will take a while to get there. But yeah, I mean, you're totally right. Hardware is the big problem. And for example, stick that now down demonstrate. So I think there's hardware is done. So I hope people really get to activate on the hardware side. Okay. Okay, we have to stop here. So thank you for your talk. Okay. If there's any more questions, send me an email.