Open Source Summit + AI_dev Japan 2024

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.

The announcement that the kernel LTS period would be two years came as a shock to embedded Linux developers (especially in Japan). However, it was also the moment that they had been relying on the kernel maintainers.Hirotaka wondered what we could do for the maintainers who worked so hard to maintain the kernel LTS, and started "Linux Kernel LTS Study Group" in Japan.A number of issues came up, including those related to kernel testing, the product development period and LTS period, and upgrading kernel versions. In this session, he will share the summary of discussions with in-house kernel developers working in Japanese companies and some examples of Open Source projects that can help you solve them, and encourage what other in-house kernel developers or just user can do as a first step for the kernel community.

Many products and services are dependent on the Linux Kernel. Because of this the Linux Kernel has to be tested on many different hardware to ensure the stability and reliability of these products or services, this is why KernelCI needs more collaboration both from users and companies. The Linux Kernel upstream community has requested more contributions from companies and users, in particular on the testing ecosystem, such as adding and reporting test results. By understanding corporate usage, the community can more easily provide support and collaborate effectively. KernelCI is one of the current main Kernel testing frameworks and is helping ensure the quality, stability and long-term maintenance of the Linux kernel. As a member of the KernelCI Technical Steering Committee (TSC), I will give details on KernelCI developments and directions. I will talk about current KernelCI new projects. I will talk about KCI tool usage and how it is possible to test own patches with the current KernelCI API and running the test privately. This session will provide useful information for people interested in adopting KernelCI and encourage them to contribute to KernelCI.

CXL memory offers the promise of increased memory capacity, which addressing the limitations of conventional DDR DRAM, and also features a memory pool that allows users to dynamically adjust memory allocation based on workload needs. The Linux community has been rapidly developing many CXL features. Additionally, users can try a CXL memory environment with QEMU emulation without actual CXL hardware. This allows users to experiment with CXL memory features in an emulated environment. However, there are some difficulties and considerations when using CXL memory. For example, you cannot use CXL (2.0 or later) memory devices without configuring them using the "cxl create-region" command. Moreover, if you want to utilize memory interleave to achieve optimal performance, you need to understand the hardware topology, including the CXL switch, and reconfigure the region for CXL volatile memory at every boot time. While development is ongoing, these features may be improved in the future. However, there are still many difficulties for users at present. This talk will cover how to use CXL memory and its emulation.

Recent security updates to Linux, such as the new Systemd Unified Kernel Image[1] rely on the discrete or firmware integrated TPM (Trusted Platform Module) to verify boot and release secrets securely. However, there are many known attacks against the TPM chip itself. We will discuss the newly upstreamed Linux Kernel TPM security patches[2], which not only provide a basis for securely communicating with the TPM but also provide a novel defences against a wide variety of TPM based attacks by using a unique (to Linux) null key scheme. This talk will cover what TPM based attacks are (including interposer attacks), how the Trusted Computing Group expects you to tell you're talking to a real TPM and how you can communicate with it securely and use its policy statements to govern key use and release. We will then move on to how the new Linux Kernel patches extend this and can be leveraged to validate the TPM on every boot and continually monitoring it for any TPM interposer substitutions in real time. [1] https://github.com/uapi-group/specifications/blob/main/specs/unified_kernel_image.md [2] https://lore.kernel.org/all/20240429202811.13643-1-James.Bottomley@HansenPartnership.com/

bpftrace is a popular and powerful dynamic tracer for Linux systems. In the vast majority of uses cases, bpftrace does its job quickly, efficiently, and accurately. However with the rapid growth of users, use cases, and features, the bpftrace community has started to feel (technical) growing pains. In particular, we've started to uncover various reliability issues. In this talk, we will cover what is already done as well as what is currently broken and how we will systematically fix and prevent these issues from re-occuring. Because bpftrace sits at the intersection of operating systems, compilers, and observability, we have the fortunate advantage of being able to absorb techniques and tricks from these fairly different disciplines. We hope that some of the knowledge we share will be both interesting as well practical to attendees. Audience participation is highly welcome. In particular, we are quite interested in receiving feedback in the form of bug reports, feature requests, complaints, etc.

Since its introduction 10 years ago, eBPF has steadily gain grounds in networking, tracing, observability, and security applications. But a great technology cannot not thrive on the technical part alone, the people part matters, too. This session hopes to bring eBPF user, developers, and enthusiasts together to exchange novel ideas, discuss best practices, share pain points, and most importantly, collaborate and grow together as a community.

Linux is incredibly versatile, being a major player in server, mobile and embedded systems, yet your average person can comfortably live their entire life never even seeing a desktop or laptop running Linux. It's hard enough for individual users to overcome this intertia, but it's even harder for organisations. Implementing desktop Linux reaps rewards like digital sovereignty, security, cost reductions and more, but it takes you out of the cozy Windows ecosystem. This talk is an high level overview of what a corporate journey to desktop Linux can look like, the problems that have to be solved along the way, from provisioning to configuration management and most importantly why these migrations fail. It will draw on the speaker's experiences of managing a Linux Desktop estate, and from the wider community.

trace-cmd is a front end tool to the tracefs infrastructure as well as ftrace (the mechanism that supplies function tracing). But like all tools, it's limited in what it can provide by the interface it has. Luckily, the guts of trace-cmd is being extracted into libraries. The libtracefs library is an interface to facilitate any application to access the tracefs kernel interface. This makes it easy for applications enable tracing of various events with various filters. Then there's the libtracecmd library that can be used for creating and reading the trace.dat file (the file that trace-cmd creates). By using this library, you can enable tracing on a system and then do offline analysis. Finally, there's a new library called libtraceeval that is used to help keep track of the interactions of various trace events. This talk will show some simple tools that utilize these libraries (for example, a tool that shows how much tasks are sleeping, blocked, running, and preempted). And also show i bit of the interface of the libraries to demonstrate how simple they really are.

This year, we have seen several events related to Open Source security. Marta will inventory the main events and show us what we have learned. - The xz backdoor scandal shed light on sole maintainers and the risks to their projects yet again. - The Linux kernel and several other projects have become CVE Numbering Authorities (CNAs). At the same time, the National Vulnerability Database (NVD) database is facing difficulties. - The SBOM generation is rising, and people are discussing how to actually use that generated data. And SPDX3 has been released. - The European mandatory cyber security regulation Cyber Resilience Act is reaching completion, with similar laws showing up around the world - Without forgetting a list of vulnerabilities, exploited or not

This LinuxCon presentation explores recent advancements in the Linux VFIO, IOMMU, and PCI subsystems, crucial for device passthrough and virtualization. It delves into the evolution of VFIO, covering improvements in device assignment, mediated devices, and user-space drivers. IOMMU's role in device isolation and security is examined, highlighting new features and best practices. The PCI subsystem's hotplug capabilities, resource optimizations, and emerging standards like SR-IOV are discussed. Real-world use cases and demonstrations showcase these technologies in cloud gaming, HPC, and embedded systems. Attendees will gain deeper understanding and learn about cutting-edge developments, fostering collaboration and driving the advancement of device passthrough in the Linux ecosystem.

There is a lot of work around how to achieve good real-time on Linux, but not as much on how to simulate faults such as jitter in the system, deadline misses or other faults. Without this it is difficult to test how your application or entire system copes with these problems. As part of work with a number of clients, especially in the safety sphere, questions have come up on how to test processes which rely on real-time scheduling. If we have a way of injecting faults we can reliably test error handling and other mitigations. Mitigations such as throttling, restarting or some measured shutdown of services. We will go through some methods we evaluated for fault injection via both user and kernel space. How existing kernel features can be used and what needs to be done in the way of either configuring or extending kernel features. There will be discussion about how each method works and the comparative merits where overlaps exist. We hope that this can help to promote thinking and improvements on how the scheduler and particularly real-time scheduling is tested under Linux.