 Okay, I think we should be go. Good to go. Hi, I'm Peter Robinson. I work at Red Hat on IoT, primarily in Fedora, but in other parts of the organization as well. And I'll be today discussing architecting a secure IoT platform using a standard Linux distro such as Fedora. So IoT will certainly change the world, but whether that's a good thing or not remains to be seen. And a distro like Fedora is a great place to define that because, you know, we already have, you know, things like maintenance and update, security, lifecycle management already embedded as part of the distro philosophy and the things we deal with on a day-to-day basis, which is at this point not the only, but one of the major issues that a lot of Linux-based IoT platforms don't have. They don't have, you know, any concept of updates and security and maintenance and lifecycle management. It's very much to ship the product and let it go and that's it. We're done on to the next generation of platform. So this is vaguely what an IoT stack looks like. It's based on Cortex-M. One day I'll actually get around and do a nice shiny graphics version of that or bribe someone to do so. But that's a rough overview of a typical, you know, Linux gateway or endpoint style IoT stack. So what would we base a secure, robust IoT platform on? Fedora has a platform called Atomic or OS Tree. It does atomic-based upgrades rollback and gets away from the sort of yum upgrade, may fail halfway through, sort of no way to rollback if something goes wrong. We definitely have a focus on security, focus on three key architectures, although, you know, being open source and a standard Linux distribution, there's no reason that if, you know, some other great architecture for IoT comes along that we can't expand out to that. Fedora itself currently supports around seven architectures from your small sort of ARM V7, I686, right through to sort of Z-Series mainframes. And from there, we'd build a base platform as a decent foundation to build IoT verticals on. So a good foundation, secure, stable, minimal building block with an initial focus on the gateway platform, but with intentions on moving to, you know, other edge-based systems that the community might be interested in. And while we could, so Fedora runs on millions of different types of devices and, you know, hundreds and hundreds of ARM devices, for example, will initially have a focus on a handful of devices. So, you know, some of the proposed devices would be things like, you know, the Intel Dual, the Raspberry Pi simply because it has quite a good IoT following, similarly with the Beagle Bones, but, you know, larger devices like, you know, ARM64, SPSA compliant platforms. And, I mean, ultimately, we're not limited. I'm just trying to focus on a handful of devices so that we can get some good CI and QA happening against and use them as a focus. So what would a Fedora IoT gateway look like? But part of my role doing IoT at Red Hat is we're a member of Lunaro Lite. So as part of that partnership, we're building a gateway reference device. And, you know, that's part of my job and my role. So obviously, I'll have a personal focus on that. Using Fedora Atomic as a minimal base image, and then using containers as a means of adding functionality on top of that. So things like, you know, MQTT, you know, various different IoT stacks, bridging for different networks both wired and wireless, and other, you know, sort of IoT gateway functionality. Security is obviously going to be a key focus everything from UEFI or trusted execution environment, secure boot functionality, so OS verification, dependency minimization, I mean, who needs to support three or four or even more TLS stacks within a single minimal OS. Using SE Linux, Set Comp, and other related technologies to reduce attack vectors, enhance tool chain security functionality. Some of the recent GCC releases have had quite a focus on dealing with various, you know, security technologies. System D to sandbox services and containers. There was a recent CVE, which affected AF packet functionality. And with System D functionality, you can actually, which relies on Set Comp, you can actually remove things like, you know, AF packet from services so that you can effectively mitigate a bunch of CVEs. It's sort of, you know, the CVE is obviously still there, but it's effectively non-functional and non-compromisable. And then looking at, you know, various security projects like the kernel self-protection with GCC plugins and things like that to help mitigate entire classes of sort of vulnerabilities and things like that. So that even though you might have a device that is vulnerable to certain CVEs, it can't actually be compromised as part of that. Minimize the services shipped. Obviously, some of the recent compromise devices that have been used in various DDoS attacks have things like Telnet actually shipped, like who uses Telnet these days. You know, use the gateway device as a means of controlling access to networks, both inbound and outbound, using, you know, network isolation and device isolation policy routing so that, you know, if there is a compromise available against devices that are sitting behind that, you can have policies that basically null route or, you know, the attack vectors or the control hosts or control networks and various other bits and pieces. And obviously, you know, have things like, you know, centralized update platforms to push out, you know, atomic updates for those, for the atomic platforms. From a network point of view for gateways, we're going to be focusing on open standards. Obviously, Red Hat and Fedora in particular actively pushes for open standards and open platforms. So we're going to look at things like 80215 for Bluetooth LE or Bluetooth Smart, Six Lopan sitting on top of that. And also from an industrial point of view, things like support for CAN, RS485, some of the older protocols to sort of interface with existing platforms. This is a sort of diagram of a typical IoT wireless network topology with, you know, Six Lopan mesh and what have you. So some of the sample containers that we'd be looking at running on the gateway platform, obviously, this is quite new and in Fedora 26, we'll get the initial preview of the base platform and some sample containers that we'll be able to run on top of that. So things like, you know, the various different wireless technologies, open thread and related sort of platforms, MQTT and other messaging stacks might be AMQP or whatever. You know, fairly, the idea of being able to run containers on top is it's fairly flexible. So you can add, you know, MQTT caching modules, other middleware, maybe update platforms for smaller, say, Zephyr or various other devices that you may be hanging off the network. And then possible IoT specific stacks that sit on top of that, you know, edge data processing and reduction, policy and control and other business rules engines, things like the Apache Kura and Hono and all the other related Apache Eclipse and various other IoT stacks, Node-RED and then, you know, things like Solata, IoTivity, Home Assistant, pretty much anything that you would, you know, potentially want to run on these. So how do we evolve just from the gateway? I mean, how do we scale to hundreds of thousands of gateway? How do we, you know, deal with centralized update processes, you know, stage rolled out, stage like monitoring of beta or test sort of things similar to how, you know, Google rolls out updates for an Android phone or Facebook rolls out updates to their, you know, their apps, you know, they start with a constrained group of people, you know, and then test and monitor and see how that rolls out. I mean, you don't want to roll out an update for 100,000 devices and move from 100,000 devices to 100,000 bricks as a few IoT companies have experienced. You know, centralized policy frameworks, you know, if you've got a device on your network that is compromised that can be part of a DDoS, you know, how do you push out, you know, firewall policies to null route, you know, traffic to the control networks and things like that. So these, you know, potentially compromised devices that are sitting on your IoT network can continue to function as they're supposed to, but, you know, not participate in, you know, massive DDoSs and things like that. You know, how do you have, you know, message buses and deal with devices that may come and go from your network periodically because they run on batteries in the middle of, you know, farmer's fields somewhere, you know, how do you cache updates, how do you cache, like, message bus input and output from those devices as they come and go, how do you deal with things like edge analytics and data reduction so that you're not pushing, you know, tens of thousands or petabytes worth of data into the cloud and getting a big bill each month for that. These are all sort of things that are on my radar to look at and as we're obviously not going to be able to solve them straight away and, you know, these are things that I'll be looking at and, you know, other people will be looking at to evolve the gateway and the IoT stack as a whole as we move forward. So is it just a gateway? No, it's a starting point to drive focus. You know, I like a lot of tech people have the ability to be a little bit shiny squirrel and run here and there between, you know, all sorts of shiny projects, so we need to start somewhere and we need to focus. I have lots of ideas. I mean, I come from a farming background and there's a lot of IoT starting to happen in that space and my brothers who are the farmers have lots of ideas they would like me to do but, but I mean, ultimately a gateway is a good place to start. It's a good base to grow on and, you know, we can focus on the gateway as a combination of both industrial IoT and home. I mean, Red Hat obviously has more of a focus on enterprise-related things from a community and Fedora point of view. It tends to be more focused on smaller things and a lot of people I speak to have an interest in like home gateways and the ability to be able to have control over the smart devices in their home. I think, you know, both of these, while to a degree compete with each other, are also very complementary. I mean, there's really not that much difference between the two. And so in Fedora 26, I plan on doing a proof of concept and we'll start with that and we'll evolve it. Nothing will be set in stone and if we throw it away and have to start again in a few months' time because we don't get it right, need to be open to that and feedback from, you know, people, companies, ideas. So other options. I mean, I've had people ask me about imaging stacks, image processing, like identification, so anything from a security device looking for movement against doors or what have you through to number plate recognition and that style of almost stuff, you know, artificial intelligence, Amazon Alexa style, hello Fedora. I mean, Alexa is an interesting IOT home device, but me personally, you couldn't give me one. Well, at least not one that's plugged in and turned on because I don't want listening to me. You know, ultimately, it would generally just hear a lot of expletives from me as I work from home talking or muttering to myself. You know, there's lots of ideas, like every time I speak to someone about this, they have different ideas. And so there's just too many to put on a slide deck to mention. So an overall summary, you know, Atomic OS True is the right way to go. It gives us stable updates, rollbacks, almost unbrickable devices. You know, you put health checks in place. So when a new update applies, you set a watchdog, you reboot the device. If it doesn't boot or it doesn't come back or it comes up and there's no networking or it comes up and it can't speak to the sensor networks or the sensors on the devices, you know, you fail the watchdog or you fail it, you wait for the watchdog to hit and you roll back. So it's definitely the right way to go so that we don't get, you know, brick devices. You know, this is a stable foundation we want to build on. Multiple architecture support from the outset, have some initial reference devices as a focus with a focus on a base IoT platform and gateway functionality to give us like a solid foundation to build on top of. Any questions? So the question is about initial device and how we plan on adding support for devices moving forward. So at the moment it, at the moment it'll be the way Fedora adds. So in the case of x86, I mean, we already support thousands of devices. In the case of like SPSA reference platforms, any new SPSA device that comes along is automatically supported if it's SPSA compliant because that's the way that works. And it's ACPI and UEFI and things like that in terms of other, like, so we support actually around 300 devices in Fedora at the moment and all of those devices will work already out of the box with this. The intention is not to have like, we're not excluding those devices and they will work. It's more just a focus on specific devices. And we haven't looked at a BSB style, you know, at an extra kernel, vendor kernel and anything else at the moment. There is certainly intention to look at that functionality. But in the short to medium term, I mean, I've found I've been working on ARM in Fedora now for six or seven years. And we've been a little bit slow on supporting some of either shiny devices, but at the same time, by not dealing with vendor kernels and basically having a kernel for every single device we wish to support and going the upstream kernel route. And we've had this with, you know, there's been issues where vendor kernels have had, you know, backdoors and major CVEs and are based on tend to be 314 ancient kernels that aren't maintained. And we don't end up in a situation where we have to deal with that hell. And we don't need to try and audit and secure a vendor kernel. There is certainly the intention on enabling people to do that if that's the way they wish to go. But how we've how we nail that down hasn't really been resolved yet. And our focus tends to be get it in the upstream kernel and then we'll support it out of the box by default. Any, yep. Sure, the questions about requiring reboots for upgrades. I mean, there's pros and cons to it, right? If there's a new kernel with a CVE, you don't have any choice but to upgrade or reboot. Sure, you can live patch the kernel and things like that. But the support for that tends to be for specific parts of the kernel. And in a lot of cases, sure, uptime is a great thing. But if you don't have a resilient platform that can cope with upgrades, it's probably not IAT. So I'm, you know, ultimately, if you're upgrading like a single service or a container or something like that, that sits on top, you know, you restart the container or you deploy a new version of the container and tear the other one down. It depends on which bit of the OS or which bit of the stack you're dealing with at the time. So can you repeat that? Is there a great reduction in size? So that's something that we're focusing on at the moment to try and reduce, actively reduce the dependency size so that we don't need to deal with things like five different TLS stacks. It also tends to be a bit of a whack-a-mole, constant, evolutionary process. You know, you'll think you've got things in hand and suddenly there'll be a slight change and it pulls in an entire, you know, new path of software. So it tends, Fedora is in the process of putting a new CI platform in place and we're hoping to be able to have some of the dependency checks and dependency watch as part of that CI. So if someone commits something to a package that suddenly blots out, you know, that depends, sees by a couple of dozen libraries, you know, we'll be able to at least audit that and control it from that point. But it certainly tends to be a bit of sort of chasing your tail whack-a-mole style game that's sort of ongoing. Any more questions? Cool. Well, I'm going to be around for the rest of the conference and there's going to be some possible drinks tonight. So if you're around, catch me on Twitter or what have you and I can give you the details of that. Thankfully, my speaking spot was quite early in the conference so I can sort of relax a little bit now and I'll be around to speak to anyone that's interested in listening to me rabbit on about IOT or anything else regarding that stuff. Thank you.