Schedule
09:15
09:30
Keynote
45 min
English
All
Talk page
A whirlwind tour of what has been happening in the kernel development community and what can be expected in the near future.
The Linux kernel is at the core of any Linux system; the performance and capabilities of the kernel will, in the end, place an upper bound on what the system as a whole can do. This talk will review recent events in the kernel development community, discuss the current state of the kernel and the challenges it faces, and look forward to how the kernel may address those challenges. Attendees of any technical ability should gain a better understanding of how the kernel got to its current state and what can be expected in the near future.
10:15
10:45
Buildroot and Yocto, the two leading embedded Linux buildsystems, have largely overlapping goals but vastly different implementations.
Perhaps you’re familiar with either, and wonder how your daily job would change if you used the other.
Luca will share insights he gained while managing projects with both tools, spending a lot of time in learning how to achieve the same goals in a different way.
He will give a sort of “translation table” to ease the transition between the two, covering: bootstrapping a project, what happens under the hood, invoking the build, customizing the rootfs and tweaking recipes.
Introduction to firmware reverse engineering process of IoT devices. The process, described with an example on a home router, is based on Information Gathering of hardware and software, Building of an Emulation Environment to run binaries, and Techniques to analyze, hack and modify the firmware.
The introduction to firmware reverse engineering process is described with a real example, done by the author, on a recent home router with the target to load a modified firmware overcoming the router protection that doesn’t allow loading of unsigned firmware (ref: https://github.com/digiampietro/adbtools2 )
The process described is based on:
Information Gathering hw: identify main device components (CPU, Flash, SDRAM, main components) hw: locate UART and JTAG interfaces hw tools: Bus Pirate, OpenOCD, Jtagulator sw: get os image file or firmware file sw tools: strings, file, binwalk, dd, jefferson, uncramfs etc. identification of CPU, Flash, RAM, kernel version, C library, toolchain used etc. identification of Original Manufacturer and Original Firmware Manufacturer Emulation Environment using QEMU select a QEMU machine and CPU reasonably similar to the IoT device (same CPU, similar kernel version, similar modules and libraries) select a tool to build the kernel and the root file system (brief description of Yocto Project, Buildroot and OpenWRT build system). Buildroot will be used in the example and described in more detail Buildroot and kernel configuration, generation of root file system with binaries and libraries with debugging information Overcoming obstacles created by the firmware manufacturer Running interesting binaries in the emulated environment Use tools like strace, ltrace, gdb to reverse engineer the most interesting binaries Analyze how the device works the firmware upgrade process CLI and Web interface analisys main processes analisys finding vulnerabilities hacking into the system hack the firmware upgrade process replace the original firmware Create a Firmware Modification Kit to simplify the firmware modification process
11:30
Android developers are facing a common problem: how to test our applications on many devices without sacrificing too much time or money? Could we use remotely all the devices inside the company with the continuous integration system? Maybe thanks to a low cost device farm that fits into a pocket?
Android developers are facing a common problem: how to test our applications on many devices without sacrificing too much time or money?
How to build and test automatically our applications for each commit? How can we find those devices inside the company, whatever its size may be? Could there be a directory somewhere that lists those available devices? Could we use a device remotely and share it with other developers as if it were in the cloud? What if you could answer all these questions with the help of a low cost device farm that fits into a pocket? A pocket full of clouds…
Poddingue, our proposal, aims to tackle this problem thanks to Docker, HypriotOS, Armbian, Gitlab CI and OpenSTF. It’s an internal solution made of OSS readily available, but it has not yet been publicly announced as a whole.
This is a feedback about an idea on its way to production, a long journey full of different feelings : horror, happiness, suspense, boredom…
Why should I come? This presentation won’t be too technical ; it is opened to anybody who has an interest into Android, exotic hardware or continuous integration, as long as you can stand a bad sense of humour. At the end of the talk, you should know how to build your own cloudy pocket farm of Android devices and how to use it to test your applications within your ci pipeline.
And as I am cheap, you will also be surprised at how little money you need to build it.
The exploding popularity of Embedded/IoT computing facilitate this security problems using low or non-existent security policies and exploits countermeasures. So why not explore some security measures that are widely available in the Linux world? We will focus on memory corruption techniques.
The Linux kernel was always focused on security features and giving bad times to the exploiters. This talk will introduce some common exploits and techniques, showing the mitigations employed by the kernel. By focusing on the major threats that affects modern Linux boxes, we will see which are the main features that can give problems to the system administator and how a preliminary penetration test can be done, ensuring that the system is in a sane state. The talk will also focus on problematics of embedded/IoT Unix systems, showing how some recent attacks gained control over a big network of devices and how a simple embedded system can be analyzed, hunting for bugs. Talk outline: Penetration testing, Linux, netfilter/bpf, memory corruption, ASLR, Spectre/Meltdown.
The development of device drivers usually requires hardware availability. We will try to address this issue by simulating our “missing” device thanks to a QEMU ARM machine. The fake device will be tested and debugged using bare-metal software, again running in QEMU. Finally, we will write a Linux device driver from scratch that will interact with the device and expose it to the userspace.
The training assumes some basic knowledge of the C programming language and using Linux as a development platform. During the training, we will show how to build the Linux kernel and write a simple yet complete device driver, how to use QEMU as a development platform and a few notions of bare-metal and kernel code debugging.
12:15
This talk will guide you through the perils of building a resilient software stack for embedded system using buildroot as a base, stuff your software in between and adding swupdate as cherry on top! The talk will be composed by three main areas:
- How to use buildroot as a base system for your stack
- An introduction to swupdate and it’s fields of use
- An example of using buildroot + swupdate to update your stack.
In the first we will talk about using buildroot as base for your software and how to add your software around. Buildroot make really easy to build a complete firmware image when using the standard configurations provided by the software but it could be cumbersome if you want to add your software in simple, easy and automated way. So we will show you how to write a simple makefile to add your software as an external component and how to automate the process of compiling everything to produce your binary artifacts.
The second part will discuss about swupdate and it’s field of use. Swupdate provides several ways of use: it can be used in a simple way, it could be integrated to do A/B updates, it could be used via network or locally using a medium. We will discuss about the possibility of approaches of system updates and how swupdate can satisfy each one of the use cases.
The third phase will show you a real approach adopted to solve a specific use cause with the hope it can be used a reference for auditor specific needs.
Do you ever wonder what the kernel is doing while your code is running? This talk will explore some methodologies and techniques (eBPF, ftrace, etc.) to look under the hood of the Linux kernel and understand what it’s actually doing behind the scenes.
This talk explores methodologies that allow to take a look “live” at kernel internal operations, from a network perspective, to I/O paths, CPU usage, memory allocations, etc., using in-kernel technologies, like eBPF and ftrace. Understanding such kernel internals can be really helpful to track down performance bottlenecks, debug system failures and it can be also a very effective way to approach to kernel development.
13:00
14:30
When building a network of communicating IoT devices, it is compulsory to ensure that all the devices are reachable regardless of their IP address and location. This talk is about an open source software named n2n that enables secure communication over a lightweight and secure p2p network overlay.
When building a network of IoT devices, communication topology can be a problem as some of them might be behind a NAT, and some others might be reachable only from certain network nodes. Furthermore the advent of mobile and automotive computing with non persistent addressing will make all this even more challenging. To address all this, usually people use a centralised cloud-based topology that makes the network weak and not optimal, as all the devices have to communicate though this central point instead, when possible, to talk directly. However the cloud does not address privacy and security, in particular when IoT devices are used and developers and not fully aware of security issues: this can be addressed by a network overlay that tackles this problem at network instead that at application level This talk is about an open source, lightweight network overlay software named n2n ( https://github.com/ntop/n2n ) [available for Linux, BSD, MacOS, Windows] developed by the authors, that enables the creation of a persistent network that promotes secure communications even on environments where security is an option, or some communications are prevented by NATs or firewall devices.
15:15
The workshop shows how to build hardware and firmware of a GPS-disciplined TDC device with microsecond precision, using a completely Free Software toolset. The TDC is a device that reports the timestamp of digital pulses for a number of input lines: the audience is accompanied through all the design choices that lead from the idea to a complete device, including performance measurement and analysis of different approaches for data transfer and calibration. The bravest attendees will be awarded with a physical TDC device, which unfornatuntely isn’t sharp enough to show that neutrinos are faster than light.
Note: the limited time frame doesn’t allow the whole code to be written from scratch during the workshop.
This year we will have a recruiting session at LinuxLab!
First, representatives from firms looking for people will go on stage: each one will have 5-10 minutes to describe the firm’s activities and the competencies they are looking for.
Then, each representative will sit at a desk, where candidates will be able to give their resume and talk about job opportunities.
Because of the many people present, there will not be time for actual job interviews at the session, but the short discussion will nonetheless allow both parties to know each other and evaluate whether to pursue the contact further. It is also possible to schedule a private meeting/interview to be held in the following days in private meeting rooms available in the venue.
16:00
16:30
U-Boot project has evolved in the time span of over 17 years and so as its complexity and its uses. This has made it a daunting task in getting started with its development and uses. This talk will address all these issues start with overview, features, efforts created by community and future plans.
The U-Boot project has evolved in the time span of over 17 years and so as its complexity and its uses. This has made it a daunting task in getting started with its development and uses. This talk will address all these issues and share development efforts created by the U-Boot community.
In this talk Jagan Teki(Maintainer for Allwinner SoC, SPI, SPI FLASH Subsystems) will introduce U-Boot from scratch with a brief overview of U-Boot history, U-Boot Proper, SPL, TPL, Build process and Startup sequence. He will talk about other preliminaries such as Image booting, Falcon Mode, Secure Boot and U-Boot features like device tree, device overlays, driver model and DFU, etc.
Once giving enough introduction, he will also talk about steps to port U-Boot to new hardware with a demo, along with U-Boot testing process. Finally, he will address and review ongoing development work, issues and future development regarding U-Boot.
The workshop shows how to build hardware and firmware of a GPS-disciplined TDC device with microsecond precision, using a completely Free Software toolset. The TDC is a device that reports the timestamp of digital pulses for a number of input lines: the audience is accompanied through all the design choices that lead from the idea to a complete device, including performance measurement and analysis of different approaches for data transfer and calibration. The bravest attendees will be awarded with a physical TDC device, which unfornatuntely isn’t sharp enough to show that neutrinos are faster than light.
Note: the limited time frame doesn’t allow the whole code to be written from scratch during the workshop.
17:15
18:45
09:30
10:15
10:45
Building Linux-based low-latency audio processing software for nowadays multi-core devices can be cumbersome. I’ll present some of our on-going research on the topic at the Real-Time Systems Lab of Scuola Superiore Sant’Anna, focusing on sound synthesis on Android where power-efficiency is a must.
The talk will provide basic background information on how the audio sub-system of Linux works, in terms of interactions between the Linux kernel and the ALSA sound architecture, including how user-space applications normally cope with low-latency requirements, touching briefly on design concepts behind the existence of the JACK low-latency framework. Then, a few concepts will be provided on the peculiarities of the Android audio processing pipeline, crossing the concepts with the due complications arising from the world of mobile and power-efficient devices. Throughout the talk, I’ll touch upon concepts behind our research efforts on the topic, describing how properly designed real-time CPU scheduling strategies can make a difference in what is achievable in this area.
Can you possibly speculate how badly the spectre of the hardware bugs, recently discovered in microprocessors, haunts virtualized systems (like Xen & KVM)? Are things fine, or is everything going to meltdown ? Come to the talk, and let’s discuss this together…
At the beginning of 2018, Meltdown and Spectre taught us that speculative execution can, from deep down inside our super fast processors, pose some security concerns. During the following months, more Spectre variants, L1TF, etc, taught us how really serious such concerns needed to be.
One of the interesting things about this class of security issues, is that they do not come, like most bugs, from someone’s “mistake”. In fact, they represent the failure of fundamental assumptions that CPU designers have been relying on for years.
This talk will give a quick overview of speculative execution, and of how the attacks work, at a high level. Then, it will go through how these vulnerabilities could be exploited in virtualized environments. It will also try to explain what the main mitigations are, and how they work, for the two main Open Source virtualization solutions, Xen and KVM.
11:30
Linux can now push to full speed even the fastest storage. But it throws away 80% of that speed, if control is needed (e.g., to start applications quickly or to guarantee bandwidths to clients). A new I/O scheduler now enables 90-100% of the speed to be reached, while preserving full control.
Thanks to a brand new I/O stack, Linux can now push to full speed even the fastest storage devices. But what about control? In the configurations that enable full speed to be reached, control is so poor that, e.g.,:
if there is some additional I/O in the background, then applications take an impressively long time to start (even on very fast storage);
on any kind of server, an unlucky client gets practically zero throughput. It happens if the client needs random I/O to be served, but a handful of other clients happen to be triggering sequential I/O at the same time.
To address these issues, Linux does provide mechanisms to control I/O. But the best performing mechanism, available so far, easily ends up utilizing as little as 20% of the storage speed. This just wastes the benefits of the new I/O stack, and is particularly problematic with lower-end hardware.
Fortunately, there is now a new I/O scheduler, named BFQ, which endows Linux with full control on I/O, and at the same time reaches 90% to 100% of the available speed. On the downside, BFQ is currently limited to devices with a peak rate below 400 KIOPS (work is in progress to overcome this limitation).
This presentation is devoted to showing–mainly through demos–both the above personal-system to server problems, and how BFQ solves these problems.
The Yocto Project is an open source collaboration project that provides models, tools and methods to create custom Linux-based systems for embedded products that are independent from the adopted hardware architecture. The project was created in 2010 as a collaboration among several hardware manufacturers, open-source operating system providers and electronics companies to bring some order into the chaos of Linux Embedded development. Over the years, Yocto Project has established itself as the de-facto standard for the generation of embedded Linux systems, surpassing alternative products thanks to its characteristics.
The free tools that Yocto provides are powerful and easily generated (including emulation environments, debuggers, an application generator toolkit, etc.). The complete abstraction from the hardware of the development environment allows to optimize the investments made during the prototyping phase. The Yocto Project encourages the adoption of this technology by the open source community allowing users to focus on the characteristics and development of their product.
12:15
This talk illustrates how to use the Jailhouse hypervisor for running Linux alongside an RTOS on modern ARM multi-core SoCs, aiming at building smarter devices for the automotive market.
Recently, the industry has shown a growing interest for executing activities with different levels of criticality on the same multi-core SoC. These could consist, for example, of non-critical activities (e.g., monitoring, logging, human-machine intefaces) together with safety-critical tasks. The rationale behind this interest is the continuous need for reducing the time-to-market as well as the design and hardware costs. This is particularly suitable for the automotive market, where new infotainment functionalities might be coupled with traditional safety-critical tasks (e.g. engine/brake control). In this talk, we will present our experience (grown through the HERCULES EU project) in using the Jailhouse hypervisor for executing the Linux general-purpose OS alongside an automotive RTOS on modern ARM multi-core platforms. Besides providing useful instructions for using Jailhouse, we will illustrate a library designed for easing the communication between the two OSs as well as some mechanism for limiting the interference on shared hardware resources. Finally, a short video of a simple demo will show the effectiveness of the proposed approach.
The ‘complex camera’ user-space library is a fairly new and hot topic in the Linux kernel video community. The issue is debated and targets a real technical debt of Linux systems.
The Linux kernel video input subsystem and its APIs changed greatly in the last years to keep up with the increasing complexity and processing power embedded in modern SoCs. Namely, the biggest game-changing feature introduced already 5 years ago is the media controller subsystem and its pad oriented APIs, that allows composing pipelines of processing blocks to model the acquisition and re-processing of video and images.
While most of the media subsystem drivers in mainline Linux have been ported to fully support media-controller, the real missing component is now user space support to automate setting up and controlling the image processing pipelines.
The Video4Linux community is now tackling the issue by implementing support for “complex camera” systems by providing a user space library that aims to support the most recent use cases represented by mobile consumer devices and high end laptops.
This talks provides an overview of the in-kernel APIs of modern media-controller capable video device drivers, their userspace APIs and the challenges the currently in-development library has to face.
It also aims to provide to both driver and application developers an overview of the most modern implementation of the Linux video input stack architecture, that will likely be found in most system in next years.
13:00
14:30
This talk describes how to use some available technologies (the SCHED_DEADLINE scheduling policy, the PREEMPT_RT patchset, etc…) to execute real-time applications in kvm-based virtual machines while still providing performance guarantees to the virtualized applications.
In recent years, there has been a growing interest in supporting virtualized services even in embedded and real-time systems. However, executing real-time applications (characterized by temporal constraints) in virtual machines is not straightforward and presents some non-trivial challenges. This talk will describe how to use some technologies already available in the Linux kernel (the SCHED_DEADLINE scheduling policy, the PREEMPT_RT patchset, etc…) to execute real-time applications in kvm-based virtual machines while still providing performance guarantees to the virtualized applications. After presenting the problem (and providing a quick summary about real-time scheduling), it will be shown how to configure the host and guest kernels and the virtual machine, and how to schedule the VM threads in order to achieve predictable response times and to provide real-time guarantees.
Why not take a break from TV repeats this festive season and build a fun project with your loved ones?
In this session, you will learn how you can build an internet connected Raspberry Pi festive decoration which can be triggered by Google Assistant. No knowledge of Golang is required as Nic will walk you through the basics of writing and compiling your first program. He will then show you how you can use Go with the GPIO interface on the Raspberry Pi to illuminate simple LEDs. Finally, we will see how we can activate our lights using Google Assistant.
Nic will instruct you how to build the project yourself and also give helpful hints on how you can take your new skills and teach others, full code samples and a teaching guide will be provided after the session.
15:15
16:00