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.

The Linux desktop system boasts strong customization and freedom, but its application ecosystem has long been a weakness. Recently, the Android system has millions of applications, covering all aspects of work and life. If we could integrate these and create a brand-new desktop experience, what kind of impact would it have?

This presentation will introduce our open-source project - OpenFDE (Open Fusion Desktop Environment). This is an innovative desktop environment that integrates the Android open-source project (AOSP) deeply with Linux applications, enabling users to run various Android applications seamlessly on their Linux desktops.

We will share:
1、Project Vision: Why did we choose AOSP and Linux integration? What problems are we aiming to solve?
2、Core Architecture: How do we achieve the integration of these two major systems? In-depth analysis of the key technologies of OpenFDE in terms of graphics, window management, and application lifecycle.
3、Live Demonstration: Witness firsthand the smooth coexistence of Linux and the latest Android applications (including large-scale games) in the OpenFDE environment.

In modern cloud environments, CPU usage often looks healthy while applications still experience latency and unpredictable slowdowns. In one Kubernetes based system running latency sensitive workloads, services degraded despite CPU staying below 50%. Traditional monitoring showed no clear issue, leading to delayed debugging and reactive fixes.

This case study highlights how the real bottleneck was hidden in the Linux scheduler specifically run queue contention and scheduling delays. By examining run queue depth and task scheduling behavior, the team uncovered how fairness-driven scheduling (CFS) impacted performance under load. The session also touches on how newer approaches like EEVDF aim to improve scheduling decisions.

The result was faster root cause identification, better workload tuning, and improved application responsiveness without scaling resources.

Key Takeaways:

- Why CPU utilization can mislead performance analysis
- How run queue depth and scheduling latency impact applications
- The gap between fair scheduling and real-world performance
- What’s changing in modern schedulers (CFS > EEVDF)
- Practical ways to reason about scheduler related bottlenecks

Service operators often face a constant friction: maintaining high Service Level Indicators (SLIs) versus addressing immediate security vulnerabilities. While userspace updates cause minimal disruption, mitigating Linux kernel vulnerabilities traditionally mandates a full system reboot, forcing administrators into the dilemma of choosing between proactive security practices and continuous uptime.

This session explores the workings of Linux kernel live patching, details how a livepatch kernel module is built, examines the internal mechanisms that power the technology (e.g., ftrace), and provides a practical overview of the current ecosystem so administrators can start using live patches immediately.

Modern Linux init systems don't just magically start executing services. Long before PID 1 reaches its main loop, a complex, carefully orchestrated dance of initialization routines takes place. This presentation explores the crucial, often-overlooked machinery bridging the compiler toolchain and system orchestration: the linker.

Often treated as a black box, the linker (ld) is an immensely powerful tool for low-level systems engineers. This deep dive pulls back the curtain on how modern init architectures leverage custom linker scripts, specifically defined ELF sections, and compiler directives (like __attribute__((constructor))) to precisely control execution order and optimize memory layouts before the system fully comes alive.

Catching transient performance drops is notoriously hard; by the time you attach a profiler, the bottleneck is often gone. Continuous tracing is the solution, but manually analyzing the resulting massive data is a huge hurdle.

This session introduces a practical methodology for always-on performance monitoring and automated analysis using Guider. First, we demonstrate how Guider efficiently profiles system performance in the background with minimal overhead. Upon detecting an anomaly, it automatically generates a retroactive report using trace data captured just before the event.

We will then show how to feed these structured reports into an AI pipeline. Instead of manually deciphering complex kernel metrics, you will see how AI instantly pinpoints the root cause of performance regressions.

Attendees will learn to build a continuous monitoring pipeline that automatically turns raw trace data into real-time, actionable insights.

What if you could replace your entire OS userspace — binaries, configs, services, even init itself — without ever stopping the kernel? No firmware POST, no hardware re-init, no multi-minute downtime. Just a clean userspace restart in seconds.

That's what soft-reboot (systemctl soft-reboot), implemented in systemd, delivers: a primitive that tears down all of userspace, pivots into a fresh root filesystem, and re-launches PID 1 — while the running kernel stays untouched.

This talk unpacks how soft-reboot works under the hood, why it matters for modern OS update workflows, and how it compares to a traditional reboot and kexec. We'll walk through real production use cases: zero-downtime OS updates, staged fleet rollouts, and rapid recovery from a wedged userspace — without paying the cost of a full boot cycle.

Attendees will leave with a clear mental model of soft-reboot internals, practical guidance on when to choose it over a full reboot or kexec, and concrete patterns for building soft-reboot-aware update pipelines.

If you've ever wished you could ship an OS update as fast as restarting a service, this talk is for you.