This follows the morning liveblog.
New GPIO interfaces for User Space — Bartosz Golaszewski
A GPIO is General-Purpose Input/Output pin at the hardware level. It can be configured at runtime, enabled disabled, it can interrupt the CPU. Within this relatively simple features, it has many applications, from buttons, to leds, buzzers, thermostats, pumps, etc.
Currently in the kernel there’s a provider-consumer model with two co-existing interfaces: a legacy one, deprecated, and another one, based on GPIO descriptors, which allows more fine-grained control.
In general, Bartosz says, you should not be using GPIOs from userspace, but you might in reality often need to if you don’t have a kernel driver for your devices.
The /sys/class/gpio interface is considered the legacy user API. Since it uses sysfs, state is not tied to any process, and you have concurrent access to sysfs attributes. A crashing process will not clean its exports for example. The API is also cumbersome to use, since you have multiple attributes per GPIO, polling is complex etc.
In Linux v4.8, a new character device-based ABI has been merged. It uses one device per gpiochip, with a classic open/ioctl/poll/read/close interface. It allows requesting multiple lines at once, and write multiple values at once. The polling is simpler, and the events are buffered in the kernel, so that you don’t miss any.
Bartosz showed a few code example on how to use this API directly, but advised to use a new library libgpiod, he wrote at job at Baylibre, initially to toggle power switches. The library evolved, and now has its full API documented in doxygen, has bindingis for C++ and python3, many command line tools and a custom test suite. It provides Iterators, which aren’t in the kernel API, as well as other higher-level actions.
The tools in the libgpiod project allow enumerating the devices, listing their features, control the gpios, monitor them, etc. It has features to fully control the GPIOs from scripts, without being cumbersome.
Bartosz then woke up the room by saying he liked C++, while talking about how much easier the libgpiod C++ bindings are to use. He even rewrote the libgpiod tools as an example for the C++ API. He did the same for the Python3 bindings, which are implemented in C as a native Python3 module.
He also started working on dbus bindings, with a daemon exposing chips and line objects on the bus.
libgpiod is hosted on kernel.org, available in Yocto meta-openembedded layer, buildroot, and many distributions.
CLIP OS: Building a defense-in-depth OS around the Linux Kernel — Mickael Salaün, Timothée Ravier
CLIP OS is a new Linux distribution released last week, but it’s been worked on for many years now at ANSSI.
CLIP OS is a hardened Linux kernel and userspace, without a root account. It has an “admin” account with less privileges, for example, it cannot access user data, or tamper with the system by installing an application not on a whitelist. It uses an A/B update system similar to Android and Chromeos.
The goal is to have a multilevel security OS. You have two isolated environments “low” and “high” security level; between which you can exchange data when necessary following the Bell-LaPadula model. A device (USB key, webcam, etc.) can only be accessed by one level at a time.
It’s very similar to Qubes OS, but development started 5 years earlier than Qubes, Mickael says. The goal of CLIP OS is to target non-expert users, and favors a defense-in-depth approach within Linux. Whereas Qubes is based on supervisor and has an all-powerful admin account.
CLIP OS is based on the Gentoo hardened linux distribution. It uses the Gentoo Hardened toolchain, and the Linux-Vserver kernel patch, which adds constraints on top of linux namespaces. It’s based on grsecurity and PaX for kernel self-protection and user hardening features. It also has it’s own CLIP LSM to complement the linux permission model and integrate better with vserver and grsecurity.
It uses the Write XOR Execute policy for memory (through PaX), or for devices mount points. They added a new O_MAYEXEC open flag to control this at file opening for example.
They harden their containers by leveraging vserver admin and audit concepts, adding new capability bounding sets and hardening chroot.
In CLIP-LSM, they tried splitting linux capabilities by adding new permissions (verixec), which can then be bound to a given XID (for vserver namespaces). It does not use xattr, in order to be independent from the filesystem. This is configured in a file in /etc/verictl.d/
Coming in version 5
New linux kernel hardening is coming: paranoid command line parameters, and strict sysctl defaults.
The project also wants to cooperate with the upstream Kernel Self Protection project, by open sourcing, and merging in-flight hardening patches in their tree.
They do that with the linux-hardened tree, the Lockdown patch and Stackleak. The last two are closed to be merged upstream.
Landlock is planned to be merged into the CLIP OS kernel tree, but efforts are still in-progress by Mickael (its author) to submit it upstream.
In conclusion, the project is still ongoing, and looking for contributors.
Zinc: Minimal Lightweight Crypto API — Jason A. Donenfeld
Jason said that Zinc’s goal is to be the most boring crypto API possible.
Jason says he’s been working on Wireguard, an in-kernel VPN protocol, for the last few years. Zinc was written for Wireguard, because he found the crypto API to be too complex for a simple use case. He initially hoped to move to the linux crypto API later.
He starts by citing the big_key kernel API which was improperly designed, and had many issues. So he went on to try to fix that, and in the process learn how to use the Linux crypto api. He found that the API was fully async, had many memory allocations or incoherent designs. It was designed with crypto accelerators in mind, and not with the goal of having a simple, easy-to-review design.
big_key needed to do big 1M allocation, but some systems can’t kmalloc too much at a time. Instead of using kvalloc, a solution was designed with custom allocator with direct page allocation. Jason says that while it was designed by intelligent people, it still has this Entreprise-y feeling, that didn’t appeal him to use it.
On the contrary, Zinc has a much simpler design, with pure-software usage (no accelerators possible), evrything being done on CPU. It includes the chacha20 stream cipher, poly1305 one-time authenticator, an AEAD based on the two, blake2s and curve25519 symmetric and asymmetric ciphers. The goal is not be innovative, Jason says.
Dynamic dispatch can be implemented on top of Zinc. Existing code can be refactored to use Zinc. And in fact, many crypto functions have leaked into lib/, so this is what the developers seem to want. The goal of Zinc is to provide them in coherent library.
Zinc’s goal is to include a formally verified implementation, when it’s available. It also has SIMD-accelerated versions of many algorithms. For the formally verified versions, it uses HACL* and fiat-crypto code, which is machine-generated C code from complex formally verified models in Coq. The HACL* team is based out of Inria here in Paris. Jason wants to make Zinc easy to approach by academia, and in general professional cryptographers, whom, he says, aren’t used to work with Linux kernel.
The file organization is also different: all architecture-specific implementations are in the same directory as the generic version. It then uses compiler-inlining and not function pointers, which makes it faster without retpoline spectre mitigations.
Zinc also uses SIMD-batching, to only save FPU/SIMD context at the beginning and end of loop. It has dispositions to keep the code preemptible between loop iterations if necessary.
The Zinc patchset is posted along with WireGuard, currently in v6 form. The current goal is to have it merged for Linux 5.0/4.20.
Democracy requires free software — Matthias Kirschner
Matthias started by giving an example from the french revolution: how the architecture of Paris moved from small alleys to big boulevard changed the power balance by allowing the military to move in Paris. He gave other examples of advances that changed the power balance, from reading and writing, to mathematics, agriculture, and finally to computers.
Who controls the software running in the computers, cars, planes, washing machines, pacemakers; controls the devices. Processes are also more and more controlled by software, like the admission process to multiple universities in France. So a student association requested access to the source code of this software. Then only, the admission rules could be understood. The proximity rule for instance was discovered, and challenged because it meant that universities in Paris were more likely to accept students that lived closer, in high-rent areas, which was unfair to poorer students.
A similar case is the CV processing algorithm of some companies in the US to decide what applicant can be invited for an interview. It was supposed to be discriminating against black applicants because of the address in the application.
He then cited another software used in the justice system in some US states to guess the probability of repeating offenses, which would then influence the decision, without any recourse since the algorithm is secret.
Matthias’ main argument, is that understanding the rules of our world is fundamental. If these rules are encoded in software and you can’t understand them, then you can’t predict what will happen or what to do.
Who has power in a world where software is pervasive is critical, Matthias says. And Free Software increases distribution of power.
It’s important to provide resources and support to people, who don’t necessarily understand technology, but are directly impacted by the obscurity of proprietary-software-driven decisions. The goal is to remove barriers to understanding how the software around us works.
When governments wants to develop software, they should prefer free software.
That’s it for today ! Follow the thursday morning liveblog !