 Okay, I'm Dave Stewart. I do work at Intel, although this talk is not about Intel, per say, it's about the YAKTA project. So happens to work with Intel, ARM, MIPS, and PowerPC. But so I'm going to sort of generalize. There is a little Intel bit that I'm going to throw in just because, hey, they write me a paycheck, so I figure it's a good idea. It's really good to see everybody here. A lot of what I'm going to try and do today is update a little bit some of the stuff that I talked about at the embedded Linux conference in the spring. Did anyone hear my talk then? Awesome. Oh, a couple. All right, so, but, you know, we have done a little bit of work, but I, so I'll try and do what I can to help, you know, explain a little bit. There was this nice castle on the top of the hill yesterday, so that's what that is. It was a gorgeous day yesterday, so I'm hopeful that all this works, since I actually didn't create this presentation until yesterday, right before the party. Anyway, what we're going to try to talk about is kind of the big motivating problem, I think, that has really captured my imagination and attention ever since I started, you know, really working with embedded, with this whole idea of intelligent systems, the systems that really have, you know, internet-connected embedded systems. And so I'm going to talk a little bit about what the problem is. Talk a little bit what we've done in the Okta project to try and help. Oh, this got reformed really oddly. There are a few things that we didn't do that I said we were going to, so I don't want to dwell on those things, but actually a couple things are sort of important there. And then touch on a few best practices and then talk about what we're working on in the future with the Okta project. So let's see if we can make everything work. So we're going to talk about sort of what the problem is, and the sort of initial, by the way, photos in here are, I kind of like to take photos as I'm traveling, so some of them, some are kind of relevant to the point. Oh, there's not at all. So it'll give you at least something to look at while I talk. So November 2nd, 1988, it's a very important day for me because in the, around 86, I started working for this company called Sequent Computer Systems, which is a server manufacturer that defunct now, and, you know, working on Unix-based multiprocessors. And we were just starting to get interested in what we should do relative to security because we had this, you know, the internet was just starting at those days. And so the top software guy we had was a guy who, he said, well, you know, this whole thing about viruses is kind of interesting. I wonder how hard it would be to actually create one. So with the understanding of his manager, there's a couple of seats up here, guys, if you want to come on up, if you're not shy, feel free, I won't bite too badly. So with the permission of his manager, he created this little thing that he snuck it into the ADOT Outheader of an executable. And what it would do is it basically hijacked the entry point of whatever the binary was, and then would go and write a little file in slash temp saying, oh, I've, you know, I've infected another one right with the UID of the process. And then it would go and run through dollar path and everything, every executable, it could find a dollar path of the process. It would go and stick this little thing in the ADOT Outhead or anything that was writable. Okay, so nothing, you know, magic. And he sort of infected himself as a, as a regular user, not a supervisor, right? Yeah. So he's, you know, for a few days, he's watching the progress. And, you know, remember, this is one computer that everyone shared, right? This is like a multiprocessor that our whole, you know, engineering organization was on. So, but then what happened at some point is that somebody in sort of the supporter, the IT group, executed, yeah, an infected binary. And then basically he was running his route. Sure enough, he had, you know, SUID privileges. So, so essentially, he, he infected everything in the dollar path for every user, right? You can imagine what's going on now. Because the entire computer was like, load average went like this. Everybody's ability to do anything went like that. Because there were all these processes banging on slash temp trying to rate that file, you know, because it was trying to reinfect everything. And so famous, you know, I was, remember that my crazy Australian manager walking into this guy's office saying, disinfect, disinfect. But the amazing thing after that was, the reason I remember snow verminer second was because that exact same day, the entire internet went out. Now the internet was not very big in 1988, but it was enough. So we were like, holy crap, Bex virus got out to infected the rest of the internet. What's going on? So it wasn't, it was actually kind of famous. This guy named Morris had what was famously called the Morris worm. He was actually supposedly trying to figure out how big the internet was. And essentially he was, you know, had a worm that crawled out and essentially shut down the internet because the similar kind of little mistake that sometimes sneaks in with programming. Now the interesting thing is that whole system that I talked about that was infected was essentially a VAC 780, which, if you remember your history, is about the compute power of probably, well I think probably my smartphone has more compute power than that, right? And so reality is we crossed a barrier last year where 32-bit microprocessors actually crossed the 50 cent price barrier, okay? So the whole idea of TCPIP connected 30-bit processors is now a reality and the capabilities that companies like Intel, for example, are putting out there really up the ante for us as programmers. But guess what? I think a lot of us as programmers are kind of still living in the era where, oh, you know, we don't really have to think about these sorts of vulnerabilities that we're introducing now in vast numbers all over the internet of things. So this is actually kind of, I love this was like an ancient church in Turkey. He's got a shell, though I thought was kind of cool, so shell programming on. Anyway, it was pretty ancient. So let's talk about a couple of examples. I mean, imagination is a wonderful thing, but let's talk about some real examples that I brought out. I mean, Stuxnet was a fairly well-known worm, but in fact it's known today, it's now known that Israeli and American intelligence agents wrote Stuxnet to basically infect the centrifuges that Iran was using for uranium refinement, right? So it was basically some Siemens equipment. They went and infected the windows.dat file or something like that. Anyway, all these centrifuges were connected in a network behind a firewall. So it was actually an air gap firewall. There was no physical connection with the internet and these centrifuges. So how in the world did it get out to the rest of the internet? Well, in fact, these unrealized side effects and consequences can happen, even something that's not designed to get out. Of course, got out and cost millions or billions of dollars of impact because of that sort of thing. So yeah, intelligence organizations are at work doing some of these things. That's one particular one that we know about. So I think of industrial automation as, oh, this is such a simple thing. It's not at all sexy. It's not flashy. It just does its thing, but it's a perfect example where these Siemens put out this industrial automation based on windows, I might add, that had a vulnerability there that intelligence agents could take advantage of. Codesis is another interesting example. This is actually industrial automation software for power plants, nautical ships, military applications. It was revealed last year that they have a interesting vulnerability that, see if I can state this correctly, I got a note that I want to make sure I, good, enter a password. I hate security. I hate security. Now, can I get the right password? First try, amazing. It was purchased, it's been purchased by 261 manufacturers, Codesis, and it basically will grant a command shell to anyone who knows the proper command sequence. So it basically provides a shell, and then basically, if there's any ability that once you get to the shell to actually get to root, which is, of course, dependent on the system it's running on, and so the author of the code, Codesis, had basically said, well, we're not really capable of making the software secure, so don't connect it to the internet, because then it's relatively easy to get a command prompt. Somebody ran a quick little test and found 117 sites that had the software on it that they could access through the internet. Now, maybe those are all just demos, right, not actual power plants, or military installations, or naval vessels that you can get a command prompt to and then become root. Right, so this stuff's very, right, you know, very prosaic industrial automation. There's a certain amount of, you know, risk that's involved with that as well. Is Richard here? I was hoping Richard Purdy would be here, because it's actually, I told him I was going to stick a photo of Newcastle in there, so I did. Anyway, so let's take one more example. People talk about, you know, we want to have a smarter planet, you know, let's have smart power. A couple of years ago, we had our first Yachter Project Developer Day, and Jim Zemlin gave the keynote, and he was so proud about the fact that there was this municipality in New Mexico that had implemented smart meters on all the homes in the city, right? So they could actually monitor, like every 15 minutes, what the power use was at the house, so that they actually update, you know, how much capacity they needed on a real-time basis. So that's very cool, because you don't waste a lot of power. Minor downside, it turns out that actual power meters are one of the most, you know, kind of violated things out there. It turns out, like in hot weather states in the United States, like Arizona, where people often run the air conditioner a lot in hot weather, one of the little hacks is to take a very large, permanent magnet, stick it on the power meter during the day, so your air conditioning can run all day, and the power meter won't actually record anything, then take the magnet off, so when the person comes to read the meter, oh, I haven't used that much power. Now, that's a fairly simple hack. Actually, they started building power meters out of, like, aluminum and nonferrous metals as a result, but, you know, you kind of imagine that's a fairly, what I would call sort of a Fred Flintstone sort of hack to be able to get at that sort of thing, but in fact, the FBI did a little analysis and has actually shown that at least one, let's see if I can get the actual note here, yeah, that the smart meter hacks may have cost, according to the FBI, they basically said it may have cost a single U.S. electricity utility hundreds of millions of dollars annually because of, you know, essentially hacks on the smart meter. Okay, so we have some interesting issues here, and again, we as programmers probably don't think of this sort of thing and necessarily want to get all tied up with things like security and embedded devices. But the reality is that when these sorts of things start showing up on the front of the Wall Street Journal and newspapers like that, this is where it's going to really start becoming very critical to us to take it seriously. And I don't want to be like Cassandra. You know, Cassandra was the mythological figure who was doomed to know the future but never be believed, I think, and so I don't really want to be Cassandra. I don't want to consider, I'm not really a security person, but it's just sort of the obvious issues that might result. The real issue, of course, are what they call zero-day bugs, and again, I'm not a security person per se, but as I understand that the day you ship your software, it will have some bugs in it, guaranteed, right? In fact, there's some people are now talking about forever-day bugs, you know, because they're never fixed, right? They're things you haven't thought about, and so Linus Colonel has a number of them. How many CVs go out on the Linus Colonel, you know, every week or month is like a significant number, right? So the bugs exist. In fact, Stuxnet depended on five zero-day bugs that were in the software that Seaman put out. Now, it may seem a bit discouraging because it's like, well, if I don't know what the bugs are and there's no way I can know what they are, how in the world am I supposed to prevent against it? And this is, by the way, one of the critical things, and unfortunately, one of the things that I don't have a good solution for to offer you, and that's, at least in the Octo project, the solutions exist and you should all implement it, and that's like having some reasonably robust updating mechanism, right? Because these things will come out, you need to have the ability to update all the devices rapidly and securely and robustly so that you don't kill the device when you update it, right? I mean, clearly, if you have a situation where you have a customer who's like, well, let's say all the digital signs in Heathrow Airport suddenly become targets of an attack and become a botnet that started attacking your company's website, that might be not a very good thing to be known about. So yeah, no matter how careful you are, you won't find them, so you really need some way of robustly taking care of these things, and remember governments and kids, frankly, but governments are hard to work. Actually, sometimes history just works perfectly, but when I gave this talk last spring, the day before the New York Times had revealed had actually shown a photo of a building in Shanghai where the People's Liberation Army actually had the unit that was known as the Comet Crew. Comet Crew was doing a bunch of social engineering to start cracking into basically sites on the internet. Thus, the ostensible target were critical infrastructure, power plants and things like that, just have the ability to make sure that they could have an impact there. And actually, they probably don't even need that because of the CODISIS thing I just told you about. It's relatively easy to break in without even, you know, much in the way of social engineering, just a little bit of knowledge. So yeah, governments are hard at work. This is actually a cistern underneath the streets of Constantinople or Istanbul. So there's dark and secret places down there where people are doing things, and by the way, kids are doing this sort of thing too. It's not just, you know, governments. Americans, Israelis, Chinese, as I talk about examples, but plenty of other things going on as well. Right. If I haven't depressed you enough, just to be clear, I don't think there are other good answers either. A lot of people have said, well, gee, let's build our embedded devices using Android. And, you know, Android is a great operating system, runs on my phone, tablet. I love it. I just think in embedded situations don't think that Android is just going to be the answer because, actually, it's now a nice statistical graph that people are graphing the number of security issues that pop up in Android. And that, you know, it's now that you can start seeing, it's almost like particles, you know, particle physics where you can kind of see at a gross level how many devices are actually being, what are they, activating 1.5 million? Chris Simon said in his talk just before, there's 1.5 million activations per day. That's, you know, so now it's starting to become the tremendous target for people to do stuff. Now, there are people who are working on some security enhancements to Android for the exact reason that people have kind of gotten themselves into the Android, you know, direction. And they go, holy cow, now what do I do? And so, trying to, you know, to do some security enhancements. But I just, I wouldn't necessarily say it's necessarily easier in an Android situation. In fact, there may be more things that you aren't necessarily taking out of Android. How many tablets actually had dialers tax in them? I don't know. But, you know, it's, you know, you just open yourself up to a lot of things that are bad things that could happen to you. So, it was a little cheese there. I don't know, it's just cheese. So, it was a nice market in Lyon, it was lovely. All right, so rather than just complain about things and scare you or whatever, what we're trying to do is actually do some things in the Octo project. If you're not familiar with the Octo project, I'm not gonna spend a lot of time talking about it here. But I wanna, you know, it is something that supports Intel PowerPC MIPS and ARM. It really, as Chris, I think, said it really well. Trying to collect all the sort of chaos, the different sort of build systems that lets you tailor exactly what you want in the Linux system. It's supported by a lot of vendors, TI, Intel, Wind River, Mentor Graphics. And the, who am I missing, Chris? Huawei, Juniper Networks, Erickson's doing a bunch of stuff with it. Who am I missing, I'm missing some people. I don't know, anyway, so a long list of vendors, as well as a lot of independent organizations. And we're trying to not only have a great and well-supported Linux for Embedded, but as well a great developer experience. And so, we have developer experience tools, plugins to Eclipse and that sort of thing. So, check it out if you'd like. And we're trying to do a few things to help out. One of the things is a certain amount of compiler flags. I thought it was funny that the Kernel Summit had a, you know, hats that had a corn cob, you know? So, because of Kernel, anyway. These things don't necessarily translate out of English. I don't know what they were doing, what they were thinking about. So, one of the kind of obvious things you can actually do with GCC is add certain tool chain flags that allow you to come on in. Well, we won't try and bite. There's actually a chair if you wanna struggle ahead or just sit in the back. You know, some of the things that basically allow you to ensure that certain common attacks are essentially not available to attackers. Now, this is so incredibly simple. It just amazes me that this isn't something that's just a default. But we weren't doing it in the Octo project. And so, one of the things that we did was actually implement this in our 1.5 release. So, the release that came out, when did it come out? Last week? 18th. The 18th. Good. Last week. So, our 1.5 release actually has this, but it's not, we're also a little skittish about it too. So, we haven't implemented it universally everywhere, but there is one particular, what we call a distro policy. Essentially, what Yachto project does is allow you to create your own distro of Linux, right? So, we have certain distro policies. So, there's one called Pocky LSB that we're, and essentially what this does is it has, we've identified all of the things that Intel, or sorry, not Intel, but the Linux bits that don't work with certain of these compiler flags. So, we've done the hard work to go through everything that maybe fails because of some of these things. Now, the reason we haven't turned it on universally is we still need to do some measurements as to whether this adversely affects build performance or the target performance. So, we're still doing a little bit of work, but we have one specific example that you can look at, and very easy. By the way, even if you don't use the Yachto project, you can look at some of the recipes and some of the things that we've done and actually make use of it. It's like with all the packages that we've gone through in Linux, we've identified places where these flags don't work, right? So, there's some actual work that we've done to try to help with this. So, these are the compiler flags, the Pocky LSB distro policy helps you figure out. So, that's kind of basic sort of first step. We also have introduced something we call the Metasecurity Layer, and there's a terrific blog post on the yachtoproject.org website, which talks about a number of things in this layer. So, another architectural thing the Yachto project is, there's a layer infrastructure, which means as just typically, but anything that you'd wanna change in the basic things that have been set in Linux, you can essentially override any of them, shut them off, add new things. And so, it's effectively, that's the tailoring mechanism is in these layers. And so, essentially you can have a board support package, and maybe a user interface thing, and maybe specific things to your company that you wanna have set universally, and things of that sort. So, this Metasecurity Layer has a number of tools in it. And generally speaking, what the tools allow you to do is, just have things like static checks. Okay, so there's one called Buck Security, right? I got my content expert over here who's gonna stand up and throw things at me if I get too far off the script. But Buck Security, what it does, it'll just scan your target image and say, okay, common mistakes, right? How often have people, you've read about, oh well, somebody left a, accidentally left an administrator's password on the device, oops. Or, we have these great Eclipse debugging tools, right? For remote debugging, maybe you left, accidentally left the debugging agent, the remote agent on the target, oops, another back door, right? So, the idea here is to really scan through a number of common mistakes, common issues, kinda nice. Particularly if you're creating a product, it's nice to actually put this as part of the process of creating the product, right? Just do the scan. There's also some dynamic scan tools as well. The issue with security, of course, is that it's very easy for this stuff to get out of date. So, we're really trying to maintain these things and try and keep them fresh. What else am I missing about Metasecurity, Saul? Anything else that, by the way, this was also a piece, I'm delighted to say that this is something that it was, again, community contributed. There's actually Anne Mulhern, who's a professor at, I can't remember she's a professor of, a computer science professor, as she had herself and a bunch of her students' work on contributing these pieces to the OCTO project. So, the work has started, but we're really looking for the community to help us maintain these things, right? So, I encourage you to get involved. Yeah, you mentioned Metasecurity. It has some other related static tools as well as some dynamic tools that need to be run on the system itself when it's running. Yeah, right. How security can you run actually on the root FS on the host before it even gets installed on the target? Yeah, that's an important thing. So, what I refer to as static tools are, of course, what you do at the end of having built Linux is you now have a root file system and it's like, okay, you can actually, before you even boot it on a device or boot it on a QEMU, you can actually run some tools against it. Well, again, check some common errors by just sort of examining kind of what's in the root FS. But you can, other things are more easy to check with a running system and so you can run that against either QEMU, which we provide, or the actual target hardware you're working on, you're debugging. So, that's Metasecurity. It's a door down below the streets of Rents and Champagne. So, there's this ancient door down there. This is where it's gonna be called, murky. And that's actually in the streets of Champagne as well. This, you know, the first king of France being baptized was kind of a fun picture. So, Meta-Measured is another interesting feature. In fact, this is another, two things I wanna say about this. One is that it was again, community contributed. It was not contributed by, you know, somebody who gets necessarily an Intel employee, but the interesting thing about this is an Intel feature. So, one of the things that Intel hardware uniquely has that's very interesting is a feature called TXT, which is Trusted Execution Technology. So, what happens is that the feature makes use of something called T-Boot. So, what happens is that, you know, you can have all the virus checkers in the world on your computer or all the things to check to make sure you haven't, you know, been infected. But what happens if your OS has already been tampered with and essentially made all of the, any sort of virus checker inoperable, right? Or give false results? Even worse if you're running with a virtual memory system, right? Let's say you're running your embedded device in a VMM, which is the nice kind of thing to do, but what if somebody's infected the VMM, right? So, well, that's sort of even harder to detect with something running in user space after the system's booted, right? So, what actually that this does with Intel hardware is actually after you have done your boot of your VMM and your OS, it will do what's called a measured, it's a measured launch. So, it takes a measurement of that launch and then writes that measurement in some secure storage on the hardware itself, the Intel hardware itself. Then subsequent boots, what happens is that those also get measured and the measurement is compared against what's in the secure storage. So, in fact, then if you're, you know, somebody's tampered with the OS or the VMM and basically it implements a policy which is like, okay, you tell me what to do next, right? Now, different users of this have done different things. I was talking to a guy at Citrix last night. Citrix was actually, it was a citrus employee, Philip Treka, who, is he here? Awesome, I'm giving him props, he's not even here. No, this is great because in fact, Citrix uses this and if the measurement fails again, it'll pop up, you know, essentially before it gets into the OS, it'll basically give you a dialog box and says, did you do this on purpose because you just reinstalled Linux, right? Or, you know, or otherwise, maybe you need to go talk to your administrator and it's a password interface. Guys at VMware are using this as well. Their approach on VMware is to basically say, well, all of the storage is encrypted using TXT and so it basically doesn't give you access to any of the storage. So, again, the cool thing about this is that what Intel is actually trying to do to help with this is provide hardware that lets you actually use the hardware itself to validate that no one is tampered with the OS or the VMM. It's pretty cool. So, it's a great value for, you know, using Intel hardware. So, yeah, the meta-measure is the, you know, is the layer, check that out, it's another great feature. And I kind of like it because, you know, works with Intel. And it's so, I don't want to miss the fact that, you know, SE Linux, okay, a lot of people groan when they think about SE Linux running on their laptop or whatever. In fact, SE Linux is a phenomenal, you know, secure, you know, Linux, trusted Linux environment that I think this ought to be just, you know, kind of, again, if you're going to create a device that has any kind of network connection, whether or not it's going to be on the public internet, remember those centrifuges were not on the public internet, but they got, you know, infected anyway, right? So, it seems like SE Linux is just, you know, kind of a natural thing to do. I'm delighted that our friends at Wind River, you know, maintain, you know, the Met-SE Linux. I strongly encourage you to, you know, make use of that as well. So, these are all things that are in the, our current release of the Octo project. Highly recommend you, you know, get involved with them and check them out. But we missed a couple of things that I was hoping we would have. I did mention back at, none of you heard me say it, so why am I even bothering you? But just in case, I just think for integrity's sake, I ought to tell you, I thought we were going to do some things that we didn't. Bastille Linux was something I'd heard about at the time as a great static checker. In fact, it turns out it's a little bit like this alley in another city in France where the buildings are so close that they're actually kind of, you know, have to have prop. It's not really well maintained, okay? Not very modern. Bastille Linux actually turns out as an HP UX tool that was kind of adapted for Linux. And so, we didn't do that, but we did buck security instead. So I think it's a bit more, you know, sort of Linux oriented solution. So that's good. But one thing I'm really disappointed that we didn't have is a decent updater. So, again, it's like I told you, you know, if you have anything, I mean, there's going to be bugs, whether it's in the Linux kernel or whatever other software, whether you wrote it or somebody else did, there will be zero day bugs, guaranteed. And so as a result, you look at that and you go, you need some sort of updating mechanism that lets you, you know, send out a pack to that stuff. One of the things we do in the Octo project, by the way, is we try and, you know, patch these relevant CVs as quickly as possible and we also provide them in point releases. But again, this is something that you really need to have a really, a good updater. Now, my idea was six months ago that we would use an updater that had been developed for an operating system project called Fenris, which one of the principal engineers at Intel was doing as a hobby project. And it's got a great updater. There's nothing wrong with the software. The problem is the Octo project is not a distribution. So it doesn't exactly work very well in that environment, you know, because what you really need with an updater, it's not just the software, you need to actually be updating something, right? I mean, this is the way you make software really robust and work well. Somebody needs to actually be using it and you're actually, right? You know, otherwise it's just somebody's hobby unless people are really pounding on it and using it every day. And I couldn't figure out a way, or actually the smart people, I couldn't either, but the smart people on the project couldn't figure out how to get us to implement this in the Octo project in such a way that we really felt good about the code. So it's probably much better for a real distribution to use an updater. And then at some point, you know, one of these becomes, use Fenris or one of the other ones, someone could contribute this back to the open source project. It would be phenomenal. But if someone's not actually using it in real products, it's more like a hobby and I'm not interested in putting it in the Octo project. So I'm all disappointed, but that's kind of the reality. Reality sucks sometimes, so that's what it is. So I guess my encouragement to you as a community is, if someone could contribute something, if you would want to contribute something that's already being used, do you think it's a cool way of keeping embedded devices up to date, would love to get your software into the Octo project and give you all kinds of, you know, T-shirts and props will give you lots of public props since I think this is incredibly important. So let's talk a little bit about best practices, because you know, it's one thing to put a bunch of stuff in the Octo project and any open source project, whether it's SEO Linux or anything like that, but if you don't have an actual, you know, set of best practices to think about. And again, I understand where you are as developers. If you're not like developing something, an instrument that goes into military equipment or something like that, you may not really think that much about these issues, but I guess if there's anything that I could do to try and help you think about these a little bit more. And quite frankly, a lot of you are in a situation where maybe you're a contract programmer, right, and whoever's paying you wants something done quickly and get it to mark and get it out there and they're not, you know, necessarily, oh yeah, security, yeah, yeah, yeah, don't worry about it. I understand the situation you're in. If there's anything we could do to try and, you know, reveal some of these examples without actually having somebody show up on the Wall Street Journal, I think it's a really good idea. So I'm hoping that I can get you kind of interested in this and really maybe push your employers to really implement more of these sort of things. So, yeah, this is kind of basic. I think just doing the hard work, use the tool chain armoring. We've put the Pocky LSB distro policy in place. So what it uses is there's a security flags.inc file and basically that file has all the magic in it. So that file, you know, basically has essentially what the definition of the full set of the flags are and then all of the other, you know, exceptions that we found where things busted as a result of it. So strongly encourage you to use that. I mean, it's, again, it's built into the, it's built into the frickin' tool chain. So just use it. This is sort of like a no-brainer. I wish that we had it universally adopted in all of our, you know, build profiles. I want us to be doing more work. Are you doing, are you taking notes about this? This would be awesome, you know? If I could just, you know. They used to say that, I don't know if I can say this. I shouldn't say the company name because this will get back. But there was some very, very large company, software company that they used to say that the way they did strategic planning is they went to the CEO's keynote. And listen, you know, the executive staff would sit in the front row of the, you know, the audience that is keynote and that's how they would do their strategic planning. He said, I try not to do that because A, I'm not a CEO and B, you know, it's another sort of project. Who cares what I think? But actually, I think this is kind of cool. We should do this more. We should actually try to, you know, really assess what the impact is and we're doing that. Okay, it's on the list, good. All right. Yeah, it's, there's a little bit of hard work sort of like this millstone that's in there that you need to just, you know, drive around, you know, grind the grain, but I think it's a good idea. I think it's really good to crack into meta security. By the way, if you're not, if you want just some text to read, there's actually a blog post on yachtoproject.org which talks about this. So just go to yachtoproject.org, look at the blogs, there's a blog entry which talks about the tools in meta security. Has been updated, by the way, to take Bestial out and put that buck in. Can you go check that out and just, you know, maybe hack on it real quick? See, we only do high quality stuff in open source. So yeah, you know, again, there's a suite of tools we're going to continue to work on it, continue to make sure it works and subsequent releases the yachtoproject. So, you know, that's probably another really good, you know, again, you get into a little bit more work now. Again, using the tool chain, armoring the flags, that's sort of a no brainer. This starts getting a little bit more work in this as it pops out, you know, error messages or things to look at. You're gonna have to do a little bit more thinking, a little bit more work to try and figure out are these things I need to fix. And again, I think it's a really good idea to put these things into some sort of process. A lot of what we're trying to do in the yachtoproject is not something that is a one time thing, but it's like, you do your work now for this device and you can reuse a bunch of it for the next device. Right, you know, as opposed to the old, you know, way of doing things. Oh, you can hack together a Linux, right? And then gosh, you have to do the whole thing again for the next, you know, whether it's an updated kernel or updated, you know, user space or whatever, right? You got to do it again. And a lot of what we're trying to do with the, a lot of the value comes not just from doing one device, but it's doing a product family. It's doing an ongoing, you know, set of things that will, you know, go through many different kernel versions, user space versions, right? Different families. So the whole idea here is to really leverage this. If you're only gonna do it for one device, maybe it's not all that, you know, interesting, but it's actually to create, you know, real value for your long-term product, you know, direction, right? Right, would you say that's true? Oh, okay, you're just grunting, all right. Use it so, I had a point there. Anyway, so try and make use of a lot of those things. I think that's a, I think those are good. And I think, oh, you know, again, implementing some sort of update mechanism. It says practice, but I think it's more than just a mechanism, it really is a practice. So it's like, you could, again, if you're a consultant working for an employer and you create, you have this great mechanism, but then, you know, it's not actually part of a practice, then it's like, well, you just sort of wasted time, right? And by a practice, what I mean is, you need to make sure that, or whoever's implementing the device, needs to make sure that a pattern update doesn't, you know, brick the device, right? Particularly if you do a BIOS update as part of this thing, or a, you know, firmware bootloader update, you gotta make sure that it doesn't, you know, that the thing will still work. So, you know, people who have maybe 10,000 devices deployed worldwide, and all of their warehouses or all their HVAC machines might get a little nervous. In fact, I was gonna pull out an example, you know, it's always fun to go to an embedded conference and have hardware, have hardware, oh, here it is. So, this is a little board that we just launched, Intel just launched, it's called the Galileo, and it was launched in a Maker Faire as a, you know, for Arduino support, so it's cool from that standpoint, right? But the other thing, since it runs Linux, and it's got a little, you know, Intel chip on it, basically the idea was a lot of great applications this will go into. Our CEO talks about the fact that it's, there's somebody who has HVAC equipment all over the world in both very hot and very cool parts of the world, and he's basically installing this thing in all of them so that it can do remote monitoring, and both for energy use as well as maintenance things and things like that. But if you're gonna implement stuff like this, this poor person who puts all these HVAC things out, they're a Linux, connect with Linux devices, you gotta ask yourself the question, is there a good update mechanism that that, you know, customer of ours is putting in place? So that's something that, and again, I think it's, one of the things that's good about, you know, if you have a hardware vendor that has security features in the hardware, I also think that's a good idea. Again, but that's a practice you need to put in place. This actually brings up another point that, seeing Chris back there, it reminds me. You know, there are, I'm not a security person, I gotta tell you, I get scared about security issues, but I'm not a security expert. In fact, it's probably, it may be worth it to bring an actual expert into the equation to think about it. It was a great talk from somebody at Mentor Graphics. I've mentioned Chris back there, he's from Mentor Graphics and they're great security experts at Mentor, Wind River, and our partners, and as well as consultants who are using the Octo project who have developed an amazing set of tools far beyond what we have in meta security, right? So that they can really employ these things to help you out. The thing that's always daunting about me is I see all of these things that security experts use and it just, it makes me depressed because it's like, I'll never be an expert in all these things. Well, I think part of the good thing is there are experts who can employ more of the tools and help you out. So I think the ecosystem is ready to help out. Right, Chris? I mean, yeah, right? So not just hardware manufacturers like Intel, but some of the people working in the ecosystem with the Octo project can really help get this stuff going. They're very cool on the board. All right, what else? So what's coming next? There are a few things. So one of the things, it seems kind of obvious, but just maintaining the stuff that we put into the Octo project is pretty important, right? We talked about the fact that we have a release last week. We come up with a new release every six months with the Octo project and this is actually the 1.5 release I think is our fifth or sixth, I think it's actually our sixth, 0.9, yeah. That's just basic math, I ought to be able to add it up. Yeah, it's our sixth release that we've done every six months, a little bit insane, let me tell you. But I can come within a week to a few days of where we targeted each of those releases and they all come with the latest, basically supported, released kernel, GCC tool chain, and as many of the user level Linux ecosystem components as we can, and again, the challenge of building an operating system is just getting the thing to work. When there's literally like a thousand projects all over the internet that you can choose from to build a working OS, it's a little bit challenging. We've done a lot of that hard work for you so you don't have to compete on the latest and greatest grep command, right? You can actually start with all that done and then build actual value on it. But that's incumbent on us as an open source project to do the somewhat prosaic work of actually keeping this stuff up to date and actually making sure we maintain it. And we'll, again, we'll love help if you find that we've missed something and you can submit a patch, we would love to include you with that. You know, I think one of the things that's all, I thought, oh, now I remember when I was talking about the value of the Octo project is actually it has, you know, it's not just for the one thing that you're going to be doing, but the whole, you know, sequence of things that you do over time, right? The next product and the next one and the next one so you don't have to redo things. But one of the things I think is incredibly powerful is really establishing kind of workflow. It's not just, can I get Linux and can I put some apps on it? But what is the workflow? And this is something that we've actually worked a lot about with the developer experience. We've added some things, not only our Eclipse tools, we've added Hobb, which is a graphical developer experience that lets you do things without necessarily resorting to command line. We have our first versions of our web-based experience. You could talk, you could also go to Jessica, Jong's talk today or tomorrow. I can't remember, it's either today or tomorrow. Talking about how you can use actually Windows to build your Linux system. What? Or you can use your Mac OS, okay, that's better. To build a Linux system, right? So those are the kinds, you use the web, use Windows, Linux, Mac, right? To use any of those to build a Linux system, right? So the developer experience is something that we're working very hard on. But there's yet another thing that I think is incredibly important. I've been harping with people about this for the last three years we've had the project out of how do you make sure the thing is done, right? What is the part of the experience which you can basically say, okay, I want you to just sort of do all of the stuff that you would normally do to release a product. Now, we already have some great stuff built in on licensing, for example, right? Because one of the things you have to do with a product that has GPL-based code in it is you need to provide the source code for the GPL stuff, right? And you need to provide, you know, it's good to have a license manifest. So we exactly do that in the Octo project. We have the ability to create, you know, an archive, a source archive so you can meet the GPL requirements. Oh, joy. You know, it's automated, right? And create a license manifest so people can know all the licenses that are in the stuff that you just created. Awesome. But all of this should be automated so that not only should it be the, you know, the creating of the source archive and the checking all of these security things that are part of it that it's like, okay, this is like the last step that I do when I'm just about to burn the devices and produce, you know, hundreds or millions of them, right? It's sort of that finalization step. So those are some of the workflow things I really want to see integrated both into Toaster, which is our new web-based, you know, baking interface. We have BitBake, we have Bahab, which is what you cook on in England, I guess, and then we're going to give the Toaster. So anyway, but really to put it into the developer experience so it makes it, you know, makes it easier. So that's something we want to try and do. That's Hyde Park, I think, at some point. And then, you know, what are the missing pieces? So again, we're really looking for, you know, this is incomplete. Actually, this is an ancient Roman city in Turkey. I can't remember the name of it. It's unpronounceable to me, but it was like a few missing pieces to an actual complete city. So we're a little looking, you know, for really more help from you as a community to really help get us, you know, better, you know, tools, what are the pieces that are missing? So we're very open to this and interested in your help. So, uh-oh, yes, hit the right key. Okay, what's last? Again, I think, as a, you know, really, what I would encourage you to do is, I've said this about three or four times, I'll say it again, get involved with this as a project. Get involved with the Octo project, where it's a fun bunch. There are a few characters like every other open source project is, but actually, I think we've done some amazing things over the last three years and so I really encourage you to, you know, continue to work with us. We have a number of interesting talks today and tomorrow. I'll show a list of what they are. And, you know, let me just do that now, right? Thanks. Okay, yes, Jessica is giving her talk on modernized embedded links software development tools to achieve development anywhere. This is the development anywhere that I think is key there. Paul, this afternoon, is gonna be talking about the, one of the big things we did in 1.5 was we have integrated automated QA. So creating a QA framework is not rocket science. There's so many of them, just, you know, just pick one, right? But we actually now have the ability with when you do a build, basically, there's a suite of QA tests that run against it. Okay, so that it's actually checking the functionality of the thing and we're doing some additional extensions on that so it will automatically run against a bunch of, you know, real hardware as well. So we'll have a, you know, basically a lab of real boards that this will run against also. So it's very easy for you to integrate your own hardware into this as you do the build. It's like I said, finishing the thing, right? So you're not only, what do you have to do? You have to do a bunch of QA. We were doing a bunch of manual QA before and it's like, holy crap, this is horrible. So we've actually, you know, hopefully simplified a bunch of the effort that we're doing to make sure things work. Jeff, tomorrow is gonna, tomorrow morning he's gonna have a bof on the OctoProject. Come on, your questions, comments, nasty remarks. Mark is from the, is from Wind River. He's gonna be talking about SPDX and the OctoProject. This is where the community is really trying to get on top of this whole licensing thing. Again, we've done a bunch of work on, you know, the source license compliance and so there's some great tools we're doing with SPDX and then Ross, poor guy, last thing Friday afternoon. But he's gonna be, he will be, Ross is a very, you know, senior architect on the project, he's gonna give, I know it's gonna be, I haven't seen it. He always gives a very informative and entertaining talk with lots of good pictures and lots of good stories. So. There's also the chalk talks. Oh yeah, and during lunch, I think, out there there's some chalk talks that are gonna happen as well around the Intel booth, I think, right? Okay. That's all my content. Are there any questions from the boss? Yes. I think, yeah, I think the question is, are there any robustification? I would say that's probably more in like MetaSE Linux. I think MetaSecurity is more the analysis tools. Yeah. Yes, please. Right. Ah, okay. So we support, you know, there's always religion about which package format you support, do you support DEB, do you support RPM? One of the things I love about the project is we support them both, as well as IPK, which is sort of a very lightweight, embedded-oriented package mechanism. I don't think we have signed packages, do we? We have RPM three support, but I don't think we actually have signing in. RPM five, sorry, I always get those confused. RPM five support. Not signing them. Good question, though. I know that's important. Please. So this is actually, so the question is, do we run different services as different users, UIDs basically? That's something that I believe is Android's primary security mechanism. Every application you install is a different UID. That's actually not a policy we've implemented in Yachto project. You certainly could. There'd be nothing, there's nothing inherent that says you must, so it's something that's available. Some recipes, as Dave said, it's not something that's across the board implemented that way. It depends on the service itself. Last question. Yes, please. Yeah, in fact, there are some of those that we haven't implemented because they didn't seem like they were as applicable to embedded devices. So I think that's probably an area we could do better on. The kernel maintainer, I don't actually see him here. He's probably going to the x86 talk at the same time. So I know of several that our candidates so far, I've looked at each, I've looked at them and I've said, I'm gonna see how they apply to embedded necessarily. So we probably will look at those as they come up for sure. Thank you very much. Make sure you go down to the booth and get your Yachto box. Thank you very much. Thank you.