Open Source Summit Korea 2026

With the release of Linux 7.0, Rust is no longer considered experimental. New and safer components are expected to be written in Rust in the near future. However, the Linux kernel still contains more than 35 million lines of code written in C. This code will remain critical for years to come and, for the benefit of everyone, must continue to be maintained, improved, and hardened where possible.

In the Linux Kernel Self-Protection Project, we care deeply about this, and we've been advancing kernel hardening upstream for several years. In this presentation, we'll review recent hardening efforts and discuss the challenges we continue to face as we work toward our ultimate goal of eliminating classes of bugs and methods of exploitation in the upstream Linux kernel.

The Linux Kernel is one of the most influential and widely-used open source software projects today. However, getting started -- understanding the code and contributing to it -- can be quite daunting. Kernel code often carries history and conventions that are not always documented, but are rather shared by the community as tribal knowledge. Moreover, understanding operating-system-level source code comes with its own unique challenges: there is no libc, you need to know about low-level primitives like memory barriers and various types of locking mechanisms, and memory handling errors can bring the whole system down (no garbage collection either, of course!).

The Linux Kernel Mentorship Program (LKMP) addresses some of these difficulties and aims to mentor prospective contributors to overcome the initial hurdle -- because everything becomes easier after your first contribution. The program is led by experienced kernel maintainers with the assistance of regular contributors and is open to anyone.

In this talk I will detail my experience as an LKMP mentee and explain how I have progressed since. I will also explain how you can get started with a small patch!

GPU compute resources remain inaccessible to the Linux kernel without userspace runtimes (ROCm, CUDA), forcing network packet processing to stay CPU-bound regardless of available GPU capacity.
We present KNOD (in-Kernel Network Offload Device), a Linux kernel framework that enables GPU-accelerated network packet processing entirely within the kernel. KNOD compiles and launches GPU kernels natively, dispatching packet processing workloads directly to the GPU — no ROCm, no userspace involvement, using only publicly documented hardware interfaces.
XDP offload is KNOD's first use case. Building on our LPC 2025 talk, this talk covers: in-kernel GPU kernel compilation targeting AMD GFX9/Vega ISA with post-processing optimizations (latency: ~118µs → ~46µs); a lock-free GPU-side queue between NIC RX path and GPU compute; and branch divergence mitigation to maximize SIMT utilization across heterogeneous packet flows.
At equivalent throughput (~32 Mpps), KNOD reduces system-wide CPU utilization from 40% (CPU-based XDP) to 17-20%. We discuss lessons from MACsec/WireGuard offload attempts and the path toward KNOD as a general kernel framework for GPU-accelerated network functions.

Explore advanced Linux perf techniques for sophisticated performance analysis. This session delves into specialized areas beyond typical CPU profiling:

* Data Type Profiling: Learn how to associate memory access hotspots with specific data structures and fields, gaining insights into data layout efficiency.
* Latency Profiling: Discover methods to identify and analyze serial execution segments within parallel programs that act as scalability bottlenecks.
* Kernel Lock Contention profiling: Understand how to use perf to detect and analyze kernel-level lock contention issues.
* And more..

This talk will cover the concepts and perf tool methodologies to diagnose these critical performance aspects in both user-space and kernel contexts, empowering you to pinpoint elusive performance problems.

Running unmodified x86-64 binaries on ARM64 and RISC-V Linux systems remains important, but existing solutions often involve high overhead or depend on platform-specific hardware. Box64 addresses this gap with a wrapping-first architecture that prioritizes native execution by routing calls into host libraries through ABI translation, while reserving JIT compilation for guest code that cannot be directly mapped.

This session presents the core design of Box64 in three parts. First, a native wrapping layer that spans hundreds of libraries, handling entry-point interception and callback bridging. Second, a multi-pass JIT compiler that applies optimizations such as flag liveness analysis and deferred flag computation. Third, system-level integration techniques that enable practical deployment, including container bypass, mixed-bitness coordination with Wine, and memory ordering support on weakly ordered architectures.

We will also share performance results on ARM64 and RISC-V platforms, showing how Box64 achieves near-native performance in favorable cases and significant speedups over traditional emulation approaches.

The advent of heterogeneous memory like CXL allows systems to secure additional bandwidth, but effectively utilizing it remains challenging. While widely adopted memory tiering optimizes latency by migrating hot pages to fast memory, bandwidth-intensive workloads require utilizing multiple memory tiers simultaneously.

To address this, Weighted Interleaving was introduced to distribute pages proportionally based on each node's bandwidth. However, it has a critical limitation: it ignores the physical topology of multi-socket systems, often leading to inefficient cross-socket memory accesses.

To resolve this, we introduce Socket-aware Weighted Interleave, an advanced memory policy currently being upstreamed to the mainline Linux kernel. It recognizes multi-socket boundaries, preventing performance degradation from unintended remote accesses and maximizing total throughput via localized allocation.

This advanced policy is a newly integrated feature of HMSDK, an open-source toolkit introduced last year. This session will focus primarily on this new capability, exploring how HMSDK efficiently manages large-scale CXL and heterogeneous memory systems.

Applications often run faster on a 64K page size kernel than on 4K. This is because larger pages reduce TLB pressure and pagetable walk overhead, greatly improving memory access speed. But, sysadmins are hesitant to use a 16K/64K kernel as most applications have been historically tuned for 4K pages, and larger pages can increase memory waste due to internal fragmentation. This creates a tradeoff between performance and memory waste.

We propose a design that changes the game by separating the page size of the user and the kernel. Instead of enforcing a single system-wide page size, processes can operate under different page-size ABIs. A performance-critical app can use a 64K page-size ABI while still running on a 4K kernel. We achieve this by enabling Linux to provide memory in 64K chunks via 16 contiguous 4K pages, and by translating operations on the 4K page table into a 64K “native” page table that serves as the actual hardware page table.

At the same time, lightweight or memory-sensitive applications can continue using 4K pages to minimize memory waste. All of this happens on the same Linux kernel, without requiring separate builds of the kernel.

Stateless video decoding has become the standard approach in V4L2 using the Request API, but implementing a stateless decoder driver remains complex. It requires careful handling of codec parameters, buffer management, and coordination between userspace and the kernel.

This session presents a practical overview of implementing a stateless V4L2 decoder driver based on real development experience. It covers how SPS/PPS and per-frame parameters are passed from userspace, how reference frames are managed, and how hardware constraints are handled within a generic V4L2 framework.

We also discuss common pitfalls such as synchronization issues and buffer lifecycle management, and highlight key differences from traditional stateful decoders.

Attendees will gain a clear understanding of stateless decoder architecture and practical insights for developing robust V4L2 drivers.