 Thank you. Hello. All right, guys. So welcome to the second day of DevConf. Before we start, I would like to remind you that in the mobile app, in the Android app, you can vote for the best speaker. And if you cannot find any button or whatever, you need to be signed in in the app. Then you can vote. OK, so let's start with Peter Robinson and architecting a secure IoT platform. Hello, everyone. You'll have to bear with me a little bit. I've been a little sick over the last few days. So I hope this will be mostly cohesive. And I hope my slide deck's mostly cohesive because I did it mostly in the middle of a fever over the last couple of days at the hotel. So I kind of feel almost human today. But yeah, still not particularly great. So most of you will know over the last couple of years I've been doing release engineering in Fedora for alternate architectures. A few months ago, I transitioned to a new role defining IoT platform and investigating that. And so I'm going to cover a little bit of where we're sort of going with that. Internet of Things can potentially change the world, but will it be in a good way? I've seen a lot of recent security hacks and DDoSs and distributed DDoSs using various IoT devices due to their complete and utter lack of security. I mean, a Telnet server on a camera is great, right? The 1990s called and once it's remote access back. But these sort of security things is something we've been dealing with in a Linux distribution such as Fedora for a long time. So why can't we use what we already know in enterprise distributions and mainstream distributions to enhance IoT as a platform? And to make it... I mean, ultimately, IoT platforms are going to be, you know, complex and standard distributions are complex and we managed to secure them relatively well. So why can't we take that and use it to build a secure and robust platform for complex IoT networks? So this is a general overview of an IoT stack. It doesn't look that different to most other network stacks these days. So what we're going to be doing is having a base platform based on atomic, a focus on security, a focus on three architectures initially. X8664, Rmv7, ART64, because they're the ones that most of the world with regards to IoT from a Linux level as opposed to a tiny little embedded level tends to run. And then use this base platform as a decent foundation to build IoT verticals on. We'll be initially focusing on a gateway platform and a focus on a handful of devices, although in typical Fedora world, that won't mean. It's restricted to just those devices. You'll be able to run it on pretty much any of the Fedora supported devices, but we'll be focusing on a selection of devices to ensure sort of good support. From the reference devices point of view, like Fedora ARM, for example, supports multiple hundreds of devices these days, but the proposed subset, Intel dual, Raspberry Pi, Solid Run Humming Board, Edge and Gate devices as they're the Leonardo Light chosen one. And there'll probably be a few others added in there such as Beagle Bone or other such things. Final decision hasn't been made there yet. With the Fedora IOT gateway, we're working on a reference implementation as part of the Red Hat partnership with Leonardo Light. All of that work will be happening in Fedora. We'll be using Fedora Atomic as a minimal base built across three different architectures. Containers to add functionality on top of that. In Fedora 26, we'll be implementing a few example containers like MQTT and then bridging to different networks like AD215 for Bluetooth LE and the like. Security will obviously, for IOT, is a key focus. We'll be looking at, depending on the architecture, secure boot functionality and OS verification right way through the stack across the different architectures, dependency minimization, like there's no real need to ship three different TLS or eight different TLS stacks, SE Linux, Sec Comp and other related technologies to sandbox and contain and remove access to things that don't need access to. Toolchain security functionality, system D sandboxing such as restrict access families, which would have restricted. I don't know if any of you have followed some of the recent AF packet CVEs in the kernel where system D with a restrict access family would have actually mitigated most of those problems and things like the kernel self-protection project and related projects such as GCC plug-ins where people are focusing on certain kernel technologies to minimize and even remove entire classes of vulnerabilities and other such things. Services shipped in containers, high levels of access control to networks and between networks, network isolation and policies with regards to isolation. So building on being able to restrict access to networks based on device classes and particular devices so that if you have cameras that are insecure, you can put in policies on the gateway to restrict their access out of the network with device isolation and policy routing. Network support, there'll be a focus on open standards such as ADE-215 for Bluetooth LE6 low-pan with routing from 6 low-pan to the standard IPv6 networks and then support for wired networks for things like industrial IoT so you can support RS485 and similar technologies. So this is a sort of fairly typical IoT network with, although I wouldn't necessarily say the PC sits in there, but a gateway and then a mesh network out to various different devices. Some sample containers we're looking to ship as part of initial support in Fedora 26. Network stacks within so open thread caching modules are various home or other stacks, various IoT stacks such as Solata and some other open source IoT projects. An MQTT stack, whether that's ActiveMQ or Mosquito, I'm not sure yet. The version of ActiveMQ in Fedora actually doesn't currently support MQTT, but hopefully we can get that updated. Are we just doing a gateway? No, it's just a starting point to drive focus and drive proof of concepts. I've been speaking to various different people and there's lots of ideas. I have lots of ideas of my own, but a gateway will provide us a good starting base to demo the functionality and grow the community. The gateway focus is a combination of industrial IoT from an enterprise point of view and home gateway more from a community point of view. It's designed to be as a proof of concept for testing the platform, testing security, testing process and general functionality. Nothing's set in stone and will evolve and change as necessary. Other options, imaging stacks, cameras, image processing. I've spoken to a number of different people and there's a lot of ideas around that side of things. Artificial intelligence stacks, similar to Alexa-style functionality and numerous other ideas. So in summary, atomic is the right way to go because it offers secure atomic upgrades, rollback, and the ability not to break the device, multiple architecture support, initial reference devices as a focus, base platform and gateway functionality as an initial focus and expand it from there. Any questions? Sorry, I think I went probably through that a bit quickly. Yeah. Those types of capabilities are very similar, like us assistants, PRCs. Yeah, so the question is, what about industrial protocols such as Modbus? Yes, it will certainly be looked at. The summary that I put there was initially just for Fedora 26 and it will also depend on how open the protocols are and whether there's open source stacks that we can implement or like package and implement. I've looked at those sort of things briefly and have them on my to-do list to investigate further, but I haven't had time to do that yet. Yes. Yeah, so the question was, is the intention to deliver it as an atomic type from the get-go and the answer to that is yes. Any more? Yeah. Sorry, the question it was to check whether the boot media, yeah, so that would be, I presume, covered under the like the secure boot and other such functionality. So I didn't go into too many details, but yeah, the intention is to have that sort of functionality. I've not heard of DM Verity, but there's certainly an entire, I've got probably about 40 pages of notes of things that are being investigated. The question is, do I envisage upgrading the atomic host and if so, what do you mean by upgrading? Yes, absolutely. The full mechanism of that will be, upgrades between releases and sort of moving is already part of how atomic does a lot of its work, and so the ability to move from one release to the next, and if that fails, roll back, is an integral part of the way atomic works. Well, there will be a minimum level of device and a minimum amount of storage to enable that sort of functionality to happen, and the atomic deltas, well, it will depend on, and it'll depend on the size of the delta and some of that will still be investigated, but the base image is intended to be a few hundred megabytes, so it should be relatively straightforward to do. Stephen? So the question is whether I'm envisaging a universal image that can work on any device. Yes, I'd like to think that, and that's the intention with having the minimal base image and then building the functionality that is consumed, whether it be image-based processing or gateway functionality on top of that within either atomic layers or containerization so that there can be basically a base image that you can use across all sorts of different functionality and then you build layers on top of that, so yeah, that's very much the intention. The question is what's the expected size requirements? At the moment, I have no idea. Probably if, like, I would think probably a few gigabytes, I mean, a minimal base image at the moment is around half a gig or something like that and I intend to be able to slim that down. It then depends on the functionality you want to put on top of that, sorry. Well, a combination of both the base image and the gateway. So the endpoint devices. So there's a number of little Cortex-M series. The question was what are the endpoint devices that you would look at? So I think one of the good ones would be and some of the devices that are being looked at as part of the Leonardo Light Initiative based on ZephaOS and there's a couple of dozen different devices that will run Zepha, I think, like the BBC Micro-Bit will now run Zepha, I believe, and there's a handful of 96 boards, IOT spec devices like the Carbon that will run that have Bluetooth that I intend on being able to use as endpoints to connect into this. Sorry, yes, I think so. But I mean, that's ultimately covered by standard OS tree atomic as per the platform used for containerization and other things as it's being used in Fedora already. So I fully intend on utilizing that functionality that's already been developed as part of OSBS and various other projects within Fedora. I don't see the point in reinventing the web. I think that's something I need to investigate more. This is very early in the game and I have no doubt that we'll start with a base image and have the ability to add bits on top. I envisage with time, we'll probably bundle some of those together and have an image that's shipped out pre-built to put on devices to do functionality. But yeah, exactly how we're going to put all the puzzle pieces together is sort of still in motion.