 Last talk of the Fossum 4017 Distribution Deborah, thank you very much and I would like to introduce Peter Robertson who will talk to us about using Fedora for IoT. Hello everyone, I'm sorry for stopping you from your beer. So I'm going to talk about architecting a secure IoT platform using a generic distribution such as Fedora. So the Internet of Things has the potential to change the world, not necessarily in a good way, and Linux distributions have been around for some time and have a lot of the dealing with security and CVEs and updates and distribution mechanisms and all that sort of fun stuff long-solved and relatively straightforward. And so why can't we use the current knowledge to continue to evolve and improve the IoT to make it a little bit friendlier place for the world as a whole. This is a general overview of an IoT stack. One of these days I'll actually get around to doing this graphic myself because as someone pointed out it has a Cortex-M series which you can't exactly run Fedora on. So what would you use as a base platform for IoT if you were to use it for Fedora? Well, the first technology there is a tech called Atomic or OS Tree. It enables a single snapshot upgrade, snapshot rollback of a distribution in an atomic state. So if you boot a device with an update and it doesn't boot or it doesn't have network connectivity you can run a series of health checks and reset back to the old version. So you should never get into a situation where you have a brick device or an uncontactable device or a device that doesn't have access to all its sensors. You'd obviously need a very good focus on security and multiple architectures. Obviously x86 is a fairly widespread with a bunch of IoT but obviously ARM and more so these days ARM64 is certainly a series of well-known architectures that are deep into the IoT space. And that's basically my role is to build an IoT platform using Fedora as a base as part of my job at Red Hat to help define. We're going to initially focus on a gateway platform both industrial and home and various other use cases and focus on a handful of devices although it will work on pretty much any device that is supported by Fedora. But yeah so in the ARM space we probably support 200, 300 different ARM devices these days but it's a lot of work to be able to polish each and every one of them so we'll focus on the Raspberry Pi 2 and 3 because obviously they're very popular. The solid-run hummingboard edge devices which are the first version of the Leonardo Lite reference platform, the Beaglebone variants because they're quite good for IoT Intel dual platform from an x86 point of view and a pine 64 from an AR64 point of view but it's sort of still a bit up in the air and will evolve it as things happen. Yeah so this is basically an overview of what the gateway will be based on a minimal atomic base image with containers to add functionality and in the F26 cycle we'll focus on some example containers like an MQTT container and also various different networking technologies both wireless and wired such as 80215 for Bluetooth LE and various other open standards. Security security is a very important and poignant point when it comes to IoT and there'll be a focus on things like UEFI or OPTI as part of a secure boot and verification so from the moment the processor boots whether it's using TPMs on x86 or arm trusted firmware and various other technologies like that from the ARM platforms to give us the ability to verify the entire OS through the boot process to make sure it hasn't been compromised. Dependency minimization there's not generally no real need to ship three or four TLS stacks for example if you can ship less you've got less sort of coverage and less chance of major CVEs and compromise and things like Sec Comp and SE Linux, toolchain related functionality, sandboxing, various system D functionalities and the kernel self-protection project there's a bunch of different sort of initiatives there that are helping secure and reduce so and even eliminate entire types of sort of compromise and then obviously with containers you can namespace them and isolate them which means each sort of individual security services running is in an isolated context with either access control or proxy or what have you to be able to access different parts of the network or different components different network isolation technologies device isolation and policy routing on the gateway level to ensure that if you've got an entire class of device that you don't want to connect to the internet that you can identify whether it be via MAC address or OS fingerprinting and things like that you can set up policy routes to either null route them or isolate them to ensure that you know that if you're acting as the gateway that these devices can't become part of a botnet or other such network support focus on open standards so things like 802.15.4 rather than proprietary technology such as ZigBee and other sort of lock-in technologies where you've got a license or patent or what have you. Six low-pan as an IPA protocol and various other and things like older technology such as RS485 and someone was asking me about Modbus the other day can support for controller area networks etc. So this is a sort of general typical wireless IoT topology as a sort of just a general overview and so this will be the sort of initial focus point from my point of view with Fedora IoT. Some sample containers, open thread and other networking services, MQTT and various other messaging stacks, caching modules and various middleware and then a selection of possible IoT specific stacks. There's been a couple of people that have been slowly packaging up Node-RED and each time a new release comes out they add a few hundred extra dependencies. I'm fairly certain they now depend on over 50% of the Node.js sort of repository stack which is I believe one of the largest repositories in terms of pure numbers of libraries on the internet. So it's a very interesting project but it's vast in terms of I think they've already packaged up something like 500 different Node.js dependencies and they're still only a smaller way there so we may look and see if we can just pull that in and run it container style in the short term while we get all of that done. Plus there's some interesting IoT projects coming out of the Apache project such as Kura and Hono and similarly related projects. Solata is an Intel IoT project which is already packaged up in Fedora and there's a number of other ones that people have shown interest in. So are we just doing a gateway? Initially yes but it's just a starting point as a means of doing a proof of concept and driving focus. I have a tendency that if I'm not focused on something in particular I have lots and lots of ideas and I'll deliver little bits of lots and lots of ideas and we won't end up with something that's particularly useful. It gives us a good starting base to build both the different options but also the community around and it'll be a combination of industrial IoT and home because there's a lot of people interested in the home side of things but obviously Red Hat from a commercial point of view is more focused on industrial and medical and other such sort of industry gateways and it'll be initially a proof of concept as a testing platform nothing's that in stone it will evolve and change as necessary and as you know people discover things. What are the options? Imaging stacks I've had a bunch of interest around different sort of embedded devices with cameras used for whether it be security and detection of movement or other sort of OCR style recognition or image recognition and various other stacks like that and there's some other interesting projects where we're having some discussions with there's an AI platform called Mycroft which is open source and they're very interested in working with us to do some IoT related stuff and numerous to numerous many ideas to mention like I come up with a different idea every other day so so yes in summary I feel Atomic is the right way to go in terms of updateable secure devices, multiple architecture support from the outset, initial reference devices with focus and a base platform and gateway functionality to start with. Any questions? So you talked about dependency reduction so you wouldn't have as you said too many libraries so that involves not using the standard Fedora builds but you're using it in a slightly different way to get a minimized kind of pile is that the idea? So to repeat the question for those that might be watching online does dependency minimization result in different Fedora packages or forks of the package no it doesn't we'll be working with the maintainers of those packages to ensure that that's the case and there's already other initiatives as part of yet the intention is to be a hundred percent within Fedora we're still in the Fedora 26 timeframe it'll probably be part of the Fedora playground branding but the intention is to have it eventually as a fully accepted similar to work workstation and server and cloud anatomic the different projects there the intention or hope from the discussions that I've had with the FPL is basically to sort of have it a fully core part of Fedora or at least potentially you mentioned that you have a specific set of reference devices the question is around the reference device support and specific hardware support within those devices so by default I think all of those reference well most of those reference devices either have wireless and bluetooth or options of so like the Raspberry Pi 3 has both wireless and bluetooth the humming board has options of wireless and bluetooth the Beagle bone now has a couple of different models that come with both wireless and bluetooth the vast majority of them already have can support actual onboard can controllers except for maybe the Intel dual but at least all the so the IMX6 has can the Raspberry Pi doesn't have can so it'll depend a little bit on the device and depend a little bit on the matrix of what we decide to support initially and we'll adjust devices and support matrix as we go yeah correct yeah so in the case of like 802 15 for there's two or three devices that come with it on board but some of the different controllers are better or worse supported upstream and there's a couple of USB ones that are very well supported which is what so so yeah so so it initially it'll probably be like I personally have interest in the 802 802 15 for stuff and I have a bunch of different devices at home with it on board and then but we will probably say that like initially until there's more hardware shipping that will you know recommend the USB um so the question is around securing SSL or TLS based services outbound to the internet it's not explicitly mentioned on the slide deck but it's essentially service by service so in the case of MQTT it supports that out of the box depending on which broker you're using the underlying base platform other than pulling down like the updates won't have any outbound services to note and then each one will depend on the container that's running on does that answer your question Dennis on your picture there was like a remarkable number of devices connected and that raises the question what's about the management approach to that monitoring approach to that is there something specific which at the cost so the question is about the management of vast amounts of devices at the moment atomic doesn't have a general story there but it is also being worked on as part of that team so the intention is there to consume their standard mechanisms of dealing with it as it's developed it's certainly something that's on my roadmap management of devices managers of devices connected to the gateway control of those devices centralized policies centralized updates and yeah it's probably something that I should put on the slide deck um but it's certainly something that's like in the future yep if you look at the history of open WRT or lead as it's called nowadays it is there anything like lessons learned from your position are you interested in taking another approach in some way is there any conceptual difference um so the question is looking at projects like Lady Open WRT whether there's intention to do lessons learned from those sort of projects are the problems you've identified there and are you taking another approach to tackle them um possibly on some of some of this is still research some of this is um this is the way we're doing it in fedora there's certainly um different approaches that we can look at um there are I mean projects like Open WRT have been sometimes effective at dealing with things like security updates and sometimes not so effective due to um political and social issues within the project like they're quite often a long way between releases so there's absolutely things to learn and there's absolutely ways we can change things to make it better and the intention sort of there is to get something working and then evolve as we go that's part of the atomic functionality and true but I don't think we've got enough time to do that OS tree is a system that you can feed in rpm's or just binaries and it makes a snatch up that stores things in a kit like manner and so it enables you to you have different wraps and you can just boot the previous wrap it's like it's one of the command line options you set the fast system the points at the wrap and so the atomic raw back is that you still have the previous version installed and you just put into that as opposed to yeah so it's like like the update is like a delta between the two and you just yes yeah and I mean that's not that's not rpm specific there are projects that are using it so like endless mobile is using it um on a debbie and based distribution for their OS as well the question is could you use open shift to manage some of that stuff potentially I mean open shift is based on kubernetes and kubernetes is sort of like cluster technology so you could probably use applications running on an open shift platform um as a management thing but open shift itself I'm not sure would be at least out of the box as it stands now necessarily useful but certainly like for iot back end platforms open shift is like the perfect candidate for running those side of things but not on not so much on the actual device any more questions excellent I'll let you all go and get beer