 Okay, thank you, Tim. I really appreciate the chance to give this talk. I really appreciate everything that Tim is doing relative to the CE Linux forum and I think he's just got some tremendous things going on. So I really appreciate the chance to speak. And yeah, it's true. I did give my start around 1980 and as a kid, it was kind of amazing to be at university. I had this amazing chance to work on a Vax 11750. You know, if you remember this, this was like the Vax MIP, right? The Million Instructions Per Second. This thing was running 4.2 BSD Unix and 12 meg of memory and it was connected to the network which in that era, about 1980 was UUCP, you know, dial up networking basically. So incredibly exciting as a kid to be able to get into the source code of the operating system without breaking into something or, you know, right, stealing it, right? It was like this is amazing stuff. So I think for me that kind of motivated me to really do more with operating systems and so that's kind of what I did. And, you know, I started working for a couple of different companies out of school and, you know, that Vax, it's amazing. We ran our entire computer science department on that one Vax with 12 meg of memory on it. Amazing. At Colorado State University. When I went to work for Sequent Computer Systems, a server manufacturer, you know, similar sort of looking computers, big boxes that were one of the, Sequent was one of the early symmetric multi-processing companies and so, you know, we actually had 30 processors, 386s, 386s, you know, each about a Vax MIP, right, running on that, you know, big refrigerator looking thing and ran their entire company on it, right? Now our top software guy, it was a guy, I didn't get his permission to use his name so I, I shut her a little bit about saying it because I know he can do to me if, if, if I were. But anyway, he, he was the top software, top OS guy at Sequent. And he went to a security conference at one point in 1988 and got kind of interested in this idea of viruses. So with the permission of his manager, he created a very simple little virus. He wrote a little bit of code that would slip into some extra space in the A dot out header, right? So it would not actually override anything in the code. It circumvented the starting point basically of the binary. And then very simply would write a record to a file slash temp, giving the date and time and the user, you know, oh, I, I got caught. And then it would run through dollar path and, you know, any executable it found that was writable, it would just stick itself in that A dot out header. Very simple. And then start the program. So you'd never know that it was infected, right? Classic virus in 1988 with the permission of his manager. And, you know, he infected himself, you know, fine. And after a few days, you know, those things were, you know, low level infection and then, you know, somebody else got, oh, okay, ran one of his binaries. And so until the fateful day on November 2nd, 1988, when, in fact, somebody in the IT group who happened to be running his route, happened to run one of the infected binaries. Sure enough, every public binary in the system in that user's dollar path got infected. And so low to average is shot up. Everyone's productivity went to zero because the system was constantly pounding on that file and slash temp and then trying to go through all the dollar path and trying to infect everything it could, right? So everybody in the system essentially was infected at that point. And I, it was, it was a fateful day because I remember his manager, a wild Australian, who I also won't use his name since he might get back at me too. But, you know, I remember him walking into Bexaw, I mean into that guy's office, and he would say, disinfect, disinfect. You know, it was a great moment. Now, the reason why I remember it's November 2nd was because on that exact same day, the internet came to a grinding halt. Now, it was not a big internet in 1988, but we were all, you know, dependent on it. Those of us who are a little bit older, you know, remember that day because November 2nd, 1988 was the date that the Morris Worm got released. But all of us were saying, holy crap, Bexvirus got out to the internet. We've infected the whole world. What's happened? You know, it was like we were really, really scared. Of course, we used to do little things like launch TCP, you know, torpedoes out of conferences. Somebody did at the company. Anyway, so, but it was kind of an interesting, you know, introduction. Now, I'm not a security expert. I've been affected by these things, as I think we all have been, right? So, this is kind of, as I start thinking about embedded systems, and now that I'm working in embedded systems, it's kind of cool for me to think about how a lot of very inexpensive systems are a lot like that washing machine over there that had 12 meg of memory on it would run about a maximum, although it's much more affordable now and connected to the network, right? We have 32-bit and now 64-bit, very inexpensive, very powerful systems connected to the internet that we're using everywhere. And that's very exciting to think about. It's also, every time I think about cool applications, I start getting kind of worried about it. I start thinking, well, there's a few interesting privacy and security implications to some of these things. I want to visit a few of these things that are keeping me awake at night. You know, one of these, and I'm very grateful to Ryan Ware, who's a co-worker who spent a very little time, dug out a few recent examples, but this should just kind of give you an idea. A lot of people heard about Stuxnet virus, which affected a lot of Windows based computers. It turns out it's now known that this was actually developed by a number of American and Israeli intelligence officers, intending to attack the nuclear program at Iran. So they were working on, you know, nuclear fuel refinement. And so the idea of Stuxnet was to go and attack the high-speed centrifuges, have them run at such a high speed that they would break. A difficult problem, given that all the computers connected to those centrifuges were separated by an air gap from the rest of the network and the rest of the world. But somehow they got the virus, they were successful, but then Stuxnet got out and then started affecting computers all over the world. So the unintended consequences certainly is kind of an issue with some of these things. In fact, what Stuxnet depended on was this so-called zero-day issue, right? And, you know, I always was confused by the name, but all it means is every time you ship software, it's got some number of holes in there that you don't know about and that maybe somebody knows about, but maybe are left there to be discovered. Linux itself, Ryan tells me that's on average about 2.5 CVs per week get released on the Lance Colonel, right? That a CV is one of these, I can't remember what it stands for. It's basically a security exploit that needs to get patched. That doesn't mean that Linux is insecure, it's worse. It just means you have millions of people using Linux and a lot of eyes looking at the source code and probably revealing a lot of problems that are already there. Reality is that studies are now producing reality. There are a lot more of these zero-day bugs than we ever realize and they are considerably serious. Here's another example dug out. This is a company that has software that's actually used in a lot of power plants and this power plant software actually is, you know, it's essentially a panel that you can use to control this critical infrastructure, right? And it turns out it's very easy to get onto this software, get a root privilege and exploit it. And it turns out, somebody did for this article on Ars Technica, they did a little simple study, found 172 of these actually connected to the public internet and that was just a cursory search. So in fact, you know, and the companies basically said, I don't, you know, I can hardly blame them, they sort of said, you know, we can't, we can't, you know, solve all of these problems with our software, right? So we have, consider yourself, you know, part of an infrastructure now, dependent on an infrastructure for your lives, really for power, I think about people in hospitals and things of that sort, but you know, that are all based on this infrastructure that, well, you know, there's some things we just can't deal with, right? So this kind of keeps me awake at night a little bit, thinking about all the power of embedded Linux and all the opportunity, unfortunately, that's there for some of these bad things to happen. So now, I got to tell you, sometimes, you know, history just does funny things to you. Yesterday, New York Times, just as an example, I was great, they put on an article, did anyone see this article that apparently there's governments fighting against governments? It's always kind of this funny spy versus spy thing that turns out that, you know, some release happened in the New York Times, some report that said there's this building in Shanghai that apparently is full of people that are, you know, creating a lot of these viruses. So I'm not blaming, you know, China, I think, you know, there's a lot of countries that are probably doing this. It just happened to be this one was reported in the New York Times yesterday. So this sort of thing, you know, is happening constantly. And, you know, well, let me, let me talk about a couple other examples. Jim Zimlin last year did a, I really appreciate his keynote a year ago at the Yachter Project Developer Day. He gave, just, he knocked it out of the park. It was a great keynote. And one of the things he talked about was, you know, these utilities that are now putting these sensors on every house, right, to monitor the power use every 15 minutes at houses. So they, so that smart grids, right, can get a really good idea of how much power is needed. Problem is, FBI's basically now said, gee, there's hundreds of millions of dollars for one US utility that basically has been lost because it's very easy to exploit these. Apparently a very easy exploit in this article was you take a big permanent magnet and you set it on top of the, you know, that's not a very sophisticated attack, I grant you. But, you know, that's, that's at least, that's the most, you know, simple, what we call redneck engineering. I heard somebody at the keynote on Monday talking about redneck engineering. That's, that's a good way to do it. But there are, you know, costs that are associated with this. A few years ago, an article came out about smart dust. These are also referred to as, as moats. So you have these now very, you know, again, my, my favorite first computer from 1980. You know, these 12 meg, you know, systems that are now projected in the first quarter of the century to be about five cents. All right, so now there are plenty of applications that are very cool to use these in if you think about pipes in which caustic liquids are being pumped in a lot of plants. Very difficult to monitor these things when the pipes are weakened and need to be replaced. And so placing these in all sorts of, of very intricate and difficult to reach locations that are, that's just one sort of example you might use, you know, smart dust for. So, you know, clearly we're going to be at the place where that Vax, you know, that I used in 1980, you know, is going to be available everywhere for five cents a bit. So five cents per unit. Now here's the problem. I don't think this is necessarily a bad thing, but guess what? I think a lot of embedded devices, a lot of us make this sort of assumption is this is not a general purpose computer. I don't really need to worry about any random application being loaded on this thing. It's a one application thing, right? So why do I have to worry about this? The problem I think as I've, you know, really grown to appreciate people working in embedded software sometimes maybe that assumption leads you into some dangerous conclusions. It maybe leads you and maybe leads your manager to kind of drive you to release software maybe earlier than you'd think it might be ready, right? Let's get this thing out, let's get time to market, let's, you know, get going on this thing so we actually are able to make money. So I think that's the intersection I'm really kind of concerned about. I don't think actually Linux is all that different. There's some other operating systems that, you know, people are actually measuring the number of exploits. Here's a general purpose operating system I won't, you know, I think is a great operating system, but there's also, you know, plenty of exploits going there as well. So telling you all this and telling you this stuff keeps me awake doesn't make me want to be known as this person. You know, Cassandra was known as, she was in Greek mythology. She was doomed to ever know the future but be cursed that no one would ever believe her. And so there's a picture of her from Wikipedia in front of a burning city and driving her mad because no one would ever believe her. I don't want to be like that. I'm not, just like I said, I'm not a security person per se. But what I can see is there is a social imperative that I think we as citizens of this world need to think about this sort of thing and try to get a handle on it so that we can prevent the world really from losing a lot of, you know, not only time and money but people's lives potentially can be at risk of this sort of thing. That's the last thing I want to have happen is embedded Linux being blamed on the front of, you know, name your favorite newspaper, Wall Street Journal or what have you to say, you know, is the cause of loss of life or a great expense. And so what are some of the things that we could do? What are some of the things that I can do? I mean, I'm working on the Octo project and if you haven't heard of the Octo project I strongly encourage you to learn more about it. What we're trying to do is with the whole world of embedded Linux really help everybody from the Silicon vendors to the embedded OSVs, to the device makers, to the entire open source community and really get a single and universal way that everyone is developing, set of tools for embedded Linux. That's an awfully high goal, right? But I think it's kind of worth it if you kind of think about what are the potential social impact if we can do some things right? It's not just making it easier to create embedded devices. It's not just making it so that you spend less time screwing around with different VSP formats or different, you know, oh, I can't hack this thing because it didn't work before and man, I have to hack it up again. It's not about that. It's really, I think about can we, as a community, come together and really do some great things in this area. So as an engineering manager, I work with the community in the OCTO project. There's just a few things that we're working on in our current release. We release every six months. Our sixth release is coming up in April and you know, here's an example of some of the things that are important. You know, if you have 2.5 CVs per week on average with the Linux kernel, it says that it's probably a really good idea to have a robust update or available, right? In other words, as the security issues are found, you need to be able to update those connected things. Now, as my friends at Wind River used to tell me all the time, customers always want the latest thing, but they don't want it to change. How does that work? Yeah, so, you know, and it's true. Certainly in the enterprise area, if you've got a bunch of, you know, embedded sensors every place, one of the last things you want to have happen is that an update to go out and to brick the system, right? So then you have to go visit it, right? So this is where I'm very, you know, happy that we're going to at least contribute, I think, to this. In our upcoming release, our intent is to have a new updater available, along with, we also have the package-based updaters like for RPM-DEB and O-Package. So we will continue to have those, but we're adding a new updater that was developed by Arun Vendavan in his project called Fenris, and that says www.fenris.org. It's actually, I got that wrong, it's linux.fenris.org if you want to go visit his website. So we're working with him to try and incorporate that as a feature. I got to tell you though, a robust firmware updater is probably needed as well, and it's a little bit more difficult to do that. What's below the kernel is typically very device dependent, very difficult to do, as sort of a general open source solution. So we're hoping that we can, you know, get some best practices out there as well. So there are some people doing some interesting things I think I've heard of with UEFI, as an example on some phones and some other devices, but I think that's still, you know, the device specific part is kind of a concern. People usually say, oh yeah, SCLinux, right? So in fact, I very much appreciate the folks from Wind River contributing this to the Octo project. There is an SCLinux layer that you can apply. That's the URL for the Git repository, and I'm extremely grateful to Mark Hatley and his other folks from Wind River for contributing this and maintaining it. And so SCLinux gives you, makes sure that you can say, well, what are the least privilege, you know, that example of Beck's virus, or the guy's virus where he took advantage of somebody having the privilege to be able to, you know, really have root privileges. It really tries to reduce that factor considerably. So we've been interested in this concept with someone called tool chain armoring. In other words, there's some things that you can do in the tool chain to actually be able to, you know, generate virus, you know, generate, sorry, generate virus, generate executables that are much less susceptible. We actually haven't quite tested this yet, but it's something we're kind of looking at. If anyone from the community would like to work with us on this, we actually tried it out and found that we had problems, the EG-Lib-C. So we're trying to sort it out. So that's one of the examples, hopefully we'll have this in the upcoming release. Well, scanning for obvious holes or backdoors would be really good. There's a project called Bastille Linux that we've identified as something that would actually scan for kind of obvious things like open backdoors and, you know, accounts with no password and things of that sort. So we're looking at integrating this. One of the other things I'm kind of interested about is integrating that into WebHob. This is something, the name's a little odd, but basically a web-based tool which will allow you to generate your Linux. By the way, one of the things that's kind of cool about is even people who are sort of skeptical about web, I would call them UI skeptical people, right? Give me a command line to build Linux, I'm fine with that, right? In fact, some of the tools are gonna be available, collected and visual and available. So you could see, well, where's the space disappearing? Why do I, is my footprint so big? And actually I identify things. Why is my build taking so long? Being able to analyze exactly what's going on there and some really good forensic information that'll help you figure out more about what's going on. We'll have that available. Preliminary versions, hopefully in our 1.4 release. We're working on that with designers. By the way, on that, will it go back? Wow, it does. Cool, you guys are great. The concept here, by the way, is we're trying not to do any of this in a vacuum. This is a true open source project. We have a mailing list, you can join, you can, we are working with some a very, very good industrial designer who's working with us on this. She would love to get your feedback and involvement in terms of some of this stuff. In fact, we have a prototype of this. We'd love to get your feedback on the Octoproject booth. And then, you know, there's some other places we could use your help. I mean, one of the things that's great about not only having the tools available that run on, by the way, ARM, PowerPC, MIPS, and X86, all of these, all the main embedded architectures are supported. And we have some starting points as well. Web kiosk is an example where you can, you know, start with any of those architectures, but add a layer that will basically give you an HTML5 web application, basically, without any kind of decoration. It's a, you know, typical kind of thing you'd want to have for a kiosk. We'd love to have your help on that. Actually, there's a talk today, Nitin Cambly is giving a Talk Friday, 215. You know, how to build your own digital signage solution with the Octoproject. Anyway, he's gonna be talking a little bit about that meta web kiosk layer. So that's one of the starting points. Well, I'd love to get help from the community. We all would to say, what are the potential security issues here? What are some of the places where we could kind of improve the software? Another starting point is with virtualization. We have some people who are actually using the Octoproject to create little virtual appliances. Things that might be Zen guests, or, you know, KVM guests, or what have you, just minimize for one specific function. Love to get your feedback on how to, you know, are there any security, potential security issues there, so that we can really make this a great starting point for the community. There are a couple of others meta-multimedia, and Baryon is one of the first ones of these we did. It's a NAS device, right, a network-attached storage. So you can use Baryon as a starting point to build a NAS. Very nice to be able to do that kind of thing. But again, we haven't necessarily done much work as a community yet to make sure there aren't any other, you know, potential backdoors in there. So we'd love, you know, your help as a community to help us with that. So, you know, there's also Intel. I mean, I am paid by Intel. They write my paycheck, so I'm delighted to work for Intel. And there's some things that Intel is actually building into hardware to try and help with this matter as well. And some of the things we're trying to, you know, enable in the Octo project is also, one of the technologies is something called TXT. It's Trusted Execution Technology. Let me kind of explain how this more or less works, is that, you know, if you are running an embedded device that maybe is running, using virtualization, maybe you have a couple of different virtual machines running, or even a bare metal kernel, the challenge is someone may have stuck some bad code into that kernel and the operating system, and when it boots up again, you don't know that it's been changed. Or they infected the VMM, right? And so people have been, you know, do things with what they call a root of trust. And so the opportunity here is actually, if you have thousands of systems, right, all over the world and the internet of things, how do you ensure that that no one's messed with that, you know, the operating system or the VMM that might be running on it? So there's an open source project called Tboot that basically has been adopted not only for the Octo project, but also for Fedora and Ubuntu and Suzy, et cetera. How it basically works is that the system actually measures the launch of the OS or the VMM, right? Measures that launch and then compares that measurement to a previous one that was saved in the TPM in the platform. If the measurements match, you're good to go. Basically no one's messed with it. If the measurements don't match, it means something has changed. And so it uses TXT to basically go into a backup mode. Backup mode depends on whatever it is you want it to be. VMware actually, I think, allows you not to decrypt the disk because it encrypts all the storage. You know, there are other sort of backup modes you can use like don't boot, or don't give access to the internet, or something like that. And then the other piece of this, besides the measured launch, is that you need the ability to actually see with a cloud of internet devices, a cloud of these connected intelligent devices, you'd like to be able to say from the central point which ones actually came up okay and which ones didn't. So we actually have an open source remote attestation stack that allows you to basically query the systems in a secure sort of way that basically allows you to interpret with this cloud of embedded devices out there which ones actually might have had a problem, might have been infected. So remotely, very quickly, an enterprise can figure out, oh, and this cloud of, you know, let's say it's the digital signs in all of the McDonald's restaurants in the world. One of the projects we were working on with the Octo project. Or, you know, all of the, you know, digital signs in the San Francisco airport. I think they're probably running Windows. But anyway, you know, this gives you, well that was stuck that was based on a Windows virus. But anyway, this would give you at a central point to be able to determine in a very provable sort of way that you actually can be trusted or not. And this is not everything. This is one piece of the puzzle. But I think it's kind of cool to think about the hardware actually locking in, you know, the security basically. And for people who, you know, care enough about this to say, yeah, I really want to make sure the integrity is guaranteed by hardware. This is a great capability. And it's, you know, the software's open source, it's open source projects. And so, so what else? So finally, final word is, I'd say, you know, join us. We actually would love to get more involved with the OCTO project. We already have great involvement from, again, Silicon suppliers, OSVs, device makers, and the open source community. And we have a number of talks here at ELC that are, you know, either touch on the OCTO project in some way or some part of it. Today, actually starting at noon, the Coon's going to be talking about the open embedded project two years after adopting OCTO. At 2 p.m., we have somebody from the LTSI effort with the Linux Foundation, very happy to have them part of the OCTO project advisory board. So I can talk about how to use LTSI with OCTO. Then, Sean from Mentor Graphics, one of those members of the community, members of the advisory board, they're an OSV. He's going to talk about building custom Linux distribution with the OCTO project. Scott Garmin at 4 p.m. This afternoon is going to be giving a very interesting and exciting talk that's probably much more interesting than the title. But we made it sort of actually kind of boring. There's really kind of a very cool announcement that's going to happen in that talk. So I can't, I can't spoil it. But it's going to be very, very cool. So anyway, go to, and then this afternoon, we have a bof at 5.30, 5.50, something like that. Then tomorrow, there's a talk from Dennis from TI. Also a strong part of our cooperative effort here on pre-built binary tool chains. Tracy and Nithya are going to be talking about marketing, which I think is, you know, very, it's a very good talk. I attended a version of this. They do a kick butt job on marketing open source projects. And so then at 1345, which way, that's 145, there's Chris Simmons, Simon's or Simmons? I keep forgetting. Simon's, okay. It's going to give a talk that is really, it's not specifically about Yachto, but it has a Yachto project as one of the components in it. I'm very excited, it's a great talk. It's very, very cool. And then if you want a general overview of the Yachto project, what's there, Saul is going to be talking at 4 p.m. tomorrow, giving it just a general overview. And then Friday, there are a few more talking about, from Michael from Nia is going to be talking about meta virtualization. Kem is going to be talking about EG, Lib C and bringing K config to it. Kem as a contributor to the project is going to be talking about EG, Lib C, which is part of the project. And then Nitin is giving that digital signage talk. And then finally, Mark and Mark from Wind River are going to be talking about licensing. So that's all I had. Thank you all very much.