OK, so hello and welcome to my presentation. My name is Kristina Quest. At daytime, I'm a normal embedded systems developer, but at nighttime or something, I like playing IT security, CTFs, or IT security war games, or go to security conferences to find out how to hack devices. And I felt like talking to my colleagues, many of my colleagues didn't imagine how the attacker thinks, like what the attack vectors are, what the view of an attacker is. And I wanted to bring this to a developer conference, this knowledge. So this is my agenda. In short, I will talk about software and hardware attacks and tell you some example attack stories I've seen in the last years. And let's start with what is IoT? So IoT were traditionally more analog devices like your light bulb or your garage opener or your baby monitor, which are now connected to a network. So often those devices are rather power constrained and memory constrained, and oftentimes less secured because you don't care about security. Well, somebody hacked my IoT light bulb. Why should I care? One of the reasons we saw in 2016, for example, there was this Mirai botnet, which was mainly created out of IoT devices, which now started to attack a distributed denial or service attack on Dundee NAS, so that DNS requests to some major websites like Netflix or Spotify or Airbnb failed. And the thing is those devices are still out there. This botnet still exists, and we don't know how many devices there are. So your device could be one of the one attacking. And the problem is not just you cannot pinpoint, like this manufacturer is to be held responsible because there's a supply chain which is rather large. We have CPCB vendor. Then we have the BSP, the broad support package vendors like Marvel and Broadcom, which create the SDK for you to work on. Then there's the ODM, the original device manufacturer, which puts his own SDK on top of it. Then a retailer, which puts his name on this whole package. And the OM, the original equipment manufacturer. So you have so many steps. You have so many hands touching the code, which introduce bugs as well. And also an embedded device has a large attack surface. It can be connected over a wireless connection. The firmware process can take place over a wireless connection, for example. It can provide a web server or mobile applications. So you have many places where you can actually try to attack. So let's talk about software. So what does the attacker do? First, he does the same that a normal embedded systems developer put us when he gets a device and no documentation. He basically tries to understand how this thing works. He tries to reverse engineer. He inspects the components, the data sheets, looks at the firmware update process, and looks whether he can tamper with that a bit. He looks at the flash content, which is already on the device. So if the firmware is some well-known and well-documented architecture, like ARM or PowerPC or MIPS, is rather an easier task. Then you have ASICs, which are, let's say, average easy. And then the most complicated are FPGAs, because the FPGA is just hardware. So the vendor can have put any program, any bit stream on it. And it's hard to figure out what he actually put on it. And the more PCB layers your device, your board has, the more complicated it gets to analyze. And then the attacker, he would tamper with the firmware update process. He would try to rewrite some parts of the memory. Also use the JTAG channel, for example, or other debug channels to have a feedback and establish a communication channel over serial or JTAG to see what kind of effects his changes have. So if you want to analyze the software running on this board, where do you get this firmware? In most cases, you can dump it from the flash memory, or otherwise you can look around whether you can find the firmware on the FTP server of the manufacturer. There are also FTP index sites where you can search. Some devices come with CDs or DVDs where you can search for the firmware. Or a very good attack vector is looking at ViyaShark. So if the firmware update process takes place over an unencrypted connection without TLS, then you can kind of dump the firmware out of the data which was transmitted. Or if it's not just the blob, you can analyze the firmware and look at the firmware update routine and see how or which part of the binary blob you just dumped is mapped in memory later. Furthermore, in firmware, you sometimes find code or strings. And you can search on the known websites like code.google.com or sourceforge.net or something. But you can recognize some open source software which was just taken from a Chinese manufacturer and put into this box. Then, yeah, you can decompile, you can recompile, you can change some values. You can fast the device, so send random data to it and see whether it crushes. And for example, if the firmware is not stripped, so it has some debug symbols in it or if you find human readable strings in it, it's easier. But once you get the hang of it, if you're really good at reversing, it doesn't keep you from reversing this anyways. So what kind of software do we use? One of them we see on the top right on the slide. This is a screenshot which I took from IDA. So IDA is like more or less the standard, which is used nowadays by reversers. It has a nice GUI and lets you look at the code flow. Then if you are more into open source command line tools, there's Rodara 2, which is being developed. And I heard a new up-and-coming as binary ninja, but I didn't try it out yet. And then for finding bugs in your software, you can use Floorfinder or the Metasploit framework. Metasploit is more, it's like a set or a database of exploits which you can just launch on a target, even if it's remote. And it will automatically perform those attacks. Then there are some tools for firmware analysis, like Firmworker. Firmworker, it uses Spinwork, which will go through a binary blob and it will be searching for headers, for example, which it can recognize. And then it will print you the files which is possibly found in this binary blob and you can extract them. It uses CPU-REC to recognize the architecture the firmware is written for. And it has also the firmware analysis toolkit or a rather academic project, the effects, the firmware analysis and comparison tool. And if your IoT device exposes a web server, you can use the usual tools like SQLMap to find SQL injections or SSLies in order to see whether you configured your server right for SSL or Go Buster. For an extensive list, I recommend you to check out the OWASP website, the Open Web Application Security Project which kind of has more extensive knowledge and put it on their list. And for interfacing with your device, you would use the usual ones, for example, GDB and Open OCD. So in terms of hardware, there are three kinds of attacks. You can have non-invasive attacks, you can have semi-invasive attacks and fully invasive attacks. So for non-invasive attacks, you don't have a direct chip access. You only have the external signals and you try to work with those. For example, you can search for the UART or JTAG and try to interface with your device and get control over it in this manner. Or if the right protection, security fuse is not enabled, you can change the boot loader, you can patch it and let it load your own firmware. You can do hardware fuzzing. Like I would estimate that one out of 10 hardware or the creatures, or do you know what fuzzing is? Fuzzing is you're sending random data to your hardware and see whether it crashes. And I guess like one out of 10 crashes, you can actually, you can create an exploit out of that. And then there are other side channel attacks like timing attacks. For example, if you have a computation, which depends on the value of the secret data. For example, you have your secret and you have the user input and you are comparing the first character and do a break out of your while loop if it's not correct than the second character and so on. So it means like the more characters you have right as an attacker, the more time it will take for the device to respond. And so you can bootforce one character after another in this manner. Also cache miss and cache hit times have a huge timing difference. So which is also used for example, in Spectrum Meta in those cache timing attacks. So you can always find a pattern in those different timing differences. So basically in this kind of attack, you trace instructions, you access register values, you can modify media memory content or extract code and data, but you're not actually physically opening up to chip. Yeah, there are other non-resif attacks like side channel attacks. For example, hardware glitching is when you apply a voltage which is too high or too low or higher or lower than what your chip originally expected. And you hope for funny effects or that your chip calculates any manner which is not expected and makes a mistake and you can use that to hack it or get more information about the secret. There's also glitching attacks where it can alter the clock period during the execution of a program and have a similar effect. Then there's power analysis. If the power consumption of your device depends on the secret data which is computed at that moment, you can get information from that and I will be presenting an attack on that later. There's simple power analysis where you're directly looking at the power traces, but there's also differential power analysis where you kind of correlate the power traces you took and if your correlation criterion is right, you get a peak in your There's also AM radiation, channel attacks or acoustic channels. So all the side effects of a computation you can try to find a pattern and get more information about the secret. Then there are semi-invasive attacks where you actually decap a package and then you can shine infrared light onto this chip and with a certain probability, a gate which switches will emit a photon. In this manner, you can find a location for your attack. For example, in the picture we saw before, here you see emitted photon from your chips and you can assume that the brighter areas are gates which are switching a lot. For example, the brightest spot you see on the left would be the clock or up there, for example, memory address accesses. But the problem with laser glitching is you have an unknown timing. It's more or less trial and error because you're shooting this laser on a big area and you hope that the chip does an error in his calculation. So if semi-invasive attacks didn't work, then you can try fully invasive attacks which require much more effort but you have a 100% success rate. So you can use a focus ion beam to remove or put material on the chip and, for example, create micro probing pads. So basically you can analyze any pad or any signal in your chip you want but obviously it costs much more, it takes more time and knowledge to do that. But fully invasive attacks are mainly used if you have countermeasures put in place in hardware and you want to circumvent it. So mainly for the non-invasive attacks, those are the tools which are used. The oscilloscope for just looking at logic signals or a logic analyzer if you want to analyze UR, for example. Then for JTEC there are good open source alternatives as well. For example, the GoodFed created by Teras Goodspeed or I've heard many good things about the Blackmagic probe. Then for the side channel attacks I mentioned like power glitching and so on. Two years ago you had to make your own set up using an FPGA because that was the only thing which would get the timing right. But nowadays you can take the chip whisperer to do glitching and power loss for you out of the box. You can use the FaceDancer which is based on the GoodFed to do some whole site Python scripting and to fast test your USB device drivers. And if you want to do SDR, software defined radio, there are the HackRF and actually more devices which I didn't list here that you can use. The HackRF is a great Scott Gadget device which can send and receive from one megahertz to six gigahertz. So let's go to some real world attacks. This was theory, now let's go to practice. So there was this nice video which I really recommend to you which is called Hack All Things, 20 devices and 45 minutes where they presented how they, yeah, owned 20 devices really fast in a very entertaining manner. So one of the common attacks was just connecting to UART and often time you just put into a console where you have no password or a password which you can guess easily and you can replace the image device that's running using this console. Sometimes the UART is populated, sometimes it's not, but even if it's not populated, you can easily just put your own connector on it, solder it on the board. What else did it was, for example, change some parameters of the kernel command line. Like if for example, like when you block yourself out of your computer, you boot it up and you put in it equals bin s h into the kernel command line and would directly boot up into a shell. And from here you can, yeah, mount devices, you can replace the image and put your own firmware. Also often bootloaders, they try to execute a preconfigured script and you can just, if you have access to the memory, you can just put a script with the same name instead of that and it will boot up with your firmware. One attack which if those two don't work, you can try to short the pins of the NAND which contains the bootloader and maybe one out of 10 times it will boot up into a corrupted U-boot environment where you have control and you can again replace a firmware. Because the thing for the attackers, you just have to get it right one out of 100 times and you hacked your device. As a defender you actually have to get it right 100 times or your device is corrupted. Sometimes they analyze the firmware and they found out coded or base 64 encoded user names and passwords in the binary. Yeah, base 64 is not encryption, it's just encoding. It's basically easy to decipher. Also brute forcing worked on some devices because many manufacturers would just use brute and manufacturer name as a password so you can easily get in. What else? They had access to an EMC or they wrote a SUID binary on the EMC which uses a similar protocol to whatever an SD card reader is using and afterwards they executed the SUID binary on the device and got root that way. Other devices, they took user input unsanitized and put it into a system function for example. And obviously if you put Zemicolon reboot Zemicolon your device will reboot and you can put any system command or batch command you want in that. Often WEP or Wi-Fi password fields of the configuration page were not sanitized. They would just take whatever you give to it or network folder names who would put any batch commands into a network folder name, right? They are trustworthy. Or URL parameters. Sometimes they could just execute a command by just passing it to an URL. Also if the firmware update takes place over an encrypted channel, for example, just plain HTTP or FTP, it can be intercepted. They can put a man in the middle attack in place so you send your firmware, I modify it and I send it further to the device you want to update and well, I control the device now. Then this one was a rather academic attack. They attacked a PLC, a programmable logic controller which is used a lot in industry and they tried to downgrade to an older firmware version but it didn't work, it didn't let them do that. They searched for JTAG or something similar, they didn't find it on the board. They tried injecting code on the web page of the manufacturer to do a firmware update and put their firmware on this device but it didn't work. They assumed that maybe the firmware was, there was a checksum over the firmware or the firmware was signed so that's why it was not taken. So they ended up actually modifying the board. So the flash chip which contained the first stage boot loader was right protected using a pin and they soldered this pin and could alter any data on this flash chip. Then there was an attack on an electronic safe lock by Plur which was presented at DEF CON 24. So what he had was a metal box and outside of this metal box he would have a keypad, a buzzer and a battery and inside behind steel doors there was a lock and MCU and E-prom and a bolt motor. So between those two inside and outside there was just one hole to pass the wires through. And the good thing was that inside the MCU and the E-prom they were connected by a direct line which was connected to a pull-up. So every time the device would read a zero from the E-prom the voltage drop over the pull-up would be higher so he could record a higher current taken from the battery. So he could look at the power trace directly and say okay this one is a zero, this one is a one. So how can you mitigate this kind of attack? Yeah so he would put any combination of numbers in there. He would read on the power trace the real secrets which was read out from the E-prom and he could put in that real secret afterwards. And you can protect yourself against those kind of attack by for example storing the hash instead of the real secret. So the attacker can just see the hash but he doesn't possibly know how the hash is calculated. And the second attack he did so this easy attack didn't work on this block. So he did timing attack, the one I described before where you have this Y loop where you compare the real secret character to the user input one by one and if there's one mismatch between characters encountered you just break out of the loop. So you see it in the power trace the more characters he got right the more digits he entered were correct the longer it took for the lock to respond. The problem in this case was after five tries he got locked out for 10 minutes. So brute forcing is not so easy if you have to wait 10 minutes between the tries. But he got lucky because normally in the E-prom if you reset it, it would be reset to zero X F F so everything is one. But in this case the E-prom, in this case the E-prom was an STM 8S. So when you reset it, it was reset to zero. So he had this small time window of 500 microseconds after and he counted the number of tries he performed was stored in E-prom as well. So in order to write a new counter value in the E-prom the counter is set to zero before it's initialized with a new value. So he had a 500 microseconds timeframe after the write starts where this counter would be at zero. And if he applied the brownout voltage exactly at this moment in time he would have gained infant amount of tries because the counter would be reset to zero. And how can you mitigate against this attack? You can do constant time comparisons. So basically you check all the values and then you give back whether the key code entered was correct or not or using hash secret.  So another question is how do you protect against that? Well, you can start with protecting against buffer overflows, stack overflows, heap overflows by comparing rigorously the buffer bounds. Don't use the unknown unsafe functions like gets or string compare. Use the saver functions like f, get, s or string and compare which takes into account the buffer size. Then many compilers have secure compiler flex where you can disable or enable the nx bit of the stack. So the stack becomes non executable. You can activate the stack protection and so on. Also build systems like Yocto and build route will have flex for that or you can enable it in your, there are some secure options in the kernel which you can enable via menu config. Then if your device has a web server, you should protect against SQL injections or cross-site scripting. Instead of black listing commands, you should white list your commands because you should never underestimate the creativity of an attacker and never directly take user input and put it in system or something. Always sanitize, always validate input coming from the user. Don't trust user input ever. So if you do firmware updates, always do it over a secure channel. Always do it over a TLS because otherwise, yeah, you can just man the middle of this update. Don't do your own crypto. There are so many libraries which you can use where many eyes have looked over and which are tested by many people. Don't reinvent your crypto reel. Maybe also implement an anti-rollback protection because often older firmwares have known bugs and a hacker could just reinstall an older version and apply the bugs, which were bugs two years ago, five years ago. Don't have hard-coded secrets in your firmware. Always don't put user names and passwords and so on as hard-coded secrets into your firmware or in non-protected storage. Like for example, EEPROM or flash is not a safe storage. You should not put your keys in there. And if your platform has a trusted execution environment like trust on for ARM or SGX for Intel, you should try to use that. Do identity management have different user, have different accounts for web management and for remote console access? Don't put tokens and IDs and cookies into the URL because the attacker can just sniff it and replay it. Especially don't use tokens which can easily be guessed like sequential numbers one, two, three is not a secure token or current time is not a secure token. You can guess that. Use secure passwords for logins for the URL for example. And in the best case, you would have an individual secret for each device to deliver because otherwise one device gets hacked. All your devices are compromised. If you have one password per device, it's only this one. Then how many of us have unused language or shell interpreters in our devices? How many bash and dash and ash and ZSH we have in this devices which we never use or libraries? The more attack surface an attacker has, the more tools he will find to exploit the device. So reducing the attack surface is one of the protections against hacking. Also disable ancient legacy protocols like FTP and Telnet. You would be surprised how many devices are out there which I still use that. Remove debugging interfaces because the hacker can also enter from there. And also manufacturers often have those management interfaces where they can do customer support where they have either and very easily put possible password or no password at all. And oftentimes those interfaces come with a root privilege. Yeah, if possible, tag third party code and SDKs. I don't know whether it's always possible. There are tools you can use for that. Keep your kernel, your framework, your libraries up to date. For example, using a package manager and check whether the tools you use are vulnerable. There are many vulnerability databases and you just enter the version of the tool you're using and see whether it has known vulnerabilities. Or you use one of the tools recommended by OWASP in order to check third party code or components or do some static analysis on it and it will tell you where there might be possible bugs. And do thread modeling. Like get in the shoes of an attacker and think how, through which port can he enter? Like what are the possible vulnerable parts of your device? And once your device gets compromised, how do you treat with it? How do you contain the damage which is done? So if you didn't take in very anything from this lecture, maybe those points. So the main attack vectors for devices are crypto or the web interface or old firmware which still has bugs from 2000 or doing a firmware update process over an unencrypted channel or having the attacks passwords in your binary or storing secrets in an unprotected place. And so maybe it's a good idea to integrate security tests already in your continuous integration or your development cycle instead of in the end after your product is finished and ready to be shipped to find some security vulnerabilities and not have the time to fix it afterwards. And also there's basically not a way of how you can really secure your system 100%. It just makes it harder for the attacker or more so that you would have to invest more cost or more time in order to hack your device but it's never impossible. You just try to get the bar as high as possible so basically that he will attack the other manufacturer not you. So do you have any, thank you for listening to me renting and do you have any questions? So you recommended each device having their own secret for the keys and such and I agree that's a great idea. Do you have any suggestions on tools to help manage like thousands or tens of thousands of keys across out there? I didn't try out anything but maybe mentor since they have tools to do firmware update processes securely maybe they have a solution for that but I don't know, you would have to talk to them. Yeah, I know more of the attacker side than actually how to protect it because it's really hard to protect. Thank you.


Hello everyone. Thank you for joining this talk. My name is Ricardo. I'm a software engineer at Colabora and today I'm going to talk about fuzzing the Linux kernel and how to use this color to fuzz a Linux driver. So let's get started. So before we begin let me give you a brief overview of what the talk will be about in more detail. First of all I'm going to start by giving a short introduction to fuzzing in general, what it is and how it works and why it is a valuable tool in the Linux for Linux kernel development. Then I'll introduce this color for those of you who aren't familiar with it already. I'll show you how it works, what are its key features and how to configure it. And once we are familiar with this color I'm going to show you how to use it to target a specific part of the kernel. In this case a particular driver, a unit dedicated hardware board as a test machine. And finally I'm going to show you how to get results from this color and how to use them. Software testing is a very large area and over time it's becoming even more complex and developed which makes sense because as you may know most of the time in software development is spent in maintenance and debugging. And testing is a way to help us reduce both the number of bugs and the time we spend looking for them and trying to fix them. Now there are many approaches to software testing and different techniques with different goals. In this talk I'm mostly interested in using testing as a way to find bugs. In this regard there are two main methods or at least two of the most well known and most used which are unit testing and on the other hand fastening. Most people is already familiar with unit testing as part of the software development process. Unit tests try to check there are certain piece of code behaves as documented so developers and test writers write manually tests to make use of a function interface and try to cover the documented functionality including corner cases and edge cases in function input. And if done correctly over time this test will help catch bugs when they are introduced. For example when a certain feature no longer works as documented or when a code error is introduced in the path covered by the test. Fasting on the other hand is a more automated process and doesn't require you to write any kind of tests manually. What a fastener does is instead is to generate random or semi random sequences of instructions as programs including also randomized data inputs to try to trigger certain bugs that went unnoticed in the first place. So the idea is to produce both data inputs and runtime flows that may be similar to the one found in a real use case. And beyond that that is to also create patterns that trigger bugs in code parts that aren't normally executed in a normal use case but they are there and had to be found. In summary a faster will try to come up with non-conventional data inputs and interactions that are hard to get in a manually written test. When passing the Linux kernel the test surface is the system call API which is the part that is accessible from user space. So a kernel faster will generate sequences of system calls with semi random or data inputs to try to crush the kernel and then it tries to be aware of that when that happens. Now there are many types of buzzers and not all of them use the same strategies and the same techniques but in order to make passing effective in a target as big and complex as the Linux kernel there are at least some number of key features that we want in order to make the passing process more effective. Because otherwise we would be relying only in pure luck so in order to make the passing process more directed and more informed we want at least these series of features which is first of all the ability to check code coverage during the test so that the faster can do a directed search instead of a random one. We also want some way of getting information about the source code so that the faster can generate test programs more efficiently. It's also good to have the capacity to generate data inputs and code sequences in a random but smart way because we want the two things here. We don't want something that looks like a manually reading test but we don't want a completely random test either and of course having a good report generation it's also important because when the faster finds a bug it's good to know that there's a bug but we would also like to have some information about how to reproduce it. Now of all the kernel clusters that are available CISColor is one of the most recent efforts and it's probably the most successful today so we're going to see how it works and how to use it to discover bugs in kernel code. CISColor appeared in 2016 it was written by Dimitri Vukov and it has become one of the most important tools to make the kernel more robust and more secure. It's a coverage guided fuzzer we're going to see what that means and it makes use of many kernel debugging features to make the fuzzing process more efficient. Now what does coverage guided mean? Well CISColor any other fuzzer will generate sequences of instructions as program as test programs in this case the instructions will be mostly system calls but this generation process is not completely random instead what it does is to keep track of the amount of kernel code that ran as a result of running each of these generated programs and use that information to guide the code generation process. The idea is to cover as much kernel code as possible so when CISColor mutates its test corpus we're going to see in a while how that works. Code coverage is one of the most important aspects of it this means that a program that covers new kernel code has a greater mutation potential. Now in order to improve the fuzzing process CISColor uses a few kernel debugging features the most important one is K-Cov. K-Cov is something you can enable when you are compiling the kernel when you are building it and it's key to CISColor. What it does when it's enabled is to make the compiler introduce instrumentation code all over the kernel code so that the kernel can keep track of the curve of the code coverage and share this information with user space. Then CISColor will retrieve this information and check the code coverage when it runs one of its test programs to see how effective it was. Another feature used by CISColor are kernel sanitizers such as KSM, KT-SAM, KC-SAM etc. when available of course. These sanitizers offer runtime detection of certain error conditions such as out-of-bounds memory access or null pointer the reference or data races and they are also based in in compile time instrumentation sorry and the combination of an automated tool such as a fuzzer that generates programs and runs them automatically with these sanitizers is already a very good tool to detect some bugs some very simple bugs which are not tied to the application logic but are simply programming errors such as null pointer the reference and this combination is able to discover new bugs automatically in a pretty simple way without barely any human interaction at all. Additionally CISColor can also use the kernel fault injector such as failslab or faultfutex to make the kernel introduce control faults during a test and what CISColor does is to selectively enable these fault injectors so that it covers even more code that normally would be executed only when one of these faults happened naturally so normally there are very very little chances of getting to these deep code checking error conditions and such and fault injectors made code coverage of these blocks much easier. Now we're going to take a look at the architecture of CISColor in a global way. The slide shows a diagram of the architecture and you can see it's divided in three agents which are CIS manager. CIS manager runs in the host and it starts and monitor and restarts the targets which may be virtual machines instances or in this case a Linux system running on a dedicated board. So it starts the CISCfazer processes in the targets and is responsible for the persistent storage of both crash reports and the test corpus. Then CISfazer runs inside the test target which is a completely separate environment from the host where CIS manager runs. It keeps a communication channel between two sorry two CIS managers so even though they run in separate environments they communicate between each other and CISfazer guides the fuzzing process and sends whatever input it created that trigger new code that cover new code. It sends that back to CIS manager for storage and finally CIS executor which also runs in the target machine whatever it is. It processes the test program created by CIS executor and so it accepts the program runs it and sends the results back to CISfazer. The programs here are simply C++ programs generated by CISfazer and they are statically built and standalone programs. CIS color uses a user defined high-level description of the available system calls described in a domain specific language called CISlang. These definitions, these information lets CIS color generate more thoughtful code using reasonable parameters and usage patterns instead of simply generating random sequences. So for example the open system call for this system call it makes sense to use a path name parameter looks like our actual file path because if we simply relied on input in random strings for this parameter it could take forever for the generator to create a string that by pure lack looks like a file path. So most of the time the system call would simply bail out when checking this parameter and we'd never get to reach the interesting parts of the code of the system call. So here's an example of definitions in CISlang of open, close and read. You can you can see that the file parameter doesn't take a string as an input. Instead it takes a file name data type which is defined as a string with path lag formatting, a string that looks like a correct file path. And also the the system call flags are defined for the same reason to avoid simply using random integers here which would cause the error or the parameter validation code in the system calls to bail out immediately. However the the fuzzer would will still use some random numbers in these kind of parameters especially it will try to input some carefully crafted integers to test the edge cases for these kind of parameters because it it can trigger some bugs it's interesting to do so but most of the time it will find more interesting results by using the information provided by the user here. Now assuming that we have a test setup that is ready to be used by CIScolor for example a virtual machine image. Oh by the way this is pretty well documented in the CIScolor documentation. Now to start a test we have to create a configuration file that describes the target environment and the system calls that we want to enable or disable for this test. Here's an example in the slide and once everything is in place we can start CIScolor by running CISmanager in the host and pointing into the configuration file that we just wrote. Once CIScolor starts running it will take control of the target machine and it will boot it will configure it and runs this fuzzer in it keeping a communication channel between CISmanager and CISfuzzer. After that it will start growing the test corpus generating test programs and running them and keeping track of the amount of kernel code covered as well as the possible crashes when they appear. The evolution of the test corpus is influenced by internal heuristics and also by the priority given to each of the elements that's already in the corpus. So initially the test corpus may contain all the primitive instructions very simple system calls and over time as the test programs go uncovering new kernel code the test corpus is mutated taking these programs as bases for new ones. Finally I should also mention that CIScolor starts a local web server with a web GUI that's shown in the slide where you can check the current test corpus the system calls that are enabled the current code coverage and also the number of crashes and their reports. So now that we have a general idea about CIScolor we're going to see how to use it for a specific use case which is fuzzing a driver in a dedicated hardware board. Now there are many requirements on the type of machine that we can use as long as it can run Linux and that it has a network link with the host because the host will open an SSH session to the target machine we can use whatever we want so I'm going to use a rubby 4 board because the driver that I want to fuzz which is the hand through video for Linux 2 driver runs on that hardware. So first of all we have to prepare the runtime environment for CIScolor because obviously CIScolor expects the target machine to behave in a certain way, long way for it. So the CIScolor distribution already includes some tools to make this process automatic and to generate file system images for different types of targets. The create image script in the tools directory can be used to create a generic file system image that is suitable for CIScolor to use and also of course the kernel should be also generated with at least a set of debug options enabled which is this is all well documented in the CIScolor documentation and you can see that at least it enables and configures kcuff and one of the sanitizers here kasun as well as you know you can enable any other sanitizer that it's available in the board architecture or on your target machine that you want to enable for additional checks. Of course you also need to build all the necessary modules. In this case since we're interested in the hand through video for Linux 2 driver I also enabled it and then you can bring up your board using the kernel and the rule file system provided that you regenerate it and my personal recommendation is to configure the boot loader so that it can boot the kernel from tftp and mount a root file system via NFS because of I don't know you know I like to avoid relying on an sd card because of the potential where after long test sessions you know these kind of targets will probably stay in a laboratory running 24-7-4 months so you want to avoid using non-volatile media that is not too robust. Finally we have to change some options of the configuration file we rolled before to suit it to our test target which is the Rockpy 4 board. Specifically note that the type option is isolated which means that it's going to run in a dedicated board elsewhere not in a virtual machine or anything like that and in the vn section which is still called vn our target now is the IP of the board in our setup okay so now that we know how this color works in general terms we're going to see how to target the flossing process and how to make it more specific to a concrete part of the kernel which is the in this case the Hunchrow driver because unless we enable only and specifically the system calls that we want to test in the configuration file and so before this color we'll try to generate programs using every system call that it knows about that means every system call that is described in in syslang and this is not what we want because we don't want to fuzz the kernel in general in our world we want to spend most of the time fuzzing one particular part of the kernel our driver so the first thing we need to do is to make sure that syscolor knows about the interface for our driver and that means refining and improving the description of system calls now the collection of system calls descriptions in syscolor is something that is a work in progress and it's always evolving so this means that there will be some parts of the system call API which are described in more detail than others in syscolor for example the descriptions for video for linux 2 drivers were created a long time ago and they are not complete furthermore a video for linux 2 drivers have a notoriously complex and big user interface and it's always constantly changing so the descriptions may be out of date and if we use a recent driver it will most likely use newer operations and flags that aren't maybe described yet so the first step would be to make sure that our driver interface is properly supported in syscolor that means including the necessary new syscalls and flags described in syslang so that syscolor knows about them and can generate code that use them in this slide there is a fragment a very simple example of how you can define new system calls in this case 400 as you can see there are some things that are different from the normal open-net descriptions in this case there are some parameters that are fixed and there's a specific device file name which makes the test process use that path name directly instead of trying to use whatever randomly generated file name now let's talk about device access most driver interactions in linux involve opening a device file and working on the descriptor return by open the problem with this approach when it comes to testing is that a certain device won't always be accessible through the same device file name this is something that will probably vary between setups syscolor doesn't have any knowledge about the devices in your machine so it makes a best-of-fort approach by describing system calls using pattern matching to generate file name strings so for beautiful linux2 drivers for example you may find something like that long line in the slide which as you can see tries to open slash the slash video hash and that hash stands for any number so that system call which is actually a pseudo system call we'll talk about that later we'll try to generate open system calls to any kind of file name that starts with slash the slash video and then a number so maybe it will start targeting device file names that aren't really in your system so again a lot of time will be spent doing nothing trying to open something that don't exist and it would be much faster if we could restrict the open system call to our particular driver so our way to do this is to use some udev rules so that udev will create normal file name for the driver that we want so this way we can always be sure that we can reach our driver through the same device file name and we can add these in the box in the slide something along these lines to the create image script that we saw before in the tools folder to automate the process during image creation there's one more thing that we can do to make the fasting process more specific to our driver and this has to do with pseudo system calls now please take into consideration that pseudo system calls well incorporating new pseudo system calls to system color is discouraged because it makes the core system call bigger and why it makes it could make make sense for pseudo system calls that are general and that can be useful for many users in this case which is something that's very specific for one driver it's totally discouraged but still I think it's good to sorry I think it's good to show how they work and how it can be used so as we saw in the previous slide system call descriptions in sys lang don't need to be exclusively system calls but they also can be pseudo sys calls pseudo sys call is simply a function a block of code implemented internally in sys color so when the code generation process picks up one system call and decides to use it for a test program it simply outputs that call it's just an instruction and whatever instructions are needed to generate the input data and that's it but when it decides to use a pseudo sys call what it does is to take the whole block of code and output it in the test program using whatever parameters are needed in any case so there are some applications of this which are quite important for fastened drivers the first one is that this is a way of generating a static chunk of code that won't be reordered and won't change like a known sequence of instructions that will always run in the same way and this can be useful for preparing a setup for a part of the test or to run an operation that it's made of many system calls that need to be called in a particular sequence and it's also useful to generating input data in a controlled way or even more useful in a programmatic way beautiful Linux 2 drivers are a good target for these kind of things because most of the operations in these drivers involve calling a big long number of system calls in a proper order of execution and some of them depend on the format and the contents of the input data so leaving all of that to a random process will make it very hard for the passing process to converge to a valid input that will reach the inner parts of the driver code so now that we have six color running after some time if everything went right we should start seeing the test corpus growing in the webgui and also we can see that the code of our driver is getting covered and in case any bug happened we should see a crash report hopefully with a reproducer for the bug a reproducer for a bug is simply a C program that triggers the bug when it runs now this color will always try to obtain a reproducer every time it finds a crash although sometimes maybe it won't be able to do that because the bug may have been triggered because of a race condition so it's not caused by the code that ran itself by a test program but maybe it was triggered by a certain runtime condition so it's hard to reproduce simply by running a program and this color can't be sure of that or maybe because there's more than one candidate that could have triggered the bug because sometimes this color will run many test programs concurrently so it's the interaction between these programs that may have caused the bug itself still even if it can give you a specific reproducer for that bug with certainty it will at least try to give you a high level description of the program that caused the bug an example of that is shown in the in the upper side of the slide and and also this color provides a few tools that can be used to turn these high level descriptions into standalone C programs as you see in the in the bottom part of the slide so with a little manual effort you can take one of these high level descriptions and turn them into C programs and try to run them in the target and start investigating from there the advantage of having reproducers is that they reduce the amount of time that we spent investigating a bug tremendously especially if we take into account that this color already tries to minimize the reproducer to avoid having a lot of noise during the investigation finally I'd like to mention Cisbot which is arguably more widely known that Ciscolor itself. Cisbot is a continuous fuzzer and reporting tool which has a public dashboard where you can you can see it in the link in the slide and it has proven to be an invaluable tool for discovering new kernel bugs you know what it does is simply to run Ciscolor on a number of a bunch of kernels in a number of different platforms and keep track of the crashes it finds and report them with all the information it can find about them to the appropriate developers maintainers and the appropriate mailing lists and as you as we saw before you know Ciscolor gives as much information as it can about about a crash including a reproducer and Cisbot does that of course but it also gives by section information so it it's not only automating bug discovery process in many cases but it's also automating part of the investigation about the bugs that's all for today I hope you found the talk interesting and that you learned about the importance of Ciscolor as a tool for kernel improvement any contributions to the project are well received Dimitri is putting a lot of effort into it and is always welcoming new improvements and developments on Ciscolor so thank you all for listening have a good day


Good morning. I'm going to talk today about a new specification put out by the Wi-Fi Alliance called EasyMesh and the effort I've been doing to make an open source implementation of that. Most of my time, oh, this is slow.  Sorry. So most of my time, I'm also actually going to spend to explain what this new specification is and why it exists, what the problem is and what the specification is about. Then I will explain why I'm doing this work, which is sponsored by Purple and what kind of architecture we envision. I'm also with a little bit of trepidation going to talk about security and finally about missing features, which hopefully will be implemented in the second revision of the specification. So the problem that Wi-Fi Alliance wants to deal with is when you have multiple access points in the house, when you have a single access point, it's easy. It has an SID and you connect to it and typically that's the gateway that's given to you by your, well, for you probably not, but for the normal home user, typically it's the gateway that is given to them by the carrier, the telecom operator. But of course, you don't get enough coverage, so you need multiple access points in your house. So you add another access point, but it's a bit complex to set that up. You need, well, ideally you should give both of them the same SSID so that when you have a device, it will automatically select one of the two access points, the one that is in reach. And of course, if you add more access points to get full coverage, this complexity only increases. So there is setup complexity, but it's not only that. Another issue is that of interference. If you have multiple access points and they're using the same channel, yeah, they're going to conflict with each other. And there is a bit of automatic channel selection that is done in access points, but sometimes you have two access points like this one and this one. They don't actually see each other, but anybody who is in the middle will still get interference from those two access points. So automatic channel selection does not work perfectly. And another issue is that the access points are used suboptimally. If you have, well, usually you have a lot of devices, a lot of Wi-Fi devices in the house, and all of them are smart enough to, when you have, when they see multiple access points with the same SSID, they will select the best one, the strongest one. Now, if you have devices which are concentrated in the same area, which is often the case, they all see the same access point as the strongest one. And the net effect is that all of them connect to the same access point, and these other access points, they go unused. So you have unused bandwidth in the air. So Wi-Fi certified EasyMesh is a way to deal with all that. So the idea is that the setup is easy, that you can add access points to your house, just push a button and they connect to each other. And also that they will automatically manage how different devices connect to the different access points. So it's the, the branding here is a bit complicated. The Wi-Fi Alliance, they make, well, originally they only did certification. Nowadays, they make specifications as well for new standards, industry standards. But then there's also always the specification, which is a certain name in this case. It's the Wi-Fi Alliance, oh, sorry. The Wi-Fi Alliance multi-access point or multi-AP specification. And then, so you have this specification. You make an implementation of that specification. It is put in some products and then in the end, the Wi-Fi Alliance gives you a certification so you can use the brands. That's why there is always a TM here because it's a brand name. You can use the brand EasyMesh to sell your product. And that's how Wi-Fi Alliance makes their money. They charge money for this certification and that's how they get an income, which hopefully they spent on developing better standards. So what we will be doing is only the multi-AP implementation parts, which allows vendors, product developers, to develop products more easily and where they know that it will be really easy to get this certification. Something similar is also happening in Bluetooth, for example, where you also have to go through such a certification process. So a little bit of insight in how this Wi-Fi multi-AP standard works. It is based on an existing IEEE standard 95.1, which I had before this never heard about. It's something that is used to allow different routers or bridges in a network, in a wired network, typically, to discover each other, to discover the topology, which can then be used to optimize the usage of the network. So it's a bit like an STP on steroids to discover how to route your packets. So what does this 95.1 thing look like? It's a purely L2 protocol, so there's no IP involved. It has a specific error type. It is number. And then it uses either a unicost L2 address or a multicost L2 address, so this 48-bit internet addresses. So to do the discovery, it will use multicost, and then the routers, the bridges, which are 95.1 enabled, they will capture this multicost and only forward it in certain situations. So that allows you to do the discovery in a controlled way. And once you discover which devices are available in the network, you use normal unicost Ethernet frames to go to that device, but it's using instead of the normal MAC address of an interface, it will use a special AL MAC address. For a bridge, it doesn't matter what this address is, it will just look at an address, it knows, ah, on that port, I have, I've seen that address before, so I send it to that port. And in case it's an unknown address, it will flood it, so this just works out of the box. And then all the packets that are used in this protocol, they use this kind of layout, so there is a, the packets are called CMD use for command units. So they have a header, as always, with a version and a message ID, and then they have TLVs, type, length, value elements. So it's always a one-byte type, then a two-byte length, and then a value, which is of varying length. And the different, so the message ID is the, sorry, the CMDU type is a type. Each type has a specific set of TLVs that is associated with it, and there's some catering for extensions for unknown TLVs and unknown CMD use, so it's specified how to deal with those, which is why it's easy for the multi-AP specification to reuse this protocol because they can, they can just add CMD use and they can add TLVs. And if there is some existing 1905.1 device in the network, it will correctly deal with that because it's all extensible. And then the other thing it has is this message ID, which is used for dealing with retransmissions and for lost packets, so it's, it's like a sequence number, and it also has possibilities for fragmentation. Some of these messages can be really large, larger than the MTU, and then they can be fragmented and collected together again. So the, what is, what the multi-AP standards reuses from the 1905 is mostly the topology discovery, so sending out packets in the network to see which other devices are in the network. And also the 1905.1 standard already has an onboarding concept. So they have had the concept of a push button configuration similar like WPS and actually reusing the same frames as WPS. So when you have two 1905.1 devices in the network and you push a button on both, they will start sending a specific type of message broadcast or multicasting them. And then the, the, that allows them to set up a secure connection just like you do WPS on an access point. So what it, what the multi-AP specification adds is a lot of new command units and TLVs. Actually, there are more in the multi-AP standards than that there are in the original 1905.1 standards. It also extended this onboarding procedure. So the, the new onboarding procedure, well, I'll come back to that. It's mainly to set up a, a wireless link between two access points. The 1905.1 standard assumes that access points were connected with a wire or, or devices which are onboarded are connected with a wire. The multi-AP specification allows it to be wireless. And then the, the core of the extensions is a collection of capabilities and metrics. So the capabilities are things like, does this access point support 5 GHz networks? Does it support in 5 GHz, 80 MHz bandwidth? Does it, does it need radar detection? Things like that. And then the metric collection is about which beacons do you see? So which other access points does that particular access point see? Which stations are connected to it? What kind of speeds do these stations get? What kind of RSSI do they get? So how strong is a signal? And all of that gets sent to a central device which is called the controller. And all the other devices, all the other access points are called agents. And so this controller based on that capability in metric information can make some decision, a global decision for the entire network. And then it sends back control frames for configuration, so which SSIDs should be enabled on the access point. Channel selection, so in which channel they should be, make sure that they're not interfering with each other. And also steering, meaning telling a specific client to connect to a specific access point. So a bit more details of how this works. So the discovery procedure allows the agents and the controller to discover each other. Usually the controller is going to be on a gateway, but this is not specified. So the controller can be anything. It can be a PC even. It doesn't even need to be an access point itself. But so the way that the carriers see it is that the controller is always going to be their gateway. And then the access points are, all access points are agents. Also the device which is the controller can also be an agent. So it will also be controlled by the same controller, obviously. In principle, there should be no additional information needed between these two. So there should not be any reason to have the controller on the same device, on an access point itself. So once they have discovered each other, the controller will ask all the agents for their metrics. It will ask all the agents for the configuration, for the capabilities. So then the agents start collecting metrics and these are sent autonomously to the controller. So the controller says, I want metrics every 10 seconds, for instance. And then the agent sends those metrics every 10 seconds. It should be a bit more than 10 seconds. And then based on that, the controller can take decisions. And for example, it can say to this access point, okay, this station was connected to you, send it a message that it should no longer connect to you, but it should instead connect to this access point. There is a Wi-Fi standard for allowing that. It's called CAC. I have no idea what it stands for. Not all devices support that. So if the device does not support it, there is an alternative and it's just blacklisting. So this access point will no longer accept a connection from that device. So that device basically sees I can't connect anymore to the network. And normally that device will then look for another access point with the same SSID and connect to that one instead. So normally it should work and it should find this access point and connect to that. Worst case, your device is disconnected, which is not so nice, but yeah. Price you have to pay. A more complicated thing is the onboarding procedure. So assuming that the devices are already connected, for example, with a wire, then the new agent, so this is a new agent that is connected to the network, it will send out a search message, which is broadcasted all over the network. And then the controller will reply to that and send a reply to it to say, okay, I'm the controller.  There is no support for multiple controllers. There's not even any support for electing a controller. So if all these devices, if all access points would also have controller functionality, the system doesn't work. It's a bit like DGP. You can have only one DGP server in the network. So the controller sends a response. That's a unicast message. So the response goes straight to the correct agent. And from then on there is a, well, they know about each other. So the agents will know, okay, I can accept commands from this particular controller. And the controller knows that's one agent in the network that I have to control. Now if you don't have a wired connection, but you have a wireless connection, you need to set that up as well. And so for that, there is an, yeah. For making the wireless connection, there is a normal WPS procedure between them. So you push a button on one access point and you push a button on the new access point, which has to be in view of the other access points that you push the button on. The existing access point will start broadcasting beacons which have the WPS bit sets. And they also have these beacon messages have an additional element saying that it supports the multi-AP specification. And then the new agent, it waits for that kind of beacon message with the WPS indication. And if this beacon message has the multi-AP element, it will make, establish a backhaul link as it is called. So a backhaul link is a link where this one acts as the client, as a station. This one acts as the, as access point as usual. But the client is going to use that link for, as it's one site of the network, as it's white area network site of the network. And it's also going to use that link for the multi-AP communication. So once that is done, you just have a connection between those two agents. You don't have a connection to the controller yet. So then comes the, the controller discovery procedure. And once the controller has been discovered, the new agent is going to send an WSC, which is the, the protocol underlying WPS is going to send a WSC message to the controller. And the controller sends back a WSC message to the agent. So you get the same kind of protocol as you have for WPS. You get a second time, but now between the agent and the controller, which can't actually see each other directly. So it's, it's routed over, over this network. You get an interaction between the agent and the controller, and that interaction is then set up, used to set up the, the SSIDs on the agent. So which, for each radio that it has, which SSID should configure to it. And normally that would be the same SSID as all the other access points in the network have. But actually the controller can choose to give every access point a different SSID. So that is the, the 10-minute overview of the multi-AP standards. So the Wi-Fi Alliance developed this standard, approved it, I think, in March this year. And then, of course, chip vendors want to start implementing this multi-AP standard. So Broadcom, Intel, Contenna, Qualcomm, all these chip vendors, they, they want to sell chips that have this, that are enabled for this standard. And then OMS, so the, the companies that develop the, the, not really the, the routers, but the, the boards which are put in routers, they want to, to use the multi-AP standards, but they want to be able to use different chips from different vendors without having to swap out the software. This happened already with HostAPD. So in, in the past, every chip vendor would, instead of using the existing CFG A2211 infrastructure in your kernel, or extending the existing infrastructure, they would have their, their own way of setting up and their, their chips, because they have all kinds of extensions that they want to be able to use. And that meant that they also need a fork of HostAPD. So it makes it very difficult for the, the product developers to use different radios in their devices, because they anyway, every time have to install different software almost, which is annoying. So the, the product developers, they want to use the same thing without having to change their software all the time. And the carriers, they want two things. They want the interoperability, so they want that if they have one device coming from one OM vendor and another device coming from another OM vendor, that they actually work together. And they want manageability. The interoperability that is satisfied because now there is a standard. So before that, there already existed this kind of implementations, but then for a specific vendor. So you have to have that specific vendor to be able to use it. And all the devices in the network have to be from that specific vendor. With this Wi-Fi certified standard, we can have some interoperability. Interoperability. And then the manageability, that's something I don't fully understand myself, but the carriers, what they basically want is that they own all the devices which are in your house and that they can control everything. And if you put in some other device, that they can still control it. That's basically the way I read it. I think the reason that they want that is because when there's something wrong with your network, probably not your network, but the normal person's network, they're going to call the help desk of the carrier because that's the one that's providing the internet and the internet is not working. And then the carrier somehow has to solve it. So what they want is that they want to have some insight in what is happening in that network. And so then comes in the Purple Foundation. The Purple Foundation, it says a bit of a weird history. It actually started out as a foundation for developing MIPS, MIPS processors or software for MIPS, a bit like Linairo for ARM. But it evolved into a foundation for open source community-driven development for routers, for anything which is related to the network, the edge network, so in homes and in small businesses. And nowadays it's actually mostly oriented towards carriers, but it in principle also caters towards like links is normal router vendors. And so the Purple Foundation works on mainly standards and API, so making sure that different routers and different pieces of software in routers use the same kind of interfaces so that you can easily combine things together. And then you see a lot of companies that are members of the Purple Foundation ranging from carriers like Vodafone, chip vendors like Intel, I don't see it now, but Intel is a member here. And software vendors like Soft at Home and OMS so making the devices like Technicolor. And how does the Purple Foundation achieve this interoperability and so on. That's by making APIs and so the high-level architecture that is being developed basically by Purple Foundation consists of a high-level API in a low-level API. The low-level API is basically telling, for example, telling chip vendors you have to use CFG A2211 and then the OMS that you buy those chips they also tell the chip vendors you have to use A2211 and that's the way to convince those people that they should use A2211, CFG A2211. So the low-level API is basically standardizing how you talk to drivers or how you talk to hardware. The high-level API is a single way to manage the device so that's the manageability aspect that the carriers want. That's the way that you can get information about the device. The way that you can get that you can control the device is unified and so that the carriers can develop one web UI and use the same web UI on different devices because it uses the same API to talk to the device itself. And so in between is the stuff that actually makes things work.  And so their purple is also I think my project is the only one where it's actually doing software development but helping with the software development of that. So that's how we arrive at this purple mesh implementation. So the idea was in this context of this high-level API in the low-level API and the services which are in between in the push from chip vendors and OMS and carriers to have an open-source implementation of the multi-AP specification. The idea was to make an open-source reference implementation of this multi-AP implementation which is ready to be Wi-Fi certified. So the idea is not to actually get the label from Wi-Fi Alliance but to make it easy for open vendors to actually get that label. And concentrating on the agent. So the idea is that the controller which is actually making decisions which has the intelligence that that one is left as a differentiator so that different vendors can sell their controller and compete on that. Probably at some point in a faraway future there will also be conversions on the controller but for now the idea is that that's the differentiator. And of course it is something that should match with purple APIs and add carrier manageability which basically means it should be possible for the controller to not even be in your network in your gateway but be somewhere in the cloud and controlled by the carrier. The whole thing is anyway going to be controlled by the carrier so it doesn't make much of a difference.  So yeah as I said before the path to implementation is that you have purple mesh which can then be integrated into one product by a vendor and because we know that this is certifiable it's going to be easy to get the certified label. There is also an involvement of the broadband forum so the basically this came to be because the broadband forum has already an implementation of the 1905.1 stack which is publicly available in Apache 2.0 license so you can find it here. So we started a relationship with the broadband forum and they also have a working group on multi-AP. The broadband forum is mostly concentrated on doing things well adding things to it for enabling carrier management like QoS. QoS is the idea that you're using this Wi-Fi to stream TV to digital TV and of course you want your TV to always work even if somebody is downloading something big. So the Wi-Fi access points should have a quality of service setup so that the TV can have priority over the bulk traffic or traffic. And then also metrics acquisition but on a bit higher level to so that the carrier can have an idea of the state of the network. And also they will do test plans so the certification the Wi-Fi line certification that's a bunch of test plans but broadband forum is going to have additional tests to test the carrier grade aspects to test that it is stable. Up to now I have not been involved very much with what happens at the broadband forum site. So the architecture of the purple mesh demon is going to be like this so the central thing is data model which basically models what the access well the capabilities of the access points the metrics and is able to send this information over the network and then you have the 1905 or multi AP stack that actually communicates over the network and then you have two pieces on the bottom platform integration in drivers. So yeah I'll start with the data model the data model looks a bit like this so the for agent this is the only the left hand side is the only thing which is relevant so you have a local device or if that's the only device it's not really important. We have a number of radios typically a 2.4 gigahertz and a 5 gigahertz radio and on each radio you have access points or backhaul links so station links with SSIDs and so on and so then the metrics and so on our children of this for the controller model you basically have this repeated for multiple devices so also for remote devices but the idea is that you have the same data model for local devices and remote devices so that you can operate easily. Now purple mesh is going to work just with CFG 8211 in upstream host step D well or patched upstream host step D because some patches are needed to make multi AP work but we do want vendors to be able to extend it in a way that they can support their specific hardware which is not CFG 211 enabled yet so to make that possible there will be callbacks on every structure instead of having a fixed way to configure a radio there will be a callback which is set up per radio to do specific things and by replacing that callback with something else the vendor can have their own implementation which I'm not going to do but they can do it and we can use the same mechanism also for remote devices in the controller so if the same callback also exists for remote radios and then the implementation of that is messages which go over 1905.1 I forgot to see until what at what time does my talk end okay they're now going to skip over how this works with OpenWRT so the OpenWRT is the way to show it in an entire environment this will be based on OpenWRT that will be my demo platform but the idea is also that it can be integrated in other platforms as well many OMS have their own integration platform fortunately many also use OpenWRT security I'm going to be very brief on it's not okay but hopefully this will be fixed in a future release although I don't trust it very much so some features which are missing are now it's all seen as one flat network there's no way to specify how you have to do firewalls or VLANs or whatever there's no quality of service there's no end-to-end authentication so there's the thing missing in the security aspect it's all just plain text going over the network and you can have only one controller on the network the second release is supposed to fix all that so I'll go in a little more detail about multiple bridges in a typical router you will have multiple bridges so you have your your LAN bridge so the LAN network and then you have a not that white area network but in on the LAN side you also have a few other bridges like a guest network which is an open Wi-Fi or a DMZ which is password protected Wi-Fi but which is more heavily firewalled so that's one device in the DMZ cannot talk to another one so the multi-AP standard has nothing to deal with this and that's one of the extensions that I hope will be coming in the second release so the with this multi-AP it should be possible to have for normal users to make it easier to set up Wi-Fi networks with multiple access points in their home I'm making an open source implementation of it but I'm actually hoping nobody will use it as it is now because of the security aspects which make it not very trustable but hopefully that will be fixed in the second release there is time for questions a little bit yeah but hang on I'll hand out the microphone for the video when will the second release be due I don't know the easy answer is I don't know they are so recently the starting to work on the second release has been approved by the Wi-Fi Alliance but when that then will actually happen I don't know I guess somewhere next year I'm mainly wondering about channel differentiation between the different APs so that they don't distribute distribute with multiple clients the what differentiation so if they're all running on the same channel and everybody's broadcasting on the same channel then you get interference from each other so I wonder if there would be or if there is a channel differentiation so that different APs can run on different channels yeah so the whole idea is that the controller because it knows the different APs and their capabilities and which channels they can operate on it will select for each AP a channel which does not interfere with another one and so they are better than commercial OEMs well there is actually air ties is a commercial system that exists that does the same thing is the source code for the current version already available yeah it's on jithub under the purple foundation group purple mission okay thank you I should have mentioned that and so the the repository is actually a fork of the broadband forum 1905.1 repository but which is so heavily refactored it's not recognizable anymore and it's very much still a working progress so I was hoping to have something demonstratable by today but unfortunately I understand that from different sort of organizational backgrounds but maybe you could compare purple or the wifi mesh with the batman spec if you are this is a mesh networking from the german fryfunk yeah I'm not happy with the name easy mesh or purple mesh because it's not actually really a mesh network so when you say wifi mesh isn't something that exists already for a while to allow stations to connect with each other and to discover connections between them unfortunately it never really took off it doesn't really work in different implementations don't actually work together very well so that's I think why the wifi line sets let's do something new which is completely different and give it the same name but so basically the main difference is that easy mesh is centrally controlled which makes it much simpler to set up in a way because you when once you have discovered controller you're just slave and you just have to execute and the controller sees everything and can make all the decisions and I believe batman is like wifi mesh but then working it's decentralized it's you have this covers system I'm not familiar so also yeah I should show this nice picture with the different hops that's something which is also lacking in the current standard it is actually possible for the controller to so the basically the how things are connected is initially defined by how you happen to have your push button configuration on it is possible for the controller to re reorganize that afterwards but it's not really the main thing so it's kind of assuming that you start with I mean it's it's section 21 or something in the specification of 23 sections so it looks a bit like an afterthought I think we're running out of time so thank you for your attention