Afternoon Session

The report for the afternoon session will be a bit shorter than my last report, mainly because it is mainly about products and services of the OSADL member companies.

Rüdiger Kügler (WIBU-SYSTEMS) talked about "Secure distribution and storage of private keys for OPC UA". The question they care about is how to ensure privacy and authentication in industrial scenarios. He basically explained how public key infrastructures work.

Philipp Michel (Wind River) then talked about "Titanium Control - Secure on-premise virtualization platform for critical infrastructure"; the talk mainly explained "Industrie 4.0", cloud, fog and their related products.

Steffen Schlette (PHOENIX CONTACT Software) talked about "PLCnext strategy based on Linux RT". Until 2015, Win CE was their main operating system for the PLCs; since then, they have moved to Linux RT and Debian. The focus of the devices has changed from fixed-function to a versatile platform, where apps can be installed and change functionality over the time. While in the past 61131 languages were in focus, this has now changed towards more languages, including standard IT ones like C/C++; people can use standard IDEs and any kind of other open or closed source software, including OPC UA mechanisms.

My colleague Enrico Jörns then talked about "The fearless way of effective platform updates": he explained that customers often build embedded products for pretty long lifetimes of 10...15 years. However, as embedded systems today are computers, it might happen that at some point in the future, security incidents happen and i.e devices might turn into a part of a botnet. It turned out that the upstream versions of software components are usually only maintained over max. 5 years, so staying with one version of a software over 10...15 years is not a good idea. Even within the supported time, backporting security fixes is not easy (think of Spectre/Meltdown). In result, a good way of caring with updating is a continuous maintenance strategy: after the initial feature development phase (already based on mainline Linux) of a project is over, a maintenance phase follows. During this time, support for the device in the mainline kernel is improved, patches are ported, more tests are written and automated.

With this in place, it gets easier and easier over the time to continuously test the device against upstream components. The more tests and documentation are there, the easier it is to quickly test upcoming versions without much manual interference. One should establish a maintenance cycle (i.e. a year, or half a year) and during that time revisit the components used, check for new versions and new security incidents (the CVE database is your friend). As the software is continuously updated and tested, it is basically always deployable, i.e. by using the RAUC field upgrade framework. Of course, it is not necessary to deploy any new eversion - it is just possible to do so and the processes are well defined and all involved people are used to them. Automation techniques such as Jenkins and labgrid are helpful to keep the effort low.

Joachim Dietrich (OSADL) talked about "The OSADL Linux add-on patch: Why is it separate and what does it contain?". Maintaining the OSADL test farm, it turned out that the "magic sysrequest key" is a helpful tool to diagnose hanging realtime systems. The patch stack contains a patch that makes it possible to send sysreq keys over the network, which is helpful in cases where the local console is not reactive any more. Another patch adds support for the OSADL diagnostics parport card. The most important patch of the patch set adds special latency histograms to the kernel; it adds more statistic data to the kernel's histogram functionality. While there is a generic histogram feature in the kernel, they decided that it is too difficult to port their needs to the upstream variant.

Afternoon Session, Part II

After the coffee break, Armijn Hemel (Tjaldur Software Governance Solutions) talked about the OSADL License Compliance Audit (LCA). The reason why OSADL and Armijn do this is that license compliance cases have hit the courts recently, so companies see an increased need to be sure they play after the copyright rules correctly. The LCA starts with a questionnaire for preparation, then a one day workshop on-site, with a technician and a lawyer, who can be asked anything. Then the team tries to rebuild the core components, following the rules provided by the manufacturer.

Carsten Emde then added more insights into the license scanning topic by talking about "The OSADL Scanbook". It turned out that some of the scan tools do not easily install on modern distributions, so OSADL decided to provide a pre-installed notebook with all the relevant software installed.