Monday, October 23, 2017
Today is the first day of the Embedded Linux Conference Europe ELCE 2017 #lfelc.
Main topics of this year are definitely Continuous Integration (CI), Automated testing (AT), Encryption and this means that companies want two main things in Linux: reliability and security.
Main topics (I’ve attended) today:
- OP-TEE – Using TrustZone to Protect Our Own Secrets – Marc Kleine-Budde, Pengutronix e.K.
The TrustZone feature in ARM v7/8 CPUs promises to protect sensitive data even with a compromised kernel. Although it could be used for securing VPN keys, running a TPM in software or handling feature licenses, TrustZone has been largely ignored by the Linux community. Currently, the most widespread use for TEEs (Trusted Execution Environments) seems to be proprietary DRM for video streaming on Android. This is about to change, because since the merge of the OP-TEE infrastructure in Linux 4.12, we how have a standardized interface with a fully open source implementation. We can now run small applications separately from the normal Linux world, protecting the user’s data instead of hiding data from the user.
- SD/eMMC: New Speed Modes and Their Support in Linux – Gregory Clement, Fee Electrons
Since the introduction of the original “default”(DS) and “high speed”(HS) modes, the SD card standard has evolved by introducing new speed modes, such as SDR12, SDR25, SDR50, SDR104, etc. The same happened to the eMMC standard, with the introduction of new high speed modes named DDR52, HS200, HS400, etc. The Linux kernel has obviously evolved to support these new speed modes, both in the MMC core and through the addition of new drivers.
- The Serial Device Bus – Johan Hovold, Hovold Consulting AB
UARTs and RS-232 have been around since the 1960s, and despite the advent of technologies like USB and PCIe, it seems UART-attached devices aren’t going away anytime soon. In embedded systems, UARTs are a commonly used peripheral interface (e.g. for Bluetooth, NFC, and GPS) even if the kernel infrastructure for dealing with such devices has been both limited in what it can provide (e.g. in terms of power management) and cumbersome to use (e.g. requiring user-space daemons).
- Continuous Integration: Jenkins, libvirt and Real Hardware – Anna-Maria Gleixner & Manuel Traut, Linutronix GmbH
Jenkins is a well established CI-System. It has excellent support for libvirt, but controlling real hardware in Jenkins can be tedious task and is not standardised. The Jenkins based CI-RT system provides smoke tests for Real-Time Linux developers, which include compile, boot and latency regression tests, This requires control of real hardware. Instead of adding custom hardware controls to Jenkings the RTL team decided to standardise on libvirt and add a libvirt extension, which interfaces with R4D (Remote control For Device-under-test). R4D allows simple integration of remote power controls and serial device servers for console access. Libvirt/R4D makes controlling real hardware from Jenkins as simple as controlling a VM.
- Farming Together – Andrew Murray, Witekio
Everyone is talking about board farms and becoming farmers to their own board farms. Board farms add a link to continuous integration that allows for continuous deployment and automated testing. However we are all working on this in silos – yet we come across the same challenges and solve them with very different proprietary solutions.
- An Overview of the Linux Kernel Crypto Subsystem – Boris Brezillon, Free Electrons
The Linux kernel has long provided cryptographic support for in-kernel users (like the network or storage stacks) and has been pushed to open these cryptographic capabities to user-space along the way. But what is exactly inside this subsystem, and how can it be used by kernel users? What is the official userspace interface exposing these features and what are non-upstream alternatives? When should we use a HW engine compared to a purely software based implementation? What’s inside a crypto engine driver and what precautions should be taken when developing one?
- Automation beyond Testing and Embedded System Validation – Jan Luebbe, Pengutronix
Current OSS testing projects like LAVA have mostly achieved their goals: automate and simplify software testing on embedded hardware. However, the integrated automation layer is not easy to reuse for different scenarios: ad-hoc scripting to reproduce a sporadic error during development, automated flashing in the factory, git bisection, development scripts for repetitive steps or CI for whole system update processes including reboots. Separating the automation layer from the testing infrastructure makes it easier to implement tools to handle these cases outside of a fixed CI framework. Also, combining the automation layer with a general software testing framework like pytest allows expressive test cases with little boiler-plate.