 We're going to actually start with a little bit of a panel. It's going to be moderated by Jeff Thorpe, who's the director of IoT security at NXP. And this is, I saw Jeff a couple of weeks ago at Lenaro Connect, it was the first time I met him actually. And he had some really interesting stuff to say about security in general and in the Zephyr project. And so I think you'll find this a very interesting discussion. So I think we're going to start off with a video and then the panel will get going after that. So let's go ahead and do that. Security is a big challenge for the internet of things. You can't avoid it. We're talking about people's homes, security cameras, and health information, and infrastructure like roads and buildings. If people don't trust that they're secure, they won't deploy IoT devices. And that's why the Zephyr project is an RTOS designed with security in mind for small footprint IoT devices. Mirror cryptography isn't enough anymore. So that's why Zephyr goes further. At its very foundation, Zephyr runs on single executable binaries, meaning every feature is compiled upfront. Throughout the project's development, every component goes through a rigorous life cycle to check the security of the feature. Once a feature is added to the project, it's reviewed for security and compiled into the static binary. This doesn't stop bad code from existing. It's a fact of life in software development. So the Zephyr project is designed around tools and processes to minimize the risk of insecure code being included. A community of project members reviews every feature to make sure that sound security practices are applied as code is implemented into the Zephyr project. And features that relate to security get extra scrutiny through our security risk assessment. Regular code reviews ensure compliance, functionality, readability, and maintainability. Static code analysis finds complex and significant functional and security defects. And survivability ensures that security vulnerabilities that happen upstream from Zephyr are addressed and disclosed appropriately. The result? When you incorporate Zephyr security updates, your edge devices become more functional and more secureable. And we're just getting started. We have several groundbreaking features in mind and we're looking for thought leaders to help build them out and add more. IoT is the future and Zephyr is the future of IoT. You can help make the future of IoT more secure by downloading the code and contributing. Join us by visiting zephyrproject.org today. Hi, everybody. Can you hear me OK? Yeah? Yep. Thanks very much for coming along. And I know we're all that stands between you and the prizes. So you'll forgive us nonetheless for not resisting the temptation to profit from a captive audience. Tim didn't actually give you the whole story. See, what happened was Tim and some Linux Foundation people thought it would be cool that I come along and something and Linux Foundation said, you have to come along and talk what's hot and everyone's lips, right? I said, well, you know, this Donald Trump thing, it's not really my game. But he said, no, no, no, the other thing everyone's talking about is, well, Zephyr or IoT security and they're really all talking about that. And they said, no, but we were just trying to make you feel good. Nonetheless, thank you for being here. What was scheduled was a talk on IoT security and Zephyr, a subject about which I'm very passionate. But we have in town here the technical leaders from Zephyr. And at the booths here and at other conferences and offline discussions, online discussions, there's a bunch of things that keep coming back. And so what we thought would be good is to use this opportunity to discuss those here with the relevant people. But the IoT security, I mean, this is a marketing message that we use to try and encourage a certain class of people, perhaps, who need to have some grasp of the basic terms to understand what's going on. That's not really you people. I know it's a very technically literate crowd. And my concern on IoT security is much the contrary. It's not a positive message. It's really a much more worried one. The talk, I gave this talk on Tuesday, I think. And so it's online. If you have any interest at all, I really can't recommend too highly to just take a look at it. It really is a kind of call to arms about a number of key things that we think are problematic that are coming. And this is not the typical commercial IoT security apocalypse story that people use to apply their wears. This is, I think, some blind spots that everyone is actually missing right now. And so all the chit-chat around IoT security that you do here, I think, in some sense, leads us into a false sense of security, because I think there's a few key points that are being missed. So again, if you have the 15 minutes to lose, please take a look at the talk. There's some material in there that we care about. And to be clear, we're not trying to say Zephyr has the answer to all these things, or that Zephyr is the answer, or that we're better than anyone else at this stuff. It's just that there is some stuff there that we want to be part of addressing that needs to be addressed and is not being sufficiently addressed. So that's my 50-minute talks, we compact it to two minutes so that we can have some real coders do some talking. So yeah, we have the key most technical leaders here. I'd like to introduce Anas, who's from Intel, and he's basically, he's the chair of the Technical Steering Committee. So he's sort of coordinating the code and coordinating the people working on the code. We've got my colleague Maureen from NXP, who's top-notch microcontroller security architect for us, and so she's always explaining these things to me. And Lanaro has just joined. They formed a light group, which is, well, I may let Kumar explain, but anyway, Kumar's a familiar face to many of you, and so these three are like, I think, three of the key people. And before we get into it, I certainly want to not forget, there's a couple of other people that ought to be here. Rude from Synopsys has been engaged with this from the very outset. Unfortunately, I had to leave last night, so I can't be here, but, and also Kate, who is here, can't be here because she's been keeping so many Linux Foundation projects alive for the last two weeks that I think she's talked herself out and no longer has a voice. So it's sort of a shout out to those who couldn't shout even if they tried. So without further ado, I have some basic questions, but you guys can sort of take this wherever you think it ought to go. So yeah, the sort of recurring themes that come up, and I know the key one that keeps coming up is that you know there's this caricature, right, about standards, that the good thing about standards is there's so many to choose from, right? The RTOS landscape is a little bit the same. There are so many different RTOSes out there, and everyone and their uncle seems to be building one. And so is the solution to build another one? So I guess that would be where I'd like to start this off is why another RTOS? Okay, so thank you for the introduction. Why another RTOS? Obviously, when we started looking at the problem that we had at hand, we looked at what's available out there, and we were not able to find anything that would give us something comparable, for example, to Linux, something that does not have any specific direction or distinction and something that would basically drive innovation. We didn't find any project that has governance. There are many reasons out there related to licensing and ownership and innovation again, and fragmentation within the projects themselves that existed out there. So the idea was actually to take something, well obviously Zephyr itself is not a project that was started from scratch, it's based on something that already existed. Just we modified it in a way that would fit the needs for what we think is best for IoT and the plans that we have in terms of security and so on. Would you like to pile onto that or is it good? Sure, so I think from the Leonardo viewpoint, one of the things that's always important to us is having an upstream and having a vibrant community around that upstream. So Linux, Linux kernel development is a very vibrant natural community and when you look at a lot of the RTOSs out there, part of the governance involved with Zephyr, both from the members that are there, so that there's a balance between membership as well as involving the community and seeing that community grow in the last, I don't know, four or five months that I've been involved with the project and trying to see that similar open source activity, contribution from developers, whether that be from member companies or other companies or other individuals that have projects that they're working on and have an interest in. So I think that's another reason that when you look at a lot of these RTOSs that are out there, trying to get one that really has a vibrant community was one of the reasons we thought that Zephyr was worth participating in. So I think for those of you that have come by the booth or checked out the code, you've probably heard us talk about and have seen the fact that Zephyr is cross architectures, right, we talk about Intel, we talk about NXP and ARM and Synopsys, but I think the other thing that's special about Zephyr is not just the instructions that architecture, but that this philosophy of having interfaces that are common across different hardware platforms. And so we extend that to the device driver model, for example. That isn't always the case in the microcontroller world and in other RTOSs out there that you could take a look at. So I think it makes things much easier for somebody that's developing middleware or higher level drivers or applications that they have a common interface that they can write to that they can be used across multiple platforms. I'm gonna put you on the spot. With respect to the multi-architecture point, we're gonna have, this has kind of come up another guide. This question's come up in other forms, but perhaps not in this form, is that we have Intel, we have ecosystem members, we wanna have lots of other people coming in, but right now it's primarily the critical masses of three architectures in terms of involvement. How have you found working with the enemy? So I guess I've been working with the enemy in one shape or another and different enemies, if you look at it that way for most of my career with open source and it's one of the things I love about working on an open source project is I can be working with a competitor for my business, the company I may work for or be representing and we can still work and collaborate on problems that honestly aren't value add to those companies. It is that sense of work that we all have to do or all have to solve and doing it together always produces a better solution than doing it separately. So I think what I've seen since we started this project and launched this project back in February that the other members have really practiced what they preach in terms of, we saw Intel initially developing on our NXP board, they didn't stop, they continued to do that, they continued to build upon that and give us feedback and we've seen that happening across multiple members and other contributors in the community. Yeah, I mean, you're talking about enemies here. Yeah, I don't know if that's the right analogy here, but if we take it this far, I think one of the things, we are learning a lot from our enemies in this project and that's something that actually adds a lot of value to the project because when you are forced to think, when you are obstructing software interfaces, ABIs or we are implementing software ABIs, you have to start thinking differently when you have to support other architectures and that makes your ABIs much more better. They are not specific to your architecture, they are not specific to your hardware and that's of course, I mean, if you look at it from an end user perspective, this is what users expect. I want a user of Intel hardware to be able to switch and test their hardware on other platforms if need be or I want also of course, customers of my enemies to come to use my hardware, yeah. No chance. Without changing any software. So that's actually very beneficial and it improves the software tremendously, I think. Cool. So with respect to the community, I mean, we started out as a very small group of large companies and we're having all sorts of people show up little unexpectedly sometimes showing interest but ultimately I know that the interest for me and I believe many people who I represent was that this would attempt to try and create the circumstances that are fertile for the open source community to kick in, we're all kind of jealous of what, you know, the various Linux kernel and other tools enjoy in terms of the sort of the self-driving dynamic of an open source movement, what could be done or what could be done better to work on that, to encourage that kind of dynamic, that kind of open source community. We could come out here and talk to you guys. No, and I think some of it is socialization, so getting more people just aware of the project, whether that's at conferences like this and others, I think having some more developer-oriented actions so we can get hacking together on code and then I think there's just things that as the project grows, we learn sort of the pain points or realize as we talk to people who do come and contribute, like what were their barriers, was it easy to find information about how to do a board port or maybe it's documentation, maybe it's things on the wiki and having to do items or just different things to get people engaged and learning from them on what their issues were and how do we remove them so it is easier for people to contribute. Yeah, the engagement with the community and even with our partners in the project actually had taught us a lot here because when you put something as an open source project, obviously you come from a certain culture and you have certain ways of doing things and when you go open source, when we went open source with the project, a lot of people have different expectations from something like Zephyr in this case, especially when other vendors that might be interested in joining the project but especially the community and the community, I mean over the last few weeks, we are learning a lot. When people try to use Zephyr, when they go have the first experience with Zephyr, I'm always glad to see them come back to mailing lists or IRC or whatever social channels we have there and report and I always go and ask them, yeah, why, I mean, how can I help? What was wrong? What didn't you like? And sometimes I get these answers and my job in this project actually to listen and try to direct whatever comes from the community into actual and actionable items within the project itself. So the community itself is actually helping us move the project into the right direction and I think this is going also to help other users and help the project itself move to where we want to go in terms of security and other features that we are working on. So I think one of the common questions I got over the last couple of days was, do you support this or do you support that? And I think that the fact that we're really striving to be an open source project and so if something isn't there or if there's a feature that you're interested, go scratch your itch. We really are welcoming and encouraging new patches to be submitted so it's not a static thing. It's something that grows with time. Cool. If I may, I mean, we all work on lots of different stuff but if I could make maybe a show of hands for people who would say that there are more Linux developers than, say, RTOS developers. Right, that's what I suspected. I mean, with respect to the security angle I won't rehash my other talk but I mean, the key concern I have there is that there is a difference in culture of security around device security and network security or logical security. I mean, there's a static versus dynamic. There's all sorts of ways those areas of computing are very different and IoT and microcontrollers are being dragged, kicking and screaming into the networked world as part of IoT. So that is a necessary and difficult adjustment but I guess we're so many Linux hackers here. What would you guys say would be if someone's trying to work perhaps for the first time or for the first time in a long time on something that's microcontroller based, coming from where they come from, what are they going to, what should they expect? What are they gonna hit, say, with Zephyr? So, I mean, I came from that world so I've been kernel hacking for 10, 15 years. I don't remember when I started on PowerPC and coming into Zephyr. And so it was one of the nice things about Zephyr is since it utilizes the kernel Kconfig and build system that just had a natural feel just to get it going with it. So that was kind of an easy transition in that respect. And then it's just kind of going through the code and looking at it and it has at least that feel or similarities in some respects to Linux and so forth. So that was an easy transition for me to make. So I think on the other side of that, I don't come from a Linux hacker background. I come from a microcontroller background. And so, a lot of our customers and a lot of the people that we work with similarly. And so it's not unusual to see microcontroller applications that are developed on Windows, different proprietary tool chains and really another big important thing is, we're very resource constrained in terms of memory, in terms of performance. And so I think coming down from the Linux world into the microcontroller world, you'll see things in Zephyr where we put a huge emphasis on code size and keeping things optimal so it can fit into some of these small microcontrollers. Yeah, I'm also coming from Linux and I mean the exciting thing about Zephyr is when you're trying to address the MCU space, you have the numbers, basically it fits when you try to do that with Linux. And we have been trying actually to squeeze Linux to fit in MCU class devices. And that's a journey that I mean, a lot of people have to go through depending on what they are trying to do and usually it ends without any success there, especially if you are trying to target 8K of devices. Obviously Linux will not run there, yeah, of run. From, you know, in Zephyr compared with Linux, you are basically the kernel, you are the middleware, you are the application. And you are not just building a kernel like in Linux, you're actually building more than that and you have to, as a provider or as a software developer, yeah, in Zephyr, you have to worry about all the aspects going all the way from the scheduler to networking, to middleware and basically to the final application and how you interact with the user. So it is actually much more challenging than what a Linux kernel developer would be doing on a daily basis. So the scope is actually more than just kernel. It gives you also an exposure into the world of use cases and use cases and how to design the OS in a way that fits into different use cases in terms of security, connectivity and also how you manage devices like that. So it is more than just building code that runs as a kernel on a desktop machine where the software is done by other people. So I was warned this would happen. I have lots of things to talk about but the hook is gonna come out shortly and yank us off. So anyway, we thank you for your patience and for the interest that's been shown at this conference was remarkable. So that's why we wanted to do this. And sorry for the late change to the schedule. So please come up and see us. We're gonna stick around a little bit here. There's mail lists, IRC. If you've got itches to scratch, scratch them or get treatment depending. And thank you for your time and I hope you win. Whatever it is.