24-28 August 2020
Canada/Newfoundland timezone

Accepted Microconferences

LPC 2020  Microconferences


Containers and Checkpoint/Restore MC

The Containers and Checkpoint/Restore MC at Linux Plumbers is the opportunity for runtime maintainers, kernel developers and others involved with containers on Linux to talk about what they are up to and agree on the next major changes to kernel and userspace.

Common discussions topic tend to be improvement to the user namespace, opening up more kernel functionalities to unprivileged users, new ways to dump and restore kernel state, Linux Security Modules and syscall handling and more. 

Last year's success has prompted us to reprise the microconference this year.

Topics we would like to cover include:

  • Next steps for uid/gid shifting for mounts and namespaces
  • pidfds and their use for containers
  • Handling of new mount APIs and unprivileged containers
  • Solutions to transition from CgroupV1 to CgroupV2
  • Use and limitations of the time namespace
  • Hardware assisted isolation of processes/containers
  • More to be added based on CfP for this microconference

If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.

MC leads

Scheduler MC

The scheduler is an important functionality of the Linux kernel as it decides what gets to run, when and for how long. With different topologies and workloads this is no easy task to give the user the best experience possible.

Potential topics for this year include:

  • Core Scheduling - How do we merge?
  • Capacity Awareness - For busy systems
  • Interrupt Awareness
  • Proxy Execution - More cases
  • Latency Nice - What interfaces do our use cases like?
  • Load Balancing
  • NUMA load balancing
  • Status of the rework (that went in v5.5), new regressions
  • Formal specification of SCHED_DEADLINE
  • Flattening CPU RQ hierarchy

If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.

MC leads

Real-Time MC

Since 2004 a project has improved the Real-time and low-latency features for Linux. This project has become know as PREEMPT_RT, formally the real-time patch. Over the past decade, many parts of the PREEMPT RT became part of the official Linux codebase. Examples of what came from PREEMPT_RT include: Mutexes, high-resolution timers, lockdep, ftrace, RT scheduling, SCHED_DEADLINE, RCU_PREEMPT, generic interrupts, priority inheritance futexes, threaded interrupt handlers, and more. The number of patches that needs integration has been reduced in the last years, and the pieces left are now mature enough to make its way into mainline Linux. For real, this year could possibly be the year PREEMPT_RT is merged™!

In the final lap of this race, the last patches are on the way to be merged, but there are still some very few pieces missing. When the merge occurs, the PREEMPT_RT will start to follow a new pace: the Linus one. So, it is possible to raise the following discussions:

  • The status of the merge, and how can we resolve the last issues that block the merge;
  • How can we improve the testing of the -rt, to follow the problems raised as Linus tree advances;

What’s next? Possible topics:

  • Status of the PREEMPT_RT Merge
  • Merge – what is missing and who can help?
  • New tools for PREEMPT_RT analysis.
  • How do we teach the rest of the kernel developers how not to break PREEMPT_RT?
  • Stable maintainers tools discussion & improvements.
  • The usage of PREEMPT_RT on safety critical-systems: what do we need to do?
  • Interrupt threads are RT and are not protected by the RT Throttling. How can we prevent interrupt thread starvation from a rogue RT task?

If you are interested in participating in this microconference and have topics to propose, please use the CfP process. More topics will be added based on CfP for this microconference.

MC leads


Kernel Dependability & Assurance MC

Linux is now being used in applications that are going to require a high degree of confidence that the kernel is going to behave as expected. Some of the key areas we’re seeing Linux now start to be used are in medical devices, civil infrastructure, caregiving robots, automotives, etc.

The kernel development is producing high-quality kernels, release by release, with an increasing speed of change and arguably also increasing software quality. The process of kernel development has been adapting to handle the increasing number of contributors over the years and ensure a sufficient software quality.

The kernel processes have evolved over time to produce a high quality kernel that is able to react to security and bug fixes in an effective manner.

However there are a few areas to explore as it pertains to safety critical space:

  • What sort of uptime can we count on?
  • How can we identify when safety analysis needs to be redone after bug fixes have been applied?
  • How can we efficiently assess whether the safety analysis needs to be reworked for a released product based on a specific version of the linux kernel, after a bug fix has been applied to the current release?
  • Are the system requirements that Linux is included in being satisfied?
  • Do we have adequate tooling and processes to help us answer these questions efficiently, so that Linux can be used in high assurance systems with the right levels of analysis to build up confidence that it is safe, and that the dependability properties are maintained over time.

In short, we would like this mini-conf to bring the safety critical user community and the kernel community together to start a dialogue and collaboration on making sure that the kernel is fit to be used in safety-critical systems and that questions from the safety community wrt. software quality can be answered adequately.


  1. Kernel Quality Assurance beyond Testing and CI?
  2. Understanding the Users’ Expectations on Software Quality for business-critical systems
    1. Define safety requirements for overall kernel: features, tests etc.
    2. Define run-time characteristics and requirements
  3. Identify missing features necessary to operate in safety critical environments.
    1. Discuss safety features
  4. Regression Testing for safety: Identify configurations and tests critical and important for safety quality and dependability
    1. Discuss and identify gaps in tests.
    2. Add tests and add configurations to existing test rings.
  5. Understanding the Kernel Development Organisation and Management
  6. Assessing, Measuring and Evaluating the Development Process

MC leads

Testing and Fuzzing MC

The Testing and Fuzzing microconference focuses on advancing the current state of testing and validation of the Linux Kernel, with a focus on encouraging and facilitating collaboration between testing projects.

Suggested Topics:

  • Next steps for KernelCI (data formats, dashboards, etc)
  • Structured data feeds for cross-project collaboration
  • Integration with kernel.org tools (e.g. b4)
  • Continued defragmentation of testing infrastructure
  • Better sanitizers: KASAN improvements, KCSAN fallout, future plans.
  • Better hardware testing, hardware sanitizers: how the USB fallout was handled, are there efforts to poke at something besides USB?
  • Improving real-time testing: is there any testing for real time at all?

MC leads

System Boot and Security MC

The security of computer systems has been a very important topic for OSes and applications for many years. However, only recently has the security of firmware and boot process been taken seriously. For instance, firmware is now often being designed with security in mind and boot processes are evolving. There are many security solutions available with some now becoming common. However, such solutions are often

Given the level of activity in this area, it is now a good time to integrate the many existing approaches and build full, top-down solutions resolving the various problems met by new approaches such as TrenchBoot. For example there are many integration issues between the UEFI and TrenchBoot which have to be discussed and solved.

The goal of this microconference is to foster a discussion about the various approaches taken in the field, and hammer out, if possible, the best solutions for the future.

Perfect MC topics should discuss various designs of available security technologies and/or issues, limitations and solutions encountered during their development process. Below is the list of topics which would be nice to cover. This list is not exhaustive and can be extended if needed.

Expected topics:

  • Continued work on TrenchBoot
  • TrenchBoot and UEFI runtime services
  • Passing the bootloader logs to the kernel/user space
  • LinuxBoot - UEFI support improvements in kernel
  • SMI Transfer Monitor (STM) and its impact on security
  • More topics that cross the firmware/Linux boundary.

MC leads

Android MC

A few years ago the Android team announced their desire to try to set a path for creating a Generic Kernel Image (GKI) which would enable the decoupling of Android kernel releases from hardware enablement. Much progress has been made from previous years meetups at Linux Plumbers, but much more needs to be done.

This year's topics will include:

  • GKI compatibility in Android R, how did it go?
  • Ecosystem:
    • a) experience with GKI
    • b) what's the next phase -- GKI 2.0 in Android S (what is yet to be figured out)
  • Update on Kernel Module Interface (KMI) enforcement tools
  • Upstreaming debt from GKI work
  • DMA-BUF Heaps (vs the ION driver) and DMA API model limitations discussion
  • Patches in common needed to boot the Android Open Source Project (AOSP) with mainline
  • Bootloader standardization
  • Upstream plan for FS updates (sdcardfs, fuse, others) and Virtual A/B partitions
  • SEpolicy integration strategies and tools
  • Protected KVM use in Android
  • Open source package integration in the AOSP

MC leads