{"schedule": {"version": "2026-10-05T01:10:46+02:00", "conference": {"acronym": "prague2026", "title": "Prague 2026: LPC + OSS/ELC Europe", "start": "2026-10-05", "end": "2026-10-09", "daysCount": 5, "time_zone_name": "Europe/Prague", "days": [{"index": 1, "date": "2026-10-05", "rooms": {"Chamber Hall (Floor 3)": [{"guid": "oss-48a294b225e7418b2e7df40daa2060dd", "id": "oss-48a294b225e7418b2e7df40daa2060dd", "title": "ValkeyConf 2026 [Additional Fee; Pre-Registration Required]", "date": "2026-10-05T09:00:00+02:00", "start": "09:00", "duration": "08:00", "room": "Chamber Hall (Floor 3)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "ValkeyConf is a day for anyone running Valkey in production, and those seriously thinking about it. Developers, SREs, DBAs, and DevOps pros come together to talk shop, share hard-won knowledge, and connect with the people building Valkey’s future. Sessions, lightning talks, and plenty of time for real conversation. If you care about where Valkey goes next, this is where it happens.\nTo learn more, visit the event website.\nHow to Register: Pre-registration is required. Register for ValkeyConf as a stand alone event or add it to your Open Source Summit Europe registration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/48a294b225e7418b2e7df40daa2060dd)", "url": "https://osselceu2026.sched.com/event/48a294b225e7418b2e7df40daa2060dd", "persons": []}], "Club A (Floor 1)": [{"guid": "lpc20-c3639", "id": "lpc20-c3639", "title": "Aspects of Dependable Linux Systems", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:10", "room": "Club A (Floor 1)", "track": "LPC: Safe Systems with Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "In regulated industries, Linux is widely used due to its strong software capabilities in areas such as dependability, reliability, and robustness. These industries follow best practices in terms of processes for requirements, design, verification, and change management. These processes are defined in standards that are typically not accessible to the open source kernel community.\r\n\r\nHowever, since these standards represent best practices, they can be incorporated into structured development environments like the Linux kernel even without the knowledge of such standards. The kernel development process is trusted in critical infrastructure systems as it already covers many process elements directly or indirectly.\r\n\r\nThe purpose of this session is to initiate a discussion on what is currently available and what may be missing in order to enhance the dependability and robustness of Linux kernel-based systems. How can the artifacts be connected? Where are the appropriate places to maintain them? And who is the best responsible for each element of the development lifecycle?\n\n**Attachments:**\n- [20261005_LPCMC_SafeLinux_Aspects of Dependable Linux Systems.pptx.pdf](https://lpc.events/event/20/contributions/2493/attachments/2004/4534/20261005_LPCMC_SafeLinux_Aspects%20of%20Dependable%20Linux%20Systems.pptx.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2493/)", "url": "https://lpc.events/event/20/contributions/2493/", "persons": [{"public_name": "Philipp Ahmann"}, {"public_name": "Kate Stewart"}]}, {"guid": "lpc20-c3640", "id": "lpc20-c3640", "title": "Towards Program Verification of the Linux Kernel Library XArray", "date": "2026-10-05T10:15:00+02:00", "start": "10:15", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Safe Systems with Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "XArray is a data structure used in many Linux kernel components, most notably the page cache. Its API contracts are not precisely documented, making it challenging to understand caller obligations and which invariants any changes to the implementation must maintain over the structure. Since its integration into the Linux source tree in 2019, errors in the use of the library have caused bugs such as memory leaks [1, 2], and the library code itself has suffered from bugs like race conditions and null pointer dereferences [3, 4]. Recent case studies [5, 6] suggest that applying program verification to Linux kernel source code is a promising means to make requirements structured, explicit, and machine-checkable against the implementation. \r\nThis talk presents progress verifying the core load and store APIs of the XArray library. So far, we have verified the xa_load() function and its callees, and are working on the verification of xa_store(). We will discuss how the structured specification of the original library can be used to build confidence in the Rust re-implementation that is under active development [7]. By formalizing and checking the API’s precise contracts, we can validate the parity of the Rust port’s behavior in critical kernel clients. \r\n\r\n[1]  Matthew Wilcox. “mm/huge_memory: Fix xarray node memory leak.” url: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=69a37a8ba1b4\r\n\r\n[2] Yang Yang. “swap_state: update shadow_nodes for anonymous page.” url: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=5649d113ffce\r\n\r\n[3] Matthew Wilcox. “XArray: Disallow sibling entries of nodes.” url: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v6.19&id=63b1898fffcd\r\n\r\n[4] Matthew Wilcox. XArray: Fix xas_create_range() when multi-order entry present. url: https://github.com/torvalds/linux/commit/3e3c658055c002900982513e289398a1aad4a488\r\n\r\n[5] Julia Lawall, Keisuke Nishimura, and Jean-Pierre Lozi. 2024. Should We Balance? Towards Formal Verification of the Linux Kernel Scheduler. SAS 2024.\r\n\r\n[6] Julia Lawall, Keisuke Nishimura, and Jean-Pierre Lozi. 2025. Understanding Linux Kernel Code through Formal Verification: A Case Study of the Task-Scheduler Function select_idle_core. OLIVIERFEST '25.\r\n\r\n[7] Daniel Gomez, \"rxarray,\" commit 0ae6dd57e31d, Linux kernel development tree. url: \r\nhttps://git.kernel.org/pub/scm/linux/kernel/git/da.gomez/linux.git/commit/?id=0ae6dd57e31d9e436ee935288767f53e118db8c0\n\n**Attachments:**\n- [XArrayVerif_CorinnTIFFANY_LPC.pdf](https://lpc.events/event/20/contributions/2540/attachments/2063/4619/XArrayVerif_CorinnTIFFANY_LPC.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2540/)", "url": "https://lpc.events/event/20/contributions/2540/", "persons": [{"public_name": "Corinn Tiffany"}]}, {"guid": "lpc20-c3641", "id": "lpc20-c3641", "title": "Common pitfalls and errors, when using Linux in Safety Applications", "date": "2026-10-05T10:45:00+02:00", "start": "10:45", "duration": "00:45", "room": "Club A (Floor 1)", "track": "LPC: Safe Systems with Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Safety-oriented use of the Linux Kernel presents a class of obstacles that are normally absent from other types of use, and therefore can be easily overlooked. Sometimes what would normally constitute a strength can actually turn into a weakness. Or aspects that are peculiar of creation of physical products (e.g. cars, robots) can present unexpected challenges.\r\nThis talk wants to raise awareness about these uncommon aspects.\n\n**Attachments:**\n- [Common pitfalls and errors when using Linux in Safety Applications_.pdf](https://lpc.events/event/20/contributions/2492/attachments/2006/4617/Common%20pitfalls%20and%20errors%20when%20using%20Linux%20in%20Safety%20Applications_.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2492/)", "url": "https://lpc.events/event/20/contributions/2492/", "persons": [{"public_name": "Igor Stoppa"}]}, {"guid": "lpc20-c3642", "id": "lpc20-c3642", "title": "Scaling the Design Definition", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Safe Systems with Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The fundamental unit of design is a requirement (i.e. \"testable expectation\"). All forms of design can be expressed as a (directed acyclic) knowledge graph of requirements. A software project that documents its design in this manner can derive both source code and automated test from the same idea. Without this, there is no guarantee that test and implementation reliably reflects the same idea.\r\n\r\nIn virtually all open-source projects, documenting the design to this level of detail is rarely (if ever) considered. While the benefits are easy to understand, retrofitting a design on an existing project and then keeping it up to date is a barrier to entry that few are willing to consider.\r\n\r\nIn this troubleshooting session, Chuck will describe the problem in more detail, answer relevant background questions, and solicit ideas for potential approaches to retrofitting designs and keeping them updated.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2541/)", "url": "https://lpc.events/event/20/contributions/2541/", "persons": [{"public_name": "Chuck Wolber"}]}, {"guid": "lpc20-c3643", "id": "lpc20-c3643", "title": "Defining Linux Kernel Requirements and Test Specifications out of the Kernel Tree", "date": "2026-10-05T12:30:00+02:00", "start": "12:30", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Safe Systems with Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Following the [objections][1] in having requirements and even code documentation traceable to Kernel testing as optional part of the Linux Kernel development process, the ELISA project decided to start defining requirements and test specifications in a separate repository.\r\nThis session will present the current status for the requirements and test specifications framework and traceability to upstream code and test case implementations.\r\n\r\n\r\n  [1]: https://lore.kernel.org/all/2026021207-hatchery-spore-2800@gregkh/\n\n**Attachments:**\n- [LPC 2026_ Defining Linux Kernel Requirements and Test Specifications out of the Kernel Tree.pdf](https://lpc.events/event/20/contributions/2491/attachments/2065/4624/LPC%202026_%20Defining%20Linux%20Kernel%20Requirements%20and%20Test%20Specifications%20out%20of%20the%20Kernel%20Tree.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2491/)", "url": "https://lpc.events/event/20/contributions/2491/", "persons": [{"public_name": "Gabriele Paoloni"}, {"public_name": "Kate Stewart"}]}, {"guid": "lpc20-c3644", "id": "lpc20-c3644", "title": "From Manual Argument to Machine-Readable Graph: Toward a Safety SBOM for Linux", "date": "2026-10-05T13:00:00+02:00", "start": "13:00", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Safe Systems with Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "A safety case is the structured argument that a system is acceptably safe: claims, the evidence supporting them, and the assumptions under which the argument holds. Building and maintaining one is largely manual, and keeping it consistent as a design evolves is harder still.\r\nSPDX 3.1's Functional Safety profile changes the starting point by giving the safety case a machine-readable form. It models requirements and their refinement, verification activities, pass/fail evaluations, evidence, and assumptions of use—the same structure safety practitioners already reason about, now expressed as a graph that tools can produce, exchange, and check.\r\nThis talk introduces the profile and its data model: what each element means, and how claims link to the evidence that supports them and the assumptions they depend on. We show how this representation can be used to generate a safety SBOM for Linux—a safety case generated and recomputed from project content rather than assembled by hand—building on the work of the ELISA Architecture working group and its current efforts on requirements. We argue this graph-based approach is the foundation for an automated handshake between upstream evidence and downstream safety arguments, enabling the kind of contract-style consumption of Linux components that safety-critical projects need.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2490/)", "url": "https://lpc.events/event/20/contributions/2490/", "persons": [{"public_name": "Nicole Pappler"}]}, {"guid": "lpc20-c3645", "id": "lpc20-c3645", "title": "Wrap up", "date": "2026-10-05T13:25:00+02:00", "start": "13:25", "duration": "00:05", "room": "Club A (Floor 1)", "track": "LPC: Safe Systems with Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "\n\n[Open in Indico](https://lpc.events/event/20/contributions/2542/)", "url": "https://lpc.events/event/20/contributions/2542/", "persons": [{"public_name": "Philipp Ahmann"}, {"public_name": "Kate Stewart"}]}, {"guid": "lpc20-c3632", "id": "lpc20-c3632", "title": "Reducing kernel stack memory (on arm64)", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Kernel Memory Management MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "There have been a bunch of attempts [1] to reduce the memory consumed by kernel stacks for x86 and arm64, largely based around the idea of dynamically growing the kernel stack allocation based on page faults. This poses what appear to be insurmountable challenges, as it introduces complexity into the architecture exception entry code (which needs to be able to transition cleanly to a new stack) but also means that the kernel must be able to allocate memory from any context at all.\r\n\r\nI would like to discuss and explore alternatives to dynamic stack allocation based on some initial rework I have started of the arm64 exception entry code[2]. Specifically:\r\n\r\n- Revisiting the decision to move from 8k to 16k stacks\r\n- Changing the kernel stack size at boot time\r\n- Changing the kernel stack size per task\r\n- Controlling the kernel stack size from userspace\r\n\r\nI think it would also be useful to talk briefly about the sticking points with dynamic kernel stacks and whether there is anything that can be carried forward from that work.\r\n\r\nMy motivation is based on Android vendors having various out-of-tree implementations of the dynamic kernel stack series and I would like to see if there are alternatives that we can provide upstream so that we can all stop carrying the broken stuff around in our pockets.\r\n\r\n[1] https://lore.kernel.org/all/20260424191456.2679717-1-stevensd@google.com/\r\n[2] https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=overflow-stack\n\n**Attachments:**\n- [Kernel stack reduction - Will Deacon - LPC 2026.pdf](https://lpc.events/event/20/contributions/2419/attachments/2078/4640/Kernel%20stack%20reduction%20-%20Will%20Deacon%20-%20LPC%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2419/)", "url": "https://lpc.events/event/20/contributions/2419/", "persons": [{"public_name": "Will Deacon"}]}, {"guid": "lpc20-c3634", "id": "lpc20-c3634", "title": "Better Anon (Swap) Readahead", "date": "2026-10-05T15:30:00+02:00", "start": "15:30", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Kernel Memory Management MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "When handling swap page faults, the kernel often don't reads just a single page. For legacy HDDs, an entire cluster is read in. For SSDs, we check the VMA and page tables to see if nearby pages are likely to be needed soon, using a basic statistic-driven heuristic. For compressed RAM (like zram, and potentially soon zswap), traditional readahead is skipped entirely. Meanwhile, enabling (m)THP swap-in currently acts as kind of a speculative fetching.\r\n\r\nThe current implementation is not really ideal. For example, why can't we extend (m)THP support to SSDs by merging readahead detection with (m)THP lookaround? Why can't we enable a lightweight readahead for compressed RAM as well? We also need a smarter heuristic, where workingset shadow entries could provide a much better hint than basic per-VMA statistics?\r\n\r\nWith so much active development in the swap subsystem, the goal of this session is to consolidate these scattered paths, and explore whether the swap readahead mechanism can share common, useful infrastructure.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2421/)", "url": "https://lpc.events/event/20/contributions/2421/", "persons": [{"public_name": "Kairui Song"}]}, {"guid": "lpc20-c3633", "id": "lpc20-c3633", "title": "DMA-buf cgroup accounting for proxy allocators: attributing buffers to the right consumer", "date": "2026-10-05T15:50:00+02:00", "start": "15:50", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Kernel Memory Management MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "On embedded and automotive Linux systems, a single daemon often allocates DMA-buf memory on behalf of other clients. Today, most of that memory is invisible to cgroup accounting, only system-heap buffers can carry a charge via __GFP_ACCOUNT, and even then it lands on the allocator’s cgroup rather than the app that requested the buffer.\r\n\r\nThe misattribution has real consequences on any system that uses cgroup memory limits to drive reclaim or enforce resource budgets, as untracked buffers silently skew pressure signals. For example, on Android, where app memory limits depend on per-app accounting; or on automotive systems, where strict Freedom From Interference (FFI) is a key requirement and a central allocator absorbing the charge of its clients across domains breaks any meaningful resource isolation argument.\r\n\r\nIn this session we will discuss the design space for fixing the proxy-allocator problem, presenting the context from our proposal in upstream. Should the charge be attributed at allocation time, or before export time? Should the allocator identify the target via a pidfd (natural for approaches like Binder, where the allocator already knows the sender_pid) or a cgroupfd? What happens with buffers that may belong to different cgroups across their lifetime?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2416/)", "url": "https://lpc.events/event/20/contributions/2416/", "persons": [{"public_name": "Albert Esteve"}, {"public_name": "T.J. Mercier"}]}, {"guid": "lpc20-c3635", "id": "lpc20-c3635", "title": "Page fault  locking", "date": "2026-10-05T16:10:00+02:00", "start": "16:10", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Kernel Memory Management MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "In 2023 we introduced per-VMA locks to solve contention and priority inversion on the mmap_lock for multithreaded programs.  While successful, the initial implementation did not solve every case of contention and some workloads can still demonstrate problems.  This session will discuss ways of fixing the remaining problems.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2415/)", "url": "https://lpc.events/event/20/contributions/2415/", "persons": [{"public_name": "Matthew Wilcox"}]}, {"guid": "lpc20-c3636", "id": "lpc20-c3636", "title": "Direct map fragmentation", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Kernel Memory Management MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "On supported configurations, the direct map is built using large\r\nPMD/PUD-level block mappings. This is expected to bring many of the\r\nbenefits of hugepages: improved TLB hit rate, less page table walking,\r\nsmaller page table memory footprint.\r\n\r\nThis optimisation is most effective when the direct map gives access to\r\nthe entire physical memory with uniform permissions. Unfortunately, a\r\ngrowing number of features need to remove pages from the direct map or\r\nmodify permissions/attributes at page granularity, causing PMD/PUD\r\nblocks to be split down to PTEs.\r\n\r\nAccording to results presented by Mike Rapoport at LSF/MM 2023 [1], the\r\nperformance impact of such fragmentation is negligible for data\r\naccesses. However, recent measurements on x86 and arm64 suggest a more\r\nnuanced picture, and other factors such as power consumption should also\r\nbe considered.\r\n\r\nThis session will briefly summarise key results, and then discuss\r\npossible ways to reduce fragmentation.\r\n\r\nQuestions for discussion:\r\n\r\n* Should direct map permissions be modelled as an allocation property\r\n  in the buddy allocator, or managed by higher-level interfaces such as\r\n  execmem or secretmem?\r\n* Can x86 and arm64 use common logic for splitting and coalescing pages?\r\n\r\nA few interesting sources of direct map fragmentation:\r\n\r\n* execmem (may use PMD-sized pools; direct map PMDs will still be split\r\n  if writing code)\r\n* secretmem\r\n* Confidential VMs including guest_memfd (encrypted/unmapped pages)\r\n* pkeys-based page table protection\r\n\r\nProposals to reduce fragmentation:\r\n\r\n* 2021/01 - PMD-sized pools for secretmem [2]\r\n* 2021/04 - Grouped vmalloc [3]\r\n* 2023/03 - `__GFP_UNMAPPED` based on dedicated cache [4]\r\n* 2026/02 - pkeys-protected page table pools [5]\r\n* 2026/03 - `__GFP_UNMAPPED` based on migratype/pageblock [6]\r\n* 2026/06 - Collapsing blocks in secretmem [7]\r\n* 2026/06 - EXECMEM_ROX_CACHE for arm64 with direct map PMD coalescing [8]\r\n\r\n[1] https://lwn.net/Articles/931406/\r\n[2] https://lore.kernel.org/lkml/20210121122723.3446-8-rppt@kernel.org/\r\n[3] https://lore.kernel.org/lkml/20210405203711.1095940-1-rick.p.edgecombe@intel.com/\r\n[4] https://lore.kernel.org/all/20230308094106.227365-1-rppt@kernel.org/\r\n[5] https://lore.kernel.org/linux-hardening/20260227175518.3728055-1-kevin.brodsky@arm.com/\r\n[6] https://lore.kernel.org/lkml/20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com/\r\n[7] https://lore.kernel.org/all/20260603104624.36390-1-lance.yang@linux.dev/\r\n[8] https://lore.kernel.org/all/20260611130144.1385343-1-abarnas@google.com/\n\n**Attachments:**\n- [LPC26_direct_map_fragmentation.pdf](https://lpc.events/event/20/contributions/2420/attachments/2057/4611/LPC26_direct_map_fragmentation.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2420/)", "url": "https://lpc.events/event/20/contributions/2420/", "persons": [{"public_name": "Kevin Brodsky"}]}, {"guid": "lpc20-c3637", "id": "lpc20-c3637", "title": "Accelerating Page Migration and Making the Migration Core Composable", "date": "2026-10-05T17:30:00+02:00", "start": "17:30", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Kernel Memory Management MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "As the memory hierarchy deepens at both ends, with HBM adding a faster tier on top and CXL adding cheaper, slower capacity below, keeping hot data in the fast tier and shedding cold data downward makes page migration central to NUMA, tiered-memory and coherent CPU-GPU systems (where device memory is exposed as NUMA nodes).\r\n\r\nProfiling move_pages(2) on EPYC Zen 6 shows that the folio copy dominates migration (~96% of time for a 2MB THP), making it the primary scaling bottleneck. Yet this path is largely sequential: folios are copied one at a time by a single CPU, while DMA engines, idle cores and memory bandwidth go unused.\r\n\r\nTo tap that idle hardware, this work separates the folio content copy from the rest of migration and hands it to a pluggable migrator. The batch path:\r\n - unmaps a batch of folios and flushes the TLB once,\r\n - asks a migrator to copy the eligible folios,\r\n - marks copied folios so the move phase skips the per-folio copy,\r\n - completes the move through the existing flow [1].\r\n\r\nA faster copy is not the whole story: lower rmap overheads, a simpler migration architecture and a composable core matter just as much. The work therefore proceeds in three directions: accelerating the dominant copy phase, batching the rmap walks and restructuring the migration core so that these and other independent optimizations compose instead of becoming special cases.\r\n\r\nAccelerating the copy\r\n---------------------\r\n\r\nThree complementary, measured directions:\r\n1. dcbm - a DMA-based migrator using dmaengine devices, for bulk copy across multiple channels.\r\n2. mtcopy - multi-threaded CPU copy on idle cores, a software fallback where no DMA/offload engine is available [9].\r\n3. Bulk folio_copy() for large folios: one copy over the contiguous range, independent of the batch and offload framework [2].\r\n\r\nMeasured with move_pages() on 1GB anonymous memory, DRAM -> DRAM, batch copy offload makes 2MB THP migration several times faster: ~6x with PTDMA (Zen 3, 16 channels), ~3.5X with SDXI (Zen 6, 1 channel) and ~3.8x with multi-threaded CPU copy (Zen 3, mtcopy, 8 threads).\r\n\r\nSeparately, a related demotion effort uses non-temporal stores to reduce cache pollution and CXL-side read traffic [3].\r\n\r\nBeyond the copy: the rmap phase\r\n-------------------------------\r\n\r\nOnce the copy is offloaded, rmap work dominates for PTE-mapped large folios (mTHP) because the unmap and restore walks handle each PTE separately. Batching those walks is the next lever, and its payoff grows with folio size: on Zen 3, a 1MB folio reaches ~5.6x over vanilla with DMA offload and rmap batching, compared to ~2x with offload alone [7].\r\n\r\nReworking the core so these compose\r\n-------------------------------------\r\n\r\nSeveral efforts optimize different migration phases, and each one adds flags or special cases to the current monolithic path [1][3][4]. They also run into the same limitation: ->migrate_folio() receives only enum migrate_mode, which describes the blocking semantics but not the migration intent (for example, promotion versus demotion). So, new behavior ends up either extending migrate_mode or going through a side channel. For example, non-temporal demotion added MIGRATE_ASYNC_NON_TEMPORAL_STORES, while the DMA offload records FOLIO_CONTENT_COPIED in migrate_info.\r\n\r\nTwo changes are posted as RFC[8]:\r\n\r\n1. Pass a small context struct (migrate_control) through migrate_pages() into ->migrate_folio(), carrying mode, reason, and room for future attributes. This separates blocking behavior from intent, so the copy phase knows why the folio is migrating and copy policy (cached, non-temporal, offload, and so on) can follow.\r\n\r\n2. Split the single list in migrate_pages() into separate classes, each with its own list and retries: hugetlb folios, movable_ops pages and LRU folios. This removes the type checks scattered through the shared batch path and makes the flow easier to follow.\r\n\r\nDiscussion\r\n----------\r\n\r\nI'd like to use the session to validate the direction of the migration core work and how ongoing efforts should fit together.\r\n\r\nKey questions:\r\n\r\n- Interface: should migrate_pages() and ->migrate_folio() take a context struct? It touches every caller and callback. Is that one-time churn acceptable, and is this the right shape?\r\n- Policy: Should each policy, such as cache intent, be stated explicitly by the caller, or should the core derive it from the migration reason?\r\n- Core structure: is the per-class migration model right shape for maintainability? movable_ops pages still use page->lru, new_folio_t, put_folio_t. What should a non-folio migration interface look like?\r\n- Synchronous fallback: after the async pass, should the remaining folios be retried through a direct single-folio path, or should they keep reusing migrate_pages_batch() and avoid a second single-folio path?\r\n- Copy helpers: there is no range version of copy_page() for bulk folio copy. memcpy() works, but without FSRM on x86 it falls back to an unrolled movq loop instead of copy_page()'s rep movsq. Should we add copy_pages(), like clear_pages()?\r\n- Engine selection: who should select the copy engine: the caller, the provider (as in the current RFC), or the core, based on caller constraints and provider capability? Should folio size, batch size or topology drive that choice?\r\n- Batching trade-offs: What is an acceptable trade-off between throughput and first-folio latency? Should the batch limit be a tunable per platform?\r\n\r\nRoadmap:\r\n\r\nMigration core redesign and context passing; migration-side rmap batching, bulk copy within large folios, batch copy and DMA offload, Scatter-gather copy (DMA_MEMCPY_SG); SDXI migrator [6] and DCBM driver; topology-aware thread placement for multi-threaded copy and CPU accounting for multi-threaded copy; hot page promotion (pghot [5]) reusing the offload path.\r\n\r\nReferences\r\n-----------\r\n[1] Migration batch/offload, RFC V6: https://lore.kernel.org/all/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com\r\n[2] Bulk folio_copy optimization, RFC v1: https://lore.kernel.org/all/20260427142036.111940-4-shivankg@amd.com\r\n[3] Non-temporal demotion, RFC V2: https://lore.kernel.org/linux-mm/20260730-rfc-nt-demote-v2-0-452dbe3b5073@zptcorp.com/#t\r\n[4] migrate_mode/migrate_folio() ABI extensibility (Memory Hotness and Promotion call):\r\n    https://lore.kernel.org/linux-mm/37010218-ecad-4f75-961d-686d51b6677d@amd.com\r\n[5] pghot, V8: https://lore.kernel.org/all/20260728054356.291998-1-bharata@amd.com\r\n[6] SDXI, V3: https://lore.kernel.org/all/20260605-sdxi-base-v3-0-4d38ca2bdffe@amd.com\r\n[7] Migration-side rmap batching, RFC V2: https://lore.kernel.org/linux-mm/20260813-migrate-rmap-batch-v2-0-3c5424c555c7@amd.com\r\n[8] Migration redesign and policy, RFC V1: https://lore.kernel.org/linux-mm/20260902-migrate-refactor-shivank-v1-0-9dcca87669c4@amd.com\r\n[9] mtcopy RFC v3: https://lore.kernel.org/all/20250923174752.35701-7-shivankg@amd.com\n\n**Attachments:**\n- [mm-migrate-lpc2026-slides.pdf](https://lpc.events/event/20/contributions/2417/attachments/2055/4609/mm-migrate-lpc2026-slides.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2417/)", "url": "https://lpc.events/event/20/contributions/2417/", "persons": [{"public_name": "Shivank Garg"}, {"public_name": "Zi Yan"}]}, {"guid": "lpc20-c3638", "id": "lpc20-c3638", "title": "Tackling Isolation Issues Due to Memory Pressure", "date": "2026-10-05T18:00:00+02:00", "start": "18:00", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Kernel Memory Management MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "On a densely shared host, a routine event breaks tenant isolation: a task holding a shared kernel lock (filesystem metadata, a control-plane mutex/rwsem) allocates *inside* the critical section, the allocation falls into memory reclaim, and until reclaim finishes every other task waiting on that lock — from any cgroup — pays the stall. Shared kernel locks aren't mediated by cgroups or memcg limits, so this is cross-tenant priority inversion, and overcommit makes it worse.\r\n\r\nIn this talk we will present the data we have gathered across the Meta fleet on this problem, and share how we think the solution should take shape. Rather than a finished design or patch series, the goal is to lay out the problem space, the constraints any fix must satisfy, our current direction, and the open questions and to get early feedback from the upstream community.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2418/)", "url": "https://lpc.events/event/20/contributions/2418/", "persons": [{"public_name": "Shakeel Butt"}]}], "Club B": [{"guid": "lpc20-s3521", "id": "lpc20-s3521", "title": "Nova GPU & DRM Rust Workshop", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "03:30", "room": "Club B", "track": "LPC: Nova GPU & DRM Rust Workshop", "type": "LPC Workshop", "language": "en", "abstract": "", "description": "This workshop will center on Nova, the upstream Rust-based kernel driver for NVIDIA GPUs, and on Rust in the DRM subsystem in general.\r\n\r\nOn the Nova side, discussion topics will include the design and evolution of the firmware APIs exposed by the GPU System Processor (GSP), in particular the new GMC APIs, as well as user-space submission interfaces, compute APIs, and interactions with the core kernel (device / driver APIs; locking and lifetimes; memory management APIs). Beyond Nova, the workshop will cover the shared Rust DRM infrastructure — device / driver core and initialization, TTM/GEM, GPUVM, job submission and scheduling — and how to properly tie these components into driver lifecycle design.\r\n\r\nPotential key participants are members of the Nova team at NVIDIA and Red Hat, contributors from the DRM and Rust-for-Linux communities, and developers of parallel Rust driver efforts such as Tyr (Arm, Collabora, Google), the Asahi AGX driver, and rvkms.\r\n\r\nThe workshop aims to keep Nova and the Rust DRM infrastructure closely tied to the needs of the graphics / compute stack in Linux, and to foster collaboration around shared challenges in GPU driver design.\n\n[Open in Indico](https://lpc.events/event/20/sessions/277/)", "url": "https://lpc.events/event/20/sessions/277/", "persons": []}, {"guid": "lpc20-c3556", "id": "lpc20-c3556", "title": "Debugging CPU isolation / nohz_full", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "Installing a CPU isolated workload for extreme low-latency expectations can be challenging. Requirements and settings have been recently documented upstream but practice is another story. Let's discuss that around a live example.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2381/)", "url": "https://lpc.events/event/20/contributions/2381/", "persons": [{"public_name": "Frederic Weisbecker"}]}, {"guid": "lpc20-c3554", "id": "lpc20-c3554", "title": "Rust for Linux Office Hours", "date": "2026-10-05T15:45:00+02:00", "start": "15:45", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "A Rust-related BoF to work together on several topics, to answer questions or resolve pain points from attendees, to get to know people interested in Rust and Rust for Linux and generally to have some more time for discussion on top of the Rust MC.\r\n\r\nThe list of topics will be developed closer to the conference (and more may be added during the conference too), but some examples of potential topics would be:\r\n\r\n  - Review and discussion of particular patch series.\r\n  - Prototyping of a small project, e.g. implementing a kernel module.\r\n  - Providing assistance with `pin-init` and Klint.\r\n\r\nPlease feel free to join!\n\n[Open in Indico](https://lpc.events/event/20/contributions/2382/)", "url": "https://lpc.events/event/20/contributions/2382/", "persons": [{"public_name": "Alice Ryhl"}, {"public_name": "Andreas Hindborg"}, {"public_name": "Benno Lossin"}, {"public_name": "Boqun Feng"}, {"public_name": "Danilo Krummrich"}, {"public_name": "Gary Guo"}, {"public_name": "Miguel Ojeda"}]}, {"guid": "lpc20-c3555", "id": "lpc20-c3555", "title": "BoF: Memory Efficiency on Modern Linux Systems", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "Discussion on how organizations are managing the complex tradeoffs related to efficient use of memory resources in heterogeneous workload, large-scale datacenter environments. Especially, as DRAM prices have exploded.\r\n\r\nWhat guidance and future feature development should the community provide to support efficient use of this resource?\r\n\r\n- zswap\r\n- proactive reclaim agents\r\n- DAMON\r\n- PSI\r\n- memory tiering\r\n- memcg \r\n- etc.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2383/)", "url": "https://lpc.events/event/20/contributions/2383/", "persons": [{"public_name": "Mykolas Krupauskas"}]}, {"guid": "lpc20-c3553", "id": "lpc20-c3553", "title": "Updates and Future Directions for Resctrl RDT/MPAM/PQOS/CBQRI", "date": "2026-10-05T17:45:00+02:00", "start": "17:45", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "Significant progress has been made on the resctrl subsystem recently, driven by architectural evolutions across multiple hardware vendors. Key developments include Intel's separate control and monitor domains, ARM's IOMMU, NVIDIA's CPU-less MPAM support and MBW MAX hard limits, AMD's monitor counter assignment, and initial RISC-V inclusion.\r\n\r\nFollowing last year's highly productive BoF, which successfully guided upstream development over the past several months, this session will bring the broader resctrl ecosystem together again—including maintainers and developers from Intel, ARM, NVIDIA, AMD, RISC-V, Google, Fujitsu, and Alibaba. While we will briefly review recent milestones, the primary focus of this session will be face-to-face discussion to address current architectural bottlenecks, maintain a clean cross-architecture abstraction layer, and reach consensus on future upstream design paths.\n\n**Attachments:**\n- [resctrl_2026_combined.pdf](https://lpc.events/event/20/contributions/2368/attachments/2066/4625/resctrl_2026_combined.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2368/)", "url": "https://lpc.events/event/20/contributions/2368/", "persons": [{"public_name": "Fenghua Yu"}, {"public_name": "Ben Horgan"}, {"public_name": "Reinette Chatre"}]}], "Club D": [{"guid": "lpc20-c3744", "id": "lpc20-c3744", "title": "AF_XDP BoF", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:45", "room": "Club D", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "AF_XDP has grown considerably in functionality and hardware support,                                            but recent netdev discussions have exposed gaps in semantics, queue                                             lifecycle, offloads, and cross-driver testing. This BoF is intended to                                          align on the main pain points and identify concrete next steps.                                                 \r\n                                                                                                                \r\nTopics can, e.g., be:                                                                                           \r\n                                                                                                                \r\n * AF_XDP semantics: copy vs zero-copy, multi-buffer, UMEM constraints                                          \r\n * TX/RX metadata and offloads                                                                                  \r\n * Queue ownership, RSS contexts, netkit queue leasing                                                          \r\n * Driver capability discovery and consistency                                                                  \r\n * xskxceiver gaps and AF_XDP hardware compliance testing                                                       \r\n * Running AF_XDP tests in drivers/net/hw / NIPA CI                                                             \r\n * Open issues and next steps\n\n**Attachments:**\n- [AF_XDP BoF LPC 2026.pdf](https://lpc.events/event/20/contributions/2635/attachments/2105/4672/AF_XDP%20BoF%20LPC%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2635/)", "url": "https://lpc.events/event/20/contributions/2635/", "persons": [{"public_name": "Björn Töpel"}]}, {"guid": "lpc20-c3817", "id": "lpc20-c3817", "title": "Attested TLS for Confidential AI Agents: Lessons Learnt from CVEs on Early Attestation", "date": "2026-10-05T10:45:00+02:00", "start": "10:45", "duration": "00:45", "room": "Club D", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "We aim to bootstrap some discussions on the intersections of the following topics:\r\n\r\n - Agentic AI\r\n - Confidential Computing (MC on this already exists)\r\n - Attestation \r\n - Attested TLS\r\n\r\nTo initiate discussion, we will present a few slides to introduce the above, then pose some open questions. We very much welcome presentations by attendees on related topics. If you are interested in presenting, please email me with the title and expected time.\r\n\r\nWe will share insights from the several CVEs and GitHub Security Advisories (GHSAs) on Early Attestation. In particular, we will share our discovered critical-severity CVEs, such as [CVE-2026-92701][1], [CVE-2026-92702][2], [CVE-2026-100835][3], each of CVSS 9.1, and other [critical- and high-severity security concerns][4] against early attestation, and discuss with the community whether early attestation is really necessary.\r\n\r\n\r\n  [1]: https://www.cve.org/CVERecord?id=CVE-2026-92701\r\n  [2]: https://www.cve.org/CVERecord?id=CVE-2026-92702\r\n  [3]: https://www.cve.org/CVERecord?id=CVE-2026-100835\r\n  [4]: https://datatracker.ietf.org/doc/draft-intra-handshake-fail/\n\n**Attachments:**\n- [EarlyAttestationBleed: Three Critical-severity Vulnerabilities of CVSS ≥ 9.0 in Confidential Computing](https://lpc.events/event/20/contributions/2640/attachments/2049/4597/go)\n- [Early Attestation Considered Very Harmful](https://lpc.events/event/20/contributions/2640/attachments/2049/4598/go)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2640/)", "url": "https://lpc.events/event/20/contributions/2640/", "persons": [{"public_name": "Muhammad Usama Sardar"}]}, {"guid": "lpc20-c3822", "id": "lpc20-c3822", "title": "Live Update BoF", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:45", "room": "Club D", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "The primary topic of discussion will be LUO/KHO ABI and what type of backwards and forwards compatibility should be guarantee for the ABI. There are different opinions from various parts of the community and this would be a chance to bring out all views and come to an agreement. More context can be found at these mailing list threads: [[0]](https://lore.kernel.org/kexec/2vxzik5f311e.fsf@kernel.org/#r) [[1]](https://lore.kernel.org/kexec/20260904160009.GV4157646@nvidia.com/#r).\r\n\r\nOther list of potential topics, time permitting:\r\n\r\n- TMPFS preservation [[2]](https://lore.kernel.org/kexec/20260923224408.3745689-1-pratyush@kernel.org/T/#u) [[3]](https://lore.kernel.org/kexec/20260901180713.4185641-1-dmatlack@google.com/T/#u).\r\n- Getting rid of scratch/bootmem areas.\r\n- KHO enablement on different architectures like Loongarch or PowerPC.\r\n- Making KHO work with crash reservations and KASAN.\r\n\r\nThis list is open to suggestions.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2641/)", "url": "https://lpc.events/event/20/contributions/2641/", "persons": [{"public_name": "Pratyush Yadav"}]}], "Club E (Floor 1)": [{"guid": "lpc20-c3672", "id": "lpc20-c3672", "title": "Android MC Intro", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:01", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "\n\n[Open in Indico](https://lpc.events/event/20/contributions/2627/)", "url": "https://lpc.events/event/20/contributions/2627/", "persons": []}, {"guid": "lpc20-c3670", "id": "lpc20-c3670", "title": "Vendor hooks in Android kernels? Why? What do vendors do with them?", "date": "2026-10-05T10:01:00+02:00", "start": "10:01", "duration": "00:14", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Android’s Generic Kernel Image (GKI) enforces a single binary kernel, restricting Android ecosystem partners from modifying core kernel code. To allow partner-specific optimizations, Google introduced \"vendor hooks\", based on Linux tracepoints, to act as in-kernel callback registration points. Partners use loadable kernel modules to register handlers for these hooks to implement partner-specific features.\r\n \r\nBut what are they actually used for?\r\n\r\nIn this session we'll discuss the motivation behind providing vendor hooks and some of the common optimization patterns implemented by partners across various kernel subsystems including scheduler and mm. The discussion will be based on the actual usage of these hooks across major Android partners.\n\n**Attachments:**\n- [LPC2026-Android-VH.pdf](https://lpc.events/event/20/contributions/2556/attachments/1982/4497/LPC2026-Android-VH.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2556/)", "url": "https://lpc.events/event/20/contributions/2556/", "persons": [{"public_name": "Todd Kjos"}]}, {"guid": "lpc20-c3673", "id": "lpc20-c3673", "title": "Kernel Lock Contention Hotspots Causing Frame Drops on Android Mainline", "date": "2026-10-05T10:15:00+02:00", "start": "10:15", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "## Problem Statement\r\n\r\nAndroid UI rendering is latency-sensitive — at 90Hz, each frame has only ~11ms time budget. When a UI-critical thread (e.g., RenderThread) is blocked in the kernel, the frame is likely to be dropped.\r\n\r\nWe profiled 40 popular Android applications on a Pixel 6 (kernel 6.18.0-mainline, 90Hz refresh rate), using ftrace lock_contention events correlated with Perfetto FrameTimeline data, to confirm causal links between lock contention and dropped frames.\r\n\r\nThe results show that approximately 14% of all dropped frames are causally attributable to kernel lock contention. The contention concentrates in 5 subsystems that account for over 90% of all lock-caused frame drops.\r\n\r\nWe would like to present these findings and discuss optimization directions with the community.\r\n\r\n## Top 5 Problems\r\n\r\n### 1. Mali GPU Driver\r\n\r\nThe Mali GPU kernel driver uses multiple locks in its internal paths such as job submission and scheduling, and the RenderThread is observed to be occasionally blocked on these locks, causing frame drops.\r\n\r\n**To discuss:** What optimization approaches are available for reducing lock contention in the Mali GPU driver? Is this a known issue?\r\n\r\n### 2. mmap_lock\r\n\r\nSeveral mm paths contend on the same per-process mmap_lock on both write side (e.g., mmap, mprotect) and read side (page faults).\r\n\r\nRFC PATCH: https://lore.kernel.org/lkml/20260804095135.45897-1-zhanghongru@xiaomi.com/\r\n\r\n**To discuss:** We have frame-drop causation data showing mmap_lock contention still impacts Android UI performance on 6.18. How effective are current mitigations in practice? What remains to be addressed?\r\n\r\n### 3. ZRAM Compression\r\n\r\nWe observed priority inversion in the ZRAM swap-in path with durations exceeding 20ms. Threads such as RenderThread, Bluetooth, and SystemUI are observed to be blocked on this lock.\r\n\r\nRFC PATCH: https://lore.kernel.org/all/20260805005545.66112-1-baohua@kernel.org/\r\n\r\n**To discuss:** Possible approaches to avoid priority inversion in the ZRAM swap-in path\r\n\r\n### 4. Binder IPC Allocator\r\n\r\nWe observed lock contention in the Binder buffer allocation path with durations exceeding 8ms. Threads such as RenderThread, SystemUI, and app main threads are observed to be blocked on this lock.\r\n\r\nRFC PATCH: https://lore.kernel.org/all/20260805152752.1924434-1-zhangbo56@xiaomi.com/\r\n\r\n**To discuss:** Is this a known issue? What approaches can reduce lock contention in the Binder allocation path?\r\n\r\n### 5. cgroup threadgroup rwsem\r\n\r\nWe observed lock contention in the process fork and exit paths (cgroup_threadgroup_rwsem) with durations exceeding 11ms. The RenderThread is observed to be blocked on this lock.\r\n\r\n**To discuss:** Is this a known issue? What approaches can reduce lock contention on cgroup_threadgroup_rwsem?\n\n**Attachments:**\n- [LPC2026_Kernel_Lock_Contention.pdf](https://lpc.events/event/20/contributions/2565/attachments/1990/4576/LPC2026_Kernel_Lock_Contention.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2565/)", "url": "https://lpc.events/event/20/contributions/2565/", "persons": [{"public_name": "Barry Song"}, {"public_name": "Bo Zhang"}, {"public_name": "Hongru Zhang"}]}, {"guid": "lpc20-c3671", "id": "lpc20-c3671", "title": "RT tasks in sched-ext support", "date": "2026-10-05T10:30:00+02:00", "start": "10:30", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The upstream Linux kernel explicitly excludes real-time (RT) tasks from the sched-ext extensible scheduler framework, restricting sched-ext BPF schedulers to only manage SCHED_NORMAL/SCHED_BATCH/SCHED_IDLE tasks. However, Android's production workloads present a fundamentally different reality: many performance-critical scenarios — including audio pipelines, camera capture, display composition, and game rendering — depend on tight co-scheduling of RT and non-RT tasks to meet latency and throughput targets simultaneously. Optimizing only the CFS portion of the scheduler in isolation leaves significant headroom on the table.\r\n \r\nA concrete example is pipeline scheduling identifying related task chains and placing critical tasks onto specific pipeline CPUs to improve locality and predictability. The problem is that RT tasks remain outside sched-ext control — even when sched-ext builds and protects such a pipeline, an uncoordinated RT task can land on a pipeline CPU, break the intended task-to-core layout, and degrade performance. The same blind spot appears in load tracking, where per-CPU utilization and frequency selection must account for RT load that a BPF scheduler managing only fair-class\r\ntasks cannot see.\r\n \r\nThis talk explores the gap between upstream's conservative stance and Android's practical needs — including why upstream currently draws this line — surveys the combined RT+sched-ext scheduling scenarios that matter most on Android, and discusses what vendor hook infrastructure is currently required from the Android Common Kernel (ACK) to bridge this gap safely and\r\nmaintainably in the short term. Beyond that immediate step, the session aims to align customers, Google, and Qualcomm, and to open a discussion with the upstream community on a possible long-term direction in mainline.\n\n**Attachments:**\n- [2026_LPC_Support_RT_tasks_within_sched-ext_.pdf](https://lpc.events/event/20/contributions/2561/attachments/2025/4612/2026_LPC_Support_RT_tasks_within_sched-ext_.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2561/)", "url": "https://lpc.events/event/20/contributions/2561/", "persons": [{"public_name": "Tengfei Fan"}, {"public_name": "Aiqun Yu"}]}, {"guid": "lpc20-c3677", "id": "lpc20-c3677", "title": "BPF FD Loader: Integrity-Verified BPF on Android", "date": "2026-10-05T10:45:00+02:00", "start": "10:45", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "On modern Android devices, eBPF loading is strictly confined to early boot by a privileged loader alongside SELinux lockdown of BPF_PROG_LOAD. While this protects the kernel attack surface, it leaves the platform fundamentally rigid: platform services and hardware partners cannot deploy or activate BPF programs on demand. Furthermore, the approach of individual cryptographic signature verification fails in a decentralised client ecosystem comprising several SoC vendors, OEMs, and partners, where managing runtime key-rings in the Generic Kernel Image (GKI) imposes an unsustainable operational burden.\r\n\r\nTo address this, we introduce the BPF FD Loader driver in Android. Inspired by finit_module(), it allows the kernel to load BPF programs directly from verified file descriptors rather than untrusted userspace memory.\r\n\r\nBecause BPF lacks an in-kernel linker, our solution leverages upstream BPF Light Skeletons. At runtime, an authorised userspace daemon simply passes an open file descriptor of this ELF to the Android driver via ioctl(). The kernel driver reads the backing file directly before executing the loader, verifying that it originates from an authenticated, read-only partition sealed by Android Verified Boot (AVB) and dm-verity.\r\n\r\nIn this talk, we present the end-to-end architecture and discuss our roadmap towards standardising file-based BPF loading in the Android ecosystem.\n\n**Attachments:**\n- [[LPC2026] BPF FD Loader_ Integrity-Verified BPF on Android.pdf](https://lpc.events/event/20/contributions/2557/attachments/1997/4565/%5BLPC2026%5D%20BPF%20FD%20Loader_%20Integrity-Verified%20BPF%20on%20Android.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2557/)", "url": "https://lpc.events/event/20/contributions/2557/", "persons": [{"public_name": "Siddharth Nayyar"}]}, {"guid": "lpc20-c3678", "id": "lpc20-c3678", "title": "CPU Power Regression Testing with Wattson", "date": "2026-10-05T11:00:00+02:00", "start": "11:00", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Wattson is a trace based power estimation tool designed around perfetto to estimate CPU power consumption on ARM64 devices using a statistical per-SoC model. With support of both the Pixel 6 (gs101) and SM8750 upstream, you can now use the Wattson tool to detect CPU power regressions in the Linux kernel. This talk dives into how Google is using Wattson to catch CPU power regressions including:\r\n - What is needed to enable testing.\r\n - Walk-through of the metrics collected and how to use Wattson.\r\n - Examples of regressions Wattson has caught.\r\n - Expanding into other subsystems like GPU and TPU/NPU power estimates.\r\n\r\nUltimately, we’d like to connect with the Linux community to see who wants to collaborate on establishing CPU power regression testing upstream.\n\n**Attachments:**\n- [LPC2026 -- Wattson.pdf](https://lpc.events/event/20/contributions/2564/attachments/2036/4577/LPC2026%20--%20Wattson.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2564/)", "url": "https://lpc.events/event/20/contributions/2564/", "persons": [{"public_name": "William McVicker"}]}, {"guid": "lpc20-c3679", "id": "lpc20-c3679", "title": "Modernizing Android USB: Userspace AOA, Multi-UDC, Type-C, and Framework APIs", "date": "2026-10-05T11:15:00+02:00", "start": "11:15", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Android USB stack was originally architected around the constraints of early smartphones. Initially designed primarily for phones with a single USB Micro-B device port, the stack lacks the modern API surface required for advanced USB applications. While incremental changes have been implemented out of necessity, a larger refactoring is required to better support modern USB features like Type-C and multiple-UDC topologies.\r\n\r\nThis presentation will highlight some of the limitations of the existing frameworks, provide an update on current projects, and solicit feedback on the new architecture plans and API surfaces.\r\n\r\nTopics for Discussion:\r\n\r\n - Userspace AOA via function_fs: Deprecating the out-of-tree kernel AOA driver and moving protocol handling entirely to userspace.\r\n - Upstream Type-C Integration: Hooking the framework directly into the Type-C connector class, allowing applications to query cable capabilities and provide safe role-swap hints to the TCPC.\r\n - Multi-UDC & Per-Port Configuration: Refactoring the framework to break the single-UDC assumption, allowing for independent per-port configurations on laptop-class devices.\r\n - Modular Function Provider Patterns: Replacing legacy broadcast mechanisms with strict provider patterns and robust APIs with proper error handling.\n\n**Attachments:**\n- [LPC26 - Modernizing Android USB.pdf](https://lpc.events/event/20/contributions/2559/attachments/2030/4568/LPC26%20-%20Modernizing%20Android%20USB.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2559/)", "url": "https://lpc.events/event/20/contributions/2559/", "persons": [{"public_name": "Neill Kapron"}, {"public_name": "George Chan"}]}, {"guid": "lpc20-c3676", "id": "lpc20-c3676", "title": "Space sharing between super and data partitions on Android system", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Android Super partition relies on static reserved space to guarantee OTA upgrade capability. However, this fixed allocation method possesses an inherent defect: if the reserved space is too large, it permanently occupies flash memory and cannot be utilized by the data partition; if it is too small, OTA upgrades will fail due to insufficient space. To address the industry pain points of static partition isolation and low flash utilization, we propose a space-sharing mechanism between the super and data partitions. Distinct from traditional reserved space schemes, this technology enables space sharing between the two partitions. The core idea is that in daily usage scenarios, idle physical blocks within the Super partition are shared with the data partition to expand the storage space available to users; when the super partition requires expansion for OTA upgrades or system maintenance, it can dynamically requisition idle physical blocks from the data partition without causing any data corruption throughout the process.\n\n**Attachments:**\n- [LPC2026_space_sharing.pdf](https://lpc.events/event/20/contributions/2560/attachments/2002/4532/LPC2026_space_sharing.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2560/)", "url": "https://lpc.events/event/20/contributions/2560/", "persons": [{"public_name": "Yangtao Li"}]}, {"guid": "lpc20-c3675", "id": "lpc20-c3675", "title": "Android GBL + Dynamic Partitions 2.0", "date": "2026-10-05T12:15:00+02:00", "start": "12:15", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Hi I'm here to discuss the developments in android GBL + CF support, and talk about android dynamic partitions 2.0 feature (resizable super partition) to accommodate large OS updates. \r\n\r\n- Quick GBL + Cuttlefish recap \r\n- Cuttlefish default booting off GBL\r\n- New android_esp partition\r\n- Fastbootd deprecation\r\n- u-boot implementation\r\n\r\n\r\nAndroid Dynamic Partitions 2.0 allow for dynamic resizing of super partition vs. userdata during OTA to support larger os updates. We will cover the different solutions proposed and in plans of getting adopted.\r\n\r\n- Samsung F2FS patches to support dynamic data partition\r\n- bootloader support\r\n- liblp support in GBL\n\n**Attachments:**\n- [LPC-2026-GBL-DAP2.0.pdf](https://lpc.events/event/20/contributions/2562/attachments/2031/4569/LPC-2026-GBL-DAP2.0.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2562/)", "url": "https://lpc.events/event/20/contributions/2562/", "persons": [{"public_name": "Daniel Zheng"}]}, {"guid": "lpc20-c3674", "id": "lpc20-c3674", "title": "Generic Boot Loader on Android platforms", "date": "2026-10-05T12:30:00+02:00", "start": "12:30", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Bootloaders play a vital role in the Android boot process, but the ecosystem has long been fragmented across silicon vendors and OEM-specific implementations. To address this, Google introduced the Generic Boot Loader (GBL), a Rust-based EFI application in AOSP, with the goal of standardizing Android boot logic.\r\nThis session focuses on how Qualcomm is adapting its boot chain to integrate GBL while preserving existing firmware and platform capabilities. It describes the Qualcomm-specific changes required to expose core UEFI services such as block I/O, memory allocation, RNG, etc. to GBL, along with the firmware adjustments needed to present these services in a clean and consistent way. The session also covers Qualcomm’s implementation of device tree selection and fixups through GBL-defined interfaces, as well as the handling of Android-critical boot data including kernel command line and bootconfig handoff.\r\nIn addition, the talk discusses Qualcomm’s support for GBL-specific UEFI protocols that enable Android requirements such as Verified Boot and Fastboot, and how these fit into the existing Qualcomm boot flow. Overall, the session provides a practical look at the platform changes needed to bring GBL into the Qualcomm boot chain and move Android boot architecture closer to a more maintainable, upstream-aligned model.\n\n**Attachments:**\n- [Generic Boot Loader on Android platforms.pdf](https://lpc.events/event/20/contributions/2558/attachments/1993/4518/Generic%20Boot%20Loader%20on%20Android%20platforms.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2558/)", "url": "https://lpc.events/event/20/contributions/2558/", "persons": [{"public_name": "Naina Mehta"}]}, {"guid": "lpc20-c3680", "id": "lpc20-c3680", "title": "Actionable Strategies to mitigate memory footprint on 16kb kernels", "date": "2026-10-05T12:45:00+02:00", "start": "12:45", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "With the release of Android 17, partners are required to support the **16 KB developer option** on devices meeting specific hardware requirements, such as CPU compatibility and memory configurations exceeding 8 GiB. While this transition significantly improves system performance and unlocks hardware efficiencies, **Android partners** frequently observe a noticeable memory footprint increase, and they ask **\"How can we reduce this memory footprint?\"**. This regression is primarily driven by internal fragmentation, mapping more memory than what is needed and page-granularity alignment constraints across both userspace and kernel allocations.\r\n\r\nThis presentation provides a concrete, engineering-focused recipes for Partners to reduce the memory footprint in:\r\n\r\n**Userspace**\r\n\r\n - Fileback mappings\r\n - Anonymous Memory\r\n - Shmem memory\r\n\r\n**Kerne memory**\r\n\r\n - Kernel modules\r\n - CMA memory usage\r\n - Buffer allocations in drivers\n\n**Attachments:**\n- [Strategies to mitigate memory footprint on 16kb kernels.pdf](https://lpc.events/event/20/contributions/2566/attachments/2053/4604/Strategies%20to%20mitigate%20memory%20footprint%20on%2016kb%20kernels.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2566/)", "url": "https://lpc.events/event/20/contributions/2566/", "persons": [{"public_name": "Juan Yescas"}, {"public_name": "Kalesh Singh"}]}, {"guid": "lpc20-c3681", "id": "lpc20-c3681", "title": "16KB page cache and mTHP on Android", "date": "2026-10-05T13:00:00+02:00", "start": "13:00", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "This topic proposes exploring the possibility of using 16 KB for both\r\npage cache and mTHP on Android. \r\n\r\nCollaborating with Kalesh Singh, Ryan Roberts, David Hildenbrand and\r\nothers, Xiaomi is exploring the use of 16 KB large folios for both page\r\ncache and anonymous memory.\r\n\r\nWe have posted an RFC patchset for large folio support in F2FS, which\r\nhas been working well on Android devices so far:\r\n\r\nhttps://lore.kernel.org/lkml/20260622160830.324455-1-zhaonanzhe@xiaomi.com/\r\n\r\nIn this discussion, we would like to present the data we have collected\r\nusing 16 KB page cache and mTHP, and discuss the following topics:\r\n\r\n1. Pros and cons of using 16 KB large folios with 16 KB base pages.\r\n\r\n2. Memory fragmentation and direct reclaim issues observed with 16 KB\r\n   large folios, along with potential compaction optimizations for a\r\n   lightweight mechanism targeting 16 KB folios only.\r\n\r\n3. Potential Scudo and other component optimizations to reduce memory\r\n   footprint while using 16 KB as the management granularity. These\r\n   optimizations could also be beneficial when using 16 KB as the base\r\n   page size.\n\n**Attachments:**\n- [LPC2026_16KB_mTHP_and_large_folio_pagecache_on_Android.pdf](https://lpc.events/event/20/contributions/2593/attachments/2033/4572/LPC2026_16KB_mTHP_and_large_folio_pagecache_on_Android.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2593/)", "url": "https://lpc.events/event/20/contributions/2593/", "persons": [{"public_name": "Barry Song"}, {"public_name": "Bo Zhang"}, {"public_name": "nanzhe zhao"}]}, {"guid": "lpc20-c3708", "id": "lpc20-c3708", "title": "Compatibility for 4KB Applications on Large Page-Sized Systems", "date": "2026-10-05T13:15:00+02:00", "start": "13:15", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Android MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "As the ecosystem shifts toward larger page sizes for enhanced performance, preserving functionality for legacy applications remains a significant challenge. This talk will introduce a per-process 4KB compatibility mode on native 16KB kernel. Primarily for legacy Android applications, this approach intentionally prioritizes functional correctness over memory efficiency, allowing legacy software to run seamlessly while ensuring native 16KB applications experience zero compatibility overhead.\r\n\r\nWe plan to discuss to the design, current validation status, and the subsystem integration work required to bridge the gap between 4KB legacy user spaces and 16KB native environments; and outstanding challenges of ensuring consistency and correctness in a mixed-mode e4KB PTEs --> 16KB Folio environment\n\n**Attachments:**\n- [Compatibility of 4KB Applications on Large Page-Sized Systems.pdf](https://lpc.events/event/20/contributions/2630/attachments/2041/4583/Compatibility%20of%204KB%20Applications%20on%20Large%20Page-Sized%20Systems.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2630/)", "url": "https://lpc.events/event/20/contributions/2630/", "persons": [{"public_name": "Kalesh Singh"}, {"public_name": "Frederick Mayle"}]}, {"guid": "lpc20-c3793", "id": "lpc20-c3793", "title": "Secure vIOMMU architecture and implementation challenges", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:25", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Modern cloud computing increasingly relies on confidential virtual machines (VMs) - isolated environments\r\nwhere sensitive workloads run securely, even from the underlying hypervisor. A key challenge in this space\r\nis enabling these confidential VMs to safely communicate with hardware devices without exposing their data\r\nto the host system or hypervisor.\r\n\r\nVirtual IOMMU (vIOMMU) is an extended feature of AMD's IOMMU that allows IOMMU hardware to directly access\r\nand process virtual machine data structures. Building on this foundation, AMD's Secure vIOMMU extends\r\nvIOMMU capabilities to support SEV-TIO (Secure Encrypted Virtualization - Trusted IO) device assignment to\r\nconfidential virtual machines. Specifically, it enables secure communication channels between confidential\r\nvirtual machine and IOMMU hardware enabling reliable management of device DMAs including guest TLBs without\r\nhypervisor intervention.\r\n\r\nThis presentation introduces the Secure vIOMMU architecture and explains how its components work together\r\n-- including the IOMMU, AMD's Security Processor, the hypervisor, Virtual Machine Manager (VMM) and\r\nconfidential VMs. We will also cover supported operational modes (vTOM and Guest Page Table) for secure\r\ndata transmission between Trusted I/O devices and confidential VM.\r\n\r\nFinally, we will discuss the interface challenges that arise across various kernel modules including IOMMU,\r\nccp, KVM, SEV-TIO, etc, and explore potential approaches to address them.\r\n\r\nSEV-TIO specification: https://docs.amd.com/v/u/en-US/58271_0.91\r\nSecure vIOMMU initial code: https://github.com/AMDESE/linux-iommu/tree/sviommu/tsm0407_v619_v0\n\n**Attachments:**\n- [LPC2026_svIOMMU_upload_v1.pdf](https://lpc.events/event/20/contributions/2522/attachments/2080/4643/LPC2026_svIOMMU_upload_v1.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2522/)", "url": "https://lpc.events/event/20/contributions/2522/", "persons": [{"public_name": "Vasant Hegde"}, {"public_name": "Suravee Suthikulpanit"}]}, {"guid": "lpc20-c3795", "id": "lpc20-c3795", "title": "IOMMU Page Table Observability and Reclamation", "date": "2026-10-05T15:25:00+02:00", "start": "15:25", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "<br>The current Linux memory management framework lacks the mechanism for tracking IOMMU page table (IOPT) consumption across sparse virtualization workloads. By utilizing the IOMMUFD and VFIO frameworks, hypervisors dynamically map and unmap massive IOVA regions, often leaving intermediate page table directories stranded and invisible to the core  kernel. This session talks about the current state of IOPT observability and attempts to propose new features and enhancements for IOPT memory reclamation.\r\n<br>The session proposes a design for an IOMMU Page Table Shrinker that allows lockless and lazy reclamation of stranded IOPT memory, specifically by the intermediate tables while employing the generic_pt to keep the shrinker arch-agnostic. We invite a discussion to explore strategies for lockless tracking, page table branch severance, and lifecycle management using RCU state machines to ensure that the core kernel can harvest stranded memory under pressure without penalizing the IOMMU mapping paths.\n\n**Attachments:**\n- [LPC'26_ IOPT Observability & Reclamation.pdf](https://lpc.events/event/20/contributions/2624/attachments/2085/4649/LPC'26_%20IOPT%20Observability%20&%20Reclamation.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2624/)", "url": "https://lpc.events/event/20/contributions/2624/", "persons": [{"public_name": "Logan Odell"}, {"public_name": "Pranjal Shrivastava"}]}, {"guid": "lpc20-c3792", "id": "lpc20-c3792", "title": "IOMMUFD Support for Microsoft Hypervisor Hosts", "date": "2026-10-05T15:45:00+02:00", "start": "15:45", "duration": "00:25", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Device assignment in Microsoft Hypervisor (/dev/mshv) host environments has requirements beyond existing KVM-oriented workflows, including direct HWPT attachment for assigning a device to a guest while preserving existing Stage-2 page tables, and VMM-assigned virtual device information to facilitate hypercall-based device operations.\r\n \r\nWe plan to publish an RFC before LPC describing the proposed iommufd/VFIO plumbing for MSHV device assignment. At LPC, we would like to discuss the remaining design questions and potential follow-on work, including alignment with Xen and how the same model could support future use cases such as TDISP or page table sharing in general.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2520/)", "url": "https://lpc.events/event/20/contributions/2520/", "persons": [{"public_name": "Jacob Pan"}]}, {"guid": "lpc20-c3796", "id": "lpc20-c3796", "title": "arm-smmu contig hint support and performance impact", "date": "2026-10-05T16:10:00+02:00", "start": "16:10", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "This talk covers ARM SMMU contiguous-hint support in Linux stage-1 page tables and the ARM-SMMU PMU support used to measure its impact. The work enables larger effective mappings, including 64K regions built from 16 adjacent 4K entries, and extends IOMMU map/unmap support for mixed and larger mapping sizes. In parallel, ARM-SMMU PMU integration exposes TBU and TCU counters through perf, including access, TLB allocate/read/write, cache-hit, and page-table-walk events, with StreamID-based filtering for workload attribution. \r\n\r\nWe present page-table behavior observed in tracing alongside translation-side measurements from PMU counters. Early measurements show measurable gains from mixed 4K/64K mappings with contiguous hint enabled: lower TLB allocation pressure and lower elapsed time versus a 4K-only baseline. \r\n\r\nThe talk also highlights different pmu counters used, invalidation effects, and how we can evaluate real SMMU translation performance.\n\n**Attachments:**\n- [LPC2026_SMMU_CONT_hint.pdf](https://lpc.events/event/20/contributions/2625/attachments/2010/4543/LPC2026_SMMU_CONT_hint.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2625/)", "url": "https://lpc.events/event/20/contributions/2625/", "persons": [{"public_name": "Prakash Gupta"}, {"public_name": "Vijayanand Jitta"}]}, {"guid": "lpc20-c3794", "id": "lpc20-c3794", "title": "VFIO PCIe TPH Userspace API & Progressive Security Policy", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "PCIe TPH enables cache steering for high-performance P2PDMA, RDMA and SDXI workloads. Today Linux only supports TPH operations within host kernel space; userspace/VFIO passthrough environments lack a standard interface to resolve and program steering tags.\r\nI’ve posted a complete patch series adding native VFIO TPH support, aligned with community incremental security policy design. The series provides unified handling for CPU memory (via root port ACPI _DSM), dma-buf, zero-tag and literal raw ST sources, supporting cross-device P2P DMA scenarios. Three new VFIO_DEVICE_FEATURE ioctls cover feature opt-in, multi-source tag resolution and batch ST table programming.\r\nCurrent upstream challenges include:\r\nAutomated selftest coverage without physical TPH hardware;\r\nLock granularity performance tradeoffs for batch ST programming;\r\nSecurity boundary definition for cross-device dma-buf TPH metadata access.\r\nThe core uAPI and security logic are stable and targeted for v7.3 merge window in late August. Post-merge follow-up plans include extending QEMU to emulate TPH capabilities and implementing full guest passthrough support with VMM-managed _DSM emulation.\r\nThis session will briefly introduce the design, then focus on resolving the outstanding upstream challenges and aligning on VM passthrough roadmap.\n\n**Attachments:**\n- [VFIO PCIe TPH Userspace API - Progressive Security Policy.pdf](https://lpc.events/event/20/contributions/2623/attachments/1989/4507/VFIO%20PCIe%20TPH%20Userspace%20API%20-%20Progressive%20Security%20Policy.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2623/)", "url": "https://lpc.events/event/20/contributions/2623/", "persons": [{"public_name": "Chengwen Feng"}]}, {"guid": "lpc20-c3791", "id": "lpc20-c3791", "title": "Two Years of Making PCIe Hotplug Reliable: What Landed, What Didn't, and Where Do We Go", "date": "2026-10-05T17:20:00+02:00", "start": "17:20", "duration": "00:25", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "In 2024, hotplug on our NVMe storage fleet — NTB behind Microchip/Switchtec switches — was\r\nnot stable on mainline, so we ran Keith Busch's out-of-tree bus-locking series on a private\r\nbranch. It held. Then a new hardware generation arrived, we needed a kernel we could\r\nvalidate against, and that meant mainline: 6.8, now 6.17. Going upstream meant giving up the\r\nstructural work that had been keeping us alive, and we started hitting problems again. This\r\nis the story of that round trip, and where I think it should go next.\r\n\r\nThe good news is real, so I lead with it: since Keith Busch's ALPSS 2024 talk \"The Problem\r\nwith PCI Subsystems,\" the subsystem has closed most of what bit us. The child use-after-free\r\nat `pci_dev_wait` is fixed (`11a1f4bc4736`, v6.11). pciehp suppresses reset- and DPC-induced\r\nlink events (v6.16). DPC recovery holds a port reference (`a1ed752bc7cb`, v7.1).\r\n`reset_subordinate` is hotplug-safe (`8238cb69c01f`, v7.1). DPC is decoupled from per-device\r\nAER binding for v7.3 (`97ca178c899d`), which resolves — properly — a layering hack I had\r\nbeen carrying in production. The point fixes landed.\r\n\r\nThe structural work did not come with us, and its absence is where the new problems live.\r\nHierarchy mutation still sits behind one global `pci_rescan_remove_lock`; Keith's per-bus\r\nlocking and subordinate-bus refcounting are still unmerged, two years on. Where exclusion\r\nbecame coordination, the budgets do not match: `pci_dpc_recovered()` waits 4 s for a\r\nrecovery bounded at roughly 62 s. And a failure nobody was watching turned up — after a\r\nswitch-subtree reset, 3 of 8 endpoints cannot place a 1 GiB BAR that boot places without\r\ncomplaint.\r\n\r\nI am not here to complain; my crash was fixed and I will say so. I bring crash dumps, source\r\nanalysis, a reproducible switch topology, and fleet-scale test capacity — the validation\r\nbandwidth the subsystem said it was short on — and three questions about the way forward. I\r\nwant to leave the room agreeing on which one is worth fixing next, and who validates it.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2519/)", "url": "https://lpc.events/event/20/contributions/2519/", "persons": [{"public_name": "Maciej Grochowski"}]}, {"guid": "lpc20-c3790", "id": "lpc20-c3790", "title": "Describing P2PDMA capabilities in ACPI", "date": "2026-10-05T17:45:00+02:00", "start": "17:45", "duration": "00:25", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The kernel uses a [whitelist][1] do determine whether peer-to-peer DMA is supported between devices. But constantly amending the whitelist is a maintenance burden.\r\n\r\nWe are proposing to extend the ACPI HMAT table with bandwidth and latency characteristics for P2PDMA traffic between PCI host bridges (and between devices below the same host bridge).\r\n\r\nThis will remove the need for a whitelist.\r\n\r\nIt also closes a gap in virtualization: VMs have no visibility of the physical PCI topology and thus cannot determine P2PDMA reachability. The proposed HMAT extension solves this: VMMs such as qemu may present a synthesized HMAT table to VMs which reflects the physical capabilities. This replaces prior proposals such as Nvidia's [Virtual Peer-to-Peer Approval Capability][2].\r\n\r\nLast not least, the proposed HMAT extension allows users to populate PCI slots for optimal P2PDMA performance.\r\n\r\nWe will briefly present the draft of this ACPI Code First ECN and explain how it fits into the Linux P2PDMA model and path-selection algorithm. Afterwards we hope for a lively discussion on its merits.\r\n\r\n  [1]: https://elixir.bootlin.com/linux/v7.2-rc1/source/drivers/pci/p2pdma.c#L535\r\n  [2]: https://lists.gnu.org/archive/html/qemu-devel/2017-08/pdfUda5iEpgOS.pdf\n\n**Attachments:**\n- [Describing P2PDMA capabilities in ACPI.pdf](https://lpc.events/event/20/contributions/2508/attachments/2042/4584/hmat-p2pdma-virtualization.pdf)\n- [ECN Draft: HMAT Extensions for PCIe P2PDMA.pdf](https://lpc.events/event/20/contributions/2508/attachments/2042/4585/HMAT%20Extensions%20for%20PCIe%20P2P%20-%20external.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2508/)", "url": "https://lpc.events/event/20/contributions/2508/", "persons": [{"public_name": "Leon Romanovsky"}, {"public_name": "Lukas Wunner"}]}, {"guid": "lpc20-c3797", "id": "lpc20-c3797", "title": "Testing the Untestable: Using QEMU for Testing PCI Endpoint Framework", "date": "2026-10-05T18:10:00+02:00", "start": "18:10", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: VFIO/IOMMU/PCI MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Linux PCI Endpoint Framework provides the software infrastructure for a Linux system to present itself as a PCIe Endpoint device to an external Host. It consists of an Endpoint Controller layer that abstracts the hardware, an Endpoint Function layer that implements device behavior, and a ConfigFS interface for userspace to bind them together. For testing, the upstream pci_endpoint kselftests are used. But running this kselftest has always required two physical machines connected by a physical PCIe link. This makes automated testing impractical and limits coverage to whoever has the right hardware.\r\n\r\n  This talk presents a software only test setup that removes the hardware requirement entirely. Two QEMU instances communicate over a Unix socket, one acting as the Endpoint Controller and the other as the Root Complex. A new generic EPC driver on the Endpoint side talks to a virtual Endpoint Controller device emulated by QEMU, which forwards commands over the socket to the RC side where QEMU emulates a PCIe Endpoint Function that the Host kernel enumerates and tests against. The existing kselftests run unmodified against this setup.\r\n\r\nThis talk will walk through how the two VM design works, what trade-offs were made in the socket protocol and what remains to be done for full CI integration.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2384/)", "url": "https://lpc.events/event/20/contributions/2384/", "persons": [{"public_name": "Manivannan Sadhasivam"}]}], "Club H (Floor 1)": [{"guid": "lpc20-c3772", "id": "lpc20-c3772", "title": "Performance Tools and Prompts", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "A new era is upon performance engineering where we ask AI to do much of our analysis and thinking: we run \"performance prompts\" (and skills and agents) instead of \"performance tools.\" These can analyze all sources, including flame graphs, bcc and bpftrace tools (eBPF), Ftrace, PMCs, and MSRs; they can also propose new metrics and tools. How well does it currently work, and what does this mean for the future of system monitoring and observability, including for flame graphs and eBPF tools. There are many questions to ponder (more questions than answers), including: Should one day we include prompts, skills, and agents in the kernel tree, just as we do performance tools? This talk discusses questions and challenges that we will all likely be facing, and new opportunities, including example performance prompts.\n\n**Attachments:**\n- [LPC2026_PerformanceToolsAndPrompts.pdf](https://lpc.events/event/20/contributions/2450/attachments/1996/4522/LPC2026_PerformanceToolsAndPrompts.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2450/)", "url": "https://lpc.events/event/20/contributions/2450/", "persons": [{"public_name": "Brendan Gregg"}]}, {"guid": "lpc20-c3767", "id": "lpc20-c3767", "title": "Unified collection of kernel bug reports", "date": "2026-10-05T10:20:00+02:00", "start": "10:20", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "**Debugging end user kernel issues is a problem**\r\n\r\nReporting bugs is hard - important information is scattered across many log files, crash files, sysfs entries, etc. Most end users don't know where or how to file a bug. They might not even know that a crash has happened (just a glitch on the screen or a log entry somewhere).\r\n\r\nWhen a bug is reported, triage can be difficult. Likely only one report but is it really a one-off issue, never to be seen again? Was all the important info included? Were the logs collected but two hours after the bug occurred and have wrapped? ...\r\n\r\nBugs can cascade - a non-fatal issue can sometimes lead to a fatal issue later in time. A timeline of reports from a single system/boot is needed to identify cause/effect relationships. Bugs can also cross subsystem boundaries and a bug logged against driver X might really have been caused by module Y but team Y might never get to know about it because team X didn't pass it on properly (or at all).\r\n\r\n**Solution: Remove the user**\r\n\r\nAutomatically generate a dump file - a daemon can ensure it captures all important information (e.g. devcoredump and other sysfs entries plus dmesg, syslog, etc. plus timeline info such as boot time, hashed processor id, etc.) and immediately at the time of the bug occurrance. Daemon then sends the bug report a server.\r\n\r\nFirst level server can be local, but ultimately bugs are sent to a global server. Server does first step triage - build timeline of bug reports with the same session id, check for known instability issues earlier in the timeline, match new bug to existing entries, etc. It would have plugins to help analyse driver specific data blocks (e.g. devcoredump files) for customised triage. Sends notification to driver/module owner when a new bug is identified and provides database for investigating bugs - developers can see how many times a given bug has really occurred, what platforms/hardware/kernels are affected, etc.\n\n**Attachments:**\n- [Kernel Bug Reporting - LPC 2026.pdf](https://lpc.events/event/20/contributions/2576/attachments/2060/4615/Kernel%20Bug%20Reporting%20-%20LPC%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2576/)", "url": "https://lpc.events/event/20/contributions/2576/", "persons": [{"public_name": "John Harrison"}]}, {"guid": "lpc20-c3770", "id": "lpc20-c3770", "title": "What Bugs Matter? Continuous Linux Kernel Bug Monitoring", "date": "2026-10-05T10:35:00+02:00", "start": "10:35", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Linux kernel bug reports vary widely in quality: some are duplicates\r\nor false positives, while others describe exploitable vulnerabilities\r\nor issues with little practical impact. Maintainers still need to\r\ndetermine what is real, what matters, and what deserves attention\r\nfirst.\r\n\r\nAt the same time, bug findings are increasingly fragmented across\r\ndifferent tools and workflows, including fuzzers, static analyzers,\r\nhuman analysis, AI-assisted tools, and patch-review systems. For\r\nexample, Sashiko may uncover pre-existing bugs while reviewing\r\npatches, but those findings can remain scattered across individual\r\nreview reports rather than being collected and tracked in one place.\r\n\r\nWe are developing a continuous Linux kernel bug monitoring and triage\r\nplatform. The platform aggregates findings from multiple sources, maps\r\nthem to kernel subsystems, and gives maintainers a view of currently\r\nobserved bugs affecting the code they maintain. For each finding, it\r\nattempts to generate and execute a reproducer on a KASAN-enabled\r\nkernel to help validate the report. It also assesses potential impact.\r\nFor example, whether a bug may enable privilege escalation or has\r\nlimited practical impact. Confirmed bugs can also include AI-generated\r\nanalysis and draft patches to help reduce the effort required to\r\nunderstand and fix the issue.\r\n\r\nBuilding on the [mailing-list discussion][1], we would like to explore\r\nwhat actionable kernel bug observability should look like. How should\r\nheterogeneous bug signals be validated, prioritized, and presented to\r\nsubsystem maintainers? How can automated analysis help distinguish\r\nimportant bugs from noise without creating yet another stream of\r\nlow-quality reports?\r\n\r\n\r\n  [1]: https://lore.kernel.org/all/20260830115546.3942129-1-yuantan098@gmail.com/\n\n**Attachments:**\n- [yuan.pdf](https://lpc.events/event/20/contributions/2550/attachments/2059/4614/yuan.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2550/)", "url": "https://lpc.events/event/20/contributions/2550/", "persons": [{"public_name": "Yuan Tan"}, {"public_name": "Yuan Tan"}]}, {"guid": "lpc20-c3774", "id": "lpc20-c3774", "title": "Detecting Unhealthy Kernels at Scale", "date": "2026-10-05T10:50:00+02:00", "start": "10:50", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "This talk explores Meta's approaches to identifying production issues rooted in the Linux kernel. Our investigation process, spanning detection, correlation, and deep triage, relies on a unified framework of telemetry and monitoring tools. A common challenge arising in hyperscale kernel releases is that of robustly comparing kernel performance across lifecycle phases, despite vast variations in deployment size. Our findings highlight the efficacy of combining flexible data aggregation with statistically grounded analysis, to streamline and automate the release process.\n\n**Attachments:**\n- [Sam_Crossley_LPC2026_slides.pdf](https://lpc.events/event/20/contributions/2547/attachments/2035/4574/Sam_Crossley_LPC2026_slides.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2547/)", "url": "https://lpc.events/event/20/contributions/2547/", "persons": [{"public_name": "Sam Crossley"}]}, {"guid": "lpc20-c3768", "id": "lpc20-c3768", "title": "We don't know what we're looking for until we find what we're looking for", "date": "2026-10-05T11:05:00+02:00", "start": "11:05", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "What started out as an investigation for potential isolation issues in the fleet led us down into a few different rabbit holes. We started with trying to find patterns where the kernel lock holders are unable to run, causing other tasks to wait on said locks. We'll discuss ways to monitor said patterns across the fleet at a broader scale and then zoom into some interesting case studies to see what we found including:\r\n\r\n- OOM killer prints to the console while holding a lock\r\n- Act of monitoring causes isolation issues in the fleet for sensitive services\r\n- Hard partitioning from CPUSETS causes lock holder unable to get CPU time\r\n- Chain of lock waiters -> Lock holder sleeping on synchronize_rcu -> CPU holding up grace period\r\n\r\n\r\nAlso we'll discuss how to expand on monitoring for scheduling issues and/or issues in the fleet that causes stalls that prevent system wide progress\n\n**Attachments:**\n- [Observing Isolation problems in the Fleet.pdf](https://lpc.events/event/20/contributions/2548/attachments/2073/4684/Observing%20Isolation%20problems%20in%20the%20Fleet.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2548/)", "url": "https://lpc.events/event/20/contributions/2548/", "persons": [{"public_name": "David Dai"}, {"public_name": "Shakeel Butt"}]}, {"guid": "lpc20-c3775", "id": "lpc20-c3775", "title": "Low-Cost Live Kernel State Capture with BPF-Based Snapshots", "date": "2026-10-05T11:20:00+02:00", "start": "11:20", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Production incidents often require answering concrete questions about current kernel state: which tasks are blocked, what is on each runqueue, where D-state tasks are stuck, or what reclaim and I/O state looks like while the host is still alive. Existing tools such as drgn and crash are powerful, but live inspection can require substantial kernel memory traversal from userspace and may be costly on an already slow host.\r\n\r\nIthildin’s Snapshot mode explores a different design point: pre-approved, bounded, live kernel-state capture using BPF-assisted in-kernel traversal and compact userspace output. The goal is not to replace debuggers or tracing, but to provide low-perturbation answers to common operational questions while the system is still running.\r\n\r\nThis discussion will cover early measurements comparing snapshot-style capture against drgn for task lists, D-state stacks, and runqueue state under stressed workloads. More importantly, it will ask what BPF and kernel infrastructure would make this pattern easier, safer, and faster: suitable BPF program types, iterator support, helper/kfunc availability, verifier constraints, stack capture, output buffering, adding new iterators, and defining precise safety bounds.\r\n\r\n**Discussion questions**\r\n\r\n - Is BPF iterator-based live state capture the right model for this\r\n   class of production diagnostics?\r\n - Should it use a new/dedicated BPF program type?\r\n - What helper, kfunc, or iterator gaps make common snapshots awkward\r\n   today?\r\n - How easy should it be to add a new snapshot over a kernel structure\r\n   such as tasks, runqueues, block I/O, reclaim state, or cgroups?\r\n - What consistency guarantees are realistic for live snapshots without\r\n   stopping the world?\r\n\r\n **Expected outcome**\r\nGet feedback on whether this model is useful, what BPF/kernel interfaces would improve it and which iterators are worth standardizing\n\n[Open in Indico](https://lpc.events/event/20/contributions/2622/)", "url": "https://lpc.events/event/20/contributions/2622/", "persons": [{"public_name": "Imran Khan"}]}, {"guid": "lpc20-c3769", "id": "lpc20-c3769", "title": "Following the bread crumbs: Tracing packets through the kernel with per-skb BPF metadata", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Operating a network at scale, we routinely need to answer a deceptively simple question: what path did *this* packet take through the kernel, and where did it get dropped? On our edge, a single packet can cross several network namespaces, get encapsulated in GRE or IPIP, be encrypted with IPsec, and pass through multiple nftables chains before it leaves the box. Tagging the payload the way we tag L7 requests is not an option here: it's opaque, encrypted, and rewritten along the way.\r\n\r\nWe'll walk through our attempt to build an `mtr`-like tool that, instead of a list of hosts, shows the *kernel waypoints* a packet hits — interfaces, netns boundaries, tunnel encap/decap, IPsec encrypt/decrypt, nftables verdicts, and drops — each with a timestamp.\r\n\r\nWe started with [Retis](https://github.com/retis-org/retis), Red Hat's eBPF-based packet tracer, which already does most of the heavy lifting. We'll cover what worked out of the box and where we hit its limits:\r\n\r\n- It correlates events by hashing the skb data area (`skb->head`); we found\r\n  tracking by `skb` address to be both cheaper (~15% fewer trigger events on a busy box) and a better fit.\r\n- The \"tcpdump model\" mismatch: Retis filters at every probe, capturing many\r\n  flows. For a traceroute-like UX we instead want to *lock on* to a packet once,\r\n  then have downstream probes fire purely on identity.\r\n\r\nThis is where the observability problem becomes a kernel interface problem. To follow a packet across transformations, and to let BPF programs annotate a packet at one hook and read it back at another, we need per-packet state that lives and dies with the `sk_buff`. The BPF-map \"side-stash\" works today but is costly: to avoid leaking entries it has to hook the `consume_skb` release path, which fires for every one of the hundreds of thousands of packets passing through the system each second, even when we only care about a handful of them. So we started an upstream effort to add a better building block: **a BPF metadata buffer embedded in an skb extension chunk**.\r\n\r\nWe'll update the audience on where that work has moved since we [last presented](https://netdevconf.info/0x1A/sessions/talk/thrice-the-charm-an-skb-extension-for-bpf-metadata.html) it at Netdev 0x1A in July, and on the challenges we faced wiring Retis up to use it.\r\n\r\nWe'd like to hear whether others have felt the same gap in production, and if not, how they observe a packet's journey through their systems today.\n\n**Attachments:**\n- [Linux Plumbers 2026 - Following the breadcrumbs.pdf](https://lpc.events/event/20/contributions/2549/attachments/2046/4592/Linux%20Plumbers%202026%20-%20Following%20the%20breadcrumbs.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2549/)", "url": "https://lpc.events/event/20/contributions/2549/", "persons": [{"public_name": "Jakub Sitnicki"}]}, {"guid": "lpc20-c3771", "id": "lpc20-c3771", "title": "Crash Dumps at a Bare-Metal Cloud Provider - Capture, Dedup, and AI-Assisted Analysis.", "date": "2026-10-05T12:20:00+02:00", "start": "12:20", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "CoreWeave is a bare-metal cloud provider. A typical machine in our fleet has at least 2TB of RAM, and customers tend to run close to that limit. That has two immediate consequences: the crash-kernel memory reservation matters a lot (every GB we reserve is a GB the customer doesn't get), and when a machine panics the resulting crash dump is huge. Because it's so big, the downtime during a crash, and how soon we can hand the machine back to the customer, ends up gated almost entirely on makedumpfile. At the fleet level it gets even more challenging as bugs triggered by a bad kernel upgrade or some fancy customer workload lead to getting tons of crash dumps at once and all of them are due to the same bug. Finally there’s us, a lean team of 2 kernel engineers at CoreWeave that have to look at all the incoming crash dumps. We lean on AI a lot, at least for triaging failures and knocking out the easy RCAs. That field has progressed and gotten more accurate over time but we still get the occasional confident hallucination.\r\n\r\nOur ideas and projects so far:\r\n\r\n- (Project in-progress at the time of submission) Fingerprint the failure before we even try to capture a dump. Compute a cheap signature of the crash from within the crash kernel, compare it against what we've already seen, and if it's a known one, skip collection altogether. (This probably needs a network connection out of the crash kernel to check against a central store, and we're not sure yet how painful that is to pull off)\r\n\r\n- (Idea) Decouple capturing the crashed memory from turning it into a proper dump. Instead of running makedumpfile to completion before we reboot, grab the crashed memory (maybe with some very light filtering), reboot early to give the machine back, and do the heavy transform/filter later. (There may be Kexec HandOver-related discussion here).\r\n- (Idea) An alternative on the above that we're weighing is to skip the general-purpose dump entirely and use drgn+sdb to take ultra-filtered dumps on the spot, driven by a preconfigured list of data structures we care about.\r\n\r\n- (Project in-progress at the time of submission) Use out-of-band kernel introspection from the DPU to grab ultra-filtered dumps the moment we know a panic happened, without even waiting for the crash kernel to come up (we got drgn+sdb on the DPU reading host memory over RDMA).\r\n\r\n- (Implemented) For the AI triaging/RCA side, hand the agent a Docker container preloaded with the crash dump plus matching debug info, the kernel source for that exact version, and some hints on where to look for existing issues (bug trackers, the mailing list, etc.). We also drop in a small agents.md whose main job is to keep the agent from spinning in endless loops.\r\n\r\n\r\nTopics we'd like to discuss:\r\n\r\n- How do folks capture dumps on multi-TB hosts at fleet scale? Full vs. aggressively filtered, local NVMe vs. a network target, and what capture times are people living with? And how do you settle on the crash-kernel memory reservation?\r\n\r\n- Is anyone else deduplicating crash dumps? If so, what crash-signature/dedup schemes are you using, and is there any appetite for converging on a shared, drgn-based triage library instead of everyone rolling their own?\r\n\r\n- How are people using AI tools for crash dump analysis, and which setups have worked best? How do you keep the confident hallucinations in check?\r\n\r\n- Is anyone else doing out-of-band introspection of production hosts (DPU, BMC, PCIe P2P, RDMA)? How do you handle it, and do you use drgn?\r\n\r\n- How do you keep historical crash dump data around? Jira and/or database plus Grafana? Something else?\n\n**Attachments:**\n- [Crash Dumps - Capture, Dedup, and Analysis.pdf](https://lpc.events/event/20/contributions/2386/attachments/2062/4618/Crash%20Dumps%20-%20Capture,%20Dedup,%20and%20Analysis.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2386/)", "url": "https://lpc.events/event/20/contributions/2386/", "persons": [{"public_name": "Serapheim Dimitropoulos"}]}, {"guid": "lpc20-c3773", "id": "lpc20-c3773", "title": "Breakpoints in drgn", "date": "2026-10-05T12:40:00+02:00", "start": "12:40", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Linux System Monitoring and Observability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Breakpoint support for drgn is currently underway (https://github.com/osandov/drgn/issues/626). Support is planned for:\r\n\r\n* KGDB\r\n* Linux kernel QEMU guests\r\n* Live kernels in production (a sequel to my [2023 LPC session](https://lwn.net/Articles/952942/)).\r\n* Userspace processes (ptrace)\r\n\r\nEach of these targets has its challenges and deficiencies. I will discuss these problems as well as next steps.\n\n**Attachments:**\n- [Breakpoints and Execution Control in drgn.pdf](https://lpc.events/event/20/contributions/2546/attachments/2067/4626/Breakpoints%20and%20Execution%20Control%20in%20drgn%20(1).pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2546/)", "url": "https://lpc.events/event/20/contributions/2546/", "persons": [{"public_name": "Omar Sandoval"}]}, {"guid": "lpc20-c3786", "id": "lpc20-c3786", "title": "Optimizing Gaming Performance and Power Efficiency with Intel LPMD", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:30", "room": "Club H (Floor 1)", "track": "LPC: Gaming on Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Gaming performance remains critical for user experience, but power efficiency has become equally important, particularly for battery-powered devices. Also improves thermal management and reduce thermal throttling. LPMD offers a solution for enhancing energy efficiency by dynamically selecting optimal processor configurations and power slider settings based on CPU and GPU utilization.\r\nThis session demonstrates how Intel LPMD can be configured to improve energy efficiency during gaming workloads while maintaining acceptable performance levels. Will present some performance metrics showing improvements in power consumption and thermal behavior. The discussion will cover LPMD configuration, implementation considerations, and get some suggestions from gaming community.\n\n**Attachments:**\n- [LPC2026_gaming.pptx](https://lpc.events/event/20/contributions/2401/attachments/2015/4549/LPC2026_gaming.pptx)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2401/)", "url": "https://lpc.events/event/20/contributions/2401/", "persons": [{"public_name": "Srinivas Pandruvada"}]}, {"guid": "lpc20-c3787", "id": "lpc20-c3787", "title": "GPU Job Scheduling: Current Development", "date": "2026-10-05T15:30:00+02:00", "start": "15:30", "duration": "00:30", "room": "Club H (Floor 1)", "track": "LPC: Gaming on Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Linux kernel is responsible for managing the dependency graph of userspace's compute and graphics shaders. Moreover, it handles the GPU load balancing and tries to guarantee forward progress and deadlock resistance.\r\n\r\nHistorically, most graphics drivers have used drm_sched, a problematic legacy code base, for these tasks. More recently, Rust drivers are ramping up their own infrastructure to achieve the same, while trying to learn from the mistakes of the past and to leverage the features of the Rust programming language for robustness and reliability. Notably, engineers at Collabora and Red Hat collaboratively develop a successor in Rust for drm_sched, drm::JobQueue.\r\n\r\nThis talk briefly informs about the aforementioned developments and then opens room for discussions which may help the developers (who are – in part – concerned with the compute aspect of GPUs) understand the wider community's pains and requirements, such as from the graphics and video game parties. Topics that could be discussed are, for example:\r\n\r\n- Future of GPU scheduling: more control is handed over to the GPU's firmware, making it difficult or impossible for the kernel to prioritize real time applications such as games.\r\n- What are the major issues in the Linux kernel regarding stability, e.g., crashing video games?\r\n- One reason why drm_sched is in bad shape is that super-priority was given to performance, for example by omitting locks. Fixing some of these missing locks has been rejected, due to reported massive performance regressions. Would video game developers argue that ~100% reliability is worth significant sacrifices with frames per second?\r\n- Used hardware: Which GPUs and drivers are most important for gaming on Linux, and which would the community desire to be supported better the most?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2400/)", "url": "https://lpc.events/event/20/contributions/2400/", "persons": [{"public_name": "Daniel Almeida"}, {"public_name": "Philipp Stanner"}]}, {"guid": "lpc20-c3788", "id": "lpc20-c3788", "title": "EPP-boost: Per-core util-based performance boosting in AMD p-state driver", "date": "2026-10-05T16:00:00+02:00", "start": "16:00", "duration": "00:30", "room": "Club H (Floor 1)", "track": "LPC: Gaming on Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "I've observed that on the Steam Deck, changes to the AMD p-state driver can have a significant impact on tail latencies and stale frame numbers. I've submitted an RFC upstream which proposes a per-CPU EPP boost heuristic: https://lore.kernel.org/all/20260728073150.54964-1-void@manifault.com/.\r\n\r\nWe should discuss gaps in the current cpufreq / AMD p-state driver, and how to best address frequency scaling for gaming workloads in general.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2403/)", "url": "https://lpc.events/event/20/contributions/2403/", "persons": [{"public_name": "David Vernet"}]}, {"guid": "lpc20-c3789", "id": "lpc20-c3789", "title": "Emulating x86 atomics on arm64", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:30", "room": "Club H (Floor 1)", "track": "LPC: Gaming on Linux MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Atomics can be challenging enough by themselves, and emulating them can be even worse. The lack of correctness will crash the application sooner or later, and the lack of performance will be very noticeable.\r\n\r\nOne key difference between x86 and arm64 is how they handle atomic operations on unaligned addresses. While on x86 such operations are supported transparently, on arm64 they raise a SIGBUS and the application is terminated. This creates a problem when emulating x86 games on arm64, since we can’t modify their source code to avoid unaligned atomic operations. So, we need a mechanism to handle such operations on top of arm64.\r\n\r\nThis talk will introduce the topic and describe an implementation design, benchmark results and how other OSes approached this issue.\r\n\r\nLKML link: https://lore.kernel.org/lkml/20251117160841.334224-1-andrealmeid@igalia.com/\n\n**Attachments:**\n- [unaligned_atomic.pdf](https://lpc.events/event/20/contributions/2594/attachments/2071/4673/unaligned_atomic.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2594/)", "url": "https://lpc.events/event/20/contributions/2594/", "persons": [{"public_name": "André Almeida"}]}], "Congress Hall Foyer 0 A (Floor 0)": [{"guid": "oss-ec8f65d00282bd0cdd87a86e983c416a", "id": "oss-ec8f65d00282bd0cdd87a86e983c416a", "title": "Registration & Badge Pick-Up", "date": "2026-10-05T07:30:00+02:00", "start": "07:30", "duration": "09:30", "room": "Congress Hall Foyer 0 A (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/ec8f65d00282bd0cdd87a86e983c416a)", "url": "https://osselceu2026.sched.com/event/ec8f65d00282bd0cdd87a86e983c416a", "persons": []}], "Congress Hall Foyer 0 B (Floor 0)": [{"guid": "oss-23e82daa15dc3c60b5b66270569aa609", "id": "oss-23e82daa15dc3c60b5b66270569aa609", "title": "Cloakroom", "date": "2026-10-05T07:30:00+02:00", "start": "07:30", "duration": "11:15", "room": "Congress Hall Foyer 0 B (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/23e82daa15dc3c60b5b66270569aa609)", "url": "https://osselceu2026.sched.com/event/23e82daa15dc3c60b5b66270569aa609", "persons": []}], "Room 4.3 (Floor 4)": [{"guid": "oss-4383dfb7d0dc472d34efced76a81cc3f", "id": "oss-4383dfb7d0dc472d34efced76a81cc3f", "title": "Zen Zone", "date": "2026-10-05T08:00:00+02:00", "start": "08:00", "duration": "09:00", "room": "Room 4.3 (Floor 4)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "All attendees may feel free to use the Zen Zone as needed. This is a quiet space for sensory relaxation, meditation, and worship. It is not to be used for conversations or as a workspace.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4383dfb7d0dc472d34efced76a81cc3f)", "url": "https://osselceu2026.sched.com/event/4383dfb7d0dc472d34efced76a81cc3f", "persons": []}], "Small Hall (Floor 0)": [{"guid": "lpc20-c3487", "id": "lpc20-c3487", "title": "Untangling convoluted performance regression", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "In this talk I will speak about a performance regression in DB2 backup speed reported by one of SUSE's customer last year. Due to various reasons the analysis was rather convoluted so I will go through the dead ends we have explored as well as leads which eventually allowed us to track down and fix the problem. Overall we demonstrate on a practical example how various tools for analyzing IO related performance regressions can be used.\n\n**Attachments:**\n- [slides-Plumbers2026-Untangling_convoluted_performance_regression.pdf](https://lpc.events/event/20/contributions/2345/attachments/2005/4535/slides-Plumbers2026-Untangling_convoluted_performance_regression.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2345/)", "url": "https://lpc.events/event/20/contributions/2345/", "persons": [{"public_name": "Jan Kara"}]}, {"guid": "lpc20-c3520", "id": "lpc20-c3520", "title": "The slab allocator sheaves post-mortem", "date": "2026-10-05T10:45:00+02:00", "start": "10:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Sheaves are a new percpu caching layer for the Linux kernel's slab allocator (specifically, its only remaining implementation, SLUB). To some extent it's a return to the former SLAB implementation's percpu arrays (callled magazines in the original Bonwick's paper), but avoiding the pitfalls that the SLAB implementation had, thus attempting to get the best of both SLAB and SLUB approaches.\r\n\r\nIn 6.18 sheaves were merged and enabled for maple node and VMA caches. Later  in 7.0 they were enabled for all caches and the original cpu slabs and cpu partial slabs caching layer was removed. This talk will discuss the new implementation, explain the tradeoffs involved, the challenges and performance regression reports encountered on the way. We'll also look at the lessons learned, and ongoing/future work that the sheaves caching has enabled.\n\n**Attachments:**\n- [vbabka-slab-sheaves.pdf](https://lpc.events/event/20/contributions/2344/attachments/2037/4578/vbabka-slab-sheaves.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2344/)", "url": "https://lpc.events/event/20/contributions/2344/", "persons": [{"public_name": "Vlastimil Babka"}]}, {"guid": "lpc20-c3485", "id": "lpc20-c3485", "title": "Modern Developments with NFS in Linux", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The Linux Kernel's NFS server and client has been undergoing a lot of changes recently. This talk will cover some of the latest developments in the Linux NFS Client and Server in the last few years. Including:\r\n\r\n- Dynamic threading\r\n- New iomodes (buffered, direct and dontcache)\r\n- Directory delegations\r\n- POSIX ACLs for NFSv4\r\n- Signed filehandles\r\n- Delegated timestamps\r\n- Multigrain timestamps\r\n- Netlink upcalls\n\n**Attachments:**\n- [Modern Developments with NFS in Linux.pdf](https://lpc.events/event/20/contributions/2351/attachments/2082/4653/Modern%20Developments%20with%20NFS%20in%20Linux.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2351/)", "url": "https://lpc.events/event/20/contributions/2351/", "persons": [{"public_name": "Jeffrey Layton"}]}, {"guid": "lpc20-c3486", "id": "lpc20-c3486", "title": "Modernizing Kernel Boot Options: Resolving cmdline and Bootconfig Discrepancies", "date": "2026-10-05T12:45:00+02:00", "start": "12:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The current Linux kernel command-line subsystem is very simple and easy to define, but it seems to have several problems, such as inconsistent API naming, drivers and the kernel sharing the same command-line options, and discrepancies between documentation and command-line option definitions. Furthermore, some options require special handling and cannot be supported by Bootconfig, an extension of kernel command-line options, but there is no way to indicate which options these are.\r\n\r\nThis session will present ideas for solving these problems, or discuss whether to continue as is.\n\n**Attachments:**\n- [Kernel_Boot_Options_mhiramat.pdf](https://lpc.events/event/20/contributions/2353/attachments/1986/4671/Kernel_Boot_Options_mhiramat.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2353/)", "url": "https://lpc.events/event/20/contributions/2353/", "persons": [{"public_name": "Masami Hiramatsu"}]}, {"guid": "lpc20-c3484", "id": "lpc20-c3484", "title": "Nova — Building an NVIDIA GPU Driver in Rust Upstream", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Nova is an open-source NVIDIA GPU driver being developed entirely upstream from day one — and in Rust. This talk presents the current status and roadmap of the project, describes the upstream development process, and dives into the driver's architecture and how Rust shapes it.\r\n\r\nOn the technical side, we present Nova's architecture: the split into nova-core, nova-drm, vGPU support, and fwctl, the rationale behind this decomposition, and how the components interact across bare-metal and virtualized environments. We follow up with implementation details showing how Rust's type system and ownership model help enforce the boundaries between these components at compile time in the context of the driver model and the DRM subsystem — and show why the DRM subsystem provides a challenge in this regard.\r\n\r\nFinally, we examine the Hardware Abstraction Layer (HAL) architecture common in GPU drivers, where multiple generations of hardware must be supported through composable abstraction layers. We discuss how Rust's trait system and generics provide stronger compositional guarantees than C when building and maintaining these layered abstractions.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2346/)", "url": "https://lpc.events/event/20/contributions/2346/", "persons": [{"public_name": "Danilo Krummrich"}, {"public_name": "John Hubbard"}]}, {"guid": "lpc20-c3488", "id": "lpc20-c3488", "title": "Long-term latency monitoring of real-time Linux systems", "date": "2026-10-05T15:45:00+02:00", "start": "15:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "With the PREEMPT_RT configuration being merged for the 6.12 release a milestone of a twenty years lasting journey was reached: Linux officially became an RTOS! During that time many technical issues have been resolved and many features have been added that made Linux even better even for non real-time users. A specific challenge which had to be tackled was testing and proving the real-time behavior. While for classical RTOSes traditionally a path analysis was carried out, this is close to impossible for a modern operating system such as Linux - not just because of the complexity of the software: Modern processors do come with a lot of performance with the price of being non-deterministic due to several levels of caches, speculation engines and other techniques. As a result the real-time behavior of modern systems has to be evaluated. This is why the OSADL QA Farm was born, doing comparable measurements on a huge variety of systems collecting long-term data to prove stability in the field. But even after 20 years of operation work is not done yet. Linux is evolving rapidly and the test scenarios (also for real-time) have to adopt. Apart from that Open Source RTOSes are also approaching small processors. This is why the OSADL QA Farm was recently extended with Zephyr tests.\r\nThis presentation gives an overview on best practices for evaluating the real-time behavior of Linux (and other) systems, sharing the experience from the OSADL QA Farm. It also wants to serve as a basis for discussion on how measurements shall be carried out in future and how data can be efficiently shared.\n\n**Attachments:**\n- [Long-term-latency-monitoring-of-real-time-Linux-systems_Jan_Altenberg.pdf](https://lpc.events/event/20/contributions/2347/attachments/2038/4579/Long-term-latency-monitoring-of-real-time-Linux-systems_Jan_Altenberg.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2347/)", "url": "https://lpc.events/event/20/contributions/2347/", "persons": [{"public_name": "Jan Altenberg"}]}, {"guid": "lpc20-c3489", "id": "lpc20-c3489", "title": "Firmware-mediated accelerators for edge AI", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "A well-represented class of accelerators for AI in edge deployments aren't programmed directly by the Linux kernel in the host CPU, but by firmware running on a companion core.\r\n\r\nDuring the first half of 2026 alone, we have seen three different drivers submitted to the mailing list for this specific type of hardware, by their respective vendors or on their behalf (TI C7x, NXP Neutron and Qualcomm QDA).\r\n\r\nThis talk will describe in detail a proposal that aligns with the upstreaming requirements in the drm/accel subsystem and streamlines the functionality that is needed inside the Linux kernel and the UAPI. The architecture will be described in detail: firmware, kernel and userspace.\r\n\r\nAn important benefit of the approach is that users will be able to accelerate their workloads without having to integrate any vendor BSPs or vendor-specific software.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2352/)", "url": "https://lpc.events/event/20/contributions/2352/", "persons": [{"public_name": "Tomeu Vizoso"}]}, {"guid": "lpc20-c3490", "id": "lpc20-c3490", "title": "20 years of pahole : alive and kicking!", "date": "2026-10-05T17:45:00+02:00", "start": "17:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The first cset for pahole is from October 24, 2006, a long time ago, from the first goals of helping reorganize the Linux kernel networking data structures, that was done beyond my expectations, helping countless open source projects to view its data structures with great precision and flexibility, to becoming a swiss army knife tool to convert type information from DWARF to CTF and, crucially, to BTF, becoming part of the kernel build process to enable BPF CO-RE, it has kept earning its keep.\r\n\r\nRecent advances in DWARF tag and language support, plus features that exist but aren't well publicized, are subjects I want to communicate.\r\n\r\nCoverage analysis, a quickly growing set of regression tests, support for DWARF tags for C++ and Rust concepts, support for DWZ, partial units, supporting modern DWARF present in distro userlands are topics of recent improvement that, by the 20th anniversary, will surely be ready to talk about.\r\n\r\nIntegration with perf, namely in having pahole and perf work together in areas such as data-type profiling has been a perennial source of requests that, by now, with some help from new and controversial friends, should finally become a reality.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2355/)", "url": "https://lpc.events/event/20/contributions/2355/", "persons": [{"public_name": "Alan Maguire"}, {"public_name": "Arnaldo Carvalho de Melo"}]}], "Small Theater (Floor 0)": [{"guid": "lpc20-c3690", "id": "lpc20-c3690", "title": "Intro/Welcome", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:05", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "\n\n[Open in Indico](https://lpc.events/event/20/contributions/2628/)", "url": "https://lpc.events/event/20/contributions/2628/", "persons": []}, {"guid": "lpc20-c3683", "id": "lpc20-c3683", "title": "A Compressed RAM Service", "date": "2026-10-05T10:05:00+02:00", "start": "10:05", "duration": "00:30", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Compressed RAM (where hardware offloads compression) presents a particularly novel problem for the kernel: the device fundamentally lies about its true capacity - while the kernel is written to assume any `struct page` it can get will always be backed by real capacity.\r\n\r\nUnlike zswap/zram - these devices provide cacheline/byte access to compressed memory, their memory can remain page-table mapped and page-cache present without generate faults on read-access (no COW, no software decompression step etc).\r\n\r\nLets discuss what it would take to formalize support for a compressed RAM service that otherwise \"looks like\" normal memory (migratable, mappable, page-cache-able - but maybe not directly writable).\r\n\r\nAll but one feature required to achieve support already exists in the kernel (or has existed at one time).\r\n\r\n 1. Anon Memory support: Page Table Write Protection (COW, KSM)\r\n 2. Page Cache support: Clean Cache (clean page eligible only)\r\n 3. Reclaim and Demotion\r\n 4. Memory Ballooning (dynamic sizing)\r\n 5. Free Page Reporting (stale data trimming)\r\n 6. Memory Tiering (Hotness / NUMA Balancing)\r\n 7. Strictly controlled NUMA memory allocation (private nodes)\r\n\r\nI will present a tested compressed ram service (mm/cram.c) that achieves near-native performance to DRAM under TAOBench and FIO benchmarks, and has been tested under most in-tree filesystems for pagecache correctness.\n\n**Attachments:**\n- [A Compressed RAM Service.pptx](https://lpc.events/event/20/contributions/2424/attachments/2052/4603/A%20Compressed%20RAM%20Service.pptx)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2424/)", "url": "https://lpc.events/event/20/contributions/2424/", "persons": [{"public_name": "Gregory Price"}]}, {"guid": "lpc20-c3684", "id": "lpc20-c3684", "title": "Unordered I/O (UIO) support and P2P paths", "date": "2026-10-05T10:35:00+02:00", "start": "10:35", "duration": "00:30", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The PCIe Unordered I/O (UIO) feature (introduced in v6.1) relaxes the strict ordering rules of the PCIe fabric, providing benefits such as the avoidance of head-of-line (HOL) blocking. CXL v3.2 specification incorporates P2P UIO access into the HDM space, enabling the peer access from non-CXL capable accelerators (e.g., GPUs) over the PCIe bus.\r\n\r\nEnabling UIO in the Linux kernel involves certain considerations:\r\n - Coherency management while allowing CXL HDM space for both normal and P2P accesses (Ex: coupling with back-invalidation).\r\n - Managing a UIO capable P2P route between a provider (e.g., CXL HDM) and requester (e.g, PCIe GPU).\r\n\r\nThis session will discuss:\r\n - Enumeration of UIO within the PCI and CXL layers.\r\n - CXL-side aspects of a P2P UIO capable memory region (including HDM-DB).\r\n - PCI driver design for UIO and associated P2P-DMA considerations.\r\n - Potential race conditions during enumeration and the mapping P2P routes.\n\n**Attachments:**\n- [LPC26_UIO_v3.pptx](https://lpc.events/event/20/contributions/2468/attachments/2086/4650/LPC26_UIO_v3.pptx)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2468/)", "url": "https://lpc.events/event/20/contributions/2468/", "persons": [{"public_name": "Arun George"}]}, {"guid": "lpc20-c3685", "id": "lpc20-c3685", "title": "CXL Performance Monitoring - Status and Outlook", "date": "2026-10-05T11:05:00+02:00", "start": "11:05", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The CXL specification defines a Component Performance Monitoring Unit (CPMU) register interface for performance monitoring of CXL devices. The Linux kernel includes a CPMU driver that exposes an interface to collect hardware events from CXL memory devices through the perf subsystem.\r\n\r\nThe current driver supports poll-based event counting using perf stat , providing events such as clock ticks, DDR CAS read/write counts, and CXL M2S/S2M protocol events. However, interrupt-based sampling is not implemented — the CPMU capability register defines interrupt support in the CXL spec, but the kernel driver does not utilize it. As a result, perf top and other sampling-based tools are not available.\r\n\r\nThis talk gives an overview of the current CPMU driver implementation, its usage with the perf tool, and the limitations encountered. We also look at how CPMUs relate to standard DRAM profiling with uncore PMUs and EDAC. We discuss adding interrupt support and extending CPMU discovery beyond CXL endpoint devices to root ports and switch ports.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2521/)", "url": "https://lpc.events/event/20/contributions/2521/", "persons": [{"public_name": "Robert Richter"}]}, {"guid": "lpc20-c3686", "id": "lpc20-c3686", "title": "Using Platform-provided Hints for Hot Page Detection and Promotion", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:25", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Hardware platforms continue to expose useful and actionable memory access information to the OS in various ways. Sources of such information include CPU-level instruction/op sampling mechanisms (like AMD IBS and ARM SPE), PMU-based precise sampling (like Intel PEBS), and device-side facilities such as the CXL Hotness Monitoring Unit (HMU). These platform-provided hints can be used by sub-systems like NUMA balancing, reclaim and hot page promotion in tiered memory systems to make better placement decisions, especially on systems with CXL-attached or accelerator memory where the cost of a bad placement is high.\r\n\r\nThe IBS Memory Profiler [1] on future AMD processors is one concrete example of such a hint source. It is a second, lightweight IBS instance on the chip, dedicated to memory access profiling, and provides per-access information (virtual/physical address,  source/target NUMA node) at low overhead. This talk intends to share the experience of working with the IBS Memory Profiler and to look at the ways and challenges in making such a hardware source usable by the kernel in general.\r\n\r\nFor any such platform-provided hint to be useful, a sub-system that can collate and act on hotness information from multiple sources in a producer-agnostic manner is needed. The pghot subsystem [2] is being developed for this purpose. It moves the hot page promotion engine out of NUMA balancing into a sub-system of its own and exposes a uniform interface so that multiple producers (NUMA hint faults, AMD IBS, CXL HMU, etc.) can feed into a single promotion policy. pghot has been discussed at LPC 2023 [3], LSF/MM/BPF 2025 [4] and LPC 2025, and is a recurring topic on the biweekly Linux Memory Hotness and Promotion community call. In this talk, pghot is treated as the enabling base infrastructure and not as the main subject.\r\n\r\nThe talk will also touch upon the producer-side ABI that pghot should commit to, where filtering and aging of the access information should reside, the coexistence with NUMA balancing-driven sampling on capable hardware, and a set of workloads and metrics for fairly comparing different hotness sources.\r\n\r\n[1] AMD IBS Memory Profiler documentation: https://docs.amd.com/v/u/en-US/69205_1.00_AMD64_IBS_PUB\r\n[2] pghot v7 patchset: https://lore.kernel.org/linux-mm/20260504060924.344313-1-bharata@amd.com/ \r\n[3] Using hardware hints for optimal page placement, LPC 2023: https://lpc.events/event/17/contributions/1513/ \r\n[4] Unifying sources of page hotness information, LSF/MM/BPF 2025: https://lore.kernel.org/linux-mm/20250319124552.0000344a@huawei.com/\n\n**Attachments:**\n- [pghot-hwhints-lpc2026.pdf](https://lpc.events/event/20/contributions/2425/attachments/2072/4642/pghot-hwhints-lpc2026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2425/)", "url": "https://lpc.events/event/20/contributions/2425/", "persons": [{"public_name": "Bharata Bhasker Rao"}]}, {"guid": "lpc20-c3687", "id": "lpc20-c3687", "title": "DAMON (Data Attributes Monitoring/Operations Engine)-based {C,G,X}PU [un]attached NUMA Pages Migration", "date": "2026-10-05T12:25:00+02:00", "start": "12:25", "duration": "00:25", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "In the last LPC, we introduced a plan to extend DAMON (Data Access MONitor) for migrating pages around NUMA nodes based on their access pattern.  Based on on/offline feedback, we continued discussions and development in the upstream community.\r\n\r\nAs a result of the collaborations, we made a concrete plan and a roadmap for the goal, including support of extensions for h/w features such as AMD IBS, Intel PEBS and ARM SPE. Major stakeholders agreed on the roadmap that currently planned to deliver the first working version by mid 2027. By the time, it will no longer be called DAMON (Data Access MONitor) but DAMON (Data Attributes Monitoring/Operation eNgine).\r\n\r\nIn this session, we will introduce the evolved design of the in-kernel framework and user interface. We will share the entire roadmap with the expected timeline and the status as of the time of the session. We will discuss pros and cons of the designs and possible adjustments on roadmap, timeline, and priorities of short term future works.\r\n\r\nQuestions we will discuss include but not limited to below:\r\n\r\n- What is the plan and the current status of DAMON for NUMA system memory optimizations?\r\n  - Does the plan makes sense?\r\n  - Any of planned work items need [de]prioritizations?\r\n    - Monitoring extension for AMD IBS, Intel PEBS, ARM SPE, and/or page faults.\r\n    - DAMOS integration with new monitoring framework.\r\n- Can we make it just works without any user inputs?\r\n- Is there a plan to use it in real products?\r\n- Will the classical page table accessed bit based access monitoring be deprecated?  What is the plan and the status?\r\n- What is the current and future test plan?\r\n- Myths and truths of DAMON for NUMA and general use cases.\n\n**Attachments:**\n- [damon_for_cgxpu_numa.pdf](https://lpc.events/event/20/contributions/2518/attachments/2107/4676/damon_for_cgxpu_numa.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2518/)", "url": "https://lpc.events/event/20/contributions/2518/", "persons": [{"public_name": "SJ Park"}]}, {"guid": "lpc20-c3688", "id": "lpc20-c3688", "title": "XMFS: A Cross-node Express Memory File System", "date": "2026-10-05T12:50:00+02:00", "start": "12:50", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "**Cross-node Memory as a Linux Storage Tier：Exploring POSIX-based Shared Memory**\r\n\r\n**Background & Motivation**\r\nMemory-semantic interconnects such as CXL 3.0 and Huawei United Bus make remote memory directly addressable. This raises a question for Linux: should cross-node memory become another storage tier that can be exposed through existing POSIX filesystem interfaces?\r\n\r\n**Our Exploration: XMFS**\r\nTo explore this question, we built XMFS, an in-kernel prototype that exports cross-node shared memory through a standard POSIX filesystem interface. Initial experiments with metadata-intensive workloads and container image sharing suggest the approach is practical.\r\n\r\n**Engineering Challenges Encountered** \r\nDuring development we repeatedly encountered four areas where existing kernel abstractions are either missing or insufficient:\r\n• Metadata synchronization: Current VFS and filesystem metadata management assume a single kernel instance coordinating namespace and inode updates. What generic kernel mechanisms are needed to efficiently synchronize metadata across multiple kernels without introducing centralized bottlenecks?\r\n• Software cache coherence: The Linux page cache and MM subsystem rely on hardware cache coherence within a machine. When memory is shared across nodes without hardware coherence, should software cache-coherence policies live inside individual filesystems, the MM subsystem, or new generic kernel infrastructure?\r\n• Integrating hybrid transports: Linux currently exposes memory-semantic interconnects and RDMA through different subsystems and programming models. How should these be integrated so that filesystems can transparently use both without exposing transport-specific behavior to applications?\r\n• Capacity management & Tiering: Linux already provides memory tiering, page migration, and NUMA-aware memory management. Should cross-node shared memory participate in these mechanisms, and what interfaces are needed between filesystems and MM to support it?\r\n\r\n**Topics for Discussion** \r\nRather than presenting XMFS as a finished filesystem, we hope to discuss whether Linux should treat cross-node memory as a first-class storage tier, which abstractions belong in VFS/MM rather than individual filesystems, and what a practical upstream path could look like. We believe these questions will become increasingly relevant as memory-semantic interconnects become more widely available.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2516/)", "url": "https://lpc.events/event/20/contributions/2516/", "persons": [{"public_name": "Yifan Qiao"}]}, {"guid": "lpc20-c3689", "id": "lpc20-c3689", "title": "DAXFS: What Does Shared-Memory Storage Need from DAX, VFS, and CXL Memory Management?", "date": "2026-10-05T13:10:00+02:00", "start": "13:10", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Device and Specific Purpose Memory MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "When multiple kernels or CXL-connected hosts share byte-addressable memory, every existing filesystem option pays a copy per participant: tmpfs replicates content N times, erofs and fscache keep a private page cache per kernel. To ground the discussion we bring DAXFS, a prototype filesystem that runs directly on DAX memory with no block layer: one shared namespace, a cooperative page cache in the shared region, and mounts backed by a raw physical range or a dma-buf, so GPUs reach file data zero-copy through the backing buffer. Unlike famfs, where a userspace master preallocates files and distributes metadata to read-only clients out of band, DAXFS is masterless: metadata lives in the shared region itself and any participant can create files and COW-write pages concurrently through lock-free CAS updates, no metadata server, no out-of-band log.\r\n\r\nThe killer use case we are building toward is checkpoint and restore of AI agent sandboxes. Thousands of short-lived agent instances share one mapping of the base rootfs and model weights, with writable state as COW overlay pages in shared memory. Today the image carries a single shared overlay; giving each sandbox its own sealable overlay would make checkpoint a seal operation and restore (or forking N agents from one checkpoint) just a map: no gigabytes serialized through a block device, cold start drops from minutes to seconds.\r\n\r\nBuilding it surfaced gaps bigger than one filesystem, and we want the MC to weigh in:\r\n\r\n* DAXFS bypasses fs/dax entirely (memremap plus raw PFN mappings) because fs/dax assumes a filesystem privately owns its dax_device. How do shared multi-writer DAX mappings become supported, not a special case?\r\n\r\n* Is a filesystem the right ABI for pooled memory carved into named shareable objects, or should this be device-dax, a sparse memfd (per the DCD discussions), or guest_memfd-shaped?\r\n\r\n* DAXFS mounts from an imported dma-buf today; exporting per-file extents as dma-bufs is the natural next step. What are the lifetime and coherence rules when the exporter is a filesystem over shared device memory, with P2P DMA targeting it?\r\n\r\n* Who owns allocation when N hosts share a Dynamic Capacity Device, and how does DCD extent release interact with live filesystem data?\r\n\r\n* Where is the line between memory core MM manages and memory a cross-kernel service manages, and how do hotness tracking and migration see pages no single kernel owns?\n\n**Attachments:**\n- [daxfs-lpc.pdf](https://lpc.events/event/20/contributions/2517/attachments/1988/4570/daxfs-lpc.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2517/)", "url": "https://lpc.events/event/20/contributions/2517/", "persons": [{"public_name": "Cong Wang"}]}, {"guid": "lpc20-c3697", "id": "lpc20-c3697", "title": "Linux Crypto API is dead, long live Linux Crypto API v2?", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Linux Crypto API has recently come under fire due to a series of discovered vulnerabilities, like [Copy Fail][1] and friends. This resulted in a drastic response from some maintainers: deprecation of the [Linux Crypto API userspace interface][2]. However, it feels like cracking a nut with a sledgehammer, as some vulnerabilities, like [Dirty Frag][3], do not even use the userspace interface directly for the exploit.\r\n\r\nDoing crypto in the kernel on behalf of userspace code may bring some security and efficiency advantages:\r\n\r\n- the key material is not exposed to the process address space anymore, which can save the key from very common memory bugs (remember Heartbleed?)\r\n- abstracting the key material as a kernel object (e.g., a file descriptor) allows sharing the key usage across unprivileged applications without giving those applications access to the key material (software HSM/KMS use case, cloud workloads, K8s)\r\n- the kernel is best positioned to abstract modern cryptographic hardware and allow applications to utilize it and reap the performance benefits\r\n- highly-constrained embedded systems may have fewer dependencies as they don't have to pull extra crypto libraries such as OpenSSL or gcrypt into their firmware\r\n\r\nOne of the reasons quoted for the deprecation is that the userspace Linux Crypto API interface is not efficient anyway and there are very few users. But maybe there are few users, because it is not very efficient and apparently insecure? What if instead of disabling it we improve it or even redesign? For example:\r\n\r\n- replace the splice()-based zero-copy interface (which was targeted by the vulnerabilities in the first place and is not truly zero-copy anyway) with a modern primitive such as io_uring\r\n- fix the limitation of authenticated encryption being able to process only ~64k of data\r\n- replace the confusing network-based AF_ALG protocol with something simpler, such as plain device files/sysfs\r\n- use eBPF to expose Linux Crypto API to userspace in a more constrained and controllable manner\r\n- limit the number of algorithms exposable to userspace – only general-purpose algorithms should be exposed\r\n\r\nThe goal of this session is to reach a shared view on whether the userspace Linux Crypto API is worth saving and, if so, what a v2 should look like.\r\n\r\n[1]: https://copy.fail/\r\n[2]: https://lore.kernel.org/netdev/20260430011544.31823-1-ebiggers@kernel.org/\r\n[3]: https://github.com/v4bel/dirtyfrag\n\n**Attachments:**\n- [linux-crypto-api-v2.pdf](https://lpc.events/event/20/contributions/2578/attachments/2039/4580/linux-crypto-api-v2.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2578/)", "url": "https://lpc.events/event/20/contributions/2578/", "persons": [{"public_name": "Ignat Korchagin"}]}, {"guid": "lpc20-c3698", "id": "lpc20-c3698", "title": "Early Attestation is Very Harmful. Why is it Required?", "date": "2026-10-05T15:25:00+02:00", "start": "15:25", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "**Abstract**: \r\nThis talk is a follow-up of LPC'25, where we introduced the security problem to the community for a suitable approach of attested TLS protocols. We would like to present updates to the work since LPC'25 and discuss open problems with the community so that the feedback can be accommodated in the standardization in the IETF. In particular, we share our discovered critical-severity CVEs, such as [CVE-2026-92701][1], [CVE-2026-92702][2], [CVE-2026-100835][3], each of CVSS 9.1, and other [critical- and high-severity security concerns][4] against early attestation, and ask the community whether early attestation is really necessary.\r\n\r\n**Discussion**:\r\nWe would like to discuss:\r\n\r\n- Section 7 of [this work][5].\r\n- [Questions][6] raised by the IETF community\r\n\r\n\r\n**Background**:\r\nTransport Layer Security (TLS) is a widely used protocol for secure channel establishment. However, it lacks an inherent mechanism for validating the security state of the workload and its platform. To address this, remote attestation can be integrated into TLS, which is named attested TLS protocol. \r\n\r\nAs presented in LPC'25, there are two key approaches for this integration, namely early (intra-handshake) and standard (post-handshake) attestation. We also present insights from formal verification using the state-of-the-art symbolic security analysis tool ProVerif that led to the discovery of the critical- and high-severity CVEs. \r\n\r\nCurrent project partners include CoreWeave, University of Namur, Stevens Institute of Technology, Shanghai Guan An Information Technology, Switch, Oxford University, Sureshot Labs, PHI-OMEGA, HashCloak Inc, Stoffel Labs Inc, EMILIA Protocol, ESILV, Birmingham City University, Verily, Arm, Linaro, Siemens, Huawei, Intuit, Axis, Bonn-Rhein-Sieg University of Applied Sciences, and Barkhausen Institut. By this talk, we hope to inspire more open-source contributors to this project. \r\n\r\nThe attendees will gain technical insights into the latest developments of standardization of attested TLS protocols in the IETF, and will be able to provide feedback on the standardization effort of attested TLS. \r\n\r\n\r\n**Benefits to the ecosystem**\r\nOur thorough formal security analysis shows that early attestation is potentially vulnerable to replay, relay, diversion, and misbinding attacks. Our analysis shows that:\r\n\r\n 1. Early attestation adds unnecessary complexity in the handshake.\r\n 2. Early attestation results in several security and privacy problems, such as those captured in published CVEs.\r\n 3. All use cases of early attestation can be handled with standard attestation while offering better security properties.\r\n\r\nBecause of critical-severity CVEs and fundamental architecture problems in early attestation, we believe early attestation is very harmful to the TEE attestation ecosystem. We would like to discuss with the community whether it is necessary.\r\n\r\n\r\n  [1]: https://www.cve.org/CVERecord?id=CVE-2026-92701\r\n  [2]: https://www.cve.org/CVERecord?id=CVE-2026-92702\r\n  [3]: https://www.cve.org/CVERecord?id=CVE-2026-100835\r\n  [4]: https://datatracker.ietf.org/doc/draft-intra-handshake-fail/\r\n  [5]: https://www.researchgate.net/publication/414529199_EarlyAttestationBleed_Three_Critical-severity_Vulnerabilities_of_CVSS_90_in_Confidential_Computing\r\n  [6]: https://www.ietf.org/archive/id/draft-intra-handshake-fail-54.html#section-17.2.1\n\n**Attachments:**\n- [EarlyAttestationBleed: Three Critical-severity Vulnerabilities of CVSS ≥ 9.0 in Confidential Computing](https://lpc.events/event/20/contributions/2585/attachments/2040/4582/go)\n- [Early Attestation Considered Very Harmful](https://lpc.events/event/20/contributions/2585/attachments/2040/4581/go)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2585/)", "url": "https://lpc.events/event/20/contributions/2585/", "persons": [{"public_name": "Muhammad Usama Sardar"}]}, {"guid": "lpc20-c3699", "id": "lpc20-c3699", "title": "Extending BPF Signing into an IMA Integrity Lifecycle", "date": "2026-10-05T15:45:00+02:00", "start": "15:45", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "eBPF programs enter the kernel as privileged extensions and, once admitted, become part of the system’s trusted computing base. Prior LPC discussions established BPF signing as a way to track the provenance of these programs, while deliberately separating signature verification from the policy that consumes it [1,2]. IMA was identified as one possible consumer through LSM integration, but its enforcement semantics were left open. Follow-up discussion highlighted unresolved issues involving dynamically generated programs, trusted loaders, and applications such as Cilium and bpftrace.\r\n\r\nWe developed IMA-BPF as a concrete continuation of this work. IMA-BPF connects BPF signatures to IMA policy, measurement, appraisal, and TPM-backed attestation. It preserves signer provenance for programs created by signed loaders, allowing resident programs to be re-evaluated after the original loader disappears. We also introduce reappraisal and purge mechanisms, allowing programs that no longer satisfy current policy or trust state to be detached and removed through BPF’s link and reference based lifetime mechanisms.\r\n\r\nThis talk will explain how IMA-BPF extends BPF signing into an integrity lifecycle, evaluated through Cilium vulnerability remediation. We hope to discuss three areas: the practicality of adopting signing across real BPF workloads; how the BPF ecosystem should standardize provenance for dynamically generated programs, such as providing common reference tooling in different languages; and how our initial reappraisal and revocation policies and mechanisms should be refined. Although our prototype demonstrates this lifecycle end to end, we hope to use the discussion to improve the design and identify a practical path toward upstream adoption.\r\n\r\nReferences\r\n\r\n1. KP Singh, BPF Signing and IMA Integration, https://lpc.events/event/16/contributions/1357/\r\n2. KP Singh, Discussion: What’s Next for BPF Signing, https://lpc.events/event/19/contributions/2167/\n\n**Attachments:**\n- [LPC talk latest.pdf](https://lpc.events/event/20/contributions/2591/attachments/2029/4567/LPC%20talk%20latest.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2591/)", "url": "https://lpc.events/event/20/contributions/2591/", "persons": [{"public_name": "Hongming Qiu"}]}, {"guid": "lpc20-c3700", "id": "lpc20-c3700", "title": "Attestation-Based Storage Provisioning for Linux: Towards a Standard Model", "date": "2026-10-05T16:10:00+02:00", "start": "16:10", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Linux has no standard model for provisioning and unlocking encrypted persistent storage at boot in environments where the underlying platform cannot be fully trusted. Today, every deployment stack solves this independently: custom boot agents, post-provisioning scripts, and platform-specific unlock logic. The mechanism exists — LUKS2 tokens and the cryptsetup plugin interface — but the workflow around it does not. Every team that wants attestation-backed storage unlocking ends up writing the same three things from scratch: a script to register token metadata at provisioning time, a plugin to perform attestation and key retrieval at boot, and custom logic to handle failure cases. None of this is reusable across platforms or deployable through standard Linux tooling.\r\n\r\nThis session proposes that the LUKS2 token mechanism and the cryptsetup plugin interface should become the standard interoperability contract between Linux storage tooling and external attestation-aware key services. In this model, a Key Broker Service holds encryption keys and releases them only after the system proves its identity through remote attestation. The LUKS2 header carries the token metadata that tells systemd-cryptsetup which plugin to invoke at boot, making the storage layer independent of any specific attestation technology, hardware platform, or key service implementation. The provisioning side is handled by systemd-repart, which registers the token metadata in the LUKS2 header at first-boot — no separate import step, no custom scripts.\r\n\r\nFor this model to work reliably end-to-end, three specific gaps need to close. First, the cryptsetup plugin error contract is undefined: today systemd-cryptsetup silently falls through to passphrase unlock when a plugin fails, with no distinction between permanent attestation failure and transient network unavailability. A KBS plugin that fails because attestation was rejected should behave very differently from one that timed out waiting for the network — but there is currently no standard way to express that. Second, the LUKS2 token JSON schema beyond type and keyslots is unspecified: KBS-specific metadata such as service endpoint URLs is stored in private fields with no agreed naming, making provisioning tools and unlock plugins non-interoperable without bilateral coordination. Third, there are no packaging or initrd inclusion guidelines for token plugins, leaving distributions without a clear answer on how to ship and discover them at boot.\r\n\r\nThe session will walk through the current state of the code in systemd-cryptsetup and systemd-repart, identify precisely where these gaps exist today, and open a discussion on what standardisation is needed. The goal is agreement on reusable, upstream building blocks for attestation-driven storage provisioning — so that every platform and deployment stack building on Linux does not have to solve this problem independently.\n\n**Attachments:**\n- [LPC_2026_Attestation_Storage_Provisioning_for_Linux.pdf](https://lpc.events/event/20/contributions/2592/attachments/2089/4654/LPC_2026_Attestation_Storage_Provisioning_for_Linux.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2592/)", "url": "https://lpc.events/event/20/contributions/2592/", "persons": [{"public_name": "Nandakumar Raghavan"}]}, {"guid": "lpc20-c3701", "id": "lpc20-c3701", "title": "Secure Boot: Getting your SHIM signed - The process and Its challenges", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "This talk walks through the end-to-end process for Linux distributions to have their SHIM submitted for review and eventual signing by Microsoft, surfacing the challenges faced by both distribution teams and the SHIM review team.\r\n\r\nWe examine this process in depth from dual vantage points: distribution maintainers navigating submission requirements -- including SBAT entries, CVE patching, DBX and revocation policies -- and the SHIM review team evaluating submissions.\r\n\r\nWe also address the Partner centre for Windows Hardware and what Linux distribution teams need to eventually get the SHIM signed by Microsoft.\n\n**Attachments:**\n- [Secure Boot: Getting your SHIM signed - The process and Its challenges.pdf](https://lpc.events/event/20/contributions/2589/attachments/2043/4586/Secure%20Boot_%20Getting%20your%20SHIM%20signed%20-%20The%20process%20and%20Its%20challenges.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2589/)", "url": "https://lpc.events/event/20/contributions/2589/", "persons": [{"public_name": "Sherif Nagy"}]}, {"guid": "lpc20-c3702", "id": "lpc20-c3702", "title": "Generic Boot Flow for Type 1 Hypervisors: UKI with systemd-stub", "date": "2026-10-05T17:25:00+02:00", "start": "17:25", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "ARM SystemReady defines a standard firmware-to-OS boot path via UEFI, but provides no standard mechanism for booting Type 1 hypervisors such as Gunyah or Xen. Platforms relying on Type 1 hypervisors to isolate security- or latency-sensitive workloads, lack a standardized boot flow, which creates fragmentation across mobile, IoT, and compute ecosystems.\r\n\r\nWe have implemented a solution for this across three areas. First, we propose extensions to the UKI format to bundle a Type 1 hypervisor and its static guest VM images in a single UEFI secure-boot authenticated image. Second, we discuss the required changes to systemd-stub to parse the extended UKI to extract and pass configuration data to the hypervisor at boot. Third, we have prototyped support to the systemd-boot tooling to control and maintain this configuration.\r\n\r\nBy aligning with both the Xen and Gunyah communities, the goal is to enable a vendor-neutral, standards-compliant boot flow for any Type 1 hypervisor, using UKI.\r\n\r\nTopics to be discussed:\r\n1. UKI extensions for Type 1 hypervisors\r\n2. Interface between systemd-stub and hypervisor\r\n3. Configuration data passed to the hypervisor\n\n**Attachments:**\n- [Standard_Type1_Hypervisor_Boot.pptx](https://lpc.events/event/20/contributions/2587/attachments/2088/4652/Standard_Type1_Hypervisor_Boot.pptx)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2587/)", "url": "https://lpc.events/event/20/contributions/2587/", "persons": [{"public_name": "Anushka Nabar"}]}, {"guid": "lpc20-c3703", "id": "lpc20-c3703", "title": "Booting Android with Linux EFI Boot Stub", "date": "2026-10-05T17:45:00+02:00", "start": "17:45", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Android is evaluating the Linux EFI boot stub to standardize OS handoff and reduce bootloader feature duplication.\r\nWe present blockers encountered with embedded hardware constraints, and aim to discuss potential solutions.\r\n\r\nTopics for Discussion:\r\n\r\n* EL2 Elevation and KVM within an EFI context\r\n    * **The Problem:** KVM requires booting the kernel at EL2. Since Android firmware operates at EL1, it must elevate to EL2 before kernel execution.  \r\n    * **Discussion:** What are the options to elevate to EL2 before jumping to the kernel?  \r\n        * Override UEFI `ExitBootServices` to hijack the boot flow?  \r\n        * Install a custom UEFI protocol callback that executes EL switch and takes over kernel jump?\r\n\r\n* Physical Image Placement and PE/COFF Relocation\r\n    * **The Problem:** The UEFI PE/COFF loader copies and relocates the kernel image to a dynamically allocated buffer address.\r\n    * **The Constraint:**  \r\n        * *Boot Latency:* Copying large kernel payloads increases boot latency.  \r\n        * *Defeat Architectural Expectations:* Hardware platforms might require the kernel image loaded at specific address ranges. The PE loader moving the kernel image around defeats this.\r\n    * **Discussion:** How do we eliminate unnecessary allocations and respect physical image placement done by the firmware/bootloader.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2590/)", "url": "https://lpc.events/event/20/contributions/2590/", "persons": [{"public_name": "Yi-Yo Chiang"}]}, {"guid": "lpc20-c3704", "id": "lpc20-c3704", "title": "Arm DRTM beyond the reference model: dynamic launch on real platforms and Linux", "date": "2026-10-05T18:10:00+02:00", "start": "18:10", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: System Boot and Security MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Arm's DRTM architecture (DEN 0113) defines a dynamic root of trust for measurement: a DCE-Preamble triggers a dynamic launch event, EL3 firmware (TF-A) measures a protected payload into a fresh chain of trust, and the dynamically launched measured environment (DLME) continues under a smaller TCB. Yet a working implementation exists only against the Base AEM FVP TF-A's plat_drtm hooks (SMMU-based DMA protection, the DRTM address map, and measurement) live solely under the fvp board, and the Neoverse reference-design platforms that model real server silicon ship no DRTM support at all.\r\n\r\nThis session looks at what it takes to move Arm DRTM off the reference model and make it useful to Linux: porting the plat_drtm platform layer onto the Neoverse reference-design ports; delivering the DCE-Preamble as a UEFI/EDK2 application rather than a bootloader patch; measuring into PCR 17/18 with a DRTM event log; and the kernel-side plumbing to consume and attest the launch. Drawing on 3mdeb's TrenchBoot work and years in the Arm DRTM ecosystem, we want to map the upstreaming path across TF-A, EDK2, and the kernel, and name the gaps and their owners.\r\n\r\nDesired outcome: consensus on a minimal, reproducible Arm DRTM reference that the community can build on FVP-first, then real silicon, and a shared list of the upstream changes needed to get there.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2577/)", "url": "https://lpc.events/event/20/contributions/2577/", "persons": [{"public_name": "Piotr Król"}]}], "South Hall 1 A (Floor 1)": [{"guid": "lpc20-c3582", "id": "lpc20-c3582", "title": "Rust-BPF updates", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Support for all of Rust required rethinking of how the verifier processes instructions. Stack liveness, SCEV, indirect calls are known building blocks while more fundamental rewrite is still necessary. The talk will cover completed and upcoming work areas in the verifier, LLVM, GCC, rustc, libbpf.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2439/)", "url": "https://lpc.events/event/20/contributions/2439/", "persons": [{"public_name": "Alexei Starovoitov"}]}, {"guid": "lpc20-c3583", "id": "lpc20-c3583", "title": "Support large-size arguments and Rust based exception handling", "date": "2026-10-05T10:30:00+02:00", "start": "10:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Large-size Arguments\r\n--------------------\r\n\r\nCurrent bpf verifier will reject a function if one of its arguments\r\nis a union/struct or more than one register size (except __int128 type).\r\nSuch limitation forces users to work around codes to fit bpf prog\r\nrequirement, but such limitation does not exists for other languages,\r\nlike normal C, rust, etc. Without such limitation, users will be able\r\nto write more elegant codes.\r\n\r\nRust Based Exception Handling\r\n-----------------------------\r\n\r\nCurrent C based bpf prog do not have language level exception\r\nhandling. The bpf echosystem added bpf_throw() kfunc to allow\r\nexception which does architecture unwinding and allows some\r\ncode at main prog level.\r\n\r\nRust bpf supports more flexible exception handling at language\r\nlevel. It allows bpf callbacks at individual function exception\r\nlevel, e.g. to release certain references etc. At each function\r\nlevel, it is possible there are multiple possible exception\r\nhandling, e.g., A -> B -> C. If C tiggered exception, bpf\r\ncallbacks can be called for C, then B, then A.\r\n\r\nIn any case, Rust can provide lots of flexibility when something\r\nwrong during verification.\n\n**Attachments:**\n- [16byte_exception.pdf](https://lpc.events/event/20/contributions/2438/attachments/2111/4681/16byte_exception.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2438/)", "url": "https://lpc.events/event/20/contributions/2438/", "persons": [{"public_name": "Yonghong Song"}]}, {"guid": "lpc20-c3591", "id": "lpc20-c3591", "title": "Extending the BPF Type Format to support more languages", "date": "2026-10-05T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Now that kernel modules can be built in Rust [1],[2], it seems timely to look at programming language constructs outside of C to assess their applicability to BTF representation. Suggestions include\r\n\r\n- slices/\"fat pointers\" with type and size\r\n- tagged unions\r\n- generics\r\n- interfaces\r\n- lifetime tags\r\n\r\nRough suggestions will be made for how to represent these as BTF kinds to trigger discussion.\r\n\r\n[1] https://docs.kernel.org/rust/index.html\r\n[2] https://lwn.net/Articles/991719/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2408/)", "url": "https://lpc.events/event/20/contributions/2408/", "persons": [{"public_name": "Alan Maguire"}]}, {"guid": "lpc20-c3584", "id": "lpc20-c3584", "title": "Slaying the BPF Verifier:  Safe & Static Kernel Extensions Using Rust", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "While the BPF verifier ensures kernel safety, its rigid static rules heavily bottleneck the development of complex kernel extensions. Last year’s LPC introduced [Rex][1] (Rust Extensions) to address these gaps. By leveraging Rust, Rex aims to guarantee memory and type safety at compile time rather than relying on the restrictive verifier. While this initial iteration utilized runtime protection to manage panics and address the halting problem, it resulted in **considerable** architectural and performance trade-offs.\r\n\r\nThis talk introduces the revamped, statically compiled **panic-free** Rex. By fully leaning into Rust’s static typing, borrow checker, and a dedicated compiler pass, this new architecture closely mirrors the verifier’s safety profile but at compile time. It empowers developers to build large-scale kernel programs using dynamic loops, complex data structures, and natural programming patterns.\r\n\r\nTo prove this model's viability, we will present a successful Proof of Concept integrating the new Rex with the [ghOSt][2] scheduler. We will walk through the implementation details, demonstrating how Rex handles complex [scheduling logic][3] safely and efficiently entirely in Rust.\r\n\r\nUltimately, we seek to engage the community in a dialogue regarding the robustness of this architectural framework and the strategic roadmap for upstream integration. We are eager to assess the broader interest in the evolved Rex and solicit feedback on potential refinements to further optimize our model.\r\n\r\n\r\n  [1]: https://lpc.events/event/19/contributions/2190/\r\n  [2]: https://research.google/pubs/ghost-fast-and-flexible-user-space-delegation-of-linux-scheduling/\r\n  [3]: https://lpc.events/event/19/contributions/2034/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2436/)", "url": "https://lpc.events/event/20/contributions/2436/", "persons": [{"public_name": "Aniket Gattani"}]}, {"guid": "lpc20-c3588", "id": "lpc20-c3588", "title": "blitmus: Litmus-testing the eBPF memory model on real hardware", "date": "2026-10-05T12:30:00+02:00", "start": "12:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The eBPF instruction set has quietly grown a concurrency surface: load_acquire/store_release instructions, arena atomics now JIT-compiled across x86, arm64, riscv and powerpc, resilient queued spinlocks, and lock-free ring buffers. eBPF programs routinely run concurrently across CPUs and increasingly coordinate through shared memory. Yet unlike the Linux kernel — which has a formal, herd7-executable memory model (LKMM) and the klitmus7 tool to exercise it — eBPF has no formal memory model and no way to check that the ordering a program requests actually survives the verifier and each architecture's JIT.\r\n\r\nThis talk presents **blitmus** (https://github.com/puranjaymohan/blitmus), a tool that converts standard LKMM litmus tests into eBPF programs and runs them on real hardware. Each process of a litmus test becomes a BPF program pinned to a specific CPU; a userspace harness races them across millions of iterations, histograms the outcomes, and compares them against the test's exists clause and expected result — the same methodology klitmus7 and herd7 use, but exercising the BPF runtime end to end. Because the same litmus test can be run unchanged on every architecture, blitmus can surface JIT ordering bugs (e.g. a missing barrier for cmpxchg) that are otherwise silent and catastrophic for concurrent BPF code.\r\n\r\nI will demo the tool converting and running the LKMM litmus suite through BPF, walk through the results on aarch64 and x86-64 (including weak behaviors observed for store-buffering and a Result: Never test that blitmus flags as violated), and use that case to discuss tool fidelity: how faithfully a batched, test-run-based harness models true multi-CPU races, and where the current barrier/interleaving strategy needs to improve.\r\n\r\nI would like to use the session to discuss next steps with the community: \r\n\r\n(1) growing the harness to cover BPF-specific primitives — arena spinlocks, rqspinlock, ring buffer reserve/commit ordering, per-CPU maps;\r\n\r\n(2) a proper litmus parser and cross-architecture CI (qemu on riscv/ppc/s390/loongarch) wired into selftests/bpf as a memory-model conformance suite;\n\n[Open in Indico](https://lpc.events/event/20/contributions/2432/)", "url": "https://lpc.events/event/20/contributions/2432/", "persons": [{"public_name": "Puranjay Mohan"}]}, {"guid": "lpc20-c3590", "id": "lpc20-c3590", "title": "Adding KASAN support for JIT-compiled BPF Programs", "date": "2026-10-05T13:00:00+02:00", "start": "13:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "KASAN (Kernel Address Sanitizer) is a powerful developer tool for detecting\r\nuse-after-free and out-of-bounds memory accesses in the kernel code.\r\nHowever, not all memory accesses performed by the kernel are covered by\r\nKASAN monitoring. BPF programs are a major example: when they are\r\ntranslated by the in-kernel JIT compiler, the kernel directly emits new\r\nnative instructions that then escape KASAN instrumentation. Closing this\r\ngap would shed some light on potential bugs in the eBPF verifier or JIT\r\ncompilers that would be hard to investigate otherwise.\r\n\r\nThis talk will present the current effort funded by the eBPF Foundation\r\naiming to introduce KASAN support for eBPF programs: we will discuss the\r\nmain architectural points, going over how the JIT compiler emits calls to\r\n`__asan_*()` functions before each memory access, discussing the register\r\nsave/restore strategy, and the interactions with the BPF verifier.\r\n\r\nAs a first draft of this work has been introduced at the LSFMMBPF\r\nconference 2026 (Zagreb, Croatia), and as many revisions have been sent and\r\ndiscussed on the BPF mailing list since then, this talk will also act as an\r\nupdate, highlighting the main changes since the first draft, as well as the\r\nremaining difficulties and issues to solve.\n\n**Attachments:**\n- [lothore-kasan-ebpf.pdf](https://lpc.events/event/20/contributions/2431/attachments/2109/4679/lothore-kasan-ebpf.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2431/)", "url": "https://lpc.events/event/20/contributions/2431/", "persons": [{"public_name": "Alexis Lothoré"}]}, {"guid": "lpc20-c3585", "id": "lpc20-c3585", "title": "BPF Kernel Verifier meets GCC: A saga of arranged marriage", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "BPF Verifier has troubles grok'ing GCC generated code (having evolved with LLVM over time). This talk is about my recent work on BPF GCC and the kernel verifier and efforts to make them like each other more.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2442/)", "url": "https://lpc.events/event/20/contributions/2442/", "persons": [{"public_name": "Vineet Gupta"}]}, {"guid": "lpc20-c3587", "id": "lpc20-c3587", "title": "Evolution of Value Tracking in the BPF Verifier", "date": "2026-10-05T15:30:00+02:00", "start": "15:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "While safety and performance get most of the credit for BPF's success, a safe and fast program that couldn't do anything interesting would be rather useless. Much of the flexibility that makes BPF programs interesting today (e.g. indexing into a map value at a computed offset, walking packet data, reading a stack array at a variable index) was actually not there at the start.\r\n\r\nIn this talk, we'll give a thousand-foot overview that goes from the initial tracking of constant/unknown all the way to cnum, covering topics like scalar IDs, sub-register bounds, bounds syncing, as well as value-tracking bugs along the way.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2447/)", "url": "https://lpc.events/event/20/contributions/2447/", "persons": [{"public_name": "Shung-Hsi Yu"}]}, {"guid": "lpc20-c3586", "id": "lpc20-c3586", "title": "Proof-Carrying Verification for eBPF", "date": "2026-10-05T16:00:00+02:00", "start": "16:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "## Abstract\r\n\r\neBPF provides a safe way to extend the kernel functionality. To ensure safety, the kernel verifies the memory safety and termination of eBPF programs and is thus the security boundary for eBPF. It must accept untrusted programs from userspace and determine, under strict time and memory limits, whether they are safe to execute.\r\n\r\nToday, the verifier symbolically executes program paths, tracks abstract register and memory states, and uses state pruning and repeated loop exploration to establish safety. Keeping both proof discovery and proof checking in the kernel has the important advantage that the kernel does not need to trust the compiler or any userspace component.\r\n\r\nThe cost of this design is that the kernel has to employ a sophisticated analysis capable of reconstructing invariants from eBPF bytecode. Compilers may already discover source-level relationships and loop invariants, but these facts are not normally conveyed to the kernel. When the verifier cannot recover invariants, it must conservatively reject the program. At the same time, the complexity of the analysis makes it difficult to audit and maintain this security boundary, and verifier bugs can result in malicious programs being accepted. Verification failures can also be difficult to predict and relate back to the source program.\r\n\r\nWe are exploring a proof-carrying verification architecture that separates proof generation from proof checking. An untrusted userspace proof generator analyzes the program, discovers invariants, and uses an SMT solver to discharge safety obligations. If successful, it emits a certificate containing the invariants and proof steps needed to validate the program. If an obligation cannot be proved, the tool can use compiler metadata and solver output to distinguish concrete counterexamples from unsupported reasoning or missing invariants, and produce source-oriented diagnostics.\r\n\r\nInside the kernel, a domain-specific checker validates the program and certificate together. The certificate supplies facts such as basic-block and loop invariants, pointer bounds, and relationships between program values. The checker does not search for invariants or invoke an SMT solver. It validates each claimed state transition and entailment using a restricted set of eBPF-specific reasoning rules.\r\n\r\nFor example, a loop certificate may provide an invariant relating an induction variable, a packet pointer, and data_end. The checker verifies that the invariant holds on entry, is preserved across the back edge, and is strong enough to justify each memory access. It does not need to infer the invariant or repeatedly explore the loop.\r\n\r\nWe have built a preliminary end-to-end prototype that generates and checks certificates for a subset of eBPF programs, including examples with control flow, loops, scalar relationships, and memory-safety obligations. Our early experiments indicate that certificate checking can perform particularly well on larger programs for which abstract interpretation requires extensive path exploration, state merging, or repeated loop analysis. In these cases, the checker benefits from being given the required invariants directly and can avoid much of the search performed by the existing verifier. These results are still preliminary and currently apply only to the supported subset. At LPC, we will present the supported feature set, representative examples, and an initial comparison of verification behavior and runtime, together with the cases where the approach does not yet apply.\r\n\r\nA central design problem is defining the safety policy shared by the proof generator and checker. This policy must cover instructions, helper calls, kfuncs, program contexts, pointer accesses, and kernel-managed resources, while evolving with eBPF and its kernel interfaces. Its format, maintenance model, and relationship to existing verifier semantics are part of the research question.\r\n\r\nThe talk will present the architecture, certificate language, prototype, and initial results. We will also discuss certificate size, malformed or adversarial certificates, unsupported features, policy evolution, verifier transformations, and the relationship between checked bytecode and JIT semantics.\r\n\r\nWe seek feedback from the eBPF community on whether this is a useful and technically plausible way to structure safety checking, which parts of current verifier semantics are hardest to express as explicit proof obligations, and whether a maintainable shared safety policy is possible.\r\n\r\n## Relation to Prior Work\r\n\r\nProof-carrying verification for eBPF was previously explored by Exoverifier, which separates proof generation from proof checking and emits general proof objects based on a Lean formalization of eBPF semantics. More recently, VEP proposed an annotation-guided toolchain with userspace verification, a specialized compiler, and a lightweight bytecode-level proof checker. BCF takes a hybrid approach: it retains the kernel verifier’s abstract interpretation, while using machine-checkable proofs generated in userspace to guide abstraction refinement and improve precision.\r\n\r\nOur work explores another point in this design space. Rather than relying on general theorem-prover objects, source annotations, or refinement of the existing verifier analysis, we are designing a restricted certificate language around eBPF-specific invariants and state transitions. The checker accepts only a fixed set of reasoning steps, with explicit limits on certificate structure and checking work. Our preliminary prototype suggests that this model is sufficient for a useful subset of programs while remaining closely aligned with current eBPF concepts. The talk will compare these approaches and discuss which parts of eBPF verification fit restricted certificate checking and which may require richer reasoning.\n\n**Attachments:**\n- [HiveGuard LPC.pdf](https://lpc.events/event/20/contributions/2440/attachments/2081/4645/HiveGuard%20LPC.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2440/)", "url": "https://lpc.events/event/20/contributions/2440/", "persons": [{"public_name": "Martin Fink"}]}, {"guid": "lpc20-c3593", "id": "lpc20-c3593", "title": "kops and rejit: Safely Optimizing eBPF for Hardware and Workloads", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "eBPF users pay for verified safety with performance. Across 27 microbenchmarks extracted from production programs, code that reaches native speed when compiled directly is up to 2x slower through the eBPF pipeline. The gap is structural and cannot be closed by LLVM optimization passes or source code rewrites: every deployment runs on specific hardware under a specific workload, yet the pipeline is a single-pass JIT deliberately kept simple to keep a minimal trusted computing base (TCB), without many optimizations. For example, a 64-bit rotate costs 15 machine instructions in the eBPF JIT instead of one ROL. Hardware features and registers, and workload facts such as stable input patterns, map contents, and biased branches remain under-explored. Improving the JIT in place needs upstream acceptance, enlarges the TCB that years of formal-methods work have hardened, and grows per-architecture kernel code.\r\n\r\nThe talk covers two pieces that try to approach this problem with minimal additions to the kernel TCB. BpfReJIT is a userspace library built on LLVM: an in-process shim intercepts an unmodified application's load and attach calls, rewrites the bytecode based on configs, workloads, and the kernel version, and resubmits every candidate through the original verifier and JIT. It can perform runtime speculative optimization similar to V8 or the JVM, but separates correctness (ensured in userspace) from safety (ensured in the kernel). Kops is the part that needs a kernel patch and discussion. A small one-time patch adds an interface through which kernel modules can register new hardware-specific operations without further core changes. Each operation carries a proof sequence of vanilla eBPF instructions that the verifier checks on every load, plus a native emit that the JIT compiles. We can further leverage Lean 4 proofs to establish that the two compute the same result, so the emit is the only per-operation addition to the TCB. Seven hardware-idiom operations yield speedups of up to 24% on x86-64 and 22% on ARM64, and add up to 12% datapath throughput on Cilium and Katran. We would like feedback on the interface design, on where module-supplied emits sit in the kernel's trust story, and on when to apply an operation at all, since naively applying every matched site can regress.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2445/)", "url": "https://lpc.events/event/20/contributions/2445/", "persons": [{"public_name": "YUSHENG ZHENG"}, {"public_name": "Hao Sun"}]}, {"guid": "lpc20-c3607", "id": "lpc20-c3607", "title": "BPF, sysctls and programmable kernel decision points", "date": "2026-10-05T17:30:00+02:00", "start": "17:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Traditionally the kernel community have introduced new sysctl tunables in places in the code where there is no \"one-size-fits-all\" answer. With BPF we have the opportunity to make such decision points programmable. A simple example of this is the kernel socket acceptq length, set via a combination of the listen() backlog and somaxconn sysctl.  While the traditional advice has been to set this to a very high value to allow for connection bursts, doing so can lead to unacceptable connection latencies for applications, particularly when the application is doing CPU-intensive processing that limits connection acceptance rate.  We only drop SYNs when the acceptq is full, but in such cases it would be beneficial to drop earlier to allow the service to recover. Having a BPF program attached could detect such conditions and handle this case by dropping SYNs. Having a dynamic response - potentially informed by wider system state - would be helpful here and in other cases. Wider discussion of decision points like these for BPF programmability is explored.\n\n**Attachments:**\n- [lpc2026-decision-points.pdf](https://lpc.events/event/20/contributions/2407/attachments/2104/4670/lpc2026-decision-points.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2407/)", "url": "https://lpc.events/event/20/contributions/2407/", "persons": [{"public_name": "Alan Maguire"}]}, {"guid": "lpc20-c3592", "id": "lpc20-c3592", "title": "eBPF Security:  The  Uneven Landscape", "date": "2026-10-05T18:00:00+02:00", "start": "18:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Although eBPF is widely used to extend the Linux kernel, running programs in kernel space introduces critical security risks. Existing technical work often overlooks eBPF's entire security lifecycle. This talk aims to address this gap by systematically analyzing eBPF vulnerabilities, mitigations, and architectural limits. By reviewing research papers and CVEs, we will map real-world exploits to specific components, revealing that current defenses target isolated attacks rather than systemic architectural risks. Finally, we will present key takeaways, outline open directions toward lifecycle-aware, composition-safe security models, and highlight understudied non-verifier components.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2444/)", "url": "https://lpc.events/event/20/contributions/2444/", "persons": [{"public_name": "Gürkan Gür"}, {"public_name": "Louie Wolf"}]}], "South Hall 1 B (Floor 1)": [{"guid": "lpc20-c3568", "id": "lpc20-c3568", "title": "Security Features status update", "date": "2026-10-05T10:00:00+02:00", "start": "10:00", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Another year of work is behind us, with lots of progress across GCC, Clang, and Rust to provide the Linux kernel with a variety of security features. Let's review and discuss where we are with parity between toolchains, approaches to solving open problems, and exploring new features.\r\n\r\nParity reached since last year:\r\n- Various little behavioral corner-case bug fixes\r\n\r\nIn progress:\r\n- Overflow Behavior Types (needed in GCC)\r\n- forward-edge CFI (GCC KCFI at v14)\r\n- coverage-sanitizer stack-depth tracking (needed in GCC)\r\n\r\nStalled / needs attention:\r\n- -fbounds-safety language extension (slow in Clang)\r\n- __strong typedef (needs design finalized)\r\n- Link Time Optimization for GCC kernel support\r\n- backward-edge CFI (x86 CET shadow stack, kernel mode)\n\n**Attachments:**\n- [LPC26 - Security features status update.pdf](https://lpc.events/event/20/contributions/2393/attachments/2115/4687/LPC26%20-%20Security%20features%20status%20update.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2393/)", "url": "https://lpc.events/event/20/contributions/2393/", "persons": [{"public_name": "Kees Cook"}, {"public_name": "Justin Stitt"}]}, {"guid": "lpc20-c3569", "id": "lpc20-c3569", "title": "Compiler-Based Context Analysis for Compile-Time Lock Safety", "date": "2026-10-05T10:30:00+02:00", "start": "10:30", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Compiler-Based Context Analysis is a language extension which enables statically checking that required contexts are active (or inactive) by acquiring and releasing user-definable “context locks”. An obvious application of this feature is lock-safety checking for the kernel's various synchronization primitives, verifying at compile time that locking rules are not violated. This session will begin with a brief overview of this new infrastructure that relies on Clang's Thread Safety Analysis (-Wthread-safety), but the focus will be on how developers can use it to annotate locking requirements to catch concurrency bugs before they ever make it into a kernel binary.\r\n\r\nCurrently, the analysis is opt-in by default and requires declaring which modules and subsystems should be analyzed, as enabling it tree-wide currently results in numerous false positive warnings. In the remainder of the talk, we will discuss strategies and best practices on broadening Context Analysis coverage across the entire kernel tree.\r\n\r\nReference: https://docs.kernel.org/dev-tools/context-analysis.html\n\n**Attachments:**\n- [ctx-analysis-slides.pdf](https://lpc.events/event/20/contributions/2391/attachments/2020/4554/ctx-analysis-slides.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2391/)", "url": "https://lpc.events/event/20/contributions/2391/", "persons": [{"public_name": "Marco Elver"}]}, {"guid": "lpc20-c3576", "id": "lpc20-c3576", "title": "BPF support in the GNU Toolchain", "date": "2026-10-05T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "In this activity we will first provide a very brief update on the status of the port of GNU binutils and GCC to the BPF target, with emphasis on the level of support for extant BPF programs and the kernel BPF selftests. Then we will address a set of particular issues for which we need feedback and/or consensus from the BPF kernel and clang/LLVM hackers.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2394/)", "url": "https://lpc.events/event/20/contributions/2394/", "persons": [{"public_name": "Cupertino Miranda"}, {"public_name": "David Faust"}, {"public_name": "Jose E. Marchesi"}, {"public_name": "Vineet Gupta"}]}, {"guid": "lpc20-c3573", "id": "lpc20-c3573", "title": "Are your types the same as mine?", "date": "2026-10-05T12:00:00+02:00", "start": "12:00", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "This session is aimed at discussing the benefits (and requirements) of having a unified type representation that can be used in tracing tools to facilitate type management, type compatibility checks, etc.  With type info from the kernel, type info from userspace, and types that may be defined in tracing scripts, the hoops that one may need to jump through to make it all work as a single environment where cross-stack tracing can be done are a bit excessive.\r\n\r\nLet's discuss ongoing efforts to work on this, and look at the needs, wants, etc to help drive this in the right direction where a single type management system can satisfy all requirements, and avoid duplication of effort, and painful conversions between systems.\n\n**Attachments:**\n- [Types-LPC-2026.pdf](https://lpc.events/event/20/contributions/2399/attachments/2110/4680/Types-LPC-2026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2399/)", "url": "https://lpc.events/event/20/contributions/2399/", "persons": [{"public_name": "Kris Van Hees"}]}, {"guid": "lpc20-c3572", "id": "lpc20-c3572", "title": "Towards real-time ABI compatibility assurance and smarter module versioning with libctf", "date": "2026-10-05T12:30:00+02:00", "start": "12:30", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The CTFv4 extension of the CTF file format into a superset of BTF is nearly complete.  Once it's working, what can we do with systemwide type information for all C programs and the kernel?\r\n\r\nOne possibility we explore in this talk is to use some simple linker extensions to provide real-time, linear-time ABI checking in ld.so to determine for every running program whether any of the C libraries it uses has changed incompatibly since the program was linked in a way that breaks the program, without linking ld.so with libctf or requiring it to do anything more difficult than a few equality comparisons and strcmps.\r\n\r\nThe end goal in userspace is to be able to see something like this\r\n\r\n\r\n    # emacs\r\n    warning: libxml.so.2.13.9: incompatible symbol: linked against\r\n      xmlDocPtr xmlReadMemory (const char *, int, const char *, const char *, int)\r\n    but running against\r\n      xmlDocPtr xmlReadMemory (const char *, int, const char *, const char *)\r\n\r\n(a contrived example: xmlReadMemory has not actually broken ABI. ld.so invokes a helper program that uses libctf to print that output, but does not itself need to use libctf.)\r\n\r\nIt also seems likely to me that the same infrastructure that implements the above can be reused to implement a better modversions without the manifold pain points of the current implementation.\r\n\r\nThis is only partly written so far: we explore the design of this scheme in part so that the audience can spot any serious errors before it causes widespread breakage, and to see if people can suggest improvements to the general design. (I'm certain that modversions will add exciting extra wrinkles to this.)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2395/)", "url": "https://lpc.events/event/20/contributions/2395/", "persons": [{"public_name": "Nick Alcock"}]}, {"guid": "lpc20-c3571", "id": "lpc20-c3571", "title": "Adding C library wrappers for all Linux syscalls - The Return", "date": "2026-10-05T13:00:00+02:00", "start": "13:00", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "At Linux Plumbers Conference 2025 in Tokyo I gave part 1 of this talk, this year I want to revisit progress made against the use cases presented last year including progress made on raw futex.\r\n\r\nIn review we'll look at more applications and if we we are able to solve their most thorny calls to syscall with actual libc wrappers.\r\n\r\nI'll include a more formal review of what is currently missing in glibc, collecting the list of syscalls for x86_64 and comparing to the kernel.\r\n\r\nI will close again with a call to action for always having syscalls available as C library calls even if they could be used behind the back of the implementation.\r\n\r\nI will propose a formal mentoring program. If you want to get a syscall wrapper into glibc I'll work with you to make it happen.\n\n**Attachments:**\n- [Adding C library wrappers for all syscalls Part 2 - Linux Plumbers Conference 2026.pdf](https://lpc.events/event/20/contributions/2397/attachments/2113/4685/Adding%20C%20library%20wrappers%20for%20all%20syscalls%20Part%202%20-%20Linux%20Plumbers%20Conference%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2397/)", "url": "https://lpc.events/event/20/contributions/2397/", "persons": [{"public_name": "Carlos O'Donell"}, {"public_name": "Florian Weimer"}]}, {"guid": "lpc20-c3574", "id": "lpc20-c3574", "title": "Advancing PGO, AutoFDO, and Propeller in the Linux Kernel", "date": "2026-10-05T15:00:00+02:00", "start": "15:00", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "AutoFDO and Propeller are upstream and PGO is available out of tree, but none of them supports kernel modules, which run 4–5% of kernel cycles on Google's servers and carry performance-sensitive vendor drivers on Android. Part 1 presents per-module profiles for all three behind one Kbuild interface, and a path to upstream PGO by reusing compiler-rt's profile code. Part 2 shows why function-level coverage misleads once functions are split, and introduces line-level attribution and Cycles per Byte (CPB) to measure how well a kernel's hot code is laid out.\n\n**Attachments:**\n- [Advancing PGO, AutoFDO, and Propeller in the Linux Kernel](https://lpc.events/event/20/contributions/2396/attachments/2087/4651/go)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2396/)", "url": "https://lpc.events/event/20/contributions/2396/", "persons": [{"public_name": "Rong Xu"}]}, {"guid": "lpc20-c3570", "id": "lpc20-c3570", "title": "Upgrading Runtime Leaks to Compile-Time Errors: Adopting Clang’s require_explicit_initialization", "date": "2026-10-05T15:30:00+02:00", "start": "15:30", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The Linux kernel makes heavy use of aggregate struct initializers to configure subsystem interfaces, driver registries, and object lifecycles (such as struct kobj_type and struct device_type). However, omitting mandatory struct members—such as a kobject's release callback—may result in silent memory leaks or deferred runtime panics.\r\n\r\nClang offers a static alternative attribute ‘require_explicit_initialization’, which triggers the -Wuninitialized-explicit-init warning if a designated field is left uninitialized during aggregate construction . This talk is proposed as a collaborative discussion to brainstorm how we can adopt this safety mechanism in kernel headers (e.g., via a macro like __required_init) . We will discuss the candidate structures that would benefit most, evaluate the engineering friction of enforcing this across cross-tree refactors, and address compiler parity issues—specifically how to handle GCC fallback and whether a similar diagnostic can be proposed for GCC.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2392/)", "url": "https://lpc.events/event/20/contributions/2392/", "persons": [{"public_name": "Ian Rogers"}]}, {"guid": "lpc20-c3577", "id": "lpc20-c3577", "title": "Kage: device driver isolation in the Linux kernel with LFI", "date": "2026-10-05T16:00:00+02:00", "start": "16:00", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Drivers in Linux run with full kernel privileges and account for a significant share of exploitable vulnerabilities. Kage is an experimental kernel subsystem that runs kernel modules inside of in-kernel sandboxes using LLVM's Lightweight Fault Isolation (LFI) feature. Kaged drivers still run in the same hardware privilege level and address space as the rest of the kernel, but are compiled such that control-flow and memory accesses are confined to a subset of virtual memory. This keeps transition costs cheap and reduces the engineering effort needed to retrofit isolation onto existing drivers. LFI is designed to provide secure isolation even for arbitrarily malicious code through the use of a machine code verifier that keeps the compiler out of the trusted code base.\r\n\r\nThis talk will walk through a prototype version of Kage, which can load LFI-built kernel modules into an isolated portion of the address space, and demonstrate how drivers can be ported to run in sandboxes. Kage uses BTF type information to automatically check call signatures and replace kernel pointers with opaque handles on calls between the kernel and the module. The current prototype can sandbox simple computational kernel modules, and is expected to grow in capabilities in order to handle MMIO, buffer sharing, DMA (via the IOMMU), and interrupt routing, with the end goal of being able to isolate real, complex drivers, such as USB, network, or possibly even GPU drivers.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2398/)", "url": "https://lpc.events/event/20/contributions/2398/", "persons": [{"public_name": "Zachary Yedidia"}]}, {"guid": "lpc20-c3579", "id": "lpc20-c3579", "title": "GCC Rust support for Linux", "date": "2026-10-05T17:00:00+02:00", "start": "17:00", "duration": "00:30", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "A conversation about the Linux kernel requirements from GCC Rust and how to promote GCC Rust as another compiler for the Rust components of the Linux kernel.  The technical and community issue.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2449/)", "url": "https://lpc.events/event/20/contributions/2449/", "persons": [{"public_name": "David Edelsohn"}, {"public_name": "Philip Herron"}]}, {"guid": "lpc20-c3578", "id": "lpc20-c3578", "title": "Crossing borders between user space and kernel space: GDB/Valgrind/drgn close cooperation", "date": "2026-10-05T17:30:00+02:00", "start": "17:30", "duration": "00:15", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "While is GDB is primarily a  user space tool, drgn is a kernel space one. Using them together may improve user experience as drgn can help GDB to get access to various kernel structures. Right now, GDB can show what a thread is doing in user space, drgn can show what it is doing in the kernel — but the two tools do not talk to each other. I would like to discuss what it would mean to cross that border.\r\n\r\nThe crossing is technically straightforward: drgn is a Python library, and GDB already has a Python API, making it natural to call drgn from GDB scripts. As a concrete demonstration, I wrote a small GDB Python command, drgn_why_sleeping, which retrieves the kernel stack of a sleeping thread via drgn and displays it alongside GDB's user-space backtrace — showing the full kernel path where bt alone shows only a generic syscall frame.\r\n\r\nThis raises further questions: could drgn's per-frame register and local variable access allow GDB users to inspect kernel frames interactively? Is a remote variant worth pursuing for kgdb setups? Could drgn help trace where in the kernel an error originates when stepping over a failing syscall? Valgrind could also benefit — since drgn does not use ptrace, it could attach to a Valgrind-instrumented process  simultaneously and resolve invalid memory addresses to named kernel structures. And in the other direction: could user-space tools like GDB or Valgrind offer anything useful back to drgn?\n\n**Attachments:**\n- [crossing_borders.pdf](https://lpc.events/event/20/contributions/2448/attachments/2112/4682/crossing_borders.pdf)\n- [RFC drgn-why-sleeping command](https://lpc.events/event/20/contributions/2448/attachments/2112/4683/go)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2448/)", "url": "https://lpc.events/event/20/contributions/2448/", "persons": [{"public_name": "Alexandra Petlanova Hajkova"}]}, {"guid": "lpc20-c3575", "id": "lpc20-c3575", "title": "Beyond Coverage: Per-Task Function Boundary Extraction for Kernel Contract Verification", "date": "2026-10-05T17:45:00+02:00", "start": "17:45", "duration": "00:15", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Toolchains Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "KCOV's trace-pc provides edge coverage feedback for kernel fuzzers, but captures no data-flow context. Two syscalls hitting identical basic blocks with different argument values (e.g., vfs_open with O_RDONLY vs O_WRONLY|O_TRUNC) are indistinguishable to the fuzzer. This \"semantic gap\" causes coverage saturation on value-dependent state transitions in complex subsystems (binder, io_uring, ksmbd).\r\n\r\nftrace function graph tracer support arg/ret values tracing during runtime. But their is a couple of challenge(FTRACE_REGS_MAX_ARGS 6) regarding architecture calling convention from register, and currently can't support structure and their members on the function.\r\n\r\nOn the other hands, Rust For Linux kernel modules can't supported by current tracing framework.\r\n\r\nWe need consensus on extending LLVM's SanitizerCoverage to capture function arguments and return values, including automatic struct field decomposition from DWARF metadata, with a kernel-resident per-task ring buffer.\r\n\r\n# What I Implemented\r\n\r\nTwo new SanitizerCoverage modes in LLVM:\r\n\r\n## Emits LLVM RFC submitted\r\n1. `__sanitizer_cov_trace_args(arg_idx, arg_size, val, offsets, num_fields)` at function entry for each parameter.\r\n\r\n2. `__sanitizer_cov_trace_ret(ret_size, val, offsets, num_fields)` before each return.\r\n\r\nThe pass uses DICompositeType metadata to extract struct field offsets/sizes at compile time and emits them as global constant arrays. At runtime, the kernel backend reads fields via `copy_from_kernel_nofault()` into a per-task lock-free mmap'd buffer at `/sys/kernel/debug/kcov_dataflow`.\r\n\r\nA native rustc path (rustc built against the custom LLVM) enables Rust kernel module instrumentation without a post-compilation pipeline. The only known method for capturing Rust function arguments at runtime given -O2 DWARF elision.\r\n\r\n# Discussion Topics Needing Agreement\r\n\r\n1. **Callback ABI stability**\r\nShould `__sanitizer_cov_trace_args/ret` be considered stable SanitizerCoverage API, or experimental? What's the path from `-fsanitize-coverage=trace-args` to an accepted upstream flag?\r\n\r\n2. **DWARF metadata dependency**\r\nThe pass requires `-g` for struct expansion. Currently it gracefully degrades: without `-g`, `F.getSubprogram()` returns null and the function is silently skipped. With `-g` but missing type info for a param, it records as scalar (offsets=NULL, num_fields=0). Should this behavior be documented as the contract?\r\n\r\n3. **Interaction with optimizations**\r\nAt -O2, scalar arguments are spilled to `alloca` so the kernel callback receives a uniform pointer. Should the pass mark these as side-effecting to prevent DSE, or accept the current behavior (compiler preserves them because the call itself is a side effect)?\r\n\r\n4. **Rust integration path**\r\nCurrently requires building rustc against the custom LLVM (native path) or using a wrapper (rustc emit-llvm-ir then opt). Is there appetite for native `-Zsanitizer-coverage=trace-args` support in upstream rustc? The kernel's Kbuild does not expose intermediate IR for external instrumentation, making the native path mandatory for Rust kernel modules.\r\n\r\n5. **Kernel-side callback design**\r\nThe kernel backend uses `copy_from_kernel_nofault()` for safe pointer reads and a bit-31 recursion guard (needed because `copy_from_kernel_nofault` itself is instrumented under INSTRUMENT_ALL). Should the LLVM pass remain fully target-agnostic, or emit hints for the runtime?\r\n\r\n6. **Scope control**\r\nPer-module opt-in (`KCOV_DATAFLOW_file.o := y`) vs. global (`CONFIG_KCOV_DATAFLOW_INSTRUMENT_ALL`). The pass currently instruments all functions with DISubprogram. Should it support function-level filtering via attributes (e.g., `__attribute__((no_sanitize(\"dataflow\")))`)?\r\n\r\n7. **Performance implications**\r\nWith INSTRUMENT_ALL: +9.5% .text, +133% syscall latency. Per-module: +8.3% on instrumented paths. The per-callback cost is ~27ns dominated by `copy_from_kernel_nofault`. Is this acceptable for the SanitizerCoverage framework, or should it be a separate pass?\r\n\r\n# Why Rust Kernel Modules Need This\r\n\r\nExisting observability tools completely fail on Rust kernel code:\r\n\r\n- **ftrace**: Cannot hook Rust functions (no `__fentry__` prologue — rustc doesn't emit `-mfentry`)\r\n- **kprobes/fprobe**: Rust symbol mangling makes targeting impractical; even with correct names, only captures raw register values (no struct expansion)\r\n- **drgn/vmcore**: `rustc -O2` elides `DW_AT_location` for all parameters — `frame.locals()` returns `{}`\r\n- **eBPF**: Requires manual struct layout specification; Rust `#[repr(Rust)]` types have no stable ABI\r\n\r\nOur LLVM pass operates on Rust-generated IR *before* codegen — the only point where both debug metadata and argument values coexist.\r\n\r\nVerified: Rust eight_struct_args_rust selftest produces correct output at -O2 on CI result: https://github.com/yskzalloc/kcov-dataflow/actions/runs/29659128011/job/88119068007\r\n```\r\ndo_el0_svc({0x4, 0x4, 0xffffffff, 0x0, 0x0, 0x0})\r\n0x0 = B...\r\nsb_start_write()\r\nfile_start_write()\r\n0x0 = _RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler() [eight_struct_args_rust]\r\n  0x11 = rsf_1(0x11) [eight_struct_args_rust]\r\n  0x33 = rsf_2(0x11, {0x11, 0x22}) [eight_struct_args_rust]\r\n  ...\r\n  0x30c = rnsf_8({0xa8, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11}) [eight_struct_args_rust]\r\n    0xaa = rsf_fwd_inner(0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44}) [eight_struct_args_rust]\r\n  0xaa = rsf_fwd(0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44}) [eight_struct_args_rust]\r\n  rsf_ret_struct(0x0, {0x11, 0x11}, 0x11) [eight_struct_args_rust]\r\n  0xfffffdffc0356e80 = rust_helper_krealloc_node_align(0x0, 0x8, 0x8, 0xcc0, 0xffffffff)\r\n  0x6f00000009 = rust_helper_krealloc_node_align(0x0, 0x10, 0x8, 0xcc0, 0xffffffff)\r\n  0xf200006e00000011 = rust_helper_krealloc_node_align(0x0, 0x18, 0x8, 0xcc0, 0xffffffff)\r\n  0x2500006e00000011 = rust_helper_krealloc_node_align(0x0, 0x20, 0x8, 0xcc0, 0xffffffff)\r\n  0xaa = rsf_heap(0x11, {0x11, 0x22}, {0x11, 0x22, 0x33}, {0x11, 0x22, 0x33, 0x44}) [eight_struct_args_rust]\r\n  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)\r\n  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)\r\n  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)\r\n  0x0 = rust_helper_krealloc_node_align(0x11, 0x0, 0x1, 0x0, 0xffffffff)\r\n0x1 = _RNvCsdfZGIOKgjaD_22eight_struct_args_rust13write_handler(0xffffa64d1231, 0x1, 0x0) [eight_struct_args_rust]\r\n...\r\n```\r\n\r\n# Implementation vs. ftrace funcgraph-args\r\n\r\nftrace's funcgraph-args (available since 6.x) captures 6 raw register values but:\r\n- Requires `-mfentry` (no Rust support)\r\n- No struct field expansion (just pointer addresses)\r\n- Shared per-CPU ring buffer with preempt_disable per event\r\n- Under load: events silently overwritten/dropped\r\n- Stack-passed args (> 6) not captured\r\n\r\nkcov-dataflow:\r\n- Per-task private mmap buffer (no contention, no preempt_disable)\r\n- Automatic struct field expansion from DWARF\r\n- All args including stack-passed (alloca'd at compile time)\r\n- Works on both C and Rust identically\r\n- Zero-copy consumer via mmap\r\n\r\n# Current Status\r\n\r\n- Repository (kernel + LLVM + rustc + selftests + CI):\r\n  https://github.com/yskzalloc/kcov-dataflow\r\n- CI (x86_64 + arm64, 6 selftests):\r\n  https://github.com/yskzalloc/kcov-dataflow/actions\r\n- Tested on linux-next 7.2.0-rc3 with custom clang/LLVM 23 and rustc 1.99-nightly\r\n- All selftests pass on both x86_64 (KVM) and arm64 (native) Github CI\r\n\r\n# Why This Needs Face-to-Face Discussion\r\n\r\n- This work crosses 3 communities (LLVM, kernel, Rust-for-Linux) that rarely meet simultaneously.\r\n- The callback ABI, optimization interaction, and Rust pipeline decisions require input from all 3.\r\n- LPC Toolchains Track is the only venue where clang/LLVM developers, kernel maintainers, and Rust-for-Linux contributors are in the same room.\r\n\r\n# References\r\n\r\n- LLVM RFC: https://discourse.llvm.org/t/rfc-sanitizercoverage-add-fsanitize-coverage-trace-args-trace-ret/91026\r\n- LLVM PR: https://github.com/llvm/llvm-project/pull/201410\r\n- Kernel patch v3: https://lore.kernel.org/all/20260902-b4-kcov-dataflow-rfc-v3-v3-0-824609f279f5@est.tech/\r\n- arXiv paper: https://arxiv.org/pdf/2606.00455\r\n- LWN: https://lwn.net/Articles/1092429/\n\n**Attachments:**\n- [LPC2026_kcov-dataflow-v2.pdf](https://lpc.events/event/20/contributions/2402/attachments/1998/4644/LPC2026_kcov-dataflow-v2.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2402/)", "url": "https://lpc.events/event/20/contributions/2402/", "persons": [{"public_name": "Yunseong Kim"}]}], "South Hall 3 A (Floor 3)": [{"guid": "oss-2cd1c9d4abcf374d1919bd43911bc745", "id": "oss-2cd1c9d4abcf374d1919bd43911bc745", "title": "Observability Summit [Additional Fee; Pre-Registration Required]", "date": "2026-10-05T09:00:00+02:00", "start": "09:00", "duration": "09:00", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "Observability Summit brings together developers, operators, and business leaders who are shaping the future of open source observability. From deep-dives to hands-on workshops, every moment is curated by the community, for the community! This event will be focused on real challenges, practical solutions, and innovations driving the next era of visibility and control. This is a must attend event to help you build, scale and succeed.\nTo learn more, visit the event website.\nHow to Register: Pre-registration is required. Register for Observability Summit Europe as a stand alone event or add it to your Open Source Summit Europe registration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2cd1c9d4abcf374d1919bd43911bc745)", "url": "https://osselceu2026.sched.com/event/2cd1c9d4abcf374d1919bd43911bc745", "persons": []}], "TBA": [{"guid": "lpc20-b3820", "id": "lpc20-b3820", "title": "Evening Event", "date": "2026-10-05T19:30:00+02:00", "start": "19:30", "duration": "03:00", "room": "TBA", "track": "LPC: Social Events", "type": "LPC Social", "language": "en", "abstract": "", "description": "", "url": null, "persons": []}]}}, {"index": 2, "date": "2026-10-06", "rooms": {"Chamber Hall (Floor 3)": [{"guid": "oss-ede03d6969a3c904a25d54033b1ac95a", "id": "oss-ede03d6969a3c904a25d54033b1ac95a", "title": "Valkey Contributor Summit [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "08:00", "room": "Chamber Hall (Floor 3)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "Calling all Valkey contributors, maintainers, product leaders, and community builders! Join us for the annual Valkey Contributor Summit: a community-led forum of builders who actively shape the direction of this fast-growing open source project. Together, we’ll share ideas, discuss priorities, and plan the future of Valkey.\nTo learn more, visit the event website.\nHow to Register: Pre-registration is required. Register for Valkey Contributor Summit as a stand alone event.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ede03d6969a3c904a25d54033b1ac95a)", "url": "https://osselceu2026.sched.com/event/ede03d6969a3c904a25d54033b1ac95a", "persons": []}], "Club A (Floor 1)": [{"guid": "lpc20-c3646", "id": "lpc20-c3646", "title": "DT bindings and sources shared with U-Boot: current status and ongoing work", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Devicetree MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Since early 2024, U-Boot has been synchronizing the DTS and bindings of each Linux release into the U-Boot source tree using git subtree functionality. Since this transition, some platforms like Amlogic or Qualcomm have immediately switched, and some older platforms have been actively migrating to upstream Linux DT sources and bindings while maintaining minimal local U-Boot DTS modifications.\r\n\r\nNeil will summarize the current state of U-Boot's integration of these upstream DTS, provide an update on ongoing migrations, and outline the remaining work required to fully eliminate local U-Boot DTS modifications.\n\n**Attachments:**\n- [DeviceTree MC - DT bindings and sources shared with U-Boot_ current status and ongoing work.pdf](https://lpc.events/event/20/contributions/2388/attachments/2011/4544/DeviceTree%20MC%20-%20DT%20bindings%20and%20sources%20shared%20with%20U-Boot_%20current%20status%20and%20ongoing%20work.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2388/)", "url": "https://lpc.events/event/20/contributions/2388/", "persons": [{"public_name": "Neil Armstrong"}]}, {"guid": "lpc20-c3647", "id": "lpc20-c3647", "title": "Status of the DTS Validation in the Linux Kernel", "date": "2026-10-06T10:20:00+02:00", "start": "10:20", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Devicetree MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The great benefit of Devicetree bindings in the current DT schema format is the ability to validate the correctness of DTS (Devicetree sources) against those bindings. However, once validation was introduced, we discovered that many in-kernel DTS files simply did not pass.\r\n\r\nContinuing such summary from 2025, what is the status of dtbs_check now? Which platforms have the most warnings and which are warning-free? What improved over last year?\r\n\r\nThis is a similar talk to one in 2025 LPC showing current stage of dtbs_check.\n\n**Attachments:**\n- [Status of DTS Validation in Linux Kernel - Krzysztof Kozlowski, Qualcomm - LPC 2026.pdf](https://lpc.events/event/20/contributions/2390/attachments/2008/4540/Status%20of%20DTS%20Validation%20in%20Linux%20Kernel%20-%20Krzysztof%20Kozlowski,%20Qualcomm%20-%20LPC%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2390/)", "url": "https://lpc.events/event/20/contributions/2390/", "persons": [{"public_name": "Krzysztof Kozlowski"}]}, {"guid": "lpc20-c3651", "id": "lpc20-c3651", "title": "SDCA  and Devicetrees", "date": "2026-10-06T10:45:00+02:00", "start": "10:45", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Devicetree MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Last year's LPC discussion explored whether ACPI-defined hardware descriptions could be reused on systems booting with Devicetree, and where the boundary should exist between the two firmware ecosystems.\r\n\r\nSince then, several related efforts have continued across the kernel community, having intermediate representation for MIPI DISCO tables for SDCA, emerging ACPI-DT hybrid approaches. At the same time, new platform requirements—particularly on ARM64 laptops and embedded systems—continue to challenge the traditional \"ACPI or DT\" model.\r\n\r\nThis session will review the current state of these efforts, How should systems without ACPI tables should work with drivers like SDCA, discuss practical use cases where combining ACPI and Devicetree provides value, examine ongoing hybrid firmware work, and identify remaining technical ad architectural challenges. The goal is to gather feedback on whether the community should continue evolving hybrid solutions, standardize common mechanisms, or pursue alternative directions given that we have more data points.\r\n\r\nKey Highligths:\r\n- Ongoing efforts.\r\n- Current Status of work on SDCA.\r\n- ACPI-DT hybrid mode and future.\r\n- Systems without ACPI tables(mobile devices).\r\nHans is covering ACPI-DT Hybrid mode in detail https://lpc.events/event/20/contributions/2363/\n\n**Attachments:**\n- [SDCA and Devicetree-LPC-2026.pdf](https://lpc.events/event/20/contributions/2469/attachments/2001/4531/SDCA%20and%20Devicetree-LPC-2026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2469/)", "url": "https://lpc.events/event/20/contributions/2469/", "persons": [{"public_name": "Srini Kandagatla"}]}, {"guid": "lpc20-c3652", "id": "lpc20-c3652", "title": "Streamlining DT Bindings to Protect Upstreaming Momentum", "date": "2026-10-06T11:10:00+02:00", "start": "11:10", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Devicetree MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Corporate adoption of an \"upstream-first\" strategy is gaining traction, with companies increasingly willing to allocate engineering bandwidth to contribute hardware support directly to the Linux kernel. However, integrating these contributions smoothly remains a practical challenge. The review process frequently experiences friction during Device Tree (DT) binding discussions, which can extend timelines, consume allocated engineering bandwidth, and occasionally discourage newcomers to the open-source ecosystem.\r\n\r\nThis discussion explores ways to accelerate DT binding adoption so developers can maintain their focus on driver implementation. We will discuss current friction points and propose solutions to streamline the process. Specifically, we will evaluate the concept of \"experimental bindings\"—exploring whether provisional bindings could be used under certain circumstances to unblock driver development and maintain contributor momentum without compromising the long-term quality of hardware descriptions.\n\n**Attachments:**\n- [LPC2026-Devicetree-MC-Experimental-DT-bindings.pdf](https://lpc.events/event/20/contributions/2470/attachments/2108/4678/LPC2026-Devicetree-MC-Experimental-DT-bindings.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2470/)", "url": "https://lpc.events/event/20/contributions/2470/", "persons": [{"public_name": "Amit Kucheria"}]}, {"guid": "lpc20-c3650", "id": "lpc20-c3650", "title": "Device Tree Addons: Describe hot-pluggable extension boards", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Devicetree MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Device Tree has been extremely successful at describing non-discoverable hardware in Linux and other embedded systems. However, it remains fundamentally monolithic: each Device Tree describes a complete system, and reuse across independently developed hardware components is limited.\r\n\r\nThis becomes problematic for modular platforms where expansion boards, mezzanines, daughter cards, or hot-pluggable hardware are expected to work across multiple base boards. While Device Tree Overlays provide a mechanism to modify an existing hardware description, they require detailed knowledge of the target system. They do not offer a robust way to describe addon boards independently of the base platform nor a way to use the same addon board description to describe the same board connected on multiple connectors available on a single base board.\r\n\r\nThe recently proposed Device Tree Addon format [1] aims to address those limitations. It allows a single addon DTB to describe an extension board that can be used on different connectors of a given base board, or on different base boards, without requiring board-specific customization.\r\n\r\nThe design goal of Device Tree Addon is illustrated in slides used for a talk given at ELCE 2025 [2]. The relevant slides sections are the following:\r\n  - Use case and goals\r\n  - The connector abstraction.\r\n\r\nThe \"Connector: current status\" section available in [2] is now obsolete. The Device Tree Addon concept emerged from discussions [3] that followed the ELCE 2025 conference.\r\n\r\nThis session will briefly present Device Tree Addon concepts recently\r\nintroduced and available in the RFC implementation [1]. Beyond introducing the format, the focus will be on the remaining challenges that must be addressed before broader adoption.\r\n\r\nTopics for discussion include remaining design questions, integration with\r\nDevice Tree bindings and validation rules, standardization efforts in Devicetree Specification (DTSpec). We will also examine the work still required in dtc, libfdt, bootloaders, and the Linux kernel.\r\n\r\nThe goal of the session is to gather feedback from Device Tree maintainers,\r\nkernel developers, bootloader developers, and users of modular hardware platforms to help shape the future direction of Device Tree Addons.\r\n\r\nA Bootlin blog post about Device Tree addons (based on its current state) is available [4].\r\n\r\n[1] https://lore.kernel.org/all/20260826094950.1088288-1-herve.codina@bootlin.com/\r\n[2] https://bootlin.com/pub/conferences/2025/elce/ceresoli-hotplug-status.pdf\r\n[3] https://lore.kernel.org/all/20250902105710.00512c6d@booty/\r\n[4] https://bootlin.com/blog/device-tree-addons-describing-non-discoverable-addon-boards-and-connectors/\n\n**Attachments:**\n- [codina-device-tree-addon.pdf](https://lpc.events/event/20/contributions/2387/attachments/2016/4550/codina-device-tree-addon.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2387/)", "url": "https://lpc.events/event/20/contributions/2387/", "persons": [{"public_name": "Hervé Codina"}]}, {"guid": "lpc20-c3648", "id": "lpc20-c3648", "title": "Using DT overlays to manage a collection of related boards", "date": "2026-10-06T12:30:00+02:00", "start": "12:30", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Devicetree MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "It is commonplace that many boards in the real world have many sibling or cousin boards that are 95-99% the same as each other. Some examples:\r\n\r\n - During development, most boards go through several revisions. A board might have proto0, proto1, evt0, evt1, evt1.1, dvt1, pvt, and mp revisions. These revisions almost the same with just small changes. While only \"mp\" (mass production) devices should end up in the public's hands, old prototype devices continue to be used for many years within the companies supporting the hardware.\r\n - Many boards have several small variants that are nearly the same. As an example, the Pixel 10, Pixel 10 Pro, and Pixel 10 Pro XL are based on the same design and are nearly the same.\r\n - Many boards are based on a reference design and only make small changes from that reference design. Chromebooks are one example of this. \"sc7180-trogdor\" was a reference design and a pile of different ODMs took this design and made small changes. Outside of Chromebooks, many phones are heavily based on the reference design of the SoC vendor.\r\n\r\nProducts that are highly similar to each other usually end up sharing a single binary image that is shipped out. That single image contains all needed device trees. Firmware on the product can figure out which specific device it's running on and can pick the correct device tree.\r\n\r\nThe common practice in the upstream device tree repository today is that each of these very similar boards needs its own complete device tree. The device tree is often shared using #includes of .dtsi files, but the final result is a pile of .dtb files that are mostly the same.\r\n\r\nThere are a few problems we have today. Two of them that are perhaps the most important:\r\n\r\n 1. All of those device trees take up a lot of space. It would be nice if we didn't need a whole pile of .dtb files that are nearly the same.\r\n 2. While firmware has all the details about the exact device it's running on, there is no standard way to mark device tree files so firmware can find the right one.\r\n\r\nThe device-tree overlay concept should help with point #1 in reducing the amount of space things take up. Trying to get agreement about how this should look has been difficult, though. One question that came up is if a \"base\" device tree was required to be a board or not. For supporting Pixel 10 hardware, it was most convenient for the base device tree to represent the SoC itself since some Pixel 10 devices had a different revision of the SoC. A second question that came up is how to deal with the top-level device-tree \"compatible\" in this case. It was unclear if we needed some way to \"merge\" the compatible based on all the overlays included which then led into questions about what needed to be in this top-level \"compatible\" to begin with.\r\n\r\nTrying to solve point #2 has come up again and again, but somehow we never end up with any resolution. The typical refrain is that we need a grand unified design that all device-tree loaders will agree to use, but this always fails to materialize.\r\n\r\nBoth problems have downstream solutions. As an example, Pixel phones ship with devicetree overlays to avoid some of the duplication. Device trees and their overlays on Pixel phones have special properties in them that are used to help firmware pick the right one at boot time. Trying to upstream these solutions has met with difficulty though.\r\n\r\nLet's have a discussion where we look at prior attempts and see if we can make some more forward progress.\r\n\r\nSome threads I've been involved in (this is by no means a complete list of threads about the topic):\r\n\r\n - [[PATCH 1/4] dt-bindings: arm: google: Add bindings for frankel/blazer/mustang](https://lore.kernel.org/r/20251111112158.1.I72a0b72562b85d02fee424fed939fea9049ddda9@changeid)\r\n - [[PATCH 4/4] arm64: dts: google: Add initial dts for frankel, blazer, and mustang](https://lore.kernel.org/r/20251111112158.4.I5032910018cdd7d6be7aea78870d04c0dc381d6e@changeid)\r\n - [Proposal: Officially allow \"incomplete\" trees as a base](https://lore.kernel.org/all/CAD=FV=Ux7nGFnYEyX0cUL-9__BKnTYc+kAJjkF458ZnFS7zoJA@mail.gmail.com/)\r\n - [Proposal: document where SoC info belongs](https://lore.kernel.org/r/CAD=FV=W+jE_L_LLgAhD8K_4+CtivSD9-9t7Xe63XuKrKjfyfeQ@mail.gmail.com/)\n\n**Attachments:**\n- [DT Overlays Plumbers Talk 2026.pdf](https://lpc.events/event/20/contributions/2389/attachments/2012/4545/DT%20Overlays%20Plumbers%20Talk%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2389/)", "url": "https://lpc.events/event/20/contributions/2389/", "persons": [{"public_name": "Doug Anderson"}]}, {"guid": "lpc20-c3649", "id": "lpc20-c3649", "title": "OS managed Devicetree overlays through UKI add-ons", "date": "2026-10-06T13:00:00+02:00", "start": "13:00", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Devicetree MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "SBCs like the Arduino UNO Q can have a number of extension boards, like the UNO Media Carrier or an Arduino shield connected. On top of this extra hardware may be connected through e.g. CSI camera connectors and DSI display connectors.\r\n\r\nEach of these possible hardware addons needs a DT overlay to work. This requires some method for the user to select which DT overlays to use.\r\n\r\nThere have been several attempts a decade ago to allow loading DT overlays from Linux userspace for this, but non has ever been accepted upstream.\r\n\r\nUKI addons can provide an updated DTB, the purpose of this session is to present and discuss a proposal to use this to manage DT overlays from userspace through UKI addons:\r\n\r\nPhase 1: UKI addons with a replacement DTB file embedded\r\n--------------------------------------------------------\r\n\r\n- For systems booting with secureboot, create DTBs with overlays merged in for popular hardware addon combinations and build a signed UKI addon for each such DTB on the distros build-system.\r\n   \r\n- For systems without secureboot any overlay combination can be supported by building a merged DTB locally and creating an UKI addon from that DTB.\r\n\r\nPhase 2: UKI addons with a DTBO file embedded\r\n---------------------------------------------\r\n\r\n- For this phase the UKI stub needs to be extended with the capability to merge DTBOs from addons into an earlier loaded DTB, allowing any combination of overlays by the distro providing a signed UKI addon for each available overlay.\n\n**Attachments:**\n- [os-managed-dtb-overlays-uki-addon.pdf](https://lpc.events/event/20/contributions/2471/attachments/1999/4527/os-managed-dtb-overlays-uki-addon.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2471/)", "url": "https://lpc.events/event/20/contributions/2471/", "persons": [{"public_name": "Hans de Goede"}, {"public_name": "Agathe Porte"}]}, {"guid": "lpc20-c3653", "id": "lpc20-c3653", "title": "Thermal Framework Corner Cases: Bugs or Undefined Behavior?", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Linux thermal framework has proven to be flexible and robust over the years. However, some aspects of its event handling have become increasingly difficult to reason about, resulting in inconsistent behaviors and corner cases.\r\n\r\nExamples include trip point updates while the temperature has already fallen within the hysteresis range after the notification was generated, inconsistent handling of thermal zones across system suspend and resume, and other situations where the expected behavior is not clearly defined or documented.\r\n\r\nSome of these issues have been reported over the years, while others have surfaced as new users and platforms have adopted the framework. Addressing them individually without a common understanding of the expected semantics risks introducing further inconsistencies.\r\n\r\nThe goal of this discussion is to identify the current limitations of the thermal framework, establish which behaviors are considered bugs versus intentional design choices, prioritize the issues that should be addressed, and agree on a roadmap for improving the framework while preserving compatibility with existing users.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2535/)", "url": "https://lpc.events/event/20/contributions/2535/", "persons": [{"public_name": "Daniel Lezcano"}]}, {"guid": "lpc20-c3654", "id": "lpc20-c3654", "title": "Power Cooling Devices: Bridging Thermal and Powercap", "date": "2026-10-06T15:20:00+02:00", "start": "15:20", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Linux thermal management and power capping frameworks currently evolve independently, despite relying on the same Energy Model (EM) to describe the power-performance characteristics of devices.\r\n\r\nThe thermal framework regulates temperature by estimating a sustainable power budget using the power_allocator governor. A PID control loop computes the power reduction required to maintain a target temperature, and the Energy Model translates this budget into Operating Performance Point (OPP) constraints applied through thermal cooling devices.\r\n\r\nThe powercap framework, and in particular the Dynamic Thermal Power Management (DTPM) controller, also relies on the Energy Model to enforce power budgets. However, instead of manipulating OPPs directly, it distributes power limits across a hierarchy of power domains.\r\n\r\nAlthough both frameworks address closely related problems and use the same underlying model, there is currently no mechanism to connect them. This raises the question of whether a common abstraction could allow the thermal framework to express power constraints through the powercap hierarchy rather than through device-specific OPP constraints.\r\n\r\nOne possible direction is the introduction of a power cooling device, acting as a bridge between the thermal and powercap frameworks. Such an abstraction could enable thermal governors to allocate power budgets to powercap domains while leaving power distribution and enforcement to the powercap subsystem. This approach may also open the door to hierarchical power budgeting and more coordinated thermal management across heterogeneous devices.\r\n\r\nThe goal of this discussion is to explore whether this direction makes sense from an architectural perspective, identify the challenges involved, and agree on a set of incremental milestones that would allow such an integration to be developed and upstreamed progressively.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2539/)", "url": "https://lpc.events/event/20/contributions/2539/", "persons": [{"public_name": "Daniel Lezcano"}]}, {"guid": "lpc20-c3655", "id": "lpc20-c3655", "title": "Introducing Hardware Thermal Governor", "date": "2026-10-06T15:40:00+02:00", "start": "15:40", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Modern System-on-Chip designs increasingly incorporate built-in hardware thermal controllers to manage thermal conditions efficiently. Intel platforms, beginning with the Lunar Lake generation, feature integrated platform temperature controllers capable of autonomous thermal management. However, not all platform designs directly interface temperature readings and thermal thresholds with these hardware governors, limiting their effectiveness.\r\n\r\nThis presentation introduces a kernel-level approach that leverages existing thermal zone infrastructure to provide temperature data and threshold information directly through a new hardware thermal governor, bypassing user space interactions. \r\n\r\nA proof-of-concept implementation will be demonstrated, showcasing the integration of thermal zones with hardware-based thermal control mechanisms.\n\n**Attachments:**\n- [LPC2026_thermal_hw_gov.pptx](https://lpc.events/event/20/contributions/2536/attachments/2017/4551/LPC2026_thermal_hw_gov.pptx)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2536/)", "url": "https://lpc.events/event/20/contributions/2536/", "persons": [{"public_name": "Srinivas Pandruvada"}]}, {"guid": "lpc20-c3656", "id": "lpc20-c3656", "title": "Devfreq for uncore DVFS", "date": "2026-10-06T16:00:00+02:00", "start": "16:00", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "SoC uncore components, such as interconnects, system-level caches, and memory controllers, can account for a substantial share of package power, and their operating frequency bounds the achievable bandwidth and latency. Core DVFS is well supported by cpufreq, but there is no generic upstream mechanism for uncore DVFS - a gap felt most on server platforms. We propose building uncore DVFS on top of devfreq, the DVFS framework for non-CPU devices. The device model fits, but driving it from real utilization data exposes challenges worth discussing.\r\n\r\nThis topic intends to cover:\r\n1. Motivation - why we need kernel-side uncore DVFS.\r\n2. Existing upstream techniques - devfreq and vendor drivers.\r\n3. Issues encountered - no way for a driver to obtain uncore PMU IDs and create perf events; no suitable events or scaling policy for uncore.\r\n4. Proposals and analysis - a perf core helper, an event monitoring and scaling policy, and prototype measurements.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2544/)", "url": "https://lpc.events/event/20/contributions/2544/", "persons": [{"public_name": "Jie Zhan"}]}, {"guid": "lpc20-c3658", "id": "lpc20-c3658", "title": "Autonomous CPU performance selection: a new cpufreq governor?", "date": "2026-10-06T16:45:00+02:00", "start": "16:45", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "ACPI CPPC \"autonomous selection\" lets the platform pick the CPU performance level itself, within OS-provided min/max bounds and guided by an Energy Performance Preference (EPP) hint. Today cppc_cpufreq exposes this as a per-policy auto_select sysfs toggle layered on top of whatever scaling governor is attached. The result is confusing: once autonomous mode is on, the attached governor (schedutil, ondemand, ...) keeps issuing frequency requests that the hardware ignores, and scaling_governor no longer reflects what actually drives frequency.\r\n\r\ncpufreq provides two ways to drive frequency, and CPPC autonomous mode fits neither. Scaling governors use the driver's ->target() callback to apply OS-selected operating points. setpolicy drivers (intel_pstate and amd-pstate \"active\"/EPP modes) instead let the hardware choose, but CPPC has requirements it does not cover. With setpolicy, the mode is selected globally for all CPUs at the driver level, whereas CPPC's registers are per-CPU and can be controlled per policy. setpolicy also exposes only the performance and powersave policies and provides no ->target() path, while the CPPC spec allows an OS desired_perf hint even when autonomous selection is enabled. So CPPC maps cleanly onto neither model.\r\n\r\nThis session proposes a third option: modelling autonomous, EPP-biased operation as a per-policy cpufreq governor. Selecting the governor enables autonomous mode and programs the EPP and min/max bounds; switching away restores OS frequency control. EPP is exposed as a per-policy governor tunable, and the autonomous state is reported read-only.\r\n\r\nThe broader question for the micro-conference is how cpufreq should represent hardware-autonomous selection in general:\r\n\r\n- Is a new cpufreq governor the right way to expose autonomous selection at all?\r\n- If a governor is the right model, should it be CPPC-specific or generalized so other drivers can share it?\r\n- How should it relate to the existing setpolicy model used by intel_pstate and amd-pstate?\r\n- Should such a governor also pass utilization-based desired_perf hints to the hardware?\r\n- How should the EPP control be exposed to userspace (naming, accepted values, and consistency with the existing energy_performance_preference interface)?\r\n- What is the migration path away from the current sysfs toggle without breaking existing users?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2537/)", "url": "https://lpc.events/event/20/contributions/2537/", "persons": [{"public_name": "Sumit Gupta"}]}, {"guid": "lpc20-c3660", "id": "lpc20-c3660", "title": "Amortizing CPU wakeup costs", "date": "2026-10-06T17:05:00+02:00", "start": "17:05", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Transitioning a CPU into and out of idle has a non-negligible energy overhead. During low-utilization states, frequent background wakeups repeatedly pay this \"wakeup tax.\" Because the Energy Model only prices active OPP power and not idle-state transition costs, EAS defaults to spreading tasks across a cluster rather than packing them.\r\n\r\nPrototyping with sched_ext on a Pixel 9 running Linux 7.1 as a proof-of-concept, we measure the power and latency tradeoffs of batching non-urgent wakeups onto already-active CPUs. We show that reducing idle exits measurably lowers CPU power, and that the tail-latency penalty of packing comes from committing tasks to a specific CPU at wakeup time. Deferring CPU selection until dispatch time achieves the same power savings at a fraction of the latency cost.\r\n\r\nDiscussion points:\r\n\r\n- Energy Aware Scheduling: Should the Energy Model expose an idle-exit cost term, or rely on a low-utilization packing heuristic?\r\n- Cluster-scoped deferral: Can we support cluster-scoped task push-pull (similar to RT pushable tasks) instead of committing at select_task_rq()? Would this make it easier to batch?\r\n- Classifying latency-tolerance: What task QoS hints and system-state signals should govern wakeup deferral?\n\n**Attachments:**\n- [LPC26_ Amortizing CPU Wakeup costs.pdf](https://lpc.events/event/20/contributions/2579/attachments/2023/4557/LPC26_%20Amortizing%20CPU%20Wakeup%20costs.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2579/)", "url": "https://lpc.events/event/20/contributions/2579/", "persons": [{"public_name": "Samuel Wu"}]}, {"guid": "lpc20-c3657", "id": "lpc20-c3657", "title": "Current developments in the Common Clk Framework", "date": "2026-10-06T17:25:00+02:00", "start": "17:25", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "At last year's Linux Plumbers Conference, we had some great discussions about how to fix clock tree propagation in the Common Clk Framework (https://lpc.events/event/19/contributions/2152/). Taking that feedback into account, a v8 patch set has been posted that solves the problem in a simple manner.\r\n\r\nhttps://lore.kernel.org/linux-clk/20260327-clk-scaling-v8-0-86cd0aba3c5f@redhat.com/ \r\n\r\nThe KUnit tests demonstrate the problem where a clock can unknowingly change the rate of its parent and siblings to suboptimal frequencies. This can have adverse effects on subsystems that need precise rates, such as DRM and sound. The patch set needs more eyes from the community to get across the finish line. We’d like to use part of this session to go over the approach and figure out how to get it merged.\r\n\r\nWe can use the remainder of the time to discuss suggestions for ways to replace the clk subsystem's global prepare lock with a more fine-grained locking mechanism.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2543/)", "url": "https://lpc.events/event/20/contributions/2543/", "persons": [{"public_name": "Brian Masney"}]}, {"guid": "lpc20-c3659", "id": "lpc20-c3659", "title": "Hardware Pressure on x86: Does the Linux Scheduler Need to Know When You're Throttled?", "date": "2026-10-06T17:50:00+02:00", "start": "17:50", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The scheduler's task wake-up logic and capacity-aware load balancing rely on arch_scale_cpu_capacity() to determine how much work a CPU can absorb. It also has logic to account for the effects of transient thermal- and power-driven capacity loss. This mechanism, known as hardware pressure, is currently not used on x86: arch_scale_cpu_capacity() returns a fixed constant on non-hybrid systems, and even on hybrid systems it is a self-normalizing ratio that hides *uniform, proportional* capacity loss across all cores, since the reference CPU used for normalization throttles along with the rest. No plumbing exists to feed x86 thermal/power status signals (PROCHOT, RAPL power-limitation bits, HWP capability changes) into capacity accounting.\r\n\r\nThis gap has consequences. Task placement at wake-up and EAS's\r\noverutilized-detection gate can silently keep placing or retaining tasks on a throttled CPU, because the capacity term used for comparison never reflects the throttling; the load balancer may likewise\r\nmove tasks onto throttled CPUs. This is not a purely theoretical\r\nconcern: single-core thermal throttling is common even on non-hybrid parts, and Intel Speed Select Technology’s Core Power makes persistent, policy-driven asymmetric power allocation across cores.\r\n\r\nThis talk proposes a design for exposing hardware pressure on x86 and demonstrates it against concrete use cases on real hardware. The goal is not to present a finished solution, but to solicit feedback on whether this problem is worth solving, and if so, whether the proposed solution makes sense.\n\n**Attachments:**\n- [Ricardo-Neri-HW-pressure-x86.pdf](https://lpc.events/event/20/contributions/2580/attachments/2027/4563/Ricardo-Neri-HW-pressure-x86.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2580/)", "url": "https://lpc.events/event/20/contributions/2580/", "persons": [{"public_name": "Ricardo Neri"}]}, {"guid": "lpc20-c3662", "id": "lpc20-c3662", "title": "Dynamic Runtime Prediction of CPU Idle-State Exit Latency", "date": "2026-10-06T18:10:00+02:00", "start": "18:10", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Power Management and Thermal Control MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Benefits of Accurate Exit Latency can have:\r\n\r\n**More Accurate hrtimer Expiration**\r\n**Better CPU Idle level Selection**\r\n**Improved Support for Latency-Sensitive Systems**\r\n\r\nCpu different low power state can have different exit latency. And the exit latency may be affected by:\r\n\r\n 1. current cpu frequency\r\n 2. Different firmware version \r\n 3. Different hardware difference and etc.\r\n\r\nSo compile time static idle exit latency is not sufficient. Hence propose to have dynamic Runtime Prediction of CPU Idle-State Exit Latency\r\n\r\n\r\n**More Accurate hrtimer Expiration**\r\nDue to exit latency, the actual execution time of a timer interrupt is often later than the programmed expiration time. With an accurate estimate of exit latency, the timer expiration can be advanced accordingly, improving timer firing precision.\r\n\r\n    QQ Music\r\n    Version\tMax Delay (ns)\tAverage Delay (ns)\r\n    Original\t2,446,254\t618,558\r\n    Original\t2,859,657\t664,312\r\n    Original\t1,916,403\t466,087\r\n    Optimized\t629,050\t86,448\r\n    Optimized\t674,887\t107,095\r\n    Optimized\t868,674\t102,682\r\n    Honor of Kings (30 Hz)\r\n    Version\tMax Delay (ns)\tAverage Delay (ns)\r\n    Original\t2,309,583\t14,470\r\n    Optimized\t360,256\t8,234\r\n\r\nNote that data is collected from an old kernel version and legacy qcom platform.\r\n\r\n**Better CPU Idle-State Selection**\r\nThe current TOE cpuidle governor estimates idle duration using Exit Latency / 2. A more accurate exit latency estimation allows the governor to derive an idle duration closer to the actual value, leading to more appropriate idle-state selection.\r\n\r\nImproved Support for Latency-Sensitive Systems\r\nAccurate exit latency prediction is particularly beneficial for latency-sensitive workloads, such as:\r\n\t• PREEMPT_RT systems\r\n\t• Real-time applications\r\n\t• Interactive workloads like audio scenario\r\n\r\nObtaining Accurate Exit Latency at Runtime (Monitor)\r\n\t• Exit latency is fundamentally defined as:\r\nExit Latency = System Resume Timestamp − Wakeup Event Timestamp\r\n\t• The current cpuidle governor already compares predicted idle duration against actual idle duration. However, the existing measurement only covers the interval between the last instruction before entering idle and the first instruction after wakeup. Exit latency itself is typically estimated using a static value defined in the device tree.\r\n\t• In practice, exit latency varies dynamically depending on runtime conditions and system state.\r\n\t• There are many possible wakeup sources. To accurately determine the wakeup-event timestamp, measurements are restricted to timer-based wakeups because the timer expiration time is known.\r\n\t• To ensure measurement accuracy, only idle exits triggered exclusively by timer interrupts should be considered, i.e., the timer interrupt is the only pending interrupt when the CPU wakes up.\r\n\t• CPU idle states are also dynamic. As additional CPUs enter idle, the cluster-level idle state may change. Therefore, the actual idle state must be determined dynamically both when entering and exiting idle, ensuring that collected historical data is correctly associated with the corresponding idle level.\r\n\r\nExit Latency Prediction (Predict)\r\n\t• Exit latency is influenced by multiple factors and continuously changes during runtime.\r\n\t• A sliding-window-based approach can be used to collect multiple exit-latency samples.\r\n\t• Outliers are filtered out, and the average of the remaining samples is used as the predicted exit latency.\r\n\r\nUtilizing Exit Latency (Control)\r\nMore Accurate Idle-Time Estimation\r\nThe cpuidle governor can use the predicted exit latency to improve idle-duration estimation accuracy, resulting in better idle-state selection.\r\n\r\nImproved Timer Accuracy on Broadcast-Timer Platforms\r\nOn platforms supporting a broadcast timer, multiple CPUs may need to wake up simultaneously. Since a broadcast timer interrupt can only be delivered to a single CPU initially, additional wakeup delay is introduced for the remaining CPUs.\r\nTo compensate for this effect, the exit latencies of multiple CPUs can be accumulated and applied to the first awakened CPU, producing a more accurate timer expiration schedule.\r\n\r\nSummary of Benefits\r\nAccurate exit latency prediction provides the following advantages:\r\n\t• More accurate idle-time estimation for the cpuidle governor.\r\n\t• Improved CPU idle-state selection.\r\n\t• Higher timer firing accuracy through compensation for exit latency.\r\n\t• Reduced wakeup latency on broadcast-timer platforms.\r\n\t• Better performance for latency-sensitive systems such as PREEMPT_RT.\r\n\r\nOpen Discussions\r\n\t• During evaluation, a certain percentage of outlier samples is still observed within the sampling window. Currently, these samples are removed directly to reduce their impact on prediction accuracy.\r\n\t• On platforms running multiple virtual machines, the timer virtualization mechanism may affect the effectiveness and accuracy of exit-latency prediction and compensation. Further investigation is required.\n\n**Attachments:**\n- [LPC2026-Dynamic Runtime Prediction of CPU Idle-State Exit Latency.pdf](https://lpc.events/event/20/contributions/2595/attachments/2061/4677/LPC2026-Dynamic%20Runtime%20Prediction%20of%20CPU%20Idle-State%20Exit%20Latency.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2595/)", "url": "https://lpc.events/event/20/contributions/2595/", "persons": [{"public_name": "Aiqun Yu"}, {"public_name": "Cong Zhang"}]}], "Club B": [{"guid": "lpc20-c3563", "id": "lpc20-c3563", "title": "Kernel Sanitizers Office Hours", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "The Linux kernel has numerous tools to detect bugs, among them a family of dynamic program analysis called \"sanitizers\": Kernel Address Sanitizer (KASAN), Kernel Memory Sanitizer (KMSAN), Kernel Concurrency Sanitizer (KCSAN), and the Undefined Behaviour Sanitizer (UBSAN). Although not a bug-detecting sanitizer itself, we will also cover Kernel Coverage (KCOV), which utilizes similar compiler instrumentation to collect and expose execution feedback.\r\n\r\nKnowing when to apply which sanitizer in the kernel development process may not always be obvious: each sanitizer is dedicated to finding a different class of bugs, and each introduces some amount of performance and/or memory overhead. Not only that, each sanitizer also provides a range of options to tweak their abilities.\r\n\r\nThis session is dedicated to briefly introducing each kernel sanitizer, the bug classes they help detect, and important gotchas when using them.\r\n\r\nThe rest of the session is dedicated to answering questions around each of the sanitizers, KASAN, KMSAN, KCSAN, and UBSAN. Feel free to also share success stories that may give other attendees only starting out with some of the sanitizers ideas how to best apply them.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2409/)", "url": "https://lpc.events/event/20/contributions/2409/", "persons": [{"public_name": "Aleksandr Nogikh"}, {"public_name": "Alexander Potapenko"}, {"public_name": "Dmitry Vyukov"}, {"public_name": "Justin Stitt"}, {"public_name": "Kees Cook"}, {"public_name": "Marco Elver"}, {"public_name": "Pimyn Girgis"}]}, {"guid": "lpc20-c3564", "id": "lpc20-c3564", "title": "Linux CVEs, vulnerability management and agentic security workflows", "date": "2026-10-06T10:45:00+02:00", "start": "10:45", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "This year has been marked by the rise of cyber-capable AI models, flooding maintainers with increasingly better vulnerability reports. More vulnerabilities have been reaching the headlines, resulting in emergency mitigations across different deployments. In response, many organizations have adopted agentic solutions to scan, triage, reproduce, and patch vulnerabilities.\r\n\r\nDuring this year's BoF, we plan to not only update the community on our ongoing efforts with CVE triaging (https://github.com/cloud-lts/linux-cve-analysis), but also to discuss these common agentic efforts. Our objective is to boost cross-organizational collaboration and support the security community in navigating these new challenges.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2410/)", "url": "https://lpc.events/event/20/contributions/2410/", "persons": [{"public_name": "Damiano Melotti"}]}, {"guid": "lpc20-c3741", "id": "lpc20-c3741", "title": "x86 BoF", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "This will be an x86-focused session. Broadly speaking, anything that might affect arch/x86 is on topic, except where there may be a more focused discussion occurring, like around Confidential Computing or KVM.\r\n\r\nWe'll talk about new ISA, hardware security processes and structural issues affecting arch/x86.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2633/)", "url": "https://lpc.events/event/20/contributions/2633/", "persons": [{"public_name": "Dave Hansen"}]}, {"guid": "lpc20-c3566", "id": "lpc20-c3566", "title": "DRM Fabric: Vendor-Neutral Topology Infrastructure for Scale-Up Accelerator Interconnects", "date": "2026-10-06T12:45:00+02:00", "start": "12:45", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "Modern GPUs and dedicated AI accelerators are increasingly connected through scale-up interconnect fabrics such as AMD xGMI today and [UALink](https://ualinkconsortium.org/about-ualink/) in the near future. Yet Linux lacks common topology infrastructure for reporting, vendor-neutrally, which accelerators are directly connected, through which ports, and in what state. Vendors expose fragments privately — e.g. `amdgpu`'s xGMI sysfs — and prior per-driver proposals, such as XeLink, never became shared Linux infrastructure. As a result, topology semantics are being defined by vendor-private uAPIs rather than by a shared Linux control-plane contract for monitoring and fabric management.\r\n\r\nBuilding on the LPC 2025 [\"Toward Mainline Linux Support for UALink\"](https://lpc.events/event/19/contributions/2308/) BoF, we propose DRM Fabric: a vendor-neutral, protocol-agnostic DRM topology infrastructure for scale-up interconnects, using the model:\r\n\r\n`fabric → endpoint → port → peer`\r\n\r\nVendor drivers populate it through a thin provider API; userspace queries it through `drm-fabric`, a YAML-defined generic-netlink family consumed through `ynl` tooling, following the netlink uAPI pattern `drm_ras` introduced to DRM. No data path: load/store traffic and memory semantics remain in the vendor driver, so the infrastructure remains valid across vendors and fabrics.\r\n\r\nThe implementation is split into two RFC series. Phase 1 targets provider-owned fabrics, such as an xGMI-like implementation, where the driver discovers topology and reports it read-only to userspace, including notifications, optional port statistics, and consistent multipart enumeration. Phase 2 adds privileged provisioning for software-defined, UALink-style fabrics: creating fabric containers, attaching orphan endpoints, setting administrative state, and provisioning peers on userspace-managed ports, while providers continue to report actual hardware state. The RFCs include the core infrastructure, an in-tree synthetic provider (`fabricsim`, modeled on `netdevsim`), and KUnit plus `pyynl`/kselftests exercising the infrastructure and uAPI end-to-end without hardware. The next step is a hardware-backed provider for an already-shipping scale-up fabric.\r\n\r\nWe want LPC feedback on the DRM representation, the boundary between provider-owned topology and privileged userspace provisioning, whether the proposed provisioning primitives are sufficient, and how AMD, Intel, UALink Consortium members, and other accelerator vendors should co-develop the common infrastructure and provider interfaces.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2412/)", "url": "https://lpc.events/event/20/contributions/2412/", "persons": [{"public_name": "Konstantin Sinyuk"}]}, {"guid": "lpc20-c3567", "id": "lpc20-c3567", "title": "Bridging the Linux Tux  and the FreeBSD Beastie – Linuxulator, LinuxKPI, and LLM-Assisted Porting Challenges on License Issue", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "The boundary between the Linux and FreeBSD ecosystems is often loose and porous,while developers continuously building bridges to maximize hardware support and software availability across both platforms.\r\n\r\nTwo mechanisms carry that weight on shoulders: the Linuxulator, a native\r\nimplementation of the Linux syscall ABI that runs unmodified Linux binaries,\r\nand LinuxKPI, a shim layer that lets FreeBSD build largely unmodified Linux\r\ndrivers -- the DRM drivers via drm-kmod, mac80211-based wireless drivers, and a growing set of others -- against a subset of the Linux in-kernel API.\r\n\r\nDepending directly on the ripples from Linux's advancements, Linuxulator tracks syscall, vDSO, /proc, netlink and seccomp behaviors and LinuxKPI tracks an in-kernel API that is explicitly not stable, which makes every DRM or wireless driver during release cycle into an aerobics workout. \r\n\r\nHence, this Birds of a Feather (BoF) session is then hereby proposed to serve as an information exchange hub for developers working at the intersection of Linux and FreeBSD kernel mechanisms.\r\n\r\nFurthermore, FreeBSD is not the only Frankenstein here: Fuchsia's starnix and illumos LX zones reimplement parts of the exposed surface of Linux userspace, and several BSDs have maintained downstream of DRM shims of their own. So if you are also an amphibian developer other operating systems. Don't hesitate to join us :-)\r\n\r\nDuring this session, we may discuss topics including but not limited to :\r\n\r\n- Linuxulator (Linux Emulation Layer): The current state, limitations, and future enhancements of running unmodified Linux binaries on FreeBSD. E.g. RISC-V architecture.\r\n- LinuxKPI: The compatibility framework designed to ease the porting of complex Linux kernel drivers (such as DRM and wireless drivers) to FreeBSD. We will discuss the friction points driver maintainers face and how the Linux community's API changes impact downstream compatibility.\r\n- The LLM Porting and License Issues: With the rise of Large Language Models (LLMs), developers are actively experimenting with AI to assist in translating or porting drivers from Linux to FreeBSD. However, this introduces complex license compatibility questions i.e. GPLv2 vs. BSD. And thus shall deserve a chat with beers in my humble opinion. And here's the living witness of such kind of work : [aqtion-freebsd-aq2 work][1].\r\n\r\nRelated discussions could be found in [AsiasBSDCon 2026][2]\r\n\r\n\r\n  [1]: https://wiki.freebsd.org/DevSummit/202603?action=AttachFile&do=view&target=aq2.pdf\r\n  [2]: https://wiki.freebsd.org/DevSummit/202603\n\n[Open in Indico](https://lpc.events/event/20/contributions/2413/)", "url": "https://lpc.events/event/20/contributions/2413/", "persons": [{"public_name": "\"Ruinland\" ChuanTzu Tsai"}, {"public_name": "Li-Wen Hsu"}]}, {"guid": "lpc20-c3742", "id": "lpc20-c3742", "title": "F2FS update", "date": "2026-10-06T15:45:00+02:00", "start": "15:45", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "Touch F2FS topics:\r\n - Large folio\r\n - Sub-page block support (16KB page on 4KB block)\r\n - Device Aliasing for Android\n\n[Open in Indico](https://lpc.events/event/20/contributions/2634/)", "url": "https://lpc.events/event/20/contributions/2634/", "persons": [{"public_name": "Jaegeuk Kim"}]}, {"guid": "lpc20-c3580", "id": "lpc20-c3580", "title": "Improving THP placement policies", "date": "2026-10-06T17:00:00+02:00", "start": "17:00", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "Transparent Huge Page placement has historically been (and is) quite simplistic and overeager. This normally results in users turning off THP completely, or for selected workloads using any number of available toggles.\r\n\r\nI'd like to discuss realistic ways in which we could meaningfully improve this, including past ideas such as thp=auto.\r\n\r\nSeveral relevant aspects would include:\r\n - adapting THP placement based on filesystem/storage needs\r\n - adapting THP placement based on userspace memory accesses\r\n - adjusting and improving expectations on MADV_COLLAPSE\r\n - getting rid of hard-to-tune heuristics like max_ptes_none & others\n\n[Open in Indico](https://lpc.events/event/20/contributions/2452/)", "url": "https://lpc.events/event/20/contributions/2452/", "persons": [{"public_name": "Pedro Falcato"}]}, {"guid": "lpc20-c3581", "id": "lpc20-c3581", "title": "DAMON Nano Conference", "date": "2026-10-06T17:45:00+02:00", "start": "17:45", "duration": "00:45", "room": "Club B", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "DAMON is a kernel subsystem for efficient data access/attributes monitoring and memory operations. It received many updates last year. Many more updates are in progress. Multiple ideas for future works are flooding. In this session, multiple people who work on DAMON will present and discuss what changes have recently been made, what changes are ongoing, and what should be the next work.\r\n\r\n# Schedule\r\n\r\nNote that the schedule could be updated until the last minute.\r\n\r\n17:45-17:48 _Opening_\r\n17:48-17:55 _Breaking through Accessed Bit Limits of DAMON_, SJ Park, Ravi Jonnalagadda, Akinobu Mita\r\n17:55-18:05 _Beyond Weighted Interleaving: Bandwidth-Driven Memory Tiering with DAMON_, Ravi Jonnalagadda.  [Slides](https://lpc.events/event/20/contributions/2453/attachments/2032/4675/beyond-weighted-interleaving.pdf)\r\n18:05-18:15 DAMON for Huge Pages\r\n- _Guiding THP Decisions with DAMON Memory Monitoring_, Asier Gutierrez\r\n- _Host-side DAMON Hotness under KVM/THP: Granularity Gaps and Evidence for Demotion_, Lian Wang, Kunwu Chan\r\n18:15-18:25 _DAMON in the AI Cloud: Monitoring Real-World GPU Workloads_, Krishna Iyer. [Slides](https://lpc.events/event/20/contributions/2453/attachments/2032/4571/DAMON%20in%20the%20AI%20Cloud.pdf)\r\n18:25-18:30 _Joint QnA and Closing_\r\n\r\n# Authors (Alphabetically sorted)\r\n\r\n_Akinobu Mita_\r\nSoftware engineer at Fixstars Corporation.\r\n\r\n_Asier Gutierrez_\r\nSenior Software Engineer at Huawei.  Experienced Senior Software Developer specializing in Linux development, kernel-level debugging, and high-load, high-availability systems. I currently work for Huawei. I have worked for Intel, IBM and Yandex in the past.\r\n\r\n_Krishna Iyer_\r\nKrishna Iyer is a Software Engineer at Crusoe specializing in low-level systems, driver development, and Linux build systems. Previously at Cisco-Meraki, he now focuses on researching memory access patterns using DAMON for AI workloads on GPU infrastructure.\r\n\r\n_Kunwu Chan_\r\nKunwu Chan is a Linux kernel developer whose work spans DAMON, memory management, swap, MGLRU, and RCU. His interests include kernel performance analysis and tuning, subsystem design, and memory safety.\r\n\r\n_Lian Wang_\r\nLian Wang is a Software Engineer at Process Mission (Shanghai) Technology Co., Ltd. He works on Linux kernel memory management, with a focus on DAMON, huge pages, and memory management for virtualized and large-memory Systems.\r\n\r\n_Ravi Jonnalagadda_\r\nRavi Jonnalagadda is a Sr Manager at Micron working on Linux kernel memory management for CXL and tiered-memory systems. He co-developed the weighted interleaving memory policy and added the node_eligible_mem_bp DAMOS quota goal. His current work lets DAMON take access samples from hardware sampling units.\r\n\r\n_SJ Park_\r\nSJ is a kernel programmer with a strong focus on memory management. He develops and maintains DAMON, a Linux kernel subsystem designed for efficient data access monitoring and access-aware system operations.\n\n**Attachments:**\n- [beyond-weighted-interleaving.pdf](https://lpc.events/event/20/contributions/2453/attachments/2032/4675/beyond-weighted-interleaving.pdf)\n- [DAMON in the AI Cloud.pdf](https://lpc.events/event/20/contributions/2453/attachments/2032/4571/DAMON%20in%20the%20AI%20Cloud.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2453/)", "url": "https://lpc.events/event/20/contributions/2453/", "persons": [{"public_name": "SJ Park"}]}], "Club E (Floor 1)": [{"guid": "lpc20-c3733", "id": "lpc20-c3733", "title": "mmu_notifier: can we use it better?", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: KVM MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "KVM uses the mmu_notifier infrastructure to keep the guest mapping up to date. After having completely rewritten the memory management of KVM/s390 to use mmu_notifiers, I have noticed some of the shortcomings in how KVM uses the notifiers.\r\n\r\nSome of areas where KVM's usage of the notifiers, or the mmu_notifier infrastructure itself can be improved:\r\n\r\n - passing the reason code to the KVM callback when unmapping\r\n - more fine-grained reason codes\r\n - passing back flags from the notifier callback\r\n\r\nI will show how and why each of the above points would be useful for KVM with some concrete examples.\n\n**Attachments:**\n- [mmu_notifier_lpc2026.pdf](https://lpc.events/event/20/contributions/2552/attachments/2074/4636/mmu_notifier_lpc2026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2552/)", "url": "https://lpc.events/event/20/contributions/2552/", "persons": [{"public_name": "Claudio Imbrenda"}]}, {"guid": "lpc20-c3735", "id": "lpc20-c3735", "title": "Exploring KVM and SMMUv3 Stage-2 Page Table Sharing for arm64 pKVM", "date": "2026-10-06T10:30:00+02:00", "start": "10:30", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: KVM MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "As Protected KVM (pKVM) progresses on arm64, achieving full isolation requires hypervisor-controlled IOMMUs to prevent DMA attacks. While there has been progress on SMMUv3 support for pKVM via trap-and-emulate on the mailing list [1], a major architectural design question remains unresolved: managing the stage-2 translation tables.\r\n\r\nCurrently, the series relies on maintaining a shadow stage-2 page tables for the SMMUv3.\r\nArchitecturally, it is possible to share these page tables between the CPU and the SMMUv3 in a similar way the kernel does SVA for stage-1, which would reduce memory overhead. However, KVM has different design constraints than user-space processes, and we are expected to run on a wide range of hardware without introducing impractical limitations or assumptions brought by SVA.\r\n\r\n**Some of the main points:**\r\n- Dealing with page faults (Pinning, BBM…)\r\n- IO TLB invalidation and DVM\r\n- Cache coherency of the IOMMU and page tables\r\n\r\nThe goal of this session is to discuss the viability of shared stage-2 page tables and reach a path forward for DMA isolation on pKVM.\r\n\r\n[1] https://lore.kernel.org/all/20260501111928.259252-1-smostafa@google.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2555/)", "url": "https://lpc.events/event/20/contributions/2555/", "persons": [{"public_name": "Mostafa Saleh"}]}, {"guid": "lpc20-c3731", "id": "lpc20-c3731", "title": "How to support multiple backends for guest_memfd?", "date": "2026-10-06T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: KVM MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "To improve performance of CoCo VMs, there's active work on huge pages for guest_memfd. The first \"backend\" in the works for providing huge pages is HugeTLB.\r\n\r\nFrank summarized interest in having devdax/ZONE_DEVICE memory as another backend [1] for guest_memfd.\r\n\r\nIf guest_memfd is to be *the* guest memory provider of KVM, it has to support (almost) any memory backend that can be configured in a memslot today through VMAs, going beyond memory backends to other things can be mmap()-ed, like perhaps MMIO though VFIO.\r\n\r\nI would like to get ideas and feedback on how guest_memfd should be extended to support different backends.\r\n\r\nAre flags what we really want to go with? Will we end up supporting many flags?  Using HugeTLB as an example, flags/fields can encode use of HugeTLB, HugeTLB page sizes, but how would the HugeTLB mount be encoded? Should there be some way to encode size limits of the mount? Is that a required feature?\r\n\r\nCould we perhaps reuse existing interfaces to communicate the memory config to guest_memfd? What if we hand fds (opened on specific mounts) where guest_memfd can grab config from? Should guest_memfd perhaps use pre-allocated memory from the fd?\r\n\r\n[1] https://lore.kernel.org/all/CAPTztWajm_JLpp9BjRcX=h72r25ELrXeGkOXVachybBxLJGS=g@mail.gmail.com/\n\n**Attachments:**\n- [lpc-2026-gmem-other-backends.pdf](https://lpc.events/event/20/contributions/2551/attachments/2047/4593/lpc-2026-gmem-other-backends.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2551/)", "url": "https://lpc.events/event/20/contributions/2551/", "persons": [{"public_name": "Ackerley Tng"}]}, {"guid": "lpc20-c3729", "id": "lpc20-c3729", "title": "In-Kernel Caretaker for Orphaned VMs", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: KVM MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "As cloud infrastructure continues to push toward zero-downtime host maintenance, extending the capabilities of kexec-based Live Update to minimize guest disruption is becoming increasingly critical. This proposal introduces the architectural concept of an \"Orphaned VM\"—a virtual machine that actively executes guest instructions on isolated physical hardware while completely decoupled from a host operating system or a VMM during a host reboot. This execution asymmetry is achieved by introducing the \"Caretaker,\" a specialized bare-metal primitive interpose layer that runs within the hypervisor's privileged hardware state to trap and resolve some VM exits locally while the host kernel is offline. This session will explore the mechanisms required to orchestrate this transition using the LUO, focusing on how vcpufd structures are preserved across the reboot gap, how physical CPUs are shielded from boot-time reset signals, and how asynchronous hardware challenges like timekeeping drift, stray interrupts, and guest-to-guest IPI routing are mitigated during the management gap.\r\n\r\nRFC Reference & Discussion Thread: For full architectural background and ongoing community feedback, see the original mailing list discussion at https://lore.kernel.org/all/afEwWZksU0Fw61oT@plex\n\n[Open in Indico](https://lpc.events/event/20/contributions/2553/)", "url": "https://lpc.events/event/20/contributions/2553/", "persons": [{"public_name": "Pasha Tatashin"}]}, {"guid": "lpc20-c3728", "id": "lpc20-c3728", "title": "Orphaned VMs: Which VM Exits can we handle?", "date": "2026-10-06T12:30:00+02:00", "start": "12:30", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: KVM MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Orphaned VMs [0] is proposed to be the next evolution of hypervisor live update. It relies on a specialized micro-hypervisor, called the Caretaker, which handles VM Exits during the time between old kernel shutting down and new kernel booting up. The Caretaker reduces the downtime observed by the VM during live update by servicing VM Exits during this transition period.\r\n\r\nThe Caretaker is not a full hypervisor or VMM, so it cannot service all the VM Exits. If it cannot handle a VM Exit, it must pause the VM and wait for the next kernel to take over. The success of the Caretaker in reducing observed VM downtime relies on which VM Exits it can and can't service, and how frequently they occur.\r\n\r\nIn this talk, we will present the types and frequency of VM Exits observed under some sample workloads. We will also categorize the VM Exits into ones which the Caretaker can handle and the ones which it can't.\r\n\r\nBy combining the frequency of VM Exits and whether they can be handled, we can estimate observed VM downtime, and decide how effective Orhpaned VMs can be.\r\n\r\n[0] https://lore.kernel.org/all/afEwWZksU0Fw61oT@plex/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2554/)", "url": "https://lpc.events/event/20/contributions/2554/", "persons": [{"public_name": "Pratyush Yadav"}, {"public_name": "Tarun Sahu"}]}, {"guid": "lpc20-c3739", "id": "lpc20-c3739", "title": "KVM and Live Update", "date": "2026-10-06T13:00:00+02:00", "start": "13:00", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: KVM MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "During this session, the maintainers of KVM welcome discussion around other topics related to live update and the Caretaker that did not fit in the previous hour, including:\r\n* guest_memfd live update\r\n* stable ABI for live update\r\n* reusing the Caretaker concept for pKVM\r\n\r\nThe above list is just a suggestion, as we will take other topics from the audience if there are any.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2632/)", "url": "https://lpc.events/event/20/contributions/2632/", "persons": [{"public_name": "Paolo Bonzini"}, {"public_name": "Sean Christopherson"}]}, {"guid": "lpc20-c3825", "id": "lpc20-c3825", "title": "Testing MC Intro", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:05", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Welcome to the Kernel Testing & Dependability MC\r\n\r\n*Quick overview of the 2026 edition and usual Plumbers briefing*\n\n[Open in Indico](https://lpc.events/event/20/contributions/2644/)", "url": "https://lpc.events/event/20/contributions/2644/", "persons": [{"public_name": "Guillaume Tucker"}, {"public_name": "Arisu Tachibana"}, {"public_name": "Sasha Levin"}, {"public_name": "Shuah Khan"}]}, {"guid": "lpc20-c3799", "id": "lpc20-c3799", "title": "kci-dev: What Changed, What Works, and What Kernel Developers Still Need", "date": "2026-10-06T15:05:00+02:00", "start": "15:05", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "kci-dev was created as a standalone command-line tool that allows kernel developers and maintainers to interact directly with KernelCI. Since its initial releases, the project has grown beyond its original role as a thin client for triggering jobs and retrieving results.\r\n\r\nThe latest development cycle, including the v0.1.11 release, introduced a reusable Python library interface, direct submission of external build results to KCIDB, storage-related commands, broader result filtering, improved Maestro and Dashboard validation, machine-readable validation reports, distribution packaging workflows, and an experimental Model Context Protocol server for automation and AI-assisted tooling. Significant reliability work also addressed automated bisection, job watching, network timeouts, malformed output, configuration handling, and inconsistent Maestro behaviour.\r\n\r\nThese changes are moving kci-dev from a collection of CLI commands toward a common integration layer for kernel testing workflows. However, several important pieces are still missing before it can become a practical everyday tool for a broader group of kernel developers and maintainers.\r\n\r\nKey gaps include first-class testing of email patch series through b4 and Patchwork, reproducible pre-submit test plans, reliable comparison of results between revisions, classification of regressions versus flaky or infrastructure failures, consistent interfaces across Maestro, KCIDB and the KernelCI Dashboard, richer lab and hardware metadata, caching and multi-tree reporting, and stable extension points for external tools.\r\n\r\nThis session will present the current state of kci-dev, distinguish mature functionality from experimental work, and discuss which missing workflows should be prioritised. The goal is to agree on interfaces, responsibilities and concrete contributions needed to make kci-dev a dependable bridge between kernel development workflows and KernelCI.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2534/)", "url": "https://lpc.events/event/20/contributions/2534/", "persons": [{"public_name": "Arisu Tachibana"}]}, {"guid": "lpc20-c3801", "id": "lpc20-c3801", "title": "Kernel Builds Deserve an Identity: Portable Kernel Artifacts and Traceable Test Results", "date": "2026-10-06T15:25:00+02:00", "start": "15:25", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Our CI systems build thousands of kernels a day, yet the kernel build itself has no canonical identity and no portable distribution format. Reproducing the exact binary behind a regression report is guesswork, and correlating KCIDB results back to a build is convention, not verification.\r\n\r\nKBI (Kernel Bundle Image, Apache-2.0) is a concrete starting point for fixing this. It packages vmlinuz, modules, initrd, BTF, firmware, and config as a standard OCI image and derives a deterministic, independently recomputable build identity from the artifacts. Existing registries handle distribution and signing, which maps naturally onto pull-mode labs. Module and eBPF add-ons bind to a specific build identity, turning silent runtime mismatches in labs into early, explainable rejections.\r\n\r\nProposed discussion points:\r\n\r\n- What should define kernel build identity, and how does it interact with reproducible builds?\r\n\r\n- Could Tuxmake and KernelCI Maestro emit OCI kernel bundles, and could KCIDB adopt a verifiable build identity field?\r\n\r\n- How far should artifact metadata go toward a kernel SBOM for safety and traceability use cases?\r\n\r\n- Could it solve bare metal kernel CI testing with multikernel?\n\n**Attachments:**\n- [kbi-lpc.pdf](https://lpc.events/event/20/contributions/2620/attachments/1985/4515/kbi-lpc.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2620/)", "url": "https://lpc.events/event/20/contributions/2620/", "persons": [{"public_name": "Cong Wang"}]}, {"guid": "lpc20-c3802", "id": "lpc20-c3802", "title": "Rethinking KUnit Configuration", "date": "2026-10-06T15:45:00+02:00", "start": "15:45", "duration": "00:25", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The ``kunit.py`` tool currently spreads its configuration across three places: ``kunitconfig`` files, which contain Kconfig entries for the kernel being tested; ``qemu_config`` python scripts, which configure architecture- and emulator-specific options; and command-line arguments, which specify what is being done (building, testing, parsing, etc.), and any options specific to the run (filters, build options, output configuration, etc.)\r\n\r\nThis means that, in order to completely configure a test run, three different configuration sources need to be managed, all of which are in different formats, and one of which isn’t even a file.\r\n\r\nIf we can implement a combined configuration format, this will not only simplify configuring KUnit tests, but also allow enhancements to ``kunit.py`` which manage configurations more explicitly. With first-class configurations, ``kunit.py`` could — for example — support running multiple different configurations as part of a single execution.\r\n\r\nWould this be useful, and if so, how should we do it? In particular:\r\n\r\n - Should we extend the Kconfig-based ‘kunitconfig’ files with additional configuration lines?\r\n - Would a python-based configuration (more like the qemu_config files) be sufficiently simpler?\r\n - How important is maintaining compatibility with existing configs (it shouldn’t be hard to do so)?\r\n - Is doing multiple test runs from within kunit.py useful? (And, if not, are people doing this using other scripts/CI systems?)\r\n - If so, how should results be handled? We can merge KTAP results (but it’s trickier to do so in a way which preserves the streaming nature of results).\r\n - What else can’t be expressed in existing KUnit configurations which would be useful?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2531/)", "url": "https://lpc.events/event/20/contributions/2531/", "persons": [{"public_name": "David Gow"}]}, {"guid": "lpc20-c3823", "id": "lpc20-c3823", "title": "Optimizing local kernel build testing", "date": "2026-10-06T16:10:00+02:00", "start": "16:10", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "For the past 15 years, Arnd has been using a custom kernel build setup for regression testing linux-next kernels. Initially set up purely for the maintenance of the SoC tree, this has also helped in a number of other initiatives for cross-tree code changes and produced thousands of bugfixes across every major subsystems of the kernel.\r\n\r\nIn this session, Arnd will discuss some of the lessons learned from this work, and how some of the same ideas can be applied to other test setups and CI systems.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2642/)", "url": "https://lpc.events/event/20/contributions/2642/", "persons": [{"public_name": "Arnd Bergmann"}]}, {"guid": "lpc20-c3824", "id": "lpc20-c3824", "title": "Kselftest coverage with kcov", "date": "2026-10-06T17:00:00+02:00", "start": "17:00", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "We can use KCOV configuration options and a simple tool to measure coverage to find gaps in individual selftests. Let's discuss how and if it is helpful in improving and enhancing the existing tests strictly to identify the gaps in critical coverage.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2643/)", "url": "https://lpc.events/event/20/contributions/2643/", "persons": [{"public_name": "Shuah Khan"}]}, {"guid": "lpc20-c3803", "id": "lpc20-c3803", "title": "KFuzzTest: Fuzzing Internal Kernel Functions, One Year On", "date": "2026-10-06T17:15:00+02:00", "start": "17:15", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "At LPC 2025 we introduced KFuzzTest, a framework for exposing stateless and low-state internal kernel functions, such as complex data parsers and the like, directly to a userspace fuzzer, reaching code that system-call fuzzers struggle to exercise. Developers define targets alongside their functions using a simple macro-based API, with constraints and type annotations compiled into dedicated ELF sections for automatic discovery. This follow-up reports on a year of progress and charts the path ahead.\r\n\r\nSince last year, the patch series has matured through upstream review, with [a follow-up revision][1] that simplified the design and removed the dependency on syzkaller, lowering the barrier to adoption. With the framework stabilizing, we turn to a broader question: KFuzzTest's defining feature is a uniform, low-boilerplate interface for invoking internal functions, and that interface is useful well beyond a single fuzzing engine.\r\n\r\nWe will explore two directions. First, integration with KUnit: a fuzzing harness is naturally expressed as a specialized unit test, suggesting a guiding principle that if a function can be unit-tested, it can be fuzzed, and reusing existing test infrastructure rather than standing up new machinery.\r\n\r\nSecond, automated harness generation: writing fuzz harnesses is routine, mechanical work, and KFuzzTest's minimal interface is well suited to being driven by LLM-based agents, both to author targets and to drive fuzzing loops. We see offloading this boilerplate as a concrete value proposition.\r\n\r\nThis presentation will cover what changed over the past year, lessons from the review process, and these avenues for extending KFuzzTest's reach. We hope to use the session to gather community feedback on the most promising directions for upstreaming.\r\n\r\n\r\n  [1]: https://lore.kernel.org/all/20260112192827.25989-1-ethan.w.s.graham@gmail.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2532/)", "url": "https://lpc.events/event/20/contributions/2532/", "persons": [{"public_name": "Ethan Graham"}]}, {"guid": "lpc20-c3804", "id": "lpc20-c3804", "title": "LLM-Assisted Fuzzing with Syzkaller", "date": "2026-10-06T17:30:00+02:00", "start": "17:30", "duration": "00:15", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Coverage-guided fuzzing has proven to be highly effective at discovering Linux kernel vulnerabilities. Since its appearance in 2016, syzkaller - especially through the automated syzbot platform - has reported over 14,000 findings to the public kernel mailing lists.\r\n\r\nDespite the success, traditional fuzzing methods struggle to reach deep code paths within complex kernel subsystems, even when provided with exact descriptions of the Linux kernel interfaces and fine-grained coverage feedback. Generating programs to reach deeply nested Linux kernel locations often requires a nuanced semantic understanding of target source code - a bottleneck that historically demanded substantial manual engineering. Now, the ever increasing capabilities of LLMs offer us the opportunity to address this problem in a fully automated manner.\r\n\r\nWe will present an intelligent, context-aware bug discovery workflow that integrates LLM-driven seed program generation with coverage-guided fuzzing using Syzkaller. By leveraging coverage feedback from the fuzzing engine, our approach selectively targets weakly covered Linux kernel regions and automatically synthesizes context-relevant seed programs to reach them. These seeds are subsequently fed back into the fuzzer, enabling coverage expansion into previously unexplored code regions and facilitating bug discovery. \r\n\r\nDuring the experiments, we have successfully increased the testing coverage of the Linux kernel **from 30% to 35%** on the syzbot platform, exercising over 70,000 previously uncovered basic blocks. In total, by injecting the discovered seeds into the syzkaller pipeline, we've already discovered **450+** new, reproducible kernel bugs, including numerous UAF, OOB accesses and memory leaks.\r\n\r\nBenchmark testing of the seed program generation workflow has demonstrated that it can reach roughly **16%** of previously never reached locations (a random sample of **N=500**). We are confident that further improvements and future LLM models will let us achieve even higher effectiveness.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2619/)", "url": "https://lpc.events/event/20/contributions/2619/", "persons": [{"public_name": "Chuyang Wang"}, {"public_name": "Aleksandr Nogikh"}]}, {"guid": "lpc20-c3800", "id": "lpc20-c3800", "title": "Testing the kernel where the fleet runs: KernelCI in the cloud", "date": "2026-10-06T17:50:00+02:00", "start": "17:50", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "KernelCI provides continuous testing for the Linux kernel. Over the past year we extended testing into the cloud. AWS lab is now integrated upstream and visible on the KernelCI dashboard.\r\n\r\nWe will describe the architecture and how it maps onto KernelCI's pull-mode lab model so other cloud vendors can attach their own infrastructure. We will share the gotchas of testing on remote virtualized machines.\r\n\r\nThe cloud unlocks special test usecases from tiny, memory-pressured instances to machines with hundreds of cores and terabytes of RAM.\r\nAdditionally, EC2 exposes nested KVM on c8i instances, and we run kvm-unit-tests inside these guests to exercise the kernel's own virtualization stack.\r\n\r\nKernelCI already runs tests on AWS infrastructure. We will discuss next steps and improvements like performance testing.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2533/)", "url": "https://lpc.events/event/20/contributions/2533/", "persons": [{"public_name": "Norbert Manthey"}, {"public_name": "Stanislav Uschakow"}]}, {"guid": "lpc20-c3805", "id": "lpc20-c3805", "title": "Security Lessons from Auditing the Linux accel/ethosu Driver", "date": "2026-10-06T18:10:00+02:00", "start": "18:10", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Kernel Testing & Dependability MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Linux accel/ subsystem is still relatively young, yet it already exposes\r\ncomplex userspace interfaces for machine learning accelerators. These drivers\r\nprocess user-controlled command streams, DMA descriptors, tensors, and region\r\nmetadata, making input validation critical.\r\n\r\nThis talk presents the results of a security audit of the accel/ethosu driver\r\nthat led to seven upstream fixes merged in 2026, with the fixes subsequently\r\nbackported to supported stable kernel series where appropriate. The issues\r\nincluded out-of-bounds accesses, arithmetic overflows, incorrect index\r\nvalidation, sentinel misuse, and insufficient validation of DMA-related\r\nmetadata.\r\n\r\nRather than focusing on individual bug fixes, the presentation identifies the\r\nrecurring implementation patterns that produced these vulnerabilities and\r\ndiscusses practical techniques for preventing similar issues in future\r\naccelerator drivers. Topics include overflow-safe arithmetic, structured input\r\nvalidation, region and descriptor verification, and opportunities for improving\r\nfuzz testing of accelerator interfaces.\r\n\r\nThe session concludes with discussion of possible common validation helpers,\r\nsecurity review guidelines for new accelerator drivers, and ways to improve the\r\nlong-term robustness of the Linux accel/ subsystem as ML hardware becomes\r\nincreasingly common.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2621/)", "url": "https://lpc.events/event/20/contributions/2621/", "persons": [{"public_name": "Muhammad Bilal"}]}], "Club H (Floor 1)": [{"guid": "lpc20-c3826", "id": "lpc20-c3826", "title": "Sashiko current status", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:45", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Current status of Sashiko. Also in this block: #140 \"Citation Needed: Treating the kernel's AI review context like code\" (Fuad Tabba), and Chris Mason and others on review prompts.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2645/)", "url": "https://lpc.events/event/20/contributions/2645/", "persons": [{"public_name": "Roman Gushchin"}]}, {"guid": "lpc20-c3827", "id": "lpc20-c3827", "title": "Sashiko feedback and feature requests", "date": "2026-10-06T10:45:00+02:00", "start": "10:45", "duration": "00:30", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Open discussion with everyone: feedback on Sashiko and feature requests.\r\n\r\nRelated talks: #140 Fuad Tabba (Google); #166 Andrea Righi (NVIDIA); #298 Konstantin Sinyuk (Intel)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2646/)", "url": "https://lpc.events/event/20/contributions/2646/", "persons": []}, {"guid": "lpc20-c3830", "id": "lpc20-c3830", "title": "Automating Kernel Bug Fixes: Syzbot's AI-Assisted Patching Workflow", "date": "2026-10-06T11:15:00+02:00", "start": "11:15", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "[Syzbot][1] reports around 1,500 new fuzzer-detected findings in the Linux kernel each year. Even for straightforward bugs where the root cause is obvious, the manual effort of drafting, testing, and sending patches constitutes a significant effort on the kernel developers side.\r\n\r\nTo facilitate this process, we have launched an AI-assisted fix generation [workflow][2] in syzbot built around human-in-the-loop review:\r\n* **Two-Stage Pipeline**: Candidate patches are sent to a moderation list where reviewers reply with natural-language feedback or commands (`#syz reject`, `#syz upstream`). The AI agent interprets comments, answers questions, and iterates on new versions while preserving tags like *Reviewed-by* or *Tested-by*.\r\n* **Human Accountability**: When approved via the `#syz upstream` command, the human reviewer's *Signed-off-by:* tag is attached in compliance with Linux Kernel AI Coding Assistants guidelines before forwarding the patch to public mailing lists.\r\n\r\n**Status & Discussion**: The system is in a POC stage and undergoing active development. As of September 2026, 30 of the syzbot AI-assisted patches have been merged upstream, more are under review/discussion.\r\n\r\nIn this session, we will focus on:\r\n* **System Overview**: More detailed workflow description and how the system works under the hood.\r\n* **Lessons Learned**: Based on the current experience, what went well and what needs more attention.\r\n* **Community Discussion**: How to make the tool more useful and increase review efficiency.\r\n\r\n\r\n  [1]: https://syzbot.org/upstream\r\n  [2]: https://github.com/google/syzkaller/blob/master/docs/syzbot_ai_patches.md\n\n**Attachments:**\n- [[LPC'26] Automating Kernel Bug Fixes_ Syzbot's AI-Assisted Patch Workflow.pdf](https://lpc.events/event/20/contributions/2597/attachments/2076/4638/%5BLPC'26%5D%20Automating%20Kernel%20Bug%20Fixes_%20Syzbot's%20AI-Assisted%20Patching%20Workflow.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2597/)", "url": "https://lpc.events/event/20/contributions/2597/", "persons": [{"public_name": "Aleksandr Nogikh"}]}, {"guid": "lpc20-c3831", "id": "lpc20-c3831", "title": "Boro: Do We Need More AI-assisted Kernel Tooling?", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "AI-assisted tooling is increasingly becoming part of Linux kernel development workflows, particularly for patch review and feedback generation. Sashiko has become the de facto standard for reviewing publicly posted patch series on mailing lists.\r\n\r\nWhile Sashiko can also be used beyond the mailing-list workflow, its design is primarily optimized around upstream review interactions. This can result in a less natural fit when it's applied to more iterative or downstream-focused development workflows. In particular, it's not specifically designed for reviewing backported patch series locally or tracking upstream follow-ups related to those changes (e.g., distro kernel maintenance, applying security fixes, etc.).\r\n\r\nThese gaps motivated the development of Boro (https://github.com/NVIDIA/boro), an AI-assisted kernel development tool designed for local-first, interactive usage, focused on improving review and testing iterations before public submission, and supporting downstream workflows such as backporting and distribution kernel development.\r\n\r\nThis talk will present Boro's design and open a discussion on whether some of its functionality could be integrated into Sashiko.\n\n**Attachments:**\n- [Boro_ Do We Need More AI-assisted Kernel Tooling_.pdf](https://lpc.events/event/20/contributions/2599/attachments/2024/4558/Boro_%20Do%20We%20Need%20More%20AI-assisted%20Kernel%20Tooling_.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2599/)", "url": "https://lpc.events/event/20/contributions/2599/", "persons": [{"public_name": "Andrea Righi"}]}, {"guid": "lpc20-c3832", "id": "lpc20-c3832", "title": "Automated kernel CVE backports", "date": "2026-10-06T12:15:00+02:00", "start": "12:15", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Problem: CVEs\r\n- CVEs: Common Vulnerabilities and Exposures\r\n- February 2024, Linux kernel project becomes the Linux kernel CVE Numbering Authority (CNA)\r\n- The number of Linux kernel CVEs skyrockets\r\n- Red Hat customers expect CVE fixes/mitigations, with some having Service Level Agreements for delivery within X number of days, depending on severity\r\n- Red Hat did not get an increase in kernel developers commensurate with the increase in kernel CVEs\r\n\r\nThe Solution: Automation\r\n- Don’t manually do things that can be done by robots! (*)\r\n- Assignment of the work to the right team\r\n- Identification of the patch fixing the CVE\r\n- Backport of the fix (possibly with AI coding assistance)\r\n- Submission of a merge request containing the fix\r\n- Validation of the merge request\r\n- Testing of the fix\r\n\r\n(*) This does not necessarily mean AI, but it also does now\n\n**Attachments:**\n- [Red Hat Kernel Backport AI Use.pdf](https://lpc.events/event/20/contributions/2600/attachments/2056/4610/Red%20Hat%20Kernel%20Backport%20AI%20Use.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2600/)", "url": "https://lpc.events/event/20/contributions/2600/", "persons": [{"public_name": "Jarod Wilson"}]}, {"guid": "lpc20-c3833", "id": "lpc20-c3833", "title": "From Findings to Fixes: AI-Assisted Linux Kernel Bug Triage and Remediation", "date": "2026-10-06T12:30:00+02:00", "start": "12:30", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Kernel maintainers increasingly receive bug findings from fuzzers and AI-assisted tools. While these tools expand bug-finding coverage, they also create a growing triage burden. The quality of both bug reports and patches can vary substantially: findings may be false positives, lack a usable reproducer, duplicate existing issues, or come with patches that are incomplete or incorrect.
\r\n\r\nWe are developing Vega, a continuous Linux kernel bug discovery and triage system inspired by syzbot. Vega aggregates findings from multiple sources and gives maintainers a view of bugs affecting their subsystems. For each finding, it attempts to generate and execute a proof of concept, helping filter false positives and turn plausible findings into reproducible bugs. For confirmed bugs, Vega further analyzes impact and severity and can generate a draft patch as a remediation reference.
\r\n\r\nWe would like to share our experience triaging over 1,000 Linux kernel bugs and discuss a practical question: which bugs are actually worth fixing? AI-assisted tools can surface many real but obscure corner cases, making it increasingly important to distinguish technically real bugs from bugs that warrant engineering attention.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2601/)", "url": "https://lpc.events/event/20/contributions/2601/", "persons": [{"public_name": "Yuan Tan"}]}, {"guid": "lpc20-c3828", "id": "lpc20-c3828", "title": "Open discussion: using fix generation effectively", "date": "2026-10-06T12:45:00+02:00", "start": "12:45", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Open discussion led by Josef with the audience on using AI fix generation effectively.\r\n\r\nRelated talks: #447 Aleksandr Nogikh; #482 Yuan Tan; #315 Jarod Wilson\n\n[Open in Indico](https://lpc.events/event/20/contributions/2647/)", "url": "https://lpc.events/event/20/contributions/2647/", "persons": [{"public_name": "Josef Bacik"}]}, {"guid": "lpc20-c3834", "id": "lpc20-c3834", "title": "Talk to Your Crash Dumps: Debugging a Real-Time Kernel Stall with drgn and AI", "date": "2026-10-06T13:00:00+02:00", "start": "13:00", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Analyzing kernel crash dumps with drgn is powerful but demands fluency in drgn's Python API, kernel data structure layouts, and the right helper functions for each subsystem. drgn-mcp is an MCP (Model Context Protocol) server that exposes drgn's debugging capabilities as structured tools that AI assistants can call, enabling kernel developers to investigate crash dumps through natural language instead of scripting.\r\n\r\nThis talk is a live demo of a real-world investigation. I will use drgn-mcp to analyze a vmcore from a production RT kernel hang where rtmutex contention leads to a system-wide stall. This is a real customer bug affecting RHEL RT kernels. Starting from the vmcore with no prior analysis, I will walk through the entire investigation interactively, driven by natural language, with the LLM choosing which drgn tools to invoke to uncover the root cause live on stage.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2598/)", "url": "https://lpc.events/event/20/contributions/2598/", "persons": [{"public_name": "Wander Costa"}]}, {"guid": "lpc20-c3829", "id": "lpc20-c3829", "title": "Wrap-up", "date": "2026-10-06T13:15:00+02:00", "start": "13:15", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: AI-Assisted Open Source Development MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Session wrap-up and next steps.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2648/)", "url": "https://lpc.events/event/20/contributions/2648/", "persons": [{"public_name": "Josef Bacik"}]}, {"guid": "lpc20-c3718", "id": "lpc20-c3718", "title": "LUO support in systemd", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "systemd v261 added native support for LUO. System services, user services and nspawn containers can preserve data across kexec in a simple and transparent manner, using the existing File Descriptor Store API.\r\n\r\nThis talk will explore what is implemented and how to use it, and what are the next steps.\n\n**Attachments:**\n- [[LPC_2026] LUO support in systemd.pdf](https://lpc.events/event/20/contributions/2609/attachments/2034/4573/%5BLPC_2026%5D%20LUO%20support%20in%20systemd.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2609/)", "url": "https://lpc.events/event/20/contributions/2609/", "persons": [{"public_name": "Luca Boccassi"}]}, {"guid": "lpc20-c3719", "id": "lpc20-c3719", "title": "Resolving Complex FD Dependencies for Live Update", "date": "2026-10-06T15:15:00+02:00", "start": "15:15", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Preserving subsystem state across a live update introduces a complex challenge: managing the dependencies of File Descriptors. Interconnected subsystems—such as VFIO and IOMMUFD with a lot of shared state, IOMMUFD's dependency on memory providers memfd/guest_memfd or KVMfd/guest_memfd dependency requires preservation ordering to guarantee state immutability and performance.\r\n\r\nCurrently, the burden of orchestrating this dependency falls on userspace (VMMs), which must navigate complex API contracts, which will become much more complex with circular dependencies between subsystems down the road.\r\n\r\nThis session talks about FD dependencies with examples and it proposes a unified, kernel-driven dependency resolution architecture that is handled by Live Update Orchestrator by introducing some extensions.\r\n\r\nLooking forward to your feedback on this.\n\n**Attachments:**\n- [Live Update File Handler Dependency.pdf](https://lpc.events/event/20/contributions/2617/attachments/2075/4637/Live%20Update%20File%20Handler%20Dependency.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2617/)", "url": "https://lpc.events/event/20/contributions/2617/", "persons": [{"public_name": "Samiullah Khawaja"}]}, {"guid": "lpc20-c3720", "id": "lpc20-c3720", "title": "Extending Memory State Preservation Across Warm Reboots Using KHO/LUO/memfd", "date": "2026-10-06T15:30:00+02:00", "start": "15:30", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "**Motivation:**\r\n\r\nKexec Hand-Over (KHO) helps minimize downtime during kernel updates by preserving state across the kexec reboot. However, there are some scenarios which need a deeper form of reboot to be effective -- for example, performing a firmware update or a device-tree refresh, or even to avoid known hardware/platform bugs that make the kexec path itself unreliable. In such cases, the kernel's \"warm reboot\" facility could be leveraged, which performs a full reboot (Firmware + Bootloader + OS/kernel init), but with the guarantee that this entire flow leaves DRAM contents intact (distinct from a \"cold reboot\", where DRAM is also cleared). We would like to extend KHO (and its memory state preservation feature via LUO & memfd, in particular) to also work across warm reboots, so as to minimize downtime during update scenarios that necessitate a warm reboot.\r\n\r\n\r\n**Key Challenges:**\r\n\r\nWhen trying to extend KHO/LUO/memfd to warm reboots, we ran into 2 key technical challenges, described below. We were able to solve the first one (supported by a working prototype), but we need the community's insights & feedback to help solve the second challenge (our proposed solution approaches are outlined below).\r\n\r\n\r\n**Challenge 1: Discovering preserved KHO state in the next kernel (without passing an FDT)**\r\n\r\nDuring a kexec, the handover from the first kernel to the second one is explicit -- by passing an FDT with info embedded as to where to find the preserved KHO state in memory. However, in the case of a warm reboot, there is no opportunity for the first kernel to do a similar hand-off, and yet, the second kernel should be able to discover where the KHO state was preserved, in order to restore it.\r\n\r\nWe solved this problem by using a classic Computer Science technique -- i.e., by adding a level of indirection :-). While the KHO state can be allocated & preserved anywhere in memory, the KHO metadata info is kept in a small header and it is passed to the next kernel. On UEFI platforms an EFI variable can be used for this purpose, whereas on DT based platforms, the header can be kept in a pre-determined location, and a DT node added to inform the kernel about it. This retains the KHO allocation flexibility. We also added checksums to verify the integrity of the preserved metadata to make this mechanism robust against stale/circumstantial data left in that fixed location.\r\n \r\n\r\n**Challenge 2: Preventing firmware from clobbering preserved KHO state across a warm reboot**\r\n\r\nThe warm reboot flow includes all the usual init sequence across components like firmware and bootloader, leading up to launching the Linux kernel. The memory used by these components before Linux is launched can be termed as \"FW-Transient\", as they are only needed during that transition period. One common optimization technique used on memory-constrained systems is to allow firmware to temporarily re-use the same memory region that Linux has access to, but only when the kernel isn't running. Thus, FW-Transient memory during a warm reboot transition intentionally overlaps with Linux's usable memory, to avoid wasted permanent memory carveouts for firmware's temporary use. However, this introduces a problem for KHO, where the firmware can trample on memory regions that the kernel expects to pass unmodified to the next kernel across a warm reboot.\r\n\r\nDelving deeper into the platform/firmware constraints around the use of FW-Transient memory, we found that while the memory maps vary widely between platforms, they do remain fixed (pre-determined at design time) for a given platform. This implies that while we can't move FW-Transient memory to cooperate with KHO, KHO can instead discover the boundaries of this region to avoid saving state-to-be-preserved in that region. But the exact mechanism for how to demarcate and export that FW-Transient region info from the firmware to the kernel across a variety of platforms (UEFI vs DT) remains an open question.\r\n\r\nUsing this insight, we have 2 solution approaches that we would like to propose to solve this challenge. The first one is to influence the sizing and placement of the kho-scratch region such that it fully overlaps with FW-Transient memory. If feasible, this would be an elegant solution because KHO won't have to do anything else to prevent firmware from clobbering its preserved state, as the kho-scratch region is meant for non-preserved allocations -- by definition. However, if there are any memory-management constraints that prevent kho-scratch placement in this way, we could also explore migrating preserved KHO state out of the FW-Transient region just before the first kernel's shutdown. This latter approach has its own potential pitfalls, such as difficulties in maintaining KHO state integrity post page migration and the cost of migrating pages in a performance sensitive path (i.e., the need for fast reboot to minimize downtime).\r\n\r\nWe would like to present these challenges and solution approaches and brainstorm with the Linux kernel, Firmware, and Bootloader communities at LPC on the best approach to solve this problem to enable KHO across warm reboots.\n\n**Attachments:**\n- [Extending Memory State Preservation Across Warm Reboots Using KHO LUO memfd - LPC 2026.pdf](https://lpc.events/event/20/contributions/2614/attachments/2090/4655/Extending%20Memory%20State%20Preservation%20Across%20Warm%20Reboots%20Using%20KHO%20LUO%20memfd%20-%20LPC%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2614/)", "url": "https://lpc.events/event/20/contributions/2614/", "persons": [{"public_name": "Prasanna Kumar T S M"}, {"public_name": "Srivatsa Bhat"}]}, {"guid": "lpc20-c3721", "id": "lpc20-c3721", "title": "Live Update Compatibility", "date": "2026-10-06T15:50:00+02:00", "start": "15:50", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Data that is serialized and preserved through a live update may have formatting differences between two kernels. This can affect the compatibility between two kernels when trying to perform a Live Update. Current efforts have been to use compatibility strings with implicit version numbers, like \"memfd-v2\" to help provide compatibility data. Changes to the formatting of the preserved data may not affect the compatibility if the new kernel understands the format of the old version. For example, an optional feature may be available on a new kernel that is not strictly needed. If the old kernel does not support that feature and the new kernel does, we still want to allow a Live Update between these versions.\r\n\r\nThis discussion is for a proposed method of serializing all supported versions of a component and having the new kernel negotiate the version to deserialize. The current proposal uses file handlers as the first user of this scheme, but this will apply to any component that needs to preserve and restore serialized data.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2613/)", "url": "https://lpc.events/event/20/contributions/2613/", "persons": [{"public_name": "Logan Odell"}, {"public_name": "Pratyush Yadav"}]}, {"guid": "lpc20-c3722", "id": "lpc20-c3722", "title": "Guest_Memfd Preservation For Live Update", "date": "2026-10-06T16:10:00+02:00", "start": "16:10", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Guest_memfd is a specialized, guest-first memory subsystem within the Linux kernel, specifically designed for KVM. It provides an isolated file-descriptor-based approach to managing Virtual Machine memory.\r\n\r\nFor this MC, I want to propose the topic on Preservation of guest_memfd with LUO.\r\n\r\nI will discuss the current development on guest_memfd preservation during kernel Liveupdate and (If time permits) future topics like supporting preservation for guest_memfd with private memory.\r\nLink to patches: [Here][1]\r\n\r\n\r\n  [1]: https://lore.kernel.org/all/20260728121138.1103610-1-tarunsahu@google.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2610/)", "url": "https://lpc.events/event/20/contributions/2610/", "persons": [{"public_name": "Tarun Sahu"}]}, {"guid": "lpc20-c3723", "id": "lpc20-c3723", "title": "Performance improvements for live-update reboots", "date": "2026-10-06T17:00:00+02:00", "start": "17:00", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Many use-cases of live-update require it to be fast. For cloud providers, executing host kernel updates without impacting guest workloads demands low-downtime live-update reboots.\r\n\r\nWe will discuss what improvements were already done to the Linux kernel, the ongoing work and future plans. This talk will also explain to developers how to configure their systems to achieve the best reboot performance.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2611/)", "url": "https://lpc.events/event/20/contributions/2611/", "persons": [{"public_name": "Michał Cłapiński"}]}, {"guid": "lpc20-c3724", "id": "lpc20-c3724", "title": "Preserving tmpfs Files Across Live Update", "date": "2026-10-06T17:15:00+02:00", "start": "17:15", "duration": "00:15", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Live Update Orchestrator (LUO) can preserve memfds across kexec. But a memfd has no path, so it can't replace a file on tmpfs, such as VMM binaries on hosts without local storage. Preserving a tmpfs file's contents is easy. Retrieving it is hard: LUO always returns a new anonymous file, with no way to give it a mount, path or mount options.\r\n\r\nThis talk compares three proposals:\r\n\r\n1. RETRIEVE_INTO_FD: userspace recreates the mount and directories, and the kernel fills an empty file.\r\n2. tmpfs mount and file handlers: the kernel preserves and recreates the mount and the files in its root directory.\r\n3. Retrieve as memfd, then move: retrieve a memfd and move its folios into tmpfs with an extended splice(SPLICE_F_MOVE).\r\n\r\n\r\nWe weigh the new uAPI, ABI and kernel code each one needs against what it supports. The goal is to agree on a direction for upstream.\n\n**Attachments:**\n- [Preserving tmpfs Files Across Live Update (LPC 2026).pdf](https://lpc.events/event/20/contributions/2618/attachments/2028/4566/Preserving%20tmpfs%20Files%20Across%20Live%20Update%20(LPC%202026).pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2618/)", "url": "https://lpc.events/event/20/contributions/2618/", "persons": [{"public_name": "David Matlack"}]}, {"guid": "lpc20-c3725", "id": "lpc20-c3725", "title": "Live Update IOMMU (vIOMMU with Arm SMMUv3)", "date": "2026-10-06T17:30:00+02:00", "start": "17:30", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "<br>The current IOMMU Live Update framework establishes the mechanism for preserving IOMMU hardware state and translation units (HWPTs) across a live update. By utilizing the IOMMUFD and Kernel Handover (KHO) framework. This session talks about the current state of Liveupdate IOMMU and the upcoming features, challenges and enhancements.\r\n<br>The session dives deeper into the design challenges for enabling vIOMMU preservation to allow preserving the nested translation state, specifically guest-owned Stage 1 tables and metadata, with a focus on the ARM SMMUv3 nested translation architecture. We explore strategies for preservation, restoration, and lifecycle management of nested translation structures and associated metadata to ensure that the incoming kernel can resume Stage 1 + Stage 2 translation without guest-side disruption.\r\n<br>Looking forward to your feedback and participation.\n\n**Attachments:**\n- [Live Update IOMMU_ Arm SMMUv3_latest.pdf](https://lpc.events/event/20/contributions/2612/attachments/2077/4639/Live%20Update%20IOMMU_%20Arm%20SMMUv3_latest.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2612/)", "url": "https://lpc.events/event/20/contributions/2612/", "persons": [{"public_name": "Samiullah Khawaja"}, {"public_name": "Pranjal Shrivastava"}]}, {"guid": "lpc20-c3726", "id": "lpc20-c3726", "title": "VFIO Live Update Road to Continuous DMA", "date": "2026-10-06T17:50:00+02:00", "start": "17:50", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Live Update enables hypervisor updates with minimal guest downtime by preserving VM state across `kexec`. While memory preservation (via KHO/LUO) covers VM RAM, pass-through PCIe devices assigned to VMs (e.g., GPUs, NICs, NVMe, accelerators) require kernel support to maintain device state across the reboot boundary.\r\n\r\nThis talk presents the design of VFIO Live Update (Phase 1, recently posted in v5 [1]) and our roadmap toward continuous DMA [2]. Phase 1 establishes base support for preserving VFIO `cdev` device file descriptors across `kexec` using the Live Update Orchestrator (LUO) and Kexec Handover (KHO).\r\n\r\nWe will discuss:\r\n\r\n1. **Architecture & Current Phase**: How VFIO `cdev` device FDs are preserved across `kexec`, enforced retrieval through `LIVEUPDATE_SESSION_RETRIEVE_FD`, and safe quiescing/reset in `freeze()` in Phase 1.\r\n2. **Failure Handling & Recovery**: How VFIO devices handle failures if a Live Update session is cancelled before `kexec` (unfreezing/unpreserving) or fails after `kexec` (cleanup of unretrieved devices).\r\n3. **Subsystem Interactions**: Handoff ordering, dependencies, and recovery semantics between VFIO, PCI core, and IOMMUFD.\r\n4. **The Road to Continuous DMA**: Future phases extending beyond device reset toward preserving running devices with active DMA/interrupts (noiommu -> iommufd -> SR-IOV VFs).\r\n5. **VF and SR-IOV Live Update (Phase 5)**: Unique challenges of preserving Virtual Functions (VFs) when the Physical Function (PF) driver or host PCI core initializes post-`kexec`, and managing PF/VF dependency trees across Live Update.\r\n6. **Testing & Tooling**: How to test active DMA in QEMU environments when DMA-capable physical hardware is absent, and how to simplify/standardize VFIO Live Update selftests for developers and CI.\r\n\r\nWe hope to get community feedback on our approach and align on the future direction of VFIO Live Update.\r\n\r\n---\r\n\r\n### References\r\n* [1] [v5 Patch Series on Lore](https://lore.kernel.org/kvm/20260714151505.3466855-1-vipinsh@google.com)\r\n* [2] [VFIO PCI Live Update Presentation](https://docs.google.com/presentation/d/1XVVL-oeSHp-Y-uBrhRVwz-Bm0lGFdGCKWELR8JamPp4/edit?usp=sharing&resourcekey=0-b7I6ZPRcal0sLhK8woByEw)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2616/)", "url": "https://lpc.events/event/20/contributions/2616/", "persons": [{"public_name": "Vipin Sharma"}]}, {"guid": "lpc20-c3727", "id": "lpc20-c3727", "title": "Challenges in Preserving Virtual Networking State and dmabuf across Kexec Live Updates", "date": "2026-10-06T18:10:00+02:00", "start": "18:10", "duration": "00:20", "room": "Club H (Floor 1)", "track": "LPC: Live Update MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "As cloud infrastructure scales and Confidential Computing adoption increases, host-level Live Update via kexec has become vital for maintaining zero-downtime operations. While progress has been made in preserving guest memory (guest_memfd, hugetlb) and hardware device states (VFIO), a critical gap remains in the network stack: preserving virtual networking topologies and stateful software-defined networking (SDN) backends, as well as high-performance memory buffers like dmabuf and devmem.\r\n\r\nWhen a host undergoes a kexec warm reboot, virtual devices (such as netkit, veth, netkit, bonding) and software transport layers (RXE for Soft-RoCE, SIW for Soft-iWARP) lose their underlying kernel configurations, ring buffer indices, and state machines. Concurrently, zero-copy performance mechanisms like dmabuf and TCP devmem face the challenge of memory lifecycle decoupling—how to safely hand over page references and page tables across the kexec boundary without freeing the buffers or causing in-flight DMA corruption.\r\n\r\nThis interactive session aims to pinpoint the architectural constraints of virtual network state preservation and explore how to extend the Kexec HandOver (KHO) framework or complementary Live Update Orchestrators (LUO) to solve these stateful handover and high-performance memory recycling dilemmas.\n\n**Attachments:**\n- [Challenges_in_Preserving_Virtual_Networking_State_and_dmabuf_across_Kexec_Live_Updates.mp4](https://lpc.events/event/20/contributions/2615/attachments/2048/4596/Challenges_in_Preserving_Virtual_Networking_State_and_dmabuf_across_Kexec_Live_Updates.mp4)\n- [Challenges in Preserving Virtual Networking State and dmabuf across Kexec Live Updates(Video)](https://lpc.events/event/20/contributions/2615/attachments/2048/4595/go)\n- [LPC_2026_Challenges_dmabuf.pdf](https://lpc.events/event/20/contributions/2615/attachments/2048/4594/LPC_2026_Challenges_dmabuf.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2615/)", "url": "https://lpc.events/event/20/contributions/2615/", "persons": [{"public_name": "yanjun zhu"}]}], "Conference Hall (Floor 4)": [{"guid": "oss-fee200f7b2ce0105fb5cedc565a96319", "id": "oss-fee200f7b2ce0105fb5cedc565a96319", "title": "Project Jupyter Mini Summit [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "03:30", "room": "Conference Hall (Floor 4)", "track": "OSS: Project Mini-summits", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Join us for the Jupyter Mini Summit at Open Source Summit Europe, where we’ll bring together contributors, users, and community members to connect, collaborate, and share ideas. This gathering is an opportunity to discuss the future of Project Jupyter, highlight ongoing initiatives, and explore ways to strengthen the ecosystem.\n\nHow to Register: Pre-registration is required. To register for Jupyter Mini Summi, add it to your Open Source Summit Europe registration.\n\nAgenda\n\n9:00 - 9:15    \nWelcome and the Jupyter Ecosystem\nSerena Bonaretti\n\n9:15 - 9:45    \nWhat's new in JupyterLab 4.6 and the tooling behind it: prototype, lint, build, test\nMike Krassowski & Darshan Paudyal\n\nJupyterLab 4.6 was one of the largest minor releases with the new features propagating to Jupyter Notebook 7.6 and JupyterLite 0.8. This session will first highlight a few new features and enhancements, highlighting what those mean for users and extension authors, and then turns to the four Jupyter Foundation-funded projects that enabled the higher than before pace: jupyter-builder, @jupyter/eslint-plugin, revamped UI tests, and plugin playground. The tooling and principles behind it are reusable and might be of interest to audience behind the Jupyter ecosystem.\n\n9:45 - 10:15\nJupyterLite's Journey: From Proof of Concept to Massive-Scale Deployments\nJeremy Tuloup\n\nJupyterLite is a Jupyter distribution that runs entirely in the web browser, without any server components. What started five years ago as an experiment officially became part of Project Jupyter this year. This talk takes this milestone as an opportunity to look back at what has been enabled over the past five years, and at what is coming next.\n\nWe will go through concrete examples of JupyterLite used in the wild: the try links on jupyter.org, the interactive examples embedded in the NumPy and SymPy documentation, education platforms where entire school systems can start coding in Python and R in seconds without installing anything, offline and locked-down environments where running a server is not an option, and platforms built on top of JupyterLite such as Jupyter Everywhere and notebook.link. Since only static files need to be served, deployments can scale to a large number of users without complex cloud infrastructure, and we will see how this changes the cost and reach of interactive computing. We will also cover the current limitations of the approach.\n\nFinally, we will give an outlook on ongoing and future developments: support for more languages with R, Octave, and C++, a terminal running commands like grep and vim entirely in the browser, and AI features ranging from in-browser assistants to coding agents running directly in the terminal.\n\n10:15 - 10:45    \nA practical experience report on community management from Jupyter Hub and Jupyter Book\nSerena Bonaretti\n\nCommunity management is a critical part of growing and cultivating a healthy open source project like Jupyter. As Jupyter has grown, it has created multiple sub-projects with their own unique opportunities and challenges for growth. This year, I was hired as the first \"\"Community Manager\"\" for two sub-communities in Jupyter: JupyterHub and Jupyter Book. In this talk, I'll share my experience in the first several months of this role, including the things we have tried, what worked and didn't work, and what we've learned in the process. I'll share the main takeaways and provide suggestions for other communities that are interested in growing community management and where we'd like to focus next within Jupyter Hub and Jupyter Book. The audience should come away with a practical understanding of how Community Management could be used in an open source project like Jupyter, the most important learnings from our experiment, and how they could be applied to other open source projects.\n\n10:45 - 11:05    \nBreak\n\n11:05 - 11:35\nScaling Interactive Computing to the Cloud: A Modular, Open Source Approach\nJonathan Guinegagne\n\nInteractive computing tools like Jupyter notebooks and JupyterLab have transformed how people explore data and build ideas. Running Jupyter on your laptop is easy, but what if you need more compute power - including GPU - more storage or to collaborate in real time with others? This talk shows how an open-source, modular approach makes it possible to deploy and manage your interactive applications on the cloud with no prior expertise. We'll explore increasing levels of complexity: from a single user spinning up Jupyter and VS Code on a remote instance to organizations serving hundreds of users — and the lessons learned along the way. Attendees will leave understanding how to make cloud-hosted interactive computing accessible to their users, with Kubernetes as the enabler rather than the obstacle.\nWho should attend: Anyone who needs more compute in their interactive computing environments, or who...\n\n[Open in Sched](https://osselceu2026.sched.com/event/fee200f7b2ce0105fb5cedc565a96319)", "url": "https://osselceu2026.sched.com/event/fee200f7b2ce0105fb5cedc565a96319", "persons": []}, {"guid": "oss-4bd10f833989730956fe8f7265a1b097", "id": "oss-4bd10f833989730956fe8f7265a1b097", "title": "Civil Infrastructure Platform Mini Summit [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T13:30:00+02:00", "start": "13:30", "duration": "03:30", "room": "Conference Hall (Floor 4)", "track": "OSS: Project Mini-summits", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Join us to learn how the CIP community establishes an open source base layer of industrial grade software to enable the use and implementation of software building blocks for civil infrastructure - like transportation, energy, and industry.\n\nHow to Register: Pre-registration is required. To register for Civil Infrastructure Platform Mini Summit, add it to your Open Source Summit Europe registration.\n\nAgenda\n\n[Open in Sched](https://osselceu2026.sched.com/event/4bd10f833989730956fe8f7265a1b097)", "url": "https://osselceu2026.sched.com/event/4bd10f833989730956fe8f7265a1b097", "persons": []}], "Congress Hall Foyer 0 A (Floor 0)": [{"guid": "oss-0e79d9926c34a5364e5f3a12c236bfbb", "id": "oss-0e79d9926c34a5364e5f3a12c236bfbb", "title": "Registration & Badge Pick-Up", "date": "2026-10-06T07:30:00+02:00", "start": "07:30", "duration": "09:30", "room": "Congress Hall Foyer 0 A (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/0e79d9926c34a5364e5f3a12c236bfbb)", "url": "https://osselceu2026.sched.com/event/0e79d9926c34a5364e5f3a12c236bfbb", "persons": []}], "Congress Hall Foyer 0 B (Floor 0)": [{"guid": "oss-144b0983a9f4fc9dccc2bfc7884ee8d3", "id": "oss-144b0983a9f4fc9dccc2bfc7884ee8d3", "title": "Cloakroom", "date": "2026-10-06T07:30:00+02:00", "start": "07:30", "duration": "12:30", "room": "Congress Hall Foyer 0 B (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/144b0983a9f4fc9dccc2bfc7884ee8d3)", "url": "https://osselceu2026.sched.com/event/144b0983a9f4fc9dccc2bfc7884ee8d3", "persons": []}], "Grand Hotel Prague Towers": [{"guid": "oss-191fc8ed1e362c298b41945c405b9d0e", "id": "oss-191fc8ed1e362c298b41945c405b9d0e", "title": "Yocto Project Developer Day [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "08:00", "room": "Grand Hotel Prague Towers", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "Get ready for Yocto Project Developer Day 2026 in Prague! This one-day presentation and hands-on training day puts you in direct contact with Yocto Project technical experts and developers. Come learn about creating, customizing, and optimizing Linux distributions for embedded devices using the rich features, tools, and content of Yocto Project. You’ll come away with a deeper understanding on topics like build system workflow, embedded security, working with containers, building applications, optimizing images, hardening your devices, and leveraging tools like devtool.\nTo learn more, visit the event website and schedule.\n\n[Open in Sched](https://osselceu2026.sched.com/event/191fc8ed1e362c298b41945c405b9d0e)", "url": "https://osselceu2026.sched.com/event/191fc8ed1e362c298b41945c405b9d0e", "persons": []}], "Panorama Hall (Floor 1)": [{"guid": "oss-2d3e740b5d578a218287936a358b5e85", "id": "oss-2d3e740b5d578a218287936a358b5e85", "title": "The Linux Foundation Member European Forum [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "09:00", "room": "Panorama Hall (Floor 1)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "The Linux Foundation Member European Forum is an annual regional gathering for Linux Foundation European members interested in discussing and shaping how European organisations participate in the global technology commons.\n\nHow to Register: Participation is by invitation only. If you are interested in attending, please submit a request for an invitation. All requests will be reviewed, and you will receive an email notification once a decision has been made.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2d3e740b5d578a218287936a358b5e85)", "url": "https://osselceu2026.sched.com/event/2d3e740b5d578a218287936a358b5e85", "persons": []}], "Room 3.2 (Floor 3)": [{"guid": "oss-74ae7808f28a90f324352fd60e078d85", "id": "oss-74ae7808f28a90f324352fd60e078d85", "title": "AgStack OSS AI Summit [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "03:30", "room": "Room 3.2 (Floor 3)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "Digital trust is becoming the foundation of modern agriculture. Join AgStack, OpenAgri, CIAT, industry, and academic leaders to explore how open source digital public infrastructure, AI, interoperable traceability, and open standards are enabling trusted agricultural supply chains. Discover practical approaches to EUDR compliance, food safety, sustainability, and the development of global standards that can accelerate innovation, responsible trade, and collaboration across the agrifood ecosystem.\n\nHow to Register: Pre-registration is required. To register for AgStack OSS AI Summit, add it to your Open Source Summit Europe registration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/74ae7808f28a90f324352fd60e078d85)", "url": "https://osselceu2026.sched.com/event/74ae7808f28a90f324352fd60e078d85", "persons": []}], "Room 4.3 (Floor 4)": [{"guid": "oss-7b26d97e75ffffef74f7460887d66f1a", "id": "oss-7b26d97e75ffffef74f7460887d66f1a", "title": "Zen Zone", "date": "2026-10-06T08:00:00+02:00", "start": "08:00", "duration": "09:00", "room": "Room 4.3 (Floor 4)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "All attendees may feel free to use the Zen Zone as needed. This is a quiet space for sensory relaxation, meditation, and worship. It is not to be used for conversations or as a workspace.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7b26d97e75ffffef74f7460887d66f1a)", "url": "https://osselceu2026.sched.com/event/7b26d97e75ffffef74f7460887d66f1a", "persons": []}], "Small Hall (Floor 0)": [{"guid": "lpc20-c3491", "id": "lpc20-c3491", "title": "RCU Pseudo-Transactions: Bridging the gap between RCU and STM", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "RCU data structures are notoriously complex to design mainly due to the\r\nneed to carefully manage how mutations are made observable to concurrent\r\nreaders.\r\n\r\nAs a general solution to this problem, I am proposing a novel\r\ntransaction-based synchronisation mechanism: \"RCU Pseudo-Transactions\"\r\n(rcu_txn).\r\n\r\nIt applies both to userspace and kernel. It allows publishing complex\r\ndata structure mutations atomically to RCU readers, and synchronizing\r\nupdates from multiple writers, with minimal overhead on the read-side\r\n(low-bit pointer tag check, predicted branch on rcu_dereference), and no\r\nsize overhead on the data structure nodes. It is composable: an object\r\ncan belong to multiple transaction-aware data structures, and\r\ntransactions allow it to become visible (or hidden) atomically.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2348/)", "url": "https://lpc.events/event/20/contributions/2348/", "persons": [{"public_name": "Mathieu Desnoyers"}]}, {"guid": "lpc20-c3492", "id": "lpc20-c3492", "title": "Checkpoint/Restore for RDMA: Saving and Restoring Live Queue Pairs with CRIU", "date": "2026-10-06T10:45:00+02:00", "start": "10:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "RDMA delivers high-throughput, low-latency networking by bypassing the kernel and letting applications communicate directly with the hardware. CRIU, by contrast, works by freezing running processes and serializing their state so they can be restored later. Bringing the two together is difficult precisely because of what makes RDMA fast: RDMA bypasses the kernel abstractions CRIU would normally use to checkpoint. CRIU already migrates live TCP connections but relies on filesystem attributes and a hook in the socket interface. RDMA is conceptually similar but the interfaces required to save/restore look very different. Our work aims to close this gap with an approach we demonstrate on NVIDIA ConnectX and BlueField devices using existing SRIOV VF migration support, as well as on RXE/Soft-RoCE. In both cases the RDMA connection survives checkpoint/restore intact: when peers are checkpointed together, the connection is never torn down and neither side sees QP errors or forced reconnects.\r\n\r\nThis matters most for machine learning, where RDMA carries communication for large distributed training and inference jobs that are expensive to start and stop. The ability to checkpoint and restore these jobs enables defragmenting a cluster to improve utilization, recovering seamlessly from hardware failures, time-sharing expensive resources between seasonal workloads (for example, inference by day and training by night), and migrating jobs to cheaper resources as availability changes. It also standardizes the save/restore workflow across frameworks, simplifying resource management for infra owners. Crucially, these jobs typically run on bare metal, so virtual machine live migration—the main existing alternative—will not be adopted by many would-be users.\r\n\r\nTo get there, the talk will first propose the concrete kernel interfaces required to support checkpoint/restore for RDMA, and explain how our implementation in CRIU uses them to checkpoint and restore a connection. Then we will then turn to mlx5, which has supported live migrating RDMA connections inside of QEMU VMs for some time. By reusing the same device capabilities and firmware APIs that already power SRIOV VM live migration, we show how realistic machine learning workloads can be checkpointed and restored on Linux using networking hardware available today.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2356/)", "url": "https://lpc.events/event/20/contributions/2356/", "persons": [{"public_name": "Raphael Norwitz"}]}, {"guid": "lpc20-c3494", "id": "lpc20-c3494", "title": "Improving kernel  test coverage using stress-ng", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The Linux kernel is constantly growing and evolving; unfortunately, corner-case regressions can creep into code in every release. Gcov test coverage can find infrequently used code paths that may contain issues. This presentation discusses how such techniques are used to improve kernel testing with stress-ng and the challenges in reaching full test coverage.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2358/)", "url": "https://lpc.events/event/20/contributions/2358/", "persons": [{"public_name": "Colin King"}]}, {"guid": "lpc20-c3495", "id": "lpc20-c3495", "title": "Rust SPDM in the Kernel", "date": "2026-10-06T12:45:00+02:00", "start": "12:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "[Security Protocols and Data Models (SPDM)](https://www.dmtf.org/standards/spdm) is used for authentication, attestation and key exchange. SPDM is generally used over a range of  transports, such as PCIe, MCTP/SMBus/I3C, ATA, SCSI, NVMe or TCP.\r\n\r\nFrom the kernels perspective SPDM is used to authenticate and attest devices.  In this threat model a device is considered untrusted until it can be verified  by the kernel and userspace using SPDM. As such SPDM data is untrusted data that is possibly from a mallicious device. The SPDM specification is also complex, with the 1.2.1 spec being almost 200  pages and the 1.3.0 spec being almost 250 pages long.\r\n\r\nAs such we have the kernel parsing untrusted responses from a complex specification, which sounds like a possible exploit vector. This is the type of place where Rust excels!\r\n\r\nOver the last few years there has been gradual momentum building for SPDM support in the kernel and an implementation written in Rust. This implementation is in charge of authenticating and attesting untrusted and potentially malicious devices in the kernel using Rust code. The kernel also needs to allow userspace to apply security policies and allow remote verifiers to verify the running system, even with a possible malicious kernel.\r\n\r\nThis talk is going to cover the current status of the SPDM Rust implementation, how and why we got here and then discuss next steps for getting it merged into mainline.\r\n\r\nIt's not even over once SPDM is supported in the kernel though, as there are a range of more complex features that need to be supported. We can also talk about future features and what they might look like, ensuring we don't step on any PCI TSM feet.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2359/)", "url": "https://lpc.events/event/20/contributions/2359/", "persons": [{"public_name": "Alistair Francis"}]}, {"guid": "lpc20-c3497", "id": "lpc20-c3497", "title": "Virtio-GPU for Automotive: Implementing Libkrun + Vhost-User.", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Automotive hardware architectures are consolidating standalone Electronic Control Units (ECUs) into centralized compute platforms. A major challenge in this architecture is safely and efficiently sharing a single GPU across multiple isolated virtual machines. For example, systems must run critical instrument clusters, infotainment setups, and ADAS pipelines simultaneously without risking cross-domain interference.\r\n\r\nThis presentation tackles this challenge by introducing an architecture that combines libkrun, a process-based KVM virtualization library, with the vhost-user protocol to split device emulation into separate processes. By executing the virtio-gpu backend independently via virglrenderer, this approach achieves fault isolation, zero-copy transfers, and a reduced attack surface compared with traditional Type-1 hypervisors. We have implemented headless GPU compute acceleration, verified using AMD Radeon graphics via virgl, allowing offscreen rendering and ADAS sensor preprocessing. We have also implemented software scanout display output using the gfxstream backend, with DMABUF zero-copy scanout for virglrenderer in progress.\r\n\r\nHowever, productizing this architecture has revealed concrete specification gaps, where the virtio-gpu specification and Linux kernel implementation diverge. During our ongoing implementation of display output paths, such as UPDATE and cursor paths, we encountered some blockers where the written specification and the kernel driver handle headless state and display configurations differently.\r\n\r\nThis talk focuses on two concrete topics from our implementation experience:\r\n\r\n1. Spec vs. Kernel Reality on Headless Operation: The Virtio-GPU Spec (v1.4 §5.7.4) requires a minimum of 1 scanout, yet the Linux kernel (virtgpu_kms.c) gracefully accepts and handles 0. We will discuss how to reconcile the specification to natively support headless, compute-only automotive workloads without forcing VMMs to waste resources on dummy display allocations.\r\n2. Display Output & Device Infrastructure in libkrun: We will present the two GPU display scanout paths we are implementing: Software scanout via gfxstream (pixel copy in message payload) and DMABUF zero-copy scanout via virglrenderer and also covering their tradeoffs in latency, memory usage, and backend compatibility. We will discuss how implementing GPU display support required adding generic SHMEM region mapping and BACKEND_REQ protocol features to libkrun's vhost-user framework, and how this infrastructure then enabled support for other vhost-user devices like virtio-media (camera/decoder passthrough) with minimal additional effort.\r\n\r\nEventually, we want to engage kernel maintainers, virtio specification editors, and VMM developers to discuss how the specification and its implementation can be improved to build a way forward for automotive virtualized graphics.\r\n\r\nSession Timeline & Core Discussion Points (45 Minutes)\r\n\r\n* Architecture & Status (10 mins): High-level overview of the libkrun + vhost-user-gpu stack, where it stands relative to Type-1 hypervisors, and a status update on PR #717 (working headless compute vs. pending display paths).\r\n* Spec vs. Kernel: num_scanouts Divergence (20 mins): Open discussion on the conflict where the kernel accepts num_scanouts == 0 while the spec forbids it. Questions: Should the spec be amended to support headless operation? Should the kernel enforce spec compliance? When spec and implementation conflict, which is authoritative? What are the implications for VMM developers and automotive use cases?\r\n* Display Output & Device Infrastructure in libkrun (10 mins): The two GPU scanout paths: Software scanout (gfxstream, full-frame pixel copy) vs DMABUF zero-copy (virglrenderer, FD passing via SCM_RIGHTS), their tradeoffs and current status. How implementing GPU display required adding generic SHMEM region and BACKEND_REQ protocol support to libkrun, which then enabled vhost-user support for virtio-media with minimal additional work.\r\n* Q&A and Upstream Planning (5 mins)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2349/)", "url": "https://lpc.events/event/20/contributions/2349/", "persons": [{"public_name": "Dorinda Bassey"}]}, {"guid": "lpc20-c3498", "id": "lpc20-c3498", "title": "The State of the Kconfig Ecosystem", "date": "2026-10-06T15:45:00+02:00", "start": "15:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "**Part 1: Tooling**\r\nResearchers continue to be fascinated by the Linux kernel’s usage of Kconfig, and academic papers have been regularly published on it for almost 20 years now. And with these papers often comes tools. Some examples include detecting dead configuration options, unmet dependency bugs, and generating config files that compile affected lines of C code from patches, among many others. We take a look at which tools are still being maintained post-publication, and discuss interesting tools that have since been abandoned. Can they be picked up by the open source community? And what kind of tooling is still missing?\r\n\r\n**Part 2: The Many Implementations of Kconfig**\r\nKconfig, a language originally introduced for use in the Linux build system, has grown to over 200,000 lines of usage in Linux itself, and has been adopted by many other open source projects, like coreboot, BusyBox, Zephyr, and more. However, Kconfig does not have a specification like other languages, and is implemented differently in each of these projects that uses it. We take a look at how these implementations differ, and discuss the feasibility of a unified spec and implementation.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2357/)", "url": "https://lpc.events/event/20/contributions/2357/", "persons": [{"public_name": "Julian Braha"}]}, {"guid": "lpc20-c3499", "id": "lpc20-c3499", "title": "Devicetree-ACPI hybrid mode", "date": "2026-10-06T17:00:00+02:00", "start": "17:00", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Currently when booting in Devicetree mode the kernel will fully disable the ACPI subsystem. On WoA Snapdragon laptops where the factory Windows OS actually boots using the ACPI tables this is not necessarily desirable.\r\n\r\nThe purpose of this session is to present and discuss a proposal for a new DT-ACPI hybrid mode, in which while booting with Devicetree:\r\n\r\n1. The ACPI tables are still parsed and ACPI fwnodes are made available for device-drivers to use for (extra) information.\r\n\r\n2. Some devices may even be fully enumerated through ACPI e.g. enumerate I2C clients through ACPI for an I2C controller which itself is described in DT.\r\n\r\n3. Going futher: use ACPI GPIO-IRQ event handlers + I2C opregion support to let ACPI handle a laptops embedded controller connected over I2C and using the ACPI battery device (backed by the EC) to expose battery state information in a laptop-model agnostic way like how laptop batteries are handled on x86 laptops.\r\n\r\nNote on current laptops Linux cannot boot using ACPI due to some information missing from the ACPI tables. People are working on changing this so that for future WoA Snapdragon laptops Linux can boot using ACPI only without requiring Devicetree.\r\n\r\nAn early [RFC patch-series][1] implementing 1. + 2. has been posted upstream.\r\n\r\n  [1]: https://lore.kernel.org/linux-acpi/20260623145225.143218-1-johannes.goede@oss.qualcomm.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2363/)", "url": "https://lpc.events/event/20/contributions/2363/", "persons": [{"public_name": "Hans de Goede"}]}, {"guid": "lpc20-c3548", "id": "lpc20-c3548", "title": "Camera & ISP BoF", "date": "2026-10-06T17:45:00+02:00", "start": "17:45", "duration": "00:45", "room": "Small Hall (Floor 0)", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "While cameras have been ubiquitous in Linux systems for more than a decade, vendors have historically been very reluctant to disclose any information about Image Signal Processors (ISP), leading to the proliferation of out-of-tree kernel drivers and closed-source userspace stacks. The situation started to change with the launch of the libcamera project at the end of 2018, and progress has accelerated over the past couple of years with more and more vendors jumping on board. Even Qualcomm recently posted an initial [ISP driver][1] in a timid but very real first step, a move that was unthinkable just a couple of years ago.\r\n\r\nThere is plenty of work left to do, as the increased interest from vendors lays bare the lack of investment of the previous decade that leaves many technical issues unsolved. This BoF brings representatives of kernel subsystems (mainly V4L2, but also DRM), userspace frameworks (libcamera, GStreamer, PipeWire, ...), image sensor vendors and ISP vendors in the same room to discuss and solve open issues.\r\n\r\n# Discussion Topics\r\n\r\nTwo discussion topics have been scheduled for the BoF. Additional topics may be discussed if time permits.\r\n\r\n## RGB-IR Support in V4L2 and libcamera\r\n\r\nby Rishikesh Donadkar and Devarsh Thakkar, Texas Instruments\r\n\r\nThe Linux kernel V4L2 API does not support RGB-IR image sensors. While building blocks necessary to handle those devices are slowly being merged, RGB-IR support itself hasn't been tackled yet.\r\n\r\nRishikesh has posted an [API RFC][2]. Along with Devarsh, he will also present this topic at the [OSS Europe conference][3].\r\n\r\n## Camera Module Identification\r\n\r\nby Stefan Klug, Ideas on Board\r\n\r\nCamera tuning and calibration depend not only on the image sensor, but also on the lens and other characteristics of camera modules. While Linux supports identifying image sensors, it completely lacks the concept of camera modules.\r\n\r\nIdentification of camera modules requires coordination between platform firmware (DT or ACPI), the kernel and userspace. Discussions will benefit from the presence of DT maintainers.\r\n\r\nStefan has detailed the issue and started a [public dicussion on the linux-media mailing list][4].\r\n\r\n# Additional Topics\r\n\r\nThe following additional topic has been proposed.\r\n\r\n## Advanced Camera Use Cases\r\n\r\nGjorgji Rosikopulos proposed discussing [advanced camera use cases][5] found in proprietary camera stacks that lack upstream kernel and userspace support.\r\n\r\n[1]: https://lore.kernel.org/linux-media/20260323125824.211615-1-loic.poulain@oss.qualcomm.com/T/#m6c84ea571355ef41f3dbe203bbb1ffb652932f76\r\n[2]: https://lore.kernel.org/linux-media/20260925133001.2780868-1-r-donadkar@ti.com/\r\n[3]: https://osselceu2026.sched.com/event/2RaZj/enabling-multi-stream-camera-sensors-in-linux-rgb+ir-streams-and-embedded-metadata-rishikesh-donadkar-devarsh-thakkar-texas-instruments\r\n[4]: https://lore.kernel.org/linux-media/20261001210838.GR944070@killaraus.ideasonboard.com/T/#m30bab686ffb74d19a28ffcc51600a7726183ed0b\r\n[5]: https://lists.libcamera.org/pipermail/libcamera-devel/2026-September/062157.html\n\n[Open in Indico](https://lpc.events/event/20/contributions/2364/)", "url": "https://lpc.events/event/20/contributions/2364/", "persons": [{"public_name": "Laurent Pinchart"}]}], "Small Theater (Floor 0)": [{"guid": "lpc20-c3760", "id": "lpc20-c3760", "title": "Probe events with typecast using BTF", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "BTF fetcharg has been introduced since v6.5 for fprobe and kprobe events for fetching function parameters by name, and now we intrdouced typecast feature for BTF. This typecast feature is not only casting type, but also, the series supports nested typecasts, container_of(), this_cpu_ptr(), and \"current\" task structure access. With these features, we can access more context local data from dynamic trace events.\r\nI  would like to show how you can use these features and discuss what features we can provide with BTF, what limitations we have now etc.\n\n**Attachments:**\n- [Probe events with typecast using BTF.pdf](https://lpc.events/event/20/contributions/2514/attachments/1987/4505/Probe%20events%20with%20typecast%20using%20BTF.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2514/)", "url": "https://lpc.events/event/20/contributions/2514/", "persons": [{"public_name": "Masami Hiramatsu"}]}, {"guid": "lpc20-c3761", "id": "lpc20-c3761", "title": "Build ID + offset sampling in perf events", "date": "2026-10-06T10:22:00+02:00", "start": "10:22", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Performance event sampling traditionally captures virtual addresses, resolving them to file offsets and symbols post-facto via mmap metadata. Conversely, BPF enables a direct approach: recording the file's build ID and offset within the sample itself. While virtual addresses are smaller inline, the required mmap event stream may lead to much larger raw data files.\r\n\r\nIn this talk, we examine this new sampling method and its implementation trade-offs. The goal is to gather feedback to land the pending patchset and explore hybrid sampling schemes that selectively combine both approaches to achieve the smallest possible footprint.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2511/)", "url": "https://lpc.events/event/20/contributions/2511/", "persons": [{"public_name": "Ian Rogers"}]}, {"guid": "lpc20-c3762", "id": "lpc20-c3762", "title": "Developing Next Generation Perf Tools With Python", "date": "2026-10-06T10:44:00+02:00", "start": "10:44", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Traditionally, the Linux perf tool has relied on a text user interface (TUI) based on libslang and embedded Python/Perl interpreters for scripting support. However, developing robust user interfaces in C is tedious and error-prone, and using perf itself as the interpreter integrates poorly with broader programming language ecosystems.\r\n\r\nIn this talk, we will describe how we refactored perf into a set of libraries, enabling it to be imported and used directly as a native Python module. Building on this foundation, we will showcase new tools featuring rich, interactive console UIs, culminating in a console-based flame graph analysis tool. This modular library approach dramatically accelerates tool development, paving the way for a more agile and extensible Linux performance tooling ecosystem.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2510/)", "url": "https://lpc.events/event/20/contributions/2510/", "persons": [{"public_name": "Alice Rogers"}, {"public_name": "Ian Rogers"}]}, {"guid": "lpc20-c3763", "id": "lpc20-c3763", "title": "Bridging perf and ftrace: Recording perf in ftrace buffers and perf data to trace.dat conversion", "date": "2026-10-06T11:06:00+02:00", "start": "11:06", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The tracefs system allows for fast flexible tracing of events. Not only is it designed for speed (around 100 nanoseconds per event), it also has a fully functional filtering system and a way to build on events via probes and synthetic events.\r\n\r\nAllowing perf events to be injected into the tracefs ring buffer with these filters can allow for things like seeing how many cache misses happen between schedule switch events. Perf data could be recorded at any event and even filtered based on the value of the event fields.\r\n\r\nThere is a [Proof of Concept][1] patch set that does this but the interface is very poor. This session will be about the best way to create the interface to allow perf events to be injected into tracefs ring buffers.\r\n\r\nThe perf tool is best for statistical profiling and performance analysis, and ftrace/trace-cmd for event timeline visualization. While perf captures comprehensive performance data with minimal overhead, understanding temporal relationships and event sequences remains challenging through its native interfaces. In contrast, KernelShark provides powerful graphical insights but traditionally requires separate trace-cmd recordings. Since perf record already captures tracepoint events alongside other performance metrics, running multiple commands to obtain both statistical and timeline data is redundant in production or embedded environments.\r\n\r\nThis discussion will be about both moving perf events into trace.dat files as well as being able to inject perf events directly into the tracefs ring buffer.\r\n\r\n\r\n  [1]: https://lore.kernel.org/linux-trace-kernel/20251118002950.680329246@kernel.org/\r\n  [2]: https://lore.kernel.org/linux-trace-kernel/20251118002950.680329246@kernel.org/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2509/)", "url": "https://lpc.events/event/20/contributions/2509/", "persons": [{"public_name": "Steven Rostedt"}, {"public_name": "Tanushree Shah"}, {"public_name": "Madhavan Srinivasan"}]}, {"guid": "lpc20-c3608", "id": "lpc20-c3608", "title": "Sharing trace infrastructure between in-tree and OOT tracers", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The current situation regarding LTTng vs upstream Linux:\r\n\r\n1) There are maintainers who push for everything to be in tree\r\n2) There are maintainers who are proponents for no-GPL-export when there are no in-tree users\r\n3) Most of the tracer common facilities are used by tracers which do not compile as modules (only builtin)\r\n4) Linus Torvalds stated that LTTng will stay out of tree\r\n\r\nAs a consequence, LTTng has no way to use common tracer facilities \r\nwithout kernel patches.\r\n\r\nThis context is not favorable for collaboration of LTTng developers with upstream. It is hard to justify spending time on kernel infrastructure collaboration when the resulting APIs cannot be used by out-of-tree tracers.\r\n\r\nI am open to suggestions to improve this situation.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2480/)", "url": "https://lpc.events/event/20/contributions/2480/", "persons": [{"public_name": "Mathieu Desnoyers"}]}, {"guid": "lpc20-c3764", "id": "lpc20-c3764", "title": "Lightweight Preempt and IRQ Tracepoints for Production RT Kernels", "date": "2026-10-06T12:22:00+02:00", "start": "12:22", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Debugging latency issues in production RT kernels often requires\r\nunderstanding where and why preemption and interrupts are being\r\ndisabled. Today, enabling the `preempt_disable/enable` and\r\n`irq_disable/enable` tracepoints requires pulling in heavyweight\r\ninfrastructure — either the preemptoff/irqsoff latency tracers or the\r\nfull lockdep IRQ tracking — that carries too much overhead for\r\nproduction deployments. This forces engineers to reproduce customer\r\nissues in lab environments, which is often impractical for intermittent\r\nlatency problems.\r\n\r\nThis talk presents a patch series that introduces\r\n`CONFIG_TRACE_PREEMPT_TOGGLE` and `CONFIG_TRACE_IRQFLAGS_TOGGLE`, two\r\nnew user-selectable kernel options that enable these tracepoints\r\nindependently, with minimal overhead. The tracepoints are gated behind\r\nstatic keys.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2513/)", "url": "https://lpc.events/event/20/contributions/2513/", "persons": [{"public_name": "Wander Costa"}]}, {"guid": "lpc20-c3765", "id": "lpc20-c3765", "title": "Handling stack traces in tracing", "date": "2026-10-06T12:44:00+02:00", "start": "12:44", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Stack tracing of events can be very useful, for both kernel stack tracing as well as user space stack tracing. Stack traces can fill the buffer quickly with many duplicate stacks. Having a way to consolidate them would make it possible to store even more data. There's been [efforts][1] to do this but how to implement it and the interface is still an ongoing subject.\r\n\r\nOn top of that, tracing user space can have the same issue. With the deferred stack trace, it is now possible to do more when taking the stack trace (like reading the vma and finding what files are associated with the stack as well as reporting the actual file offset instead of the virtual memory of the task). Work for this has [been done][2] as well but it also has [issues][3]. Figuring out how to implement this in a way that everyone is satisfied would be a goal of this topic.\r\n\r\n\r\n  [1]: https://lore.kernel.org/linux-trace-kernel/20260616064119.438063-1-lipengfei28@xiaomi.com\r\n  [2]: https://lore.kernel.org/linux-trace-kernel/20250828180356.546256287@kernel.org/\r\n  [3]: https://lore.kernel.org/linux-trace-kernel/CAHk-=wi0EnrBacWYJoUesS0LXUprbLmSDY3ywDfGW94fuBDVJw@mail.gmail.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2512/)", "url": "https://lpc.events/event/20/contributions/2512/", "persons": [{"public_name": "Steven Rostedt"}]}, {"guid": "lpc20-c3766", "id": "lpc20-c3766", "title": "DEPT (DEPendency Tracker): A Path to Mainline and Solving the False Positive Challenge", "date": "2026-10-06T13:06:00+02:00", "start": "13:06", "duration": "00:20", "room": "Small Theater (Floor 0)", "track": "LPC: Tracing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "DEPT (DEPendency Tracker) is a runtime dependency tracking framework\r\nthat detects potential deadlocks by tracking wait/event relationships\r\nrather than lock acquisition order.  Unlike lockdep, which is limited to\r\ntypical locking primitives, DEPT can detect deadlocks involving general\r\nsynchronization mechanisms such as folio locks, completions, DMA fences,\r\nand other wait/event-based patterns.\r\n\r\nThis talk presents the current state of DEPT and addresses the critical\r\nchallenge blocking its mainline inclusion: false positive handling\r\nthrough subsystem annotations.\r\n\r\nAny runtime dependency tracking tool faces the inherent challenge of\r\ndistinguishing real deadlocks from intentionally ordered synchronization\r\npatterns.  Lockdep also encountered this problem at its inception and\r\nsolved it through extensive subsystem-specific annotations (lock classes,\r\nsubclasses, etc.).  DEPT currently lacks sufficient annotation for other\r\nthan typical locking primitives because it just started.\r\n\r\nThis talk proposes a collaborative path forward: (1) core framework\r\nstabilization to finalize annotation APIs, (2) subsystem pilot programs\r\nwith maintainers if any (3) gradual mainline inclusion enabled\r\nincrementally as annotations mature.\r\n\r\nI seek community discussion on: annotation design that minimizes\r\nmaintainer burden, default behavior when annotations are missing,\r\ntesting infrastructure, and coexistence strategy with lockdep.  Like\r\nlockdep before it, achieving practical utility requires extensive\r\nsubsystem-specific annotations.  This talk charts the collaborative path\r\nto get there.\n\n**Attachments:**\n- [DEPT_false_positives(LPC2026) v3.pdf](https://lpc.events/event/20/contributions/2515/attachments/1991/4517/DEPT_false_positives(LPC2026)%20v3.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2515/)", "url": "https://lpc.events/event/20/contributions/2515/", "persons": [{"public_name": "Byungchul Park"}, {"public_name": "Yunseong Kim"}]}], "South Hall 1 A (Floor 1)": [{"guid": "lpc20-c3606", "id": "lpc20-c3606", "title": "eBPF Research: What's Going On In Academia?", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The body of academic work on eBPF is growing so large and scattered that it’s hard to see the forest for the trees. Papers span all kinds of topics and conferences, vary wildly in quality, and are often dense and hard to parse.\r\n\r\nThis talk will present the dominant trends of research. To that end, we will first explain some heuristics to identify \"high-quality papers\"—it is not the number of citations!—and what it means for a paper to be considered high-quality. We’ll then map these standout papers to some of the teams behind them.\r\n\r\nFinally, we will see that only specific research topics are leading to contributions upstream and explain why that might be. We will discuss how the kernel community could encourage research on specific problems, should it choose to do so.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2427/)", "url": "https://lpc.events/event/20/contributions/2427/", "persons": [{"public_name": "Paul Chaignon"}]}, {"guid": "lpc20-c3603", "id": "lpc20-c3603", "title": "bpf_fault: Custom Page Fault Handling with eBPF", "date": "2026-10-06T10:30:00+02:00", "start": "10:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Page faults, which occur when a program accesses a virtual memory page that is not mapped to physical memory, are traditionally handled by the operating system. However, many applications benefit from running custom page fault handling logic. For example, some applications may seek to prefill newly-faulted pages with content, or intercept writes in order to make a copy of the original contents. Linux’s userfaultfd interface enables some of these use cases by offloading fault handling to userspace. Unfortunately, it suffers from significant limitations, namely high overhead, poor scalability, and a design that precludes its use in libraries.\r\n\r\nWe present bpf_fault, an experimental framework that allows applications to run page fault handlers directly within the Linux kernel using eBPF. By eliminating the overheads and complexity associated with userfaultfd, bpf_fault reduces fault latency by 2.8-6.1x and eliminates userfaultfd’s scalability bottleneck. We integrate bpf_fault with several applications, including VM live snapshots in Firecracker and QEMU (eliminating tail latency spikes caused by snapshots), JVM garbage collection, and more. We also design a novel lazy dynamic linking mechanism for Linux that defers relocations to fault time using bpf_fault, a use case impossible with userfaultfd, which reduces dirty memory usage of widely-used applications like Chrome and Clang by up to 50%. Together, these results demonstrate that eBPF-based fault handling can improve performance and reduce resource usage in widely-deployed applications.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2434/)", "url": "https://lpc.events/event/20/contributions/2434/", "persons": [{"public_name": "Tal Zussman"}]}, {"guid": "lpc20-c3601", "id": "lpc20-c3601", "title": "Programming Across the VM Boundary with eBPF: Lessons from Revisiting Phantom Tracker", "date": "2026-10-06T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "eBPF programs can exchange data efficiently with other programs and userspace through maps, ring buffers, and kfuncs, but these mechanisms stop at the boundary of a kernel instance. The Linux kernel has no generic, safe, low-latency mechanism for eBPF programs in a guest and host to communicate through shared memory across the VM boundary. Roy’s Google Summer of Code (GSoC) project [1] reimplements Himadri’s in-kernel thesis [2] prototype of Phantom Tracker using eBPF and, in turn, highlights the need for paravirtualized shared-memory drivers that expose reliable communication APIs to eBPF programs across the VM boundary.\r\n\r\nThe thesis models vCPU lifecycle states using the distinction between phantom and viable vCPUs. A phantom vCPU satisfies two conditions: (1) it is runnable but waiting in the run queue of a pCPU on the host, and (2) a worker thread of the guest parallel application that had been running on that vCPU is now stalled because the vCPU is not executing. Conversely, any vCPU that does not satisfy both conditions is considered viable. Across the VM boundary, Phantom Tracker correlates guest-side information about which vCPUs are running worker threads of the parallel application with host-side scheduler wake-up and context-switch events involving those vCPUs. The GSoC project uses a configurable eBPF timer that aggregates these observations and computes a per-VM metric called the phantom average. Guest userspace parallel runtime libraries, such as libgomp, can use this metric to adapt the application’s degree of parallelism at runtime and minimize the number of phantom vCPUs.\r\n\r\nCommunication between the host and guest is implemented using QEMU’s Inter-VM Shared Memory (IVSHMEM) device [3]. While the thesis prototype relied on custom IVSHMEM drivers tied to custom kernels, the eBPF implementation resulted in the development of new eBPF-compatible drivers [4]. By presenting the lessons learned while working on this GSoC project, this talk discusses the broader applicability of our eBPF-compatible IVSHMEM drivers within the QEMU/KVM virtualization stack and invites discussion on the scope for upstreaming them.\r\n\r\n[1] https://summerofcode.withgoogle.com/programs/2026/projects/iXbp42du\r\n[2] https://inria.hal.science/tel-05438117v3\r\n[3] https://www.qemu.org/docs/master/system/devices/ivshmem.html\r\n[4] https://github.com/himadrics/phantom-tracker/tree/main/pvsched-shmem\n\n**Attachments:**\n- [lpc26_ebpf_track_phantom_tracker.pdf](https://lpc.events/event/20/contributions/2429/attachments/2084/4648/lpc26_ebpf_track_phantom_tracker.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2429/)", "url": "https://lpc.events/event/20/contributions/2429/", "persons": [{"public_name": "Roy Nchang"}]}, {"guid": "lpc20-c3594", "id": "lpc20-c3594", "title": "shirudo: BPF live-patching infra for the agentic era", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "In times of Fable/Mythos or equivalent LLMs, security fixes and attack-surface hardening increasingly needs to land on production systems now, but data-center fleets, Kubernetes nodes, or embedded/air-gapped devices all typically share long patch-and-reboot cycles.\r\n\r\nBPF is the natural vehicle for on-the-fly live mitigations and runtime visibility - to the kernel itself as well as to userspace apps - and in the age of AI-assisted engineering the natural author of those patches is an agent working in a close loop with the operator. We'll present shirudo, which is an agentless BPF-based security platform tailored for exactly this: There is deliberately no config DSL, because agents work far better with code directly. shirudo also fully embraces xattrs, signed BPF and seals all its assets via BPF LSM in order to defend against untrusted root tampering with bpf. In this talk we walk through the operator/target node workflow, architecture internals, demo its capabilities, and discuss gaps and next steps on shirudo, BPF kernel and libbpf loader side.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2437/)", "url": "https://lpc.events/event/20/contributions/2437/", "persons": [{"public_name": "Daniel Borkmann"}, {"public_name": "John Fastabend"}]}, {"guid": "lpc20-c3596", "id": "lpc20-c3596", "title": "One Layer of the Onion: A Daemonless eBPF LSM for Confidential VMs in a WhatsApp TEE", "date": "2026-10-06T12:30:00+02:00", "start": "12:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Host-side hardening for a confidential VM is not one control, it's an onion. AMD SEV protects guest memory, MetalOS and a measured/verified boot chain establish the platform, signing and provisioning gate what lands on disk, and process isolation constrains the runtime. This talk is about one specific layer of that onion, the eBPF LSM that enforces binary identity and process protection at runtime. WhatsApp runs user workloads inside AMD SEV-backed TEEs where the guest is a QEMU process; eBPF LSM is how we add a defense-in-depth layer for that host without becoming a new single point of trust.\r\nThe core of the talk is the BPF and the goal is to give attendees a full picture of how we use BPF at Meta to supplement confidential workloads in WhatsApp. Specifically, we attach a set of LSM programs bprm_creds_from_file for exec-time identity, ptrace_access_check/ptrace_traceme for anti-trace, and task_kill for anti-signal and drive them entirely from BPF maps keyed by role. The design choice we want to dig into is persistence through pinning that has been discussed in other talks from Tetragon discussed in this lwn article and fully explore how we pin, configure our maps, set up keychains used for binary identification and how we track processes. We will also talk about the need for options for logging as is done in the initial article, but it will be a small portion to ask for opinions and discuss some other options that we are exploring, as opposed to standing exclusively behind UDP packet sending that has been discussed previously. We will mention potential malware opportunities from this approach. Our method will be contrasted with pros and cons of a typical resident daemon. In the use case at Meta, a run-to-completion init binary loads the programs, pins every program, link, and map into bpffs, and exits. Because the LSM links survive pivot root, enforcement is live before the confidential workload starts. We'll walk through the map layout, how policy is expressed per-role, and how pinned state lets the enforcement layer survive independently of any userspace processes. We will also discuss some of the strategies we use to disallow malicious userspace processes from removing these programs once they are in place and how we manage the potential fallout from this.\r\nOn identity, we'll show the in-kernel verification path in detail. At exec, the bprm_creds_from_file hook reads an extended attribute on the binary user.bpfj.policy.exec naming its role, which forces calls to bpf_get_fsverity_digest and bpf_verify_pkcs7_signature to check the binary's fs-verity digest and detached PKCS7 signature against a kernel keyring seeded from that role's certificates enrolling the process into a role only if its on-disk contents are signed for that role. Here the BPF layer leans on fs-verity, the keyring subsystem, and our custom signing pipeline do the heavy cryptographic lifting. Our programs make the runtime authorization decision from that verified identity. We'll cover the kfuncs we depend on, the sleepable-LSM constraints, and the pitfalls we eliminated by moving to signature-gated, exec-time enrollment.\r\nFinally, we show what verified identity buys at runtime with QEMU pinned to a verified role, the ptrace and task_kill hooks enforce per-role allow-lists so nothing on the host can attach a debugger to, or signal, the confidential VM closing common paths for extracting or faulting guest state. We'll be explicit about the layer's limits what it does not defend against and which sibling controls cover those gaps — so the audience sees where a focused eBPF LSM fits in a real confidential-computing threat model.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2426/)", "url": "https://lpc.events/event/20/contributions/2426/", "persons": [{"public_name": "Joshua Lilly"}, {"public_name": "Liam Wisehart"}]}, {"guid": "lpc20-c3595", "id": "lpc20-c3595", "title": "Scaling BPF LSM hooks and error injection across the kernel", "date": "2026-10-06T13:00:00+02:00", "start": "13:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "In the modern era, Linux kernel CVEs might accumulate faster than fleets can reboot into patched kernels. In some cases, this takes not even days. BPF-based mitigations can block vulnerable code paths at runtime, no reboot needed.\r\n\r\nHowever, at the moment, BPF is far from being a golden bullet. Two mechanisms on how BPF can alter an execution path, LSM Hooks and error injection, are naturally limited: by the set of existing LSM hooks and by the [short] whitelist of ALLOW_ERROR_INJECTION functions. Many subsystems, such as different parts of net/, device drivers, etc., have no BPF security coverage.\r\n\r\nIn the first part of the talk, we investigate how subsystems currently lacking BPF hook coverage can be equipped with it and present tooling and guidelines to support adding that coverage more systematically.\r\n\r\nIn the second part, we discuss the error injection topic. One recent radical attempt, killswitch, allows any function to be altered. While this ultimately solves the problem, this is not really a solution which can be kept under control. Thus we discuss what might be done to substantially extend the set of functions eligible for error injection, while keeping the mechanism firmly under control.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2435/)", "url": "https://lpc.events/event/20/contributions/2435/", "persons": [{"public_name": "Anton Protopopov"}]}, {"guid": "lpc20-c3597", "id": "lpc20-c3597", "title": "Application-Layer Parsing in eBPF", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Recent advances in the Linux kernel have enabled increasingly complex kernel offloads with eBPF. Despite this, parsing application-layer protocols, e.g. HTTP, remains a challenge. The reason for this is the self-describing structure of such protocols, which typically requires more state and more complex control flow than a transport-layer protocol. This is unfortunate because supporting L7 protocols in eBPF opens up new opportunities to optimize many applications that were previously deemed too complex, e.g. web servers, web application firewalls, or L7 service proxies. \r\n\r\nThis talk introduces [Beeper][1], a novel architecture to parse HTTP directly in eBPF, without the need for kernel modules. To circumvent eBPF’s stringent limitations, it constructs Aho-Corasick-like DFAs in user space, and leverages them in kernel space to identify and extract relevant headers from the message buffer. We will discuss the challenges Beeper must address  to parse HTTP/1.1 and HTTP/2, and show its advantage by serving HTTP requests directly from eBPF.\r\n\r\n\r\n  [1]: https://github.com/lerboe/beeper\n\n**Attachments:**\n- [beeper.pdf](https://lpc.events/event/20/contributions/2428/attachments/2064/4620/beeper.pdf)\n- [Enforcing Application-Layer Policies in eBPF](https://lpc.events/event/20/contributions/2428/attachments/2064/4622/go)\n- [GitHub Repo](https://lpc.events/event/20/contributions/2428/attachments/2064/4623/go)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2428/)", "url": "https://lpc.events/event/20/contributions/2428/", "persons": [{"public_name": "Laurin Brandner"}]}, {"guid": "lpc20-c3598", "id": "lpc20-c3598", "title": "Inline DDoS protection for cloud-native game servers at PlayStation with eBPF/XDP", "date": "2026-10-06T15:30:00+02:00", "start": "15:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "At PlayStation, we see DDoS attacks of multiple terabits per second targeting game servers. Traditional DDoS mitigation systems can be costly, slow to react, and difficult to place close enough to the ingress points of the network.\r\n\r\nThis talk presents a token-based eBPF/XDP architecture for inline DDoS protection. We show how distributing short lived tokens to legitimate clients allows us to make the most of XDP’s position early in the stack for whitelisting and minimise wasted cycles on unwanted traffic. We also complement the overall architecture with an eBPF based agent on the K8s workers that i) removes the need to expose backend clusters directly to the Internet ii) forms a transparent overlay between the public-facing DDoS protection layer and private game-server clouds and iii) solves challenges in integrating with Kubernetes CNIs and cloud environments. In order to tackle the unique requirements of frequently changing routing state that needs to be globally distributed, we also propose a control plane architecture built on CNCF xDS that allows us to propagate tokens at high rates close to our network ingress points, constantly updating the eBPF maps that drive our routing decisions.\r\n\r\nFinally, we share lessons from building and operating an eBPF based DDoS protection architecture at global scale. We discuss the challenges of integration with cloud providers and their CNIs, as well as return path optimisations that make the most of Playstation’s backbone network.\n\n**Attachments:**\n- [LPC26 Inline DDoS protection for cloud-native game servers at PlayStation with eBPF-XDP.pdf](https://lpc.events/event/20/contributions/2433/attachments/2114/4686/LPC26%20Inline%20DDoS%20protection%20for%20cloud-native%20game%20servers%20at%20PlayStation%20with%20eBPF-XDP.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2433/)", "url": "https://lpc.events/event/20/contributions/2433/", "persons": [{"public_name": "Babis Stylianopoulos"}, {"public_name": "Jeffrey Barendse"}]}, {"guid": "lpc20-c3599", "id": "lpc20-c3599", "title": "BPF ksock: bringing network sockets to BPF", "date": "2026-10-06T16:00:00+02:00", "start": "16:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "BPF-based agents aim to be as transparent as possible while minimizing CPU and memory overhead. Real-world experience from projects such as Cilium’s Tetragon has shown that moving more functionality directly into the kernel is an effective strategy. However, one remaining limitation for observability and logging is the lack of an API for sending data over the network directly from BPF programs, keeping user space in the critical path.\r\n\r\nEfforts to provide BPF programs with networking capabilities through new kfuncs have been discussed at the past two LSF/MM/BPF summits in Montreal and Zagreb. An initial approach based on the netpoll infrastructure was proposed but ultimately rejected. \r\n\r\nThis talk will recap the motivation behind the current patch sets, summarize the discussions so far, and introduce the current design. We will then demonstrate several ways BPF programs can use the new API, ranging from basic examples to practical and more unexpected use cases. Finally, we will discuss possible future extensions to the API, such as support for additional BPF program types and TCP sockets.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2430/)", "url": "https://lpc.events/event/20/contributions/2430/", "persons": [{"public_name": "Mahé Tardy"}, {"public_name": "Kornilios Kourtis"}]}, {"guid": "lpc20-c3602", "id": "lpc20-c3602", "title": "BPF-RBACd: Delegating BPF permissions with high granularity", "date": "2026-10-06T17:00:00+02:00", "start": "17:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "BPF usage has traditionally required system-wide capabilities, and giving an application access to using BPF is an all-or-nothing proposition. With BPF tokens, we gained the ability to delegate BPF capabilities to user namespaces with more granularity, and with an LSM we can increase granularity further.\r\n\r\nBoth BPF token usage, and an LSM, require a userspace implementation of the policy enforcement mechanism. `bpf-rbacd` (the \"BPF Role-Based Access Control daemon\") is such an implementation, which runs as a system service and supports granting permissions to applications or containers on the system using either BPF token delegation or syscall proxying. A policy language restricts which subset of BPF an application is allowed to use, with high granularity, enforced through an LSM written in BPF.\r\n\r\nWe are working on making `bpf-rbacd` a core part of the Fedora and RHEL distributions. In this talk we'll present the architecture of `bpf-rbacd` and solicit feedback from the community on the design of the system, in the hope that this can prove useful to other distributions and operators as well.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2441/)", "url": "https://lpc.events/event/20/contributions/2441/", "persons": [{"public_name": "Toke Høiland-Jørgensen"}]}, {"guid": "lpc20-c3604", "id": "lpc20-c3604", "title": "eBPF on Wheels - Automotive and Industrial Use Cases", "date": "2026-10-06T17:30:00+02:00", "start": "17:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The industry increasingly adopts Linux for automotive and industrial use cases, since companies like Red Hat or Canonical engaged in development of Linux platforms in safety-critical domains. Using container technologies or just a bootable images on restricted silicon, now software operates cyber-physical processes. Those platforms are often cloud-connected because of maintainability, attracting new threat actors to that domain. Defenses in this area are limited,  because of blind spots in endpoint protection solutions regarding electronics.\r\n\r\nThe missing integrations can be found in non-IP bus systems, such as the CAN bus as well as on-board interfaces to flash chips, FPGA or the protocols themselves like SPI or I2C. While less common in the IT world those missing capabilities are missing out in comprehensive observability resulting in unnoticed cyber attacks against IOT platforms.\r\n\r\nThis talk showcases the use of eBPF for protocols like CAN, DMA and SPI to create observability as well as defenses against cyber attacks in automotive or industrial contexts, such as secure updates, injection attacks and non-IP filters.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2443/)", "url": "https://lpc.events/event/20/contributions/2443/", "persons": [{"public_name": "Reinhard Kugler"}]}, {"guid": "lpc20-c3605", "id": "lpc20-c3605", "title": "Pluggable Runtime Verification (RV) monitors with BPF", "date": "2026-10-06T18:00:00+02:00", "start": "18:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: eBPF Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "RV is a lightweight method for verifying system behavior at runtime using, for instance, deterministic automata. Currently, RV monitors must be implemented in-kernel, meaning any new monitor requires going through the upstream kernel development process.\r\nWe can replicate the existing monitor infrastructure in BPF mapping kernel primitives to BPF equivalents such as maps and ring buffers, while reusing common logic where possible.\r\nThis allows to develop, test, and deploy domain-specific monitors entirely from userspace, with all the perks of the BPF tracing infrastructure.\r\n\r\nIn the talk we will cover an implementation using BPF struct_ops for mostly seamless integration with the in-kernel RV framework and tools, BPF monitor lifecycle control via the rv command line tool (i.e. registration, activation, and tracing), and various tradeoffs to keep a similar experience between different monitor implementations.\n\n**Attachments:**\n- [rv_bpf.pdf](https://lpc.events/event/20/contributions/2446/attachments/2014/4548/rv_bpf.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2446/)", "url": "https://lpc.events/event/20/contributions/2446/", "persons": [{"public_name": "Gabriele Monaco"}]}], "South Hall 1 B (Floor 1)": [{"guid": "lpc20-c3507", "id": "lpc20-c3507", "title": "Kernel CVEs at AWS Scale: Two Years of Empirical Findings", "date": "2026-10-06T10:00:00+02:00", "start": "10:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Since the Linux kernel project became a CVE Numbering Authority (CNA) in February 2024, organizations maintaining custom kernels have faced a flood of CVE disclosures.\r\n\r\nWe present empirical findings, lessons learned, and the key challenges that the kernel team responsible for Amazon Web Services fleet infrastructure encountered over the following two years while handling the steady flow of kernel CVEs.\r\n\r\nWe summarize our approach to assessing kernel CVEs in a warehouse-scale environment, pruning our code base to reduce the attack surface, along with quantitative results from field data. Specifically, we examine\r\n\r\n - how NVD/CVSS scores and third-party assessments correlate with our final in-house ratings;\r\n - how community guidance, including stable tree tracking and domain-specific risk assessment, measurably improved our development velocity, kernel maintenance, and kernel adoption strategy; and\r\n - how backporting practices introduce regressions and compound risk.\r\n\r\nWe then present data on patching velocity and CVE-related trends across LTS versions. Although our data comes from a single environment, we believe these findings generalize to any organization that maintains in-house or custom kernels.\r\n\r\nWe will close with an open discussion on emerging developments (including where AI-assisted tooling fits into the CVE triage and patching pipeline) and invite attendees to challenge, extend, or contradict our findings with their own data.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2373/)", "url": "https://lpc.events/event/20/contributions/2373/", "persons": [{"public_name": "Dylan Johnson"}, {"public_name": "Justinien Bouron"}]}, {"guid": "lpc20-c3508", "id": "lpc20-c3508", "title": "Regressions & tracking them: current state, plans, and what do you want?", "date": "2026-10-06T10:45:00+02:00", "start": "10:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Provide a quick \"state of the union\" about the Linux kernel regression ecosystem in the first part of the session before spending the second discussing what improvement the members of the audience wish for in this area.\r\n\r\nThe first part is meant to take less then half of the allotted time and will cover things like:\r\n\r\n* KernelCI and regzbot joined forces -- what this means for the future.\r\n* Tracking regressions with regzbot, the regression tracking bot: status and future plans.\r\n* Linux development workflow patters that lead to regressions or delay resolving them.\r\n\r\nThe second half will be audience driven and might discuss details in the areas raised earlier, things like the following, or whatever the audience is interested it:\r\n\r\n* Regression tracking with regzbot still useful in the age of AI?\r\n* How to improve interaction with parties interested in the space of CI, regressions, and tracking them – like kernel maintainers of distros that regularly update their kernels to latest stable or longterm series.\r\n* Is there interest in trees with \"pending\" and \"wip\" regression fixes?\r\n\r\nIn case I'm invited to the kernel maintainers summit I'll also collect topics with regards to regressions the audience wants me to bring up at kernel maintainer summit a few days later.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2372/)", "url": "https://lpc.events/event/20/contributions/2372/", "persons": [{"public_name": "Thorsten Leemhuis"}]}, {"guid": "lpc20-c3510", "id": "lpc20-c3510", "title": "Challenges in multi-tenant GPU sharing", "date": "2026-10-06T12:00:00+02:00", "start": "12:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "We would like to share some of the challenges we have encountered in a multi-tenant GPU environment, discuss the solutions we have explored, and gather feedback from the community.\r\n\r\nTo provide context for the audience, we will start by giving an overview of our multi-tenant architecture. We then plan to discuss several areas where we have encountered challenges, including:\r\n\r\n  - GPU reset and debugging\r\n  - Identifying the problematic tenant session among many concurrent sessions\r\n  - Missing resource management capabilities, especially around memory cgroups\r\n  - Lock contention in drivers\r\n  - Power distribution across different system components\r\n\r\n\r\nWe would like to close the session with an open discussion on the issues and solutions presented. If the right audience is present, we would also like to discuss what a reasonable roadmap could look like for improving Linux support for multi-tenant GPU platforms.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2375/)", "url": "https://lpc.events/event/20/contributions/2375/", "persons": [{"public_name": "Boqun Feng"}, {"public_name": "Gregoire Pean"}, {"public_name": "Jatin Kataria"}]}, {"guid": "lpc20-c3511", "id": "lpc20-c3511", "title": "Maintainer-oriented features of b4", "date": "2026-10-06T12:45:00+02:00", "start": "12:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "B4 is already a well-known tool for retrieving and applying series from lore.kernel.org. Recently, it gained several new features that can make the life of a maintainer a bit easier:\r\n\r\n- b4 review - helps with code review and full series lifecycle management\r\n- b4 bugs - integrates distributed bug tracking into your workflow\r\n\r\nThis session will go over the new features and how they can assist overloaded maintainers in keeping a handle on the stream of incoming changes.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2370/)", "url": "https://lpc.events/event/20/contributions/2370/", "persons": [{"public_name": "Konstantin Ryabitsev"}]}, {"guid": "lpc20-c3513", "id": "lpc20-c3513", "title": "Rust for Linux", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "[Rust for Linux](https://rust-for-linux.com) is the project adding support for the Rust language to the Linux kernel. This talk will give a high-level overview of the status and the latest news around Rust in the kernel since LPC 2025.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2371/)", "url": "https://lpc.events/event/20/contributions/2371/", "persons": [{"public_name": "Miguel Ojeda"}]}, {"guid": "lpc20-c3514", "id": "lpc20-c3514", "title": "Leveraging Rust's Field Projections in the Kernel and Beyond", "date": "2026-10-06T15:45:00+02:00", "start": "15:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Several Rust contributors and I have been collaborating on a novel language feature called \"Field Projections\". The feature is still being designed and implemented, so now is a good opportunity to experiment with it to see what new APIs it unlocks for the Kernel and other projects. We also want to investigate any gaps in our current design that prevent important use-cases from being supported.\r\n\r\nRust makes heavy use of custom pointers filling the gap (& going beyond) between references (`&T` and `&mut T`) and raw pointers (`*const T` and `*mut T`). Currently, they have two major issues: ergonomics and feature parity with builtin references and `Box<T>`. Raw pointers and their extensions (e.g. `NonNull<T>`) have especially bad ergonomics. Our Field Projection language feature aims to remedy these shortcomings of custom (dumb & smart) pointers; our current approach is an ambitious generalization of `Deref` that supports a plethora of custom pointers from `MyBox<T>` (that has all the properties of `Box<T>`) to `VolatilePtr<T>` (which is only using `{read,write}_volatile` to access the pointee). Our proposal integrates tightly with existing features such as place expressions, operations on places, the borrow-checker, and autoref.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2376/)", "url": "https://lpc.events/event/20/contributions/2376/", "persons": [{"public_name": "Benno Lossin"}]}, {"guid": "lpc20-c3516", "id": "lpc20-c3516", "title": "DRM: handling runtime requirements for device components.", "date": "2026-10-06T17:00:00+02:00", "start": "17:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The DRM susbsytem grew up from the desktop GPUs, where the device is a single unit, powered on and off only at the important runtime points. For the embedded display controllers it's no longer true. The display pipeline can consist of several different devices, each having its own runtime power up and down code points. Handling device power on and off in the existing atomic callbacks makes the code fragile: it's too easy to create a disbalance of calls or to miss a register access from one of the points.\r\n\r\nIn this talk I would like to point out these issues and trigger a discussion about possible ways to solve the issue.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2374/)", "url": "https://lpc.events/event/20/contributions/2374/", "persons": [{"public_name": "Dmitry Baryshkov"}]}, {"guid": "lpc20-c3517", "id": "lpc20-c3517", "title": "Bringing Linux DRM Display Panel support in the modern age", "date": "2026-10-06T17:45:00+02:00", "start": "17:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Kernel Summit Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Since the introduction of the first Samsung DSI panel, the Linux DRM panel API has been a crucial piece of software for enabling displays across diverse architectures, but it has not evolved alongside modern graphics stacks. Currently, the API lacks atomic DRM API support and the ability to adapt power setups during mode changes. Furthermore, it fails to support advanced Display Driver IC (DDIC) features that modern hardware heavily relies on, including:\r\n- Standby and advanced power states\r\n- Advanced color management\r\n- Dynamic rate switching\r\n- Command mode self-refresh\r\n\r\nThis lack of evolution has led to severe fragmentation between upstream and vendor downstream trees for advanced devices support, creating a heavy maintenance burden and making native hardware support incredibly difficult.\r\n\r\nThe goal would be to outline these architectural limitations and trigger a discussion on how to collaboratively modernize the panel API. By standardizing advanced DDIC capabilities and fully embracing the atomic DRM API, we hope to establish a unified path forward for the entire Linux community.\n\n**Attachments:**\n- [Kernel Summit 2026 - Bringing Linux DRM Display Panel support in the modern age.pdf](https://lpc.events/event/20/contributions/2377/attachments/2079/4641/Kernel%20Summit%202026%20-%20Bringing%20Linux%20DRM%20Display%20Panel%20support%20in%20the%20modern%20age.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2377/)", "url": "https://lpc.events/event/20/contributions/2377/", "persons": [{"public_name": "Neil Armstrong"}]}], "South Hall 2 A (Floor 2)": [{"guid": "oss-0f27a2ba9350ef621320e8682647bc33", "id": "oss-0f27a2ba9350ef621320e8682647bc33", "title": "Zephyr Maintainers Forum [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T08:00:00+02:00", "start": "08:00", "duration": "09:00", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "This forum is a working set of meetings with Zephyr maintainers and technical leaders to decide strategic directions for the project. The forum will focus on release planning, security & safety support, technical decisions and process changes, maintainer workflows, and cross-subsystem coordination. The agenda will be designed by the Zephyr Technical Steering Committee (TSC) with the intentions of highly interactive discussions that will advance development and strategies.\nInterested participants are encouraged to attend in-person as sessions will not be recorded. Maintainers, TSC members, subsystem owners, and frequent contributors to the project who want to be active in shaping the technical strategy for Zephyr in the coming year are welcome.\nHow to Register: Pre-registration is required. To register for Zephyr Maintainers Forum, add it to your Open Source Summit Europe registration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0f27a2ba9350ef621320e8682647bc33)", "url": "https://osselceu2026.sched.com/event/0f27a2ba9350ef621320e8682647bc33", "persons": []}], "South Hall 3 A (Floor 3)": [{"guid": "oss-d94f7032c24d4bbae9cb7ed140343a7b", "id": "oss-d94f7032c24d4bbae9cb7ed140343a7b", "title": "OpenSSF Community Day + SCORED [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "09:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "OpenSSF Community Day brings together a vibrant community from across the Security and Open Source ecosystems to share ideas and progress on capabilities that make it easier to sustainably secure the development, maintenance, and consumption of the software on which we all depend. These events, held regionally and co-located Open Source Summits, offer an opportunity to engage with the brightest minds in security for a day of collaboration and innovation in software security best practices. As a home for tools, standards, and education, OpenSSF provides attendees the chance to explore these resources, share their experiences, and contribute to a safer and more secure digital world.\nTo learn more, visit the event website.\n\nFor OpenSSF Community Day Europe, we have added conference sessions on Software Supply Chain Offensive Research and Ecosystem Defense (SCORED), in cooperation with ACM. These sessions feature original research and security-in-practice talks focused on software supply chain security from both technical and policy perspectives.\n\nHow to Register: Pre-registration is required. Register for OpenSSF Community Day Europe as a stand alone event or add it to your Open Source Summit Europe registration. 20 Euro (only in-person reg).\n\n[Open in Sched](https://osselceu2026.sched.com/event/d94f7032c24d4bbae9cb7ed140343a7b)", "url": "https://osselceu2026.sched.com/event/d94f7032c24d4bbae9cb7ed140343a7b", "persons": []}], "T-Mobile Magenta Experience": [{"guid": "oss-cc8536635fddde83524fff00fc69c3a3", "id": "oss-cc8536635fddde83524fff00fc69c3a3", "title": "Sylva Summit Europe 2026", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "05:00", "room": "T-Mobile Magenta Experience", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "Sylva Summit presents an exciting opportunity for telco professionals and technologists from various industries who want to know how Sylva can help their industry! This event will feature discussions and sessions to explore new technologies and trends in the telecom sector. It is crafted to foster collaboration and learning within the Sylva community, which is committed to influencing the future of telecom and driving forward the vision of a unified, efficient, and innovative Telco, Cloud, and Edge.To learn more, visit the event website.\n\nAgenda:\n09:00 – 09:30 | Welcome Coffee & Breakfast09:30 – 10:00 | Introduction to Sylva: Progress & RoadmapSpeaker: Carlo Cavazzoni10:00 – 11:00 | Bare Metal as a Service Using Sylva (40-min Live Demo + 20-min Q&A)Speakers: Médéric de Verdilhac & Guillaume Nevicato11:00 – 11:30 | Coffee Break11:30 – 12:00 | Sylva and the Question of Digital SovereigntySpeaker: Kai Steuernagel12:00 – 12:30 | Energy-Efficient RAN on Sylva-Based SUSE Telco CloudSpeaker: Rajesh Rajamani12:30 – 13:30 | Lunch Break\nHow to Register: Pre-registration is required. Register for Sylva Summit Europe as a standalone event or add it to your Open Source Summit Europe registration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cc8536635fddde83524fff00fc69c3a3)", "url": "https://osselceu2026.sched.com/event/cc8536635fddde83524fff00fc69c3a3", "persons": []}], "TBA": [{"guid": "lpc20-c3706", "id": "lpc20-c3706", "title": "Topics in RISC-V Linux kernel maintenance", "date": "2026-10-06T15:00:00+02:00", "start": "15:00", "duration": "00:20", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Review the past year in RISC-V Linux kernel maintenance, and discuss upcoming plans for the next year - similar to what we did last year\n\n[Open in Indico](https://lpc.events/event/20/contributions/2405/)", "url": "https://lpc.events/event/20/contributions/2405/", "persons": [{"public_name": "Paul Walmsley"}, {"public_name": "Palmer Dabbelt"}]}, {"guid": "lpc20-c3710", "id": "lpc20-c3710", "title": "RISC-V Svnapot: dynamic fold/unfold for folded PTEs", "date": "2026-10-06T15:20:00+02:00", "start": "15:20", "duration": "00:20", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Svnapot gives RISC-V an architectural way to encode contiguous PTE ranges as folded mappings, and 64K mTHP is a particularly good match\r\nfor that capability.\r\n\r\nThis session presents a patch series that enables that model through dynamic fold/unfold and a split between public and raw page-table\r\nAPIs. Public helpers preserve the logical sub-PTE view expected by core MM, while raw helpers remain available to architecture-private\r\nusers that need direct access to the encoded hardware entry. In our measurements, combining 64K mTHP with Svnapot aggregation reduces\r\nlat_mem_rd latency by about 12% compared with non-aggregated 4K mappings, improves overall SPEC CPU performance by around 2%, and\r\ndelivers about 7% on the instruction-TLB-sensitive 520.omnetpp_r sub-benchmark.\r\n\r\nThe session will also discuss whether fold/unfold transitions can avoid intermediate TLB flushes, and examine the trade-offs between\r\nhardware 64K pages and Svnapot-based aggregation, including the advantages and drawbacks of each and whether Svnapot should support\r\nadditional aggregation granularities beyond today’s 64K mTHP use case.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2341/)", "url": "https://lpc.events/event/20/contributions/2341/", "persons": [{"public_name": "Yunhui Cui"}]}, {"guid": "lpc20-c3714", "id": "lpc20-c3714", "title": "Optimizing the kernel with vector", "date": "2026-10-06T15:40:00+02:00", "start": "15:40", "duration": "00:20", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The territory of using a larger context in the kernel-mode has been a forbidden topic since the existence of Linux. The use of SIMD unit in the kernel-mode is strictly restricted because the program is highly optimized for stack footprint, responsiveness, and maximum hardware compatibility. However, as hardware and compiler technologies advance, the benefit of enabling autovectorization has become more viable, and it might be a good time to revisit it.\r\n\r\nIn this talk we will go through some initial measurements to see the benefit of compiling the risc-v kernel with autovectorization, challenges of managing VLA context and ways to maintain code when compiled with such feature.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2455/)", "url": "https://lpc.events/event/20/contributions/2455/", "persons": [{"public_name": "Tao Chiu"}]}, {"guid": "lpc20-c3709", "id": "lpc20-c3709", "title": "RVA23 in practice: discovery, dispatch, and the hardware left behind", "date": "2026-10-06T16:00:00+02:00", "start": "16:00", "duration": "00:20", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "RVA23 is ratified and the first (vendor-announced) compliant silicon is shipping, but between \"the profile exists\" and \"userspace can rely on it\" sit three unresolved kernel questions.\r\n\r\n**Discovery.** Extension capability discovery between user mode and the kernel is still messy: hwprobe and prctl can disagree, so which interface should IFUNC resolvers actually trust, or does the discovery contract itself need a rethink? The \"riscv: hwprobe: export the availability of vector to user\" series under discussion on linux-riscv is a live example.\r\n\r\n**Dispatch.** (runtime selection of optimized code paths) x86 already does coarse, library-level selection via glibc-hwcaps. Could the same mechanism sit on top of hwprobe on RISC-V, keyed on something like rva23u64? Is profile granularity even the right key? For distros like Debian that will not flip their baseline any time soon, this is probably the realistic path. But there is a catch though, as the prctl/hwprobe mismatch shows.\r\n\r\n**The hardware left behind.** What compatibility fallbacks do pre-RVA23 systems get? And further out: can kernel-side cooperation support RVA23 capability certification, and what test infrastructure would that take?\r\n\r\nAiming at concrete next steps for the discovery contract and a dispatch story distros can adopt. Four asks to the room:\r\n\r\n**Ask 1**  kernel maintainers: is the RVA23U64 bit the right shape?\r\n**Ask 2**  distros: ship rva23u64 builds of selected libraries?\r\n**Ask 3**  kernel maintainers: deprecate the V prctl?\r\n**Ask 4**  future extensions: always-on, or dynamically enabled per process?\n\n**Attachments:**\n- [lpc26-rva23-in-practice-v3-2026-10-02.pdf](https://lpc.events/event/20/contributions/2626/attachments/1995/4541/lpc26-rva23-in-practice-v3-2026-10-02.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2626/)", "url": "https://lpc.events/event/20/contributions/2626/", "persons": [{"public_name": "Guodong Xu"}]}, {"guid": "lpc20-c3707", "id": "lpc20-c3707", "title": "Extensions - What's new? What's coming up?", "date": "2026-10-06T16:20:00+02:00", "start": "16:20", "duration": "00:10", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The RISC-V ISA specs contained the ratified collection of bases, extensions and profiles. This talk will cover recently ratified extensions, as well as cover upcoming extensions and profiles which are close to ratification. We'll dive into kernel / user space design considerations that implementors will want to care about.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2454/)", "url": "https://lpc.events/event/20/contributions/2454/", "persons": [{"public_name": "Tom Gall"}]}, {"guid": "lpc20-c3711", "id": "lpc20-c3711", "title": "Local, SBI, or IPI? Tracing RISC-V TLB Flush Decisions in Linux", "date": "2026-10-06T17:00:00+02:00", "start": "17:00", "duration": "00:15", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "RISC-V Linux TLB flushing has several runtime paths. A flush may be local to the current hart, may use SBI remote fence support, or may fall back to Linux IPIs. The kernel also makes range-versus-full decisions, performs ASID-aware flushing, and carries different flush strides for normal and huge-page ranges. These decisions can matter when debugging correctness issues, performance anomalies, and SMP scalability problems, but they are not currently visible in a compact RISC-V-specific form.\r\n\r\nThis talk presents a small RFC tracepoint patch that makes the Linux-side RISC-V TLB flush decision visible. The proposed tracepoint records the requested flush range, stride, ASID, target CPU count, flush type, threshold decision, and selected transport path: local, SBI remote fence, or IPI fallback.\r\n\r\nThe goal is intentionally narrow. This is not a hardware TLB profiler and not a complete MM observability framework. It focuses on one practical question: when Linux decides to invalidate RISC-V address translations, can a developer easily see which path was selected and why?\r\n\r\nThe talk will walk through the relevant RISC-V kernel TLB-flush path, explain what existing tracing can and cannot show, and demonstrate the proposed tracepoint using QEMU and one real RISC-V board. A small multi-threaded mmap() / mprotect() / munmap() workload will be used to trigger local and remote flushes and to show range-size effects around the current threshold logic.\r\n\r\nAttendees will leave with a concrete understanding of how RISC-V TLB flush decisions are made in Linux, how they can be observed today, what a minimal tracepoint adds, and what trade-offs should be considered before adding architecture-specific observability to hot MM paths.\r\n\r\nComments:\r\n\r\nThis topic is primarily intended for the RISC-V MC because it focuses on arch/riscv MM/TLB behavior, including local flushes, SBI remote fences, and IPI fallback paths. If the organizers think the tracing or MM angle is a better fit elsewhere, it could also be considered for the Tracing MC or Kernel Memory Management MC.\r\n\r\nI previously presented in the FOSDEM 2026 Kernel devroom with a practical talk on reproducing a Linux kernel bug using virtme-ng. This LPC proposal is a different topic, but it follows the same practical style: a small kernel RFC patch, reproducible QEMU testing, and validation on real RISC-V hardware where possible.\r\n\r\nP.S. Patches to review:\r\nv1\r\nhttps://lore.kernel.org/lkml/20260829-tlb_tracepoint-v1-1-dfdaede7e741@gmail.com/T/#me0739340db5d4dfc6e0ff1675896129af941eca5\r\nv2\r\nhttps://lore.kernel.org/linux-riscv/20260830-tlb_tracepoint-v2-1-e3c88c24df5b@gmail.com/T/#u\r\nv2 re-send:\r\nhttps://lore.kernel.org/lkml/20260924-tlb_tracepoint-v2-1-4e3e78ef5cdb@gmail.com/\r\nasciinema presentation:\r\nhttps://asciinema.org/a/1266683\n\n**Attachments:**\n- [riscv_tlb_lpc2026_v10_final.pdf](https://lpc.events/event/20/contributions/2342/attachments/1979/4496/riscv_tlb_lpc2026_v10_final.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2342/)", "url": "https://lpc.events/event/20/contributions/2342/", "persons": [{"public_name": "Roman Storozhenko"}]}, {"guid": "lpc20-c3712", "id": "lpc20-c3712", "title": "Error INJection support for RAS on RISC-V architecture", "date": "2026-10-06T17:15:00+02:00", "start": "17:15", "duration": "00:15", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Error INJection (EINJ), defined by ACPI, offers a platform-independent mechanism to inject hardware errors and validate system resilience paths. By avoiding platform-specific tooling, EINJ enables consistent testing of the Linux error-handling stack across architectures, including APEI and broader RAS workflows.\r\n\r\nThis session discuss the design and implementation strategy for enabling EINJ on RISC-V platforms. It will cover architecture-specific considerations, firmware and kernel integration points, and practical validation flows for injected error scenarios. The goal is to establish a robust, upstream-friendly approach that brings RISC-V closer to feature parity with existing ACPI-based RAS ecosystems and improves confidence in production reliability.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2414/)", "url": "https://lpc.events/event/20/contributions/2414/", "persons": [{"public_name": "Himanshu Chauhan"}]}, {"guid": "lpc20-c3713", "id": "lpc20-c3713", "title": "RISC-V Trace support in ACPI", "date": "2026-10-06T17:30:00+02:00", "start": "17:30", "duration": "00:15", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "To support RISC-V E-trace/N-trace components in ACPI, we propose using the Device Graph UUID defined in the DSD Guide, aligned with how similar topologies are described on other architectures. Beyond discussing the proposal itself and how it should appear in the ACPI namespace, we also want feedback on implementation strategy.\r\n\r\n  Today, ACPI fwnode graph handling does not interpret Device Graph UUID data, so trace drivers parse ACPI graph links in-driver. We have a PoC with that approach, but it duplicates logic, raises long-term maintenance cost, and keeps DT and ACPI paths separate instead of reusing common fwnode_graph_* helpers.\r\n\r\n  Our proposal is to extend ACPI fwnode graph support, so Device Graph UUID data is translated into standard fwnode_graph_* operations. This allows shared trace-driver code across DT and ACPI, reduces duplication, and scales better as additional architectures adopt this representation.\r\n\r\n  We plan to post an RFC series before the conference so maintainers and subsystem stakeholders can review concrete patches and align on direction.\n\n**Attachments:**\n- [LPC_2026_RISCV_Trace_ACPI_v2.pdf](https://lpc.events/event/20/contributions/2422/attachments/1994/4524/LPC_2026_RISCV_Trace_ACPI_v2.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2422/)", "url": "https://lpc.events/event/20/contributions/2422/", "persons": [{"public_name": "SUNIL V L"}]}, {"guid": "lpc20-c3715", "id": "lpc20-c3715", "title": "One Kernel Per Cluster: Multikernel for Heterogeneous RISC-V", "date": "2026-10-06T17:45:00+02:00", "start": "17:45", "duration": "00:20", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Boot mainline on SpacemiT's Key Stone K3 and half the machine stays dark: eight 1024-bit AI cores rejected by smpboot because riscv_v_vsize allows exactly one vlenb per system. This is not a bring-up bug, it is the first shipping proof that RISC-V vendors will not pay for matched vector widths, and the SG2042's RVV 0.7.1 installed base makes it worse: not narrower, incompatible. Per-process vlenb patches can boot this machine, but no patch changes the physics: 4 KB of vector state cannot land in a 1 KB register file, so any single-kernel fix confines vector tasks to one cluster for life and inherits the arm64 asymmetric-32bit price list: no hotplug of the last capable core, no SCHED_DEADLINE admission, silently rewritten affinity masks, undefined cpuset isolation, plus hwprobe intersecting capabilities down to no vector unit anywhere on a 0.7.1/1.0 mix. The partition was decided at tape-out; the scheduler can only hide it, expensively. We propose making it first class instead: multikernel boots one independent Linux kernel per cluster, each compiled for its exact silicon, seeing a machine where every core matches. The capability word tells the truth, glibc picks real vector routines, hotplug and deadline scheduling and cpusets just work, and RVV 0.7.1 and 1.0 domains coexist on one board. The prototype exists (github.com/multikernel/linux); what it needs is this room. We will present the architecture and the RISC-V gaps we want to close with the community: kernel spawning on the RISC-V boot flow, cross-domain interrupt routing with AIA/IMSIC, and DT/ACPI bindings for heterogeneous vector topology. Heterogeneous VLEN is the RISC-V roadmap, not a corner case. Let's give it a first-class answer before the next SoC tapes out.\n\n**Attachments:**\n- [multikernel-riscv-lpc.pdf](https://lpc.events/event/20/contributions/2478/attachments/1992/4516/multikernel-riscv-lpc.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2478/)", "url": "https://lpc.events/event/20/contributions/2478/", "persons": [{"public_name": "Cong Wang"}, {"public_name": "Yuning Liang"}]}, {"guid": "lpc20-c3716", "id": "lpc20-c3716", "title": "Supporting Heterogeneous VLEN on RISC-V: Lessons from SpacemiT K3", "date": "2026-10-06T18:05:00+02:00", "start": "18:05", "duration": "00:15", "room": "TBA", "track": "LPC: RISC-V MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "SpacemiT K3 is among the first production RVA23-compatible SoCs, shipping, features heterogeneous vector lengths:\r\n\r\n- **8× X100 cores**: RV64GCV, VLEN=256, full RVA23 compliance, H-extension — general-purpose\r\n- **8× A100 cores**: RV64GCV, VLEN=1024, no H-extension — AI/vector compute\r\n\r\nBoth core types implement RVV 1.0, but their incompatible vector register widths create a correctness issue: if a thread using vector instructions migrates between core types, its vector state corrupts. This isn't a performance concern — it's a data integrity problem.\r\n\r\nOur current vendor-specific approach (CONFIG_SPACEMIT_HMP) enforces strict per-thread core-type binding. This works, but it's not upstream-friendly.\r\n\r\n---\r\n\r\n## What SpacemiT Can Contribute\r\n\r\nWe can provide engineering data from 2+ years of HMP scheduling in production, including details on vector state management, signal frames, ptrace, and CPU hotplug. We'll also share real constraints — why certain approaches work or don't on actual silicon.\r\n\r\nK3 development boards are available for testing, and we have deployment experience with 9+ distributions (Ubuntu, Debian, Fedora, openEuler, openKylin, etc.). We're committed to upstream patches based on community consensus.\r\n\r\n---\r\n\r\n## Proposed Discussion Topics\r\n\r\n### 1. Kernel mechanism options\r\n\r\nWe've explored several approaches and can share trade-offs:\r\n- Generic heterogeneous-VLEN scheduling (similar to ARM capacity-aware)\r\n- Cpuset/cgroup-based isolation\r\n- ISA-capability-aware scheduling\r\n- Userspace-only manual pinning\r\n\r\n### 2. Vector state management\r\n\r\n- Should `riscv_v_vsize` be per-task or per-CPU?\r\n- Signal frame handling with variable VLEN?\r\n- ptrace behavior?\r\n\r\n### 3. DT bindings and discoverability\r\n\r\n- Should VLEN capabilities be explicit in DT or runtime-discovered?\r\n- Standardization of per-core capability properties?\r\n\r\n### 4. RVA23 ecosystem assumptions\r\n\r\n- Should RVA23 distributions assume uniform VLEN=256?\r\n- How should applications/libraries handle VLEN variability?\r\n- Kernel enforcement vs. userspace detection?\r\n\r\n### 5. Should kernel support this at all?\r\n\r\n- Is this a legitimate use case (like ARM big.LITTLE) or a hardware constraint software shouldn't accommodate?\r\n\r\n---\r\n\r\n## Session Format\r\n\r\nWe suggest a community-driven discussion. SpacemiT can provide engineering data and K3-specific details, while community maintainers lead the architectural direction. We'll share detailed technical background (2-3 pages) before the conference.\r\n\r\n---\r\n\r\n## Why This Matters\r\n\r\n- **RISC-V flexibility vs. portability**: vendors can customize per-core ISA, but software must remain portable\r\n- **This is solvable**: ARM addressed big.LITTLE heterogeneity; RISC-V can too\r\n- **Prevent fragmentation**: if every vendor ships custom scheduling, distro/kernel maintenance becomes unsustainable\r\n\r\n---\r\n\r\n## Desired Outcomes\r\n\r\n1. Community consensus on whether/how to support heterogeneous VLEN upstream\r\n2. DT binding direction for representing per-core capabilities\r\n3. Clear action items for follow-up patches and testing\r\n\r\n---\r\n\r\n## Pre-Conference Materials\r\n\r\nWe will circulate 2-3 pages of technical background (HMP implementation, trade-offs, deployment observations, code pointers) to participants before the conference.\r\n\r\nReference: https://github.com/spacemit-com/linux\n\n[Open in Indico](https://lpc.events/event/20/contributions/2479/)", "url": "https://lpc.events/event/20/contributions/2479/", "persons": [{"public_name": "Qiubin Zhuang"}, {"public_name": "Dong Xu"}]}, {"guid": "lpc20-b3819", "id": "lpc20-b3819", "title": "Celebration of Life: Dan Williams", "date": "2026-10-06T18:45:00+02:00", "start": "18:45", "duration": "01:00", "room": "TBA", "track": "LPC: Social Events", "type": "LPC Social", "language": "en", "abstract": "", "description": "", "url": null, "persons": []}], "Terrace 2 A (Floor 2)": [{"guid": "oss-9653a0b6d6a71efb528406f35fa670f3", "id": "oss-9653a0b6d6a71efb528406f35fa670f3", "title": "Decentralized Trust for Open Source Maintainers: From the Linux Kernel to the Broader OSS Ecosystem [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T09:00:00+02:00", "start": "09:00", "duration": "03:30", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Project Mini-summits", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This mini summit will bring together maintainers, security practitioners, identity experts, and open source community leaders to explore a practical question: how can open source projects know that critical contributors and maintainers are real, trusted participants without creating centralized identity databases or compromising privacy?\nThe session will focus on the ToIP Decentralized Trust Graph Working Group and its emerging work around verifiable trust communities, verifiable relationship credentials, proof of personhood, and maintainer verification for open source projects. The work is directly relevant to the Linux kernel, where the existing PGP web-of-trust model has provided an important foundation but is difficult to scale across the broader open source ecosystem. The LFDT progress report specifically connects this initiative to the Linux kernel project and the need for privacy-preserving maintainer trust infrastructure following supply-chain threats such as the XZ attack.\n\nHow to Register: Pre-registration is required. To register for Decentralized Trust for Open Source Maintainers Mini Summit, add it to your Open Source Summit Europe registration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9653a0b6d6a71efb528406f35fa670f3)", "url": "https://osselceu2026.sched.com/event/9653a0b6d6a71efb528406f35fa670f3", "persons": []}, {"guid": "oss-7375dcaa8f86a51e2b826c72bb5f5962", "id": "oss-7375dcaa8f86a51e2b826c72bb5f5962", "title": "Real-Time Linux User Forum [Additional Fee; Pre-Registration Required]", "date": "2026-10-06T13:30:00+02:00", "start": "13:30", "duration": "03:30", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Project Mini-summits", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Real-Time Linux User Forum connects developers and users building products or solutions with PREEMPT_RT. This event focuses on sharing user stories and practical experiences, fostering collaboration to address real-world challenges and explore advancements in Real-Time Linux.\n\nTo learn more about the sessions and speakers, please visit the event website. \n\nHow to Register: Pre-registration is required. To register for Real-Time Linux User Forum, add it to your Open Source Summit Europe registration.\n\nAgenda\n1:30-2:00 PM: PREEMPT_RT configuration: Best practices with kconfig_checker (Speaker: Ahmed S. Darwish, Linutronix GmbH)\n2:00-2:30 PM: cpusets and other recent updates in tuna and rteval (Speaker: John Kacur, Red Hat) \n2:30-3:00 PM: Let the Kernel Monitor Your Real-Time Application (Speaker: John Ogness, Linutronix GmbH)\n3:00-3:30 PM Break\n3:30-4:00 PM: Finding sources of Latency via Tracing (Speaker: Steven Rostedt, Qube-RT)\n4:00-4:30 PM: Beyond Cyclictest: Deploying PREEMPT_RT in Mixed-Criticality Industrial Systems (Speaker: Jitendra sharma, Qualcomm India Private Limited)\n4:30-5:00 PM: Where PREEMPT_RT meets the dynamics of container runtimes (Speaker: Florian Bezdeka, Siemens)\n\n[Open in Sched](https://osselceu2026.sched.com/event/7375dcaa8f86a51e2b826c72bb5f5962)", "url": "https://osselceu2026.sched.com/event/7375dcaa8f86a51e2b826c72bb5f5962", "persons": []}]}}, {"index": 3, "date": "2026-10-07", "rooms": {"Chamber Hall (Floor 3)": [{"guid": "oss-9b310dcb973689945f4e6f7551f26dec", "id": "oss-9b310dcb973689945f4e6f7551f26dec", "title": "Open Source Security as the Foundation of European Sovereignty", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "European digital policy is often discussed through frameworks such as NIS2, the CRA, DORA, the CSA, and the broader Tech Sovereignty agenda. Yet these initiatives share a common objective: securing the software supply chains underpinning Europe’s critical digital infrastructure.OSS is the foundation of modern technology stacks, from cloud services and critical infrastructure to financial systems and AI. It is also inherently global, developed and maintained by a distributed ecosystem across borders. As reliance on OSS grows, the challenge is no longer whether it is used, but how it is integrated, governed, and secured throughout its lifecycle within this global dependency network.This session explores software supply chain security as the common thread across Europe’s cyber and digital policy landscape. It examines how regulations converge on transparency, dependency management, vulnerability handling, provenance, and secure development practices.Finally, it connects these developments to EU Tech Sovereignty goals, arguing that secure and standardized consumption of globally developed open source is key to Europe’s resilience, competitiveness, and technological sovereignty.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9b310dcb973689945f4e6f7551f26dec)", "url": "https://osselceu2026.sched.com/event/9b310dcb973689945f4e6f7551f26dec", "persons": [{"public_name": "Madalin Neag"}, {"public_name": "Mirko Boehm"}]}, {"guid": "oss-f9e8562e9f571cceae72f05861d15491", "id": "oss-f9e8562e9f571cceae72f05861d15491", "title": "ORBIT Launchpad: Building the Due Diligence Bridge Between Manufacturers and Open Source", "date": "2026-10-07T11:40:00+02:00", "start": "11:40", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The EU Cyber Resilience Act requires manufacturers to exercise due diligence when integrating open source components — but what does that actually look like in practice? ORBIT Launchpad is an OpenSSF initiative building the catalogs, criteria, and tooling that help manufacturers demonstrate they've done the work.\n \n This talk covers how ORBIT Launchpad bridges the gap between regulatory intent and operational reality. We'll share how the CRAB-FOSC and CRAB-FOMA catalogs translate CRA obligations into actionable criteria that manufacturers can evaluate against, how we're aligning with complementary efforts across foundations to avoid duplication, and what the open source ecosystem needs to provide so that due diligence doesn't become an unfunded mandate on maintainers.\n \n Attendees will leave with a practical understanding of: what due diligence means for manufacturers consuming open source under the CRA; how ORBIT Launchpad's open catalogs and tooling reduce that burden; and how standards bodies and open source communities can work together to make compliance achievable.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f9e8562e9f571cceae72f05861d15491)", "url": "https://osselceu2026.sched.com/event/f9e8562e9f571cceae72f05861d15491", "persons": [{"public_name": "Nicole Bates-Callaghan"}, {"public_name": "Sarah Evans"}]}, {"guid": "oss-f0c4eab0c6c5171e13fa267928696e22", "id": "oss-f0c4eab0c6c5171e13fa267928696e22", "title": "Digital Sovereignty, Institutionalisation and International Momentum: 2026 OSOR Report on Progress and Trends", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The presentation gives an overview of the European Commission’s Open Source Observatory’s (OSOR) activities and the preliminary findings of the 2026 Report on Progress and Trends.\n\nThe report provides an overview of the evolution of open source software policies, governance models and implementation practices in Europe, based on insights from OSOR research activities. It will highlight the importance of open source technologies in strengthening the digital sovereignty of European countries. There is an increasing commitment to open source principles across the continent, evidenced by growing institutionalisation and the creation of new, noteworthy cross-border projects.\n\nAdditionally, the report will include short case studies on Switzerland and Ukraine. By comparing how these two very different countries implement open source solutions, we can gain insight into the influence of the EU outside of its membership in shaping digital priorities.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f0c4eab0c6c5171e13fa267928696e22)", "url": "https://osselceu2026.sched.com/event/f0c4eab0c6c5171e13fa267928696e22", "persons": [{"public_name": "Éléonore Daxhelet"}]}, {"guid": "oss-8caaa08fe452ebdb6f1026eed718d99b", "id": "oss-8caaa08fe452ebdb6f1026eed718d99b", "title": "The Japan-Type OSS Model: Native Species, Seeding Strategy, and Rules as Code", "date": "2026-10-07T13:50:00+02:00", "start": "13:50", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open source is now social infrastructure, rarely recognized until it fails. To shape a forward-looking strategy, we must know where we stand. In 2025, IPA ran two foundational surveys: a software-trends survey of domestic firms, and a GitHub study of 30,298 public-sector repositories across seven countries.\nThe findings show modest but clear momentum. Corporate OSS policy adoption rose from 32.0% to 36.7% (normalized), and vague \"don't know\" answers gave way to concrete work on security and talent development—a shift from awareness to practice. Japan's government OSS repositories rank alongside Germany, Singapore, and Estonia, with GIS and geospatial strengths grown from frontline needs—now a uniquely AI-ready foundation.\n\nWe propose a \"Japan-Type OSS Model\" with three axes: cultivating \"native species\" OSS rooted in real needs; a \"seeding strategy\" where the public sector publishes building blocks industry scales into services; and \"Rules as Code,\" making institutions machine-readable for trustworthy AI.\nThis session shares what one country learned from mapping its terrain—and calls for cross-border collaboration on how open source will underpin digital sovereignty worldwide.\n\n[Open in Sched](https://osselceu2026.sched.com/event/8caaa08fe452ebdb6f1026eed718d99b)", "url": "https://osselceu2026.sched.com/event/8caaa08fe452ebdb6f1026eed718d99b", "persons": [{"public_name": "Kazuki Imamura"}]}, {"guid": "oss-5f2ba201bd2587b41c28343b7c8c34d0", "id": "oss-5f2ba201bd2587b41c28343b7c8c34d0", "title": "Panel: Having an SBOM Is Not Enough. Introducing the OpenChain SBOM Document Quality Guide", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "SBOM adoption is growing, driven by global regulation such as the EU Cyber Resilience Act(CRA). Today’s software supply chains are complex and global, involving many organizations, tools, and layers of dependencies. In this environment, SBOMs need to accurately share software component information without confusion.\nA high‑quality SBOM enables precise, unambiguous information exchange between organizations, minimizing gaps and misinterpretation.\nTo achieve this, the OpenChain SBOM Working Group released a draft SBOM Document Quality Guide in April 2026 on the foundation of the Telco SBOM Guide. Global public comments have been incorporated into the official version released at this session. It defines what should be contained, how to evaluate, and how to exchange between organizations. In this panel, we will discuss:- why each of us engaged in this work- the distinct SBOM quality challenges from our own vantage points- how we actively utilize the guide to address industry-specific quality hurdlesWe hope this sparks dialogue with many addressing Cyber Resilience Act and other security regulations\n\n[Open in Sched](https://osselceu2026.sched.com/event/5f2ba201bd2587b41c28343b7c8c34d0)", "url": "https://osselceu2026.sched.com/event/5f2ba201bd2587b41c28343b7c8c34d0", "persons": [{"public_name": "Yoshiyuki Ito"}, {"public_name": "Tsukasa Yobo"}, {"public_name": "Kiyoshi Owada"}, {"public_name": "Yumi Tomita"}, {"public_name": "Takashi Ninjouji"}]}, {"guid": "oss-6c4ffa9d46a0f5f7605c291513108dd0", "id": "oss-6c4ffa9d46a0f5f7605c291513108dd0", "title": "The EU Cyber Resilience Act and Open Source: What Product Vendors Must Do", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The EU Cyber Resilience Act (CRA) is fundamentally changing how companies develop, secure, and bring products to market in the European Union. It introduces comprehensive security requirements across the entire software development lifecycle—including how open source components are selected, integrated, and maintained.Timo and Gergely provide a practitioner-focused view of what CRA means in practice, with a particular emphasis on open source.\nIn their talk, they examine the CRA from a product vendor perspective, with focus on open source. They will break down the practical implications of the regulation across three key areas: open source consumption, vulnerability management, and open source stewardship. They will also highlight where the regulation leaves room for interpretation and share insights from ongoing industry discussions that are shaping emerging best practices.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6c4ffa9d46a0f5f7605c291513108dd0)", "url": "https://osselceu2026.sched.com/event/6c4ffa9d46a0f5f7605c291513108dd0", "persons": [{"public_name": "Timo Perala"}, {"public_name": "Gergely Csatari"}]}, {"guid": "oss-cb30fce929b70bb90556e21dcdc851d7", "id": "oss-cb30fce929b70bb90556e21dcdc851d7", "title": "Challenges Using an IEC Standard in Open Source", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The electrical energy sector can largely be defined by the IEC standards that ensure compatibility and conformity. In this way IEC standards serve our industry very well, both in the physical and digital realm. Although the open source projects and IEC share a similar goal of compatibility and innovation, in practice they conflict with one another. This has to do with the way in which IEC standards are created, licensed and distributed.In this presentation Nico will share his experiences in dealing with IEC licenses from the perspective of an OSPO supporting open source development. This will highlight various issues, big and small, that hinder open source development. The presentation will also gather insights from the standards group in the LF Energy community group. By presenting this constructive assessment Nico hopes to foster discussion and encourage improvement of the situation. Much of the content will carry over to other closed standards.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cb30fce929b70bb90556e21dcdc851d7)", "url": "https://osselceu2026.sched.com/event/cb30fce929b70bb90556e21dcdc851d7", "persons": [{"public_name": "Nico Rikken"}]}, {"guid": "oss-70ccd00ba8f5940808f26d6424999774", "id": "oss-70ccd00ba8f5940808f26d6424999774", "title": "Rebuilding Mini-Grid Metering as Open Infrastructure", "date": "2026-10-07T16:50:00+02:00", "start": "16:50", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In the past 9 months, the two largest smart-metering providers serving rural mini-grids entered insolvency or severe distress, putting ~250,000 meters in 30+ countries at risk of losing billing, payment, and remote management, and threatening to leave over a million people, plus clinics and schools, in the dark. The cause was structural and familiar to anyone in open source: vertically integrated proprietary stacks, cloud lock-in, and no \"supplier of last resort\" for critical infrastructure.\nThis talk is a field report on the open-source response: an alliance of competitors, NGOs, and operators building an unbundled, multi-vendor platform on Digital Public Good principles. We cover the architecture (open APIs, multi-OEM interoperability, code and key release tied to bridge funding), the governance model for an asset that must outlive any single contributor, and how critical open infrastructure can be funded sustainably.\nWe close with concrete contribution paths: protocol work, hardware integrations (DLMS/COSEM, MQTT, STS), security review, and governance participation.\n\n[Open in Sched](https://osselceu2026.sched.com/event/70ccd00ba8f5940808f26d6424999774)", "url": "https://osselceu2026.sched.com/event/70ccd00ba8f5940808f26d6424999774", "persons": [{"public_name": "Joscha Winzer"}]}, {"guid": "oss-329c76164456b7f5532d315d60a5f702", "id": "oss-329c76164456b7f5532d315d60a5f702", "title": "Rethinking Wireless Networking With Synchronous Transmissions: The OpenSTX Standard", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Synchronous Transmission (STX) techniques have matured over a decade of research, enabling a new approach to low-power wireless networking. STX protocols exploit floods that, unlike traditional methods, purposefully embrace on-air collisions via tightly synchronized transmissions. Research repeatedly shows order-of-magnitude gains in reliability, and reduced latency and energy use over conventional approaches.\n \n Standardization is now needed to make STX industry-ready. The OpenSTX Foundation aims to define an open standard from radio interface to application layer, targeting IEEE 802.15.4, Bluetooth, and UWB.\n \n OpenSTX excels where routing-based protocols fall short: network-wide flooding completes in milliseconds with bounded latency; end-to-end reliability is above 99.9% in dense, interference-prone settings; and the absence of routing tables and topology maintenance makes networks inherently tolerant to failure and mobility. Radio duty cycling extends battery life, and network-wide time synchronization is a free by-product.\n \n This session overviews STX techniques, showcases OpenSTX primitives across a layered architecture, presents the roadmap, and describes how to get involved.\n\n[Open in Sched](https://osselceu2026.sched.com/event/329c76164456b7f5532d315d60a5f702)", "url": "https://osselceu2026.sched.com/event/329c76164456b7f5532d315d60a5f702", "persons": [{"public_name": "Davide Vecchia"}]}, {"guid": "oss-a33de77809b1d8ed9107d84e3e3662fd", "id": "oss-a33de77809b1d8ed9107d84e3e3662fd", "title": "Open Quantum Safe: Post-Quantum Software Research in the Era of the First PQC Standards", "date": "2026-10-07T17:45:00+02:00", "start": "17:45", "duration": "00:20", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Open Quantum Safe (OQS) project was founded with the mission of supporting the transition to Post-Quantum Cryptography. On its way, it became one of the most important open-source post-quantum cryptographic organizations. The subsequent publication and adoption of the first PQ standards by major cryptographic projects helps the cryptographic community in the adoption of this required type of cryptography. The mission of the OQS organization remains being at the forefront of PQC research. This talk provides an update of what these efforts look like in the era of the first PQ standards. It will include lessons learned along the way, challenges encountered when handling a PQ Open Source project and future directions, such as: 1) Addition of new PQ schemes being considered for standardization or relevant to the PQ cryptographic community (e.g. NIST on-ramp signature schemes)2) Inclusion of new functionalities like: new hybrids or constant-time analysis.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a33de77809b1d8ed9107d84e3e3662fd)", "url": "https://osselceu2026.sched.com/event/a33de77809b1d8ed9107d84e3e3662fd", "persons": [{"public_name": "Rodrigo Martín"}]}], "Club A (Floor 1)": [{"guid": "lpc20-c3663", "id": "lpc20-c3663", "title": "Constraints of process migrations", "date": "2026-10-07T10:00:00+02:00", "start": "10:00", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Triggered by:\r\nSubject: [PATCH 0/4] bpf: add a few hooks for sandboxing\r\nMessage-Id: <20260220-work-bpf-namespace-v1-0-866207db7b83@kernel.org>\r\n\r\nProblem statements:\r\n- Users (admins) are sometimes confused by some entity (PAM, systemd, container\r\n  runtimes) migrating their processes away from intended cgroup.\r\n- Coarse-grained DAC doesn't express well who (migrating process) can operate\r\n  on what (cgroup) to what (migrated task).\r\n- Limited immutability of membership assignment after certain point.\r\n\r\nProposed solution:\r\nBPF LSM hook for cgroup_attach_permissions\r\n(combination with other existing migration vetting mechanisms\r\nassociation of permissions with PIDs instead of UIDs?)\r\n\r\nAlternate solutions:\r\n- stick with regular cgroup FS permissions\r\n- utilization of other existing LSM hooks\n\n[Open in Indico](https://lpc.events/event/20/contributions/2602/)", "url": "https://lpc.events/event/20/contributions/2602/", "persons": [{"public_name": "Michal Koutný"}]}, {"guid": "lpc20-c3668", "id": "lpc20-c3668", "title": "Memory Tracking in forensic checkpointing: what soft-dirty bits can’t tell us", "date": "2026-10-07T10:20:00+02:00", "start": "10:20", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "CRIU’s incremental checkpointing is being used for forensic container snapshot(Stoyanov et al., DFRWS 2026) chains. Soft-dirty tracking cuts snapshot size by about 10× and makes high-frequency capture practical.  Live migration only needs a correct final state. Forensics needs the path that led there. Soft-dirty was built for migration and is now being reused for forensics.  \r\n\r\nA forensic snapshot chain starts with one full snapshot, then stores only later changes. Hash-chaining makes tampering detectable, as long as the host kernel and CRIU stay trusted. \r\n\r\nThis talk brings the discusion of the challenges with the existing memory tracking mechanism and improvements for forensic use.\r\n\r\nSoft-dirty answers one question: did this page change since the last reset? It cannot say when, how many times, in what order, or by whom. Tracking makes pages read-only and catches the first write to each but a page written once and a page written ten thousand times are indistinguishable. Every intermediate value is gone, along with any ordering or context. Even when two pages change, the kernel walks page tables. \r\n\r\nSome ways to improve this tracking for forensic checkpointing at container level, have been inspired from several of live migration, hypervisor specific and hardware trapping techniques. One such direction might be maintaining a kernel level dirty set of pages. PAGEMAP_SCAN already helps here, but CRIU mainly uses it as a faster way to read soft-dirty. The tracking mechanism is unchanged, and the kernel-side still walks the range, there is no maintained dirty set, only a faster way to report the outcome of a walk.  \r\n\r\nAnother direction can be to finally start utilising the first-write page fault data rather than discarding almost everything it exposes. Today’s interfaces force a choice: async uffd-wp is cheap but reports one bit, while sync uffd-wp can report richer data at a userspace round trip per fault. Forensics needs rich-and-cheap: capture at the fault, kernel-side, without that round trip. \r\n\r\nA separate, lighter option is to recover changed bytes by diffing a captured page against its parent and storing only the difference. \r\n\r\nAt last, soft-dirty is not broken. It does what live migration needed, well enough that forensic snapshot chains already use it. The problem is that forensics asks a different question, and the interface has no answer for it. Upstream work so far has made the answer cheaper to retrieve without making it richer.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2607/)", "url": "https://lpc.events/event/20/contributions/2607/", "persons": [{"public_name": "Shailja Shaktawat"}]}, {"guid": "lpc20-c3664", "id": "lpc20-c3664", "title": "Enabling Incremental Checkpointing for GPU Workloads", "date": "2026-10-07T10:40:00+02:00", "start": "10:40", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "With the increased adoption of AI workloads, efficient GPU checkpointing mechanisms are becoming crucial for inference, training, fine-tuning, and reinforcement learning workloads. One of the key challenges with GPU checkpointing today is the lack of memory-tracking support that enables incremental snapshots. When the GPU state is checkpointed into host memory, all pages appear modified, preventing CRIU from identifying which pages have changed since the previous checkpoint and resulting in full snapshot of the GPU memory for every iteration. In this talk, we will discuss extending the GPU plugins for CRIU with support for memory tracking that enables efficient incremental checkpointing. We will explore the benefits of this approach and the trade-offs between performance overhead and storage efficiency across different GPU workloads.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2603/)", "url": "https://lpc.events/event/20/contributions/2603/", "persons": [{"public_name": "Radostin Stoyanov"}]}, {"guid": "lpc20-c3666", "id": "lpc20-c3666", "title": "dm-qcow2: device-mapper-based QCOW2 storage for containers", "date": "2026-10-07T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Container storage commonly relies on directory overlays, filesystem-native subvolumes, or thin-provisioned block devices. We will explore another approach: exposing QCOW2 images directly as Linux block devices through a device-mapper target. QCOW2 is the standard virtual-disk format across much of the QEMU/KVM ecosystem. Its widespread adoption, mature tooling, and features such as backing-file chains, persistent bitmaps, and sparse allocation make it an attractive option for container storage as well.\r\n\r\nBut just having a nice loop device is not a complete solution. Container storage must also support essential operations such as snapshots, backups, and migration. This talk will show how we map these requirements onto existing device-mapper and Linux kernel capabilities, what is still missing, and which problems remain unsolved.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2605/)", "url": "https://lpc.events/event/20/contributions/2605/", "persons": [{"public_name": "Andrei Zhadchenko"}]}, {"guid": "lpc20-c3665", "id": "lpc20-c3665", "title": "Upgrade restrictions for file descriptors", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "For quite a while there has been a wish from container runtime to be able to restrict how we can reuse a particular file descriptor. For instance, CVE-2019-5736 showcased a privilege escalation in runc, whereby the possibility of reopening `/proc/self/exe` as writeable allowed a malicious image to overwrite the runc binary. That was patched on the user space side by copying runc to a sealed memfd_create() file before executing the target. However, it would be better if we could just set restrictions on how some file descriptor can be used (via procfs or O_EMPTYPATH) to reopen a file as writeable in the first place. Thus we would like to have some kind of upgrade mask for file descriptors.\r\n\r\nEffort has been spent in the past to implement something like this. For instance, by David Drysdale in 2013 and later by Aleksa Sarai as part of openat2(2) in 2019. I want to take some time to summarize some of these past ideas and see why they were unsuccessful, and what makes this in particular a hairy problem. We can finish with some discussion about what a merge-able patchset would look like.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2604/)", "url": "https://lpc.events/event/20/contributions/2604/", "persons": [{"public_name": "Jori Koolstra"}]}, {"guid": "lpc20-c3667", "id": "lpc20-c3667", "title": "Checkpoint/Restore of Device Cgroup eBPF Programs", "date": "2026-10-07T12:20:00+02:00", "start": "12:20", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "After moving OpenVZ containers to cgroup-v2 we are struggling a bit to reach\r\nfeature parity with what we had before. One such feature is running nested\r\nDocker containers inside an OpenVZ (system) container — part of making our\r\ncontainers behave as close to a regular server as possible.\r\n\r\nIn cgroup-v2 the device controller was reformed drastically: device\r\navailability can only be controlled by special BPF_PROG_TYPE_CGROUP_DEVICE\r\nprograms attached to cgroups. Docker naturally relies on this, and systemd also\r\nemploys it for its own services — so a migrated container without these\r\nprograms comes back with its device policy silently dropped. The problem is\r\nthat the BPF interface is asymmetric: the kernel accepts a program, but gives\r\nno way to get it back in a reloadable form. The verified/JITed instructions it\r\ncan report are not portable — the verifier rewrites context accesses and helper\r\ncalls into offsets and addresses specific to the running kernel, so they can\r\nneither pass verification again nor work on another kernel. Mainstream solved\r\nthe same problem for seccomp a decade ago — commit f8e529ed941ba (\"seccomp,\r\nptrace: add support for dumping seccomp filters\") added an API to retrieve\r\nloaded filters specifically for C/R — but for general BPF programs no such interface\r\nexists to this day.\r\n\r\nWe took the seccomp approach for cgroup device programs in the Virtuozzo\r\nkernel: keep a copy of the original, pre-verification instructions at load time\r\nand report it through BPF_OBJ_GET_INFO_BY_FD in a new\r\nbpf_prog_info::orig_prog_insns field. The encoding (struct bpf_insn) and the\r\nCGROUP_DEVICE context are stable UAPI, so on restore the program is simply\r\nreloaded and the destination kernel re-verifies and re-JITs it. On top of this\r\nAPI, CRIU now dumps programs and their per-cgroup attachments (via\r\nBPF_PROG_QUERY), the bpf-prog anon-inode fds held by processes, and on restore\r\nre-attaches everything once the cgroup tree is recreated, preserving the\r\noriginal sharing topology.\r\n\r\nIn this talk we will go over the kernel and CRIU sides of the design and\r\ndiscuss whether such an interface could be accepted in mainstream, along with\r\nthe open problems on the way to generic BPF checkpoint/restore: original\r\ninstructions for arbitrary program types, maps and their contents, links, and\r\npinned objects.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2606/)", "url": "https://lpc.events/event/20/contributions/2606/", "persons": [{"public_name": "Pavel Tikhomirov"}]}, {"guid": "lpc20-c3669", "id": "lpc20-c3669", "title": "Addressing Challenges for Container Migration in Heterogeneous Clusters", "date": "2026-10-07T12:40:00+02:00", "start": "12:40", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Checkpoint/Restore (C/R) is increasingly used for both startup acceleration (restoring pre-warmed snapshot instances on demand) and live migration. However, deploying static snapshots or migrating tasks across heterogeneous clusters creates severe runtime bottlenecks when source and target nodes possess differing CPU capabilities. While CRIU and container runtimes can accurately preserve memory state, handling CPU feature consistency and safe architectural state restoration across diverse hardware remains an unsolved problem at the kernel boundary.\r\n\r\nThis session will focus on two critical kernel/userspace interaction challenges:. While CRIU and container runtimes can accurately capture and restore process states and kernel resources, handling CPU feature consistency and safe architectural state restoration across diverse hardware remains an unsolved problem at the kernel boundary.\r\n\r\nThis session will focus on two critical kernel/userspace interaction challenges:\r\n 1. HWCAP Inheritance & Feature Discovery: Examining feature detection failures when restoring snapshots on target nodes with different CPU features, and reviewing proposed mechanisms to inherit or mask hardware capabilities (HWCAP/HWCAP2 via auxv) across execve().\r\n 2. Restoring Extended Signal Frame States: Analyzing edge cases where tasks contain in-flight signal frames with architecture-specific CPU state on their stack. We will discuss why rigid kernel-side frame validation during rt_sigreturn causes restoration failures across hardware generations, and propose flexible validation strategies that prevent state corruption while preserving ABI safety.\r\n\r\nGoal: Align kernel, container, and language runtime maintainers on kernel-assisted CPU feature control and flexible signal-context restoration to make snapshot-based fast-booting and live migration robust across heterogeneous fleets.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2608/)", "url": "https://lpc.events/event/20/contributions/2608/", "persons": [{"public_name": "Andrei Vagin"}]}, {"guid": "lpc20-c3717", "id": "lpc20-c3717", "title": "mmtest benchmarking of cgroup code", "date": "2026-10-07T13:00:00+02:00", "start": "13:00", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Containers and checkpoint/restore MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Triggered by: \r\na) various rstat fixups as well as people reporting issues with (memory).stat reading vs writing performance & precision\r\nb) occasional reports/attempts to make container startup quicker\r\n\r\nProblem statements:\r\na) cgroup rstats need to balance latency requirements of updaters (writers) and readers while preserving sufficient precision. The improvement for one may cause some deterioration at other places -- which is not always clear until those places start being friction points.\r\nb) the cgroup creation path is on critical path of new container starts but there're no good insights into the behavior of those.\r\n\r\nProposed solution:\r\nmmtests shellpack and monitor(s)\r\n\r\nAlternate solutions:\r\n- selftest, LTP tests\r\n- bpftrace probes\r\n- perf-bench\n\n[Open in Indico](https://lpc.events/event/20/contributions/2631/)", "url": "https://lpc.events/event/20/contributions/2631/", "persons": [{"public_name": "Michal Koutný"}]}, {"guid": "lpc20-c3692", "id": "lpc20-c3692", "title": "Backward Compactiliblity of Kernel Livepatching API", "date": "2026-10-07T15:00:00+02:00", "start": "15:00", "duration": "00:20", "room": "Club A (Floor 1)", "track": "LPC: Live Patching MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Kernel livepatches are kernel modules which are able to modify the kernel behavior by redirecting kernel functions, calling pre/post patch callbacks, and allocating shadow variables.\r\n\r\nThe interface between the kernel and the kernel livepatch module is defined in `include/linux/livepatch.h`.\r\n\r\nThe API has evolved over the years. But it has stayed backward compatible since the commit 958ef1e39d24d6cb8bf (\"livepatch: Simplify API by removing registration step\") which was added in v5.1-rc1 back in Jan 2019. This change was part of a patchset adding an **atomic replace** feature.\r\n\r\nThere are two patchsets which would want to break the backward compatibility again:\r\n\r\n - [Better integrate callbacks, shadow variables, and states APIs][1]\r\n - [Replace set support][2]\r\n\r\nIt has been acceptable to break the API back in 2019. But the kernel livepatching has been a pretty new feature and had only few users back then.\r\n\r\nIt might be more acceptable when the tools for creating livepatches can deal with it. But is it enough?\r\n\r\nQuestion for discussion:\r\n\r\n - Is is possible to break the kernel livepatching API in 2026?\r\n - Is it enough to update tools for creating livepatches?\r\n - Is it needed and enough to update klp-build?\r\n - How many old code streams people still support?\r\n - Should selftests stay backward compatible?\r\n\r\n  [1]: https://lore.kernel.org/all/20250115082431.5550-1-pmladek@suse.com/\r\n  [2]: https://lore.kernel.org/all/20260607131659.29281-1-laoar.shao@gmail.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2530/)", "url": "https://lpc.events/event/20/contributions/2530/", "persons": [{"public_name": "Petr Mladek"}]}, {"guid": "lpc20-c3693", "id": "lpc20-c3693", "title": "livepatch: Introduce replace set support", "date": "2026-10-07T15:20:00+02:00", "start": "15:20", "duration": "00:25", "room": "Club A (Floor 1)", "track": "LPC: Live Patching MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "My employer relies heavily on livepatch to rapidly experiment with new kernel features without interrupting production workloads. Our use cases include:\r\n\r\n- Case 1: Deploying a livepatch function as a stable BPF hook. \r\n   For example, some proposals for such a use case has already been submitted upstream but has not yet been accepted: \r\n  https://lwn.net/Articles/1054030/ \r\n  https://lwn.net/Articles/1043548/ \r\n  We also have another internal use case that we do not plan to upstream: \r\n  https://lore.kernel.org/live-patching/CALOAHbDnNba_w_nWH3-S9GAXw0+VKuLTh1gy5hy9Yqgeo4C0iA@mail.gmail.com/\r\n\r\n- Case 2: Combining fleet-wide cumulative livepatches with workload-specific livepatches.\r\n  For example, consider the VFS cache adjustment feature that we previously upstreamed:\r\n  https://lore.kernel.org/linux-fsdevel/20250511083624.9305-1-laoar.shao@gmail.com/\r\n  We initially deployed this feature as a livepatch before upstreaming it. In the livepatch version, we could not introduce a sysctl interface for per-workload tuning, so we used a hard-coded default value and deployed it only to specific servers.    \r\n\r\nIn Case 1, the livepatched BPF hook must remain stable. Otherwise, existing BPF programs may become invalid and need to be reloaded, which could introduce operational risks.\r\n\r\nIn Case 2, we currently need to release different cumulative livepatches for different workloads. However, we would like to have a generic cumulative livepatch combined with individual workload-specific livepatches. This approach would significantly reduce the maintenance burden of managing multiple livepatch variants.\r\n\r\nBased on these requirements, we proposed a hybrid livepatch mode, which allows multiple livepatches to coexist with different scopes. This proposal was later refined into the replace_set support proposal, which has already been discussed on the livepatch mailing list:\r\n\r\n  https://lore.kernel.org/live-patching/20260607131659.29281-1-laoar.shao@gmail.com/\r\n\r\nHowever, several implementation details and design decisions remain open. We would like to discuss them at LPC and determine the best path forward.\r\n\r\nIn this presentation, I will describe how we use livepatch across our large fleet of production servers and discuss the improvements needed to make livepatch suitable for a broader range of use cases.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2526/)", "url": "https://lpc.events/event/20/contributions/2526/", "persons": [{"public_name": "Yafang Shao"}, {"public_name": "Petr Mladek"}]}, {"guid": "lpc20-c3691", "id": "lpc20-c3691", "title": "A Common Coexistence Model for Live Patching and Production Observability", "date": "2026-10-07T15:45:00+02:00", "start": "15:45", "duration": "00:45", "room": "Club A (Floor 1)", "track": "LPC: Live Patching MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "**Abstract**\r\nLarge Linux fleets increasingly depend on always-on observability: BPF programs, ftrace, kprobes, kretprobes, and continuous profiling agents are part of the core production control plane. Kernel livepatching depends on some of the same low-level mechanisms, especially dynamic ftrace-based redirection at function entry. In large production environments, we routinely observe fleet rollout delays because critical security livepatches conflict with system-wide tracing tools anchored to the same target functions.\r\n\r\nThe current kernel documentation notes that kprobes, ftrace, and livepatch must not step on each other, citing limitations like kretprobe conflicts. At fleet scale, these are not just corner cases; they become rollout blockers, visibility gaps, or sources of dangerous runtime uncertainty.\r\n\r\nThis session proposes an upstream discussion to define a predictable, common coexistence model. The goal is to identify the minimum kernel and tooling interfaces needed by livepatch builders, BPF/tracing tool authors, and fleet rollout systems to gracefully handle instrumentation occupancy.\r\n\r\n**Discussion Topics**\r\n\r\n 1. **Conflict Inventory:** Documenting attach-point collisions among livepatch, ftrace, kprobes, and BPF trampolines.\r\n 2. **Occupancy Reporting:** Designing a per-function \"patchability\" report for tools like klp-build and rollout agents.\r\n 3. **Deterministic Failures:** Returning explicit conflict reasons when an attachment is rejected instead of opaque errors.\r\n 4. **Transition Progress:** Exposing standard tracepoints or counters for stuck tasks, forced transitions, and instrumentation blocks.\r\n 5. **Test Coverage:** Expanding kselftest to include negative tests for rejected, unsafe instrumentation combinations.\r\n 6. **Policy & Chaining:** Debating safe chaining semantics and deciding if observability should redirect to replacement functions.\r\n\r\n**Desired Outcome**\r\nAgreement on where these mechanisms belong (kernel ABI, sysfs/debugfs reporting, kselftest, or klp-build metadata). The discussion will involve livepatch, ftrace, kprobe, and BPF maintainers alongside large-fleet operators.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2523/)", "url": "https://lpc.events/event/20/contributions/2523/", "persons": [{"public_name": "Kris Van Hees"}, {"public_name": "Song Liu"}, {"public_name": "Yi Zhu"}]}, {"guid": "lpc20-c3694", "id": "lpc20-c3694", "title": "SFrame for Arm64 Reliable Stacktrace", "date": "2026-10-07T17:00:00+02:00", "start": "17:00", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Live Patching MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The Livepatch consistency model [1] requires the kernel to provide reliable stacktrace in order to be fully supported. On x86, the ORC unwinder provides these reliable stacktraces. However, arm64 misses the required support from objtool: it cannot generate ORC unwind tables for arm64. Prior RFCs have proposed to add this support to objtool, but feedback from the upstream community has indicated that a solution using data produced directly from the compiler would be preferred [2], [3]. \r\n\r\nIn the v6.17 release, the Arm64 kernel gained livepatch support, but without fully reliable stacktrace [4]. With this partial solution, interrupt stacks cannot be reliably traced because the unwinder cannot tell if the Link Register was current at the time the exception was taken.\r\n\r\nSFrame provides a generalized, compiler-based solution, inspired by the ORC unwinder [5], [6]. Currently, there's already an SFrame unwinder proposed for userspace: [7].\r\n\r\nWe would like to propose similar functionality to provide reliable stacktraces within the Arm64 kernel: [8]. This patch series adds to and depends upon the exising userspace patches by factoring out a common SFrame-lookup library which supports both kernel and userspace SFrame sections. Previous versions of this series implemented an SFrame-only kernel unwinder to replace frame-pointer unwinding entirely. However, after receiving feedback, the kernel unwinder now relies on SFrame only when unwinding across an exception boundary, and uses frame pointers everywhere else. This combined strategy enables the best of both worlds: the superior performance of frame-pointer unwinding is kept whenever possible, while the SFrame table allows for fully reliable unwind of a stack with interrupts.\r\n\r\nOngoing mailing list discussion draws into question SFrame's viability as a userspace unwinding solution [9]. This raises several questions around the in-kernel approach, which we would like to bring forward for discussion:\r\n\r\n- What is the current pathway for support for SFrame generation within the LLVM toolchain?\r\n\r\n- The kernel unwind patches continue to have a dependency on the userspace patches. From a development velocity perspective, does this dependency make sense to keep in future versions?\r\n\r\n- For the purpose of unwinding across interrupt boundaries, are there alternatives to SFrame that should be considered?\r\n\r\n[1]: https://docs.kernel.org/livepatch/livepatch.html#consistency-model\r\n[2]: https://lore.kernel.org/live-patching/ZXxO43Xwn5GHsrO8@FVFF77S0Q05N/ \r\n[3]: https://lpc.events/event/17/contributions/1540/attachments/1356/2713/lpc2023-arm64-livepatching.pdf \r\n[4]: https://lore.kernel.org/live-patching/20250320171559.3423224-1-song@kernel.org/ \r\n[5]: https://sourceware.org/binutils/docs/sframe-spec.html\r\n[6]: https://lwn.net/Articles/1029189/ \r\n[7]: https://lore.kernel.org/all/20260505121718.3572346-1-jremus@linux.ibm.com/\r\n[8]: https://lore.kernel.org/lkml/20260519064950.493949-1-dylanbhatch@google.com/\r\n[9]: https://lore.kernel.org/all/CAN30aBFVDxeoXApn_g_Hw0Ayhi4V=m7CcX8UDO6ZDTi6xA-3Pg@mail.gmail.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2529/)", "url": "https://lpc.events/event/20/contributions/2529/", "persons": [{"public_name": "Dylan Hatch"}]}, {"guid": "lpc20-c3695", "id": "lpc20-c3695", "title": "Bringing klp-build to LoongArch: toolchain lessons for the next architecture", "date": "2026-10-07T17:30:00+02:00", "start": "17:30", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Live Patching MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "A series adding LoongArch support to objtool's `klp diff` subcommand (the                                                                                \r\ndiffing engine klp-build invokes to generate a patch module) is under                                                                                    \r\nreview (v4:                                                                                                                                              \r\nhttps://lore.kernel.org/all/20260724114128.31451-1-dongtai.guo@linux.dev).                                                                               \r\nA v5, with a reordering requested by the LoongArch maintainer, is in                                                                                     \r\npreparation. Most of the effort went into the interaction between this                                                                                   \r\ntooling and the LoongArch toolchains, and several findings generalize to                                                                                 \r\nany future architecture with aggressive linker relaxation.                                                                                               \r\n                                                                                                                                                         \r\nThis topic walks through the klp-diff issues surfaced across the review                                                                                  \r\nrounds. They are not one bug but a family of toolchain-interaction                                                                                       \r\nfailures:                                                                                                                                                \r\n                                                                                                                                                         \r\n- *PC-relative reachability.* A livepatch module maps farther than the                                                                                   \r\n  +-2GB a `pcalau12i/addi.d` pair can express, so a klp relocation                                                                                       \r\n  resolving to a vmlinux symbol overflows. Far calls are already                                                                                         \r\n  redirected through a PLT stub by the module loader, but file-local                                                                                     \r\n  static data is materialized inline; a new arch hook rewrites those                                                                                     \r\n  PC-relative data references to GOT-indirect loads. This is not                                                                                         \r\n  Clang-specific: GCC emits the same form.                                                                                                               \r\n- *Local-label anchors.* GCC/GAS on LoongArch anchor relocations to `.L*`                                                                                \r\n  local labels to keep them relaxable, where klp diff assumed a function                                                                                 \r\n  or section symbol plus addend (LLVM folds these labels, so this one is                                                                                 \r\n  toolchain-specific). Fix: normalize `.L*`-anchored relocations back to                                                                                 \r\n  their containing function, fix annotation offsets in                                                                                                   \r\n  `create_fake_symbols`, and collapse `R_LARCH_ADD64/SUB64` pairs into one                                                                               \r\n  PC-relative relocation via `arch_normalize_paired_reloc`.                                                                                              \r\n- *Section pairing and inline alternatives.* Keep both words of each                                                                                     \r\n  `-mannotate-tablejump` annotation entry, and define                                                                                                    \r\n  `ARCH_HAS_INLINE_ALTS` so the `.subsection 1` ALTERNATIVE() replacement\r\n  is cloned, mirroring arm64.\r\nOn the compiler side, livepatch modules on LoongArch require -fPIC\r\n(GOT-indirect access instead of absolute addressing), which collides\r\nwith the kernel's -fno-PIE defaults in non-obvious ways (last-one-wins\r\nflag ordering vs KBUILD_CFLAGS_KERNEL), and Clang rejects GCC-style\r\n\"awM\" special-section flags, requiring ANNOTATE_DATA_SPECIAL.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2525/)", "url": "https://lpc.events/event/20/contributions/2525/", "persons": [{"public_name": "dongtai guo"}]}, {"guid": "lpc20-c3696", "id": "lpc20-c3696", "title": "Testing klp-build: from unit tests to CI", "date": "2026-10-07T18:00:00+02:00", "start": "18:00", "duration": "00:30", "room": "Club A (Floor 1)", "track": "LPC: Live Patching MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "## Abstract\r\n\r\nWith klp-build now merged into mainline, establishing an automated test\r\nsuite is the logical next step.  Historically, maintenance of\r\nkpatch-build, a similar livepatching creation tool, has shown that the\r\nobject diff and correlation layer accounts for the vast majority of\r\nregressions.  Variations across compiler versions, optimization levels,\r\nLTO modes, CFI, and architecture-specific handling in objtool's klp-diff\r\nengine introduce a broad surface area where regressions can easily go\r\nundetected.\r\n\r\nThe existing livepatch kselftests provide a proven model within the\r\nsubsystem.  Developed alongside core livepatching functionality, they\r\nhave caught real bugs, e.g. covering shadow variables, callbacks, and state\r\ntransitions. All while remaining maintainable over time.  klp-build\r\nwarrants a similar testing discipline, tailored to the toolchain layer.\r\n\r\nWe propose a two-tier testing strategy designed for both local developer\r\nworkflows and continuous integration:\r\n\r\n**Unit tests:** Directly exercise `objtool klp diff` against minimal\r\n`.orig.o` / `.patched.o` object pairs.  Scripted assertions verify\r\nsymbol correlation, demangling, checksumming, special-section handling,\r\nand relocations in seconds without requiring a full kernel build.  To\r\nadhere to kernel repository standards and avoid committing binary\r\nartifacts, a CLI-driven runner regenerates test object pairs on demand\r\nfrom module source and a kernel tree using the host/target toolchain.\r\n\r\n**Integration tests:** Execute the complete klp-build pipeline against\r\ndedicated in-tree test infrastructure (`CONFIG_KLP_BUILD_TEST`),\r\nvalidating module post-linking and runtime livepatch loading on target\r\narchitectures.\r\n\r\nBoth tiers target a comprehensive architecture (x86_64, arm64,\r\nLoongArch) and toolchain matrix (GCC, Clang, ThinLTO, CFI).  Our goal is\r\nto integrate these test suites into upstream CI infrastructure (e.g.,\r\nCKI, KernelCI) to provide continuous regression testing across\r\nconfigurations.\r\n\r\nWe invite discussion with the community on several key architectural and\r\nintegration questions:\r\n\r\n**Unit test granularity:** Should tests target individual objtool\r\ncomponents (e.g., checksumming, correlation) independently, or is a\r\nsingle `objtool klp diff` invocation per test case the appropriate\r\nabstraction level?\r\n\r\n**In-tree vs. out-of-tree structure:** Should integration tests reside\r\nin-tree within kselftests while unit tests remain out-of-tree -- and\r\nwhere should the test corpus generation tooling live?\r\n\r\n**Cross-version maintenance:** How can in-tree integration test code be\r\nstructured to remain stable across kernel releases without incurring\r\nunnecessary maintenance overhead?\r\n\r\n**CI pipeline integration:** Should we integrate this this multi-arch,\r\nmulti-toolchain matrix into continuous integration platforms like CKI\r\nand KernelCI?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2528/)", "url": "https://lpc.events/event/20/contributions/2528/", "persons": [{"public_name": "Joe Lawrence"}, {"public_name": "Song Liu"}]}], "Club B+C": [{"guid": "lpc20-c3730", "id": "lpc20-c3730", "title": "The Supply Chain Attack on Buildsystems", "date": "2026-10-07T10:00:00+02:00", "start": "10:00", "duration": "00:30", "room": "Club B+C", "track": "LPC: Build Systems MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Modern embedded Linux build systems such as Yocto and Buildroot rely on complex pipelines that reuse intermediate artifacts and external inputs. While this improves performance and reproducibility, it also creates opportunities for supply chain attacks that are difficult to detect.\r\n\r\nThis talk demonstrates practical attack vectors targeting build systems at different stages of the pipeline. First, we show how intermediate object files produced by make in Buildroot can be tampered with during the build process, resulting in compromised binaries without modifying upstream source code. Next, we explore how shared state (sstate) cache artifacts in Yocto can be poisoned, allowing malicious code to propagate across builds through trusted cache reuse.\r\n\r\nWe demonstrate these attacks end-to-end by injecting malicious behavior into binaries and executing them in a final Linux image under QEMU, illustrating how such compromises can evade traditional verification mechanisms.\r\n\r\nWe then present mitigation strategies, focusing on signing and verification of sstate artifacts to establish trust in reused build outputs. Integration points and tradeoffs between security, performance, and reproducibility are discussed.\r\n\r\nThis session provides a practical look at real-world build system attacks and concrete techniques to harden them. It is aimed at developers and maintainers of build systems, embedded Linux distributions, and toolchains who are concerned with supply chain security.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2582/)", "url": "https://lpc.events/event/20/contributions/2582/", "persons": [{"public_name": "Alejandro Hernandez Samaniego"}]}, {"guid": "lpc20-c3732", "id": "lpc20-c3732", "title": "OpenWrt is reproducible!  How we got there and what we learned", "date": "2026-10-07T10:30:00+02:00", "start": "10:30", "duration": "00:30", "room": "Club B+C", "track": "LPC: Build Systems MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "OpenWrt has been fully reproducible for a few months now, the culmination of many years of work to achieve this important milestone.  In this talk we'll discuss how we got here, what it took, and tips for other build systems that are looking for the same, including how to handle the unique challenges of reproducibility across multiple cross-compilation targets.\r\n\r\nWe'll also go into some of the issues specific to embedded build systems, which platforms took the longest, and some of the rationale for doing it at all.  Thanks to reproducibility, we are much better positioned to tackle a variety of regulations and new requirements on router manufacturing, which we'll address in detail as well.\r\n\r\nJoin us for an enlightening discussion on the hows and whys of making a community-built distribution reproducible, and please bring your questions and thoughts from your own experiences and/or other build systems.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2581/)", "url": "https://lpc.events/event/20/contributions/2581/", "persons": [{"public_name": "Denver Gingerich"}]}, {"guid": "lpc20-c3734", "id": "lpc20-c3734", "title": "Relevance of LTS distro releases and the GenAI world", "date": "2026-10-07T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "Club B+C", "track": "LPC: Build Systems MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Most of Linux distros who follow time based releases, do have LTS release policy e.g. Ubuntu, Yocto, Debian, buildroot to name a few, and then there are rolling releases like archlinux and its family of distros. This talk is to discuss the LTS in the wake of genAI coding agents. There is a fair bit of coding agents at work for yocto project and other distributions doing different functions from CI/CD to generating patches for package upgrades. GenAI coding agents is resulting in increased amount of patches and pace for package upgrades and general patching around distributions. This is going to increase the maintenance load for LTS dramatically in next 2-3 years. We need to rethink the utility of LTS releases and seeing if rolling release model is more viable option for the distributions especially embedded linux distributions which have smaller communities to maintain them. \r\n\r\nWe could use genAI tooling to aid in maintaining LTS releases as well. However, is that the best choice going forward or do we focus on mainline and rolling release model\n\n[Open in Indico](https://lpc.events/event/20/contributions/2586/)", "url": "https://lpc.events/event/20/contributions/2586/", "persons": [{"public_name": "Khem Raj"}]}, {"guid": "lpc20-c3736", "id": "lpc20-c3736", "title": "Bitwise-Reproducible Kernel Builds for the WhatsApp TEE — Proof of Concept", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "00:30", "room": "Club B+C", "track": "LPC: Build Systems MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "A build is bitwise reproducible when compiling the same source with the same configuration and toolchain yields byte-for-byte identical output — an identical vmlinux and bzImage, verifiable by a simple sha256sum. For a normal kernel this is a hygiene property; for a Trusted Execution Environment it is foundational. A platform that measures the code it boots and reports a cryptographic hash  is only meaningful if the expected value can be independently reproduced i.e. if an auditor or WhatsApp itself, or an external reviewer can take the published source and configuration, rebuild the kernel, and arrive at exactly the same hash the hardware attests to. Without bitwise reproducibility there is an unverifiable gap between \"the source we published\" and \"the binary that is running,\" and the attestation degrades from a proof into a promise. Reproducibility closes that gap and lets a TEE's trust chain be checked end-to-end by anyone. The central difficulty is that a stock kernel build is not deterministic by default, it embeds build timestamps, the building user and host, git-derived version strings, an archive of kernel headers, and ephemeral module-signing keys all of which vary run to run and perturb the final hash even when no source changed. The engineering problem is therefore to systematically identify and eliminate every source of non-determinism until two independent builds collapse to a single hash. \r\n\r\nThe strategy we used to obtain a proof of concept was divide and conquer, subsystem by subsystem. The final vmlinux/bzImage hash is just a deterministic function of all the compiled object files linked into it clearly if every .o in every subsystem compiles identically, the whole-kernel hash is necessarily identical. That observation turns an intractable \"the whole image differs\" problem into a localizable one. Rather than chase the top-level hash blindly, the approach hashes every object file in the tree after each of two builds and then diffs the two manifests. The resulting diff lists exactly which objects and subsystems still differ between builds. Each divergent object is a concrete lead pointing at a specific source of non-determinism; fix that source, rebuild, re-diff, and the list shrinks. Reproducibility is reached when the diff is empty. This breaks the problem down into a tractable, iterative hunt that pinpoints where in the build the divergence originates instead of guessing at the image as a whole.\r\n\r\nThe work proceeded as many rebuild-and-compare cycles against a copy of the previous build (t1/, build1/), each cycle narrowing the set of differing objects. Recurring offenders and their fixes\r\n  included:\r\n  - kheaders.o (CONFIG_IKHEADERS), embeds a freshly-archived, timestamped snapshot of the kernel headers that never matches between builds; disabled for the POC.\r\n  - Version strings — CONFIG_LOCALVERSION_AUTO appends a git-derived suffix; disabled (LOCALVERSION_AUTO off, empty LOCALVERSION/BUILD_SALT) and the generated version files under init/ and arch/ were pinned.\r\n  - Module signing (CONFIG_MODULE_SIG) — signs modules with a per-build ephemeral key, guaranteeing divergence; disabled (captured as a standalone remove_module_signing change).\r\n  - Debug/introspection artifacts — CONFIG_GDB_SCRIPTS disabled to drop non-deterministic generated content.\r\n  - Build environment — pinned via KBUILD_BUILD_TIMESTAMP, KBUILD_BUILD_USER=builder, KBUILD_BUILD_HOST=buildhost, and SOURCE_DATE_EPOCH, so timestamps and identity strings are fixed rather than sampled from the build machine. The build environment here was a standard Meta devserver, however, to deploy this we would build and deploy an image for a build environment.\r\n  \r\nThe scope of the proof of concept was to establish a clean baseline, the POC was built against Linus's mainline branch (the vanilla upstream tree, origin/linus-upstream) rather than the internal Meta proprietary TEE kernels, isolating the reproducibility problem from the additional out-of-tree patches carried by the production kernel. With the fixes above, two independent builds produced an empty object-level diff every one of the ~4,800 tracked objects matched and identical sha256sum/md5sum values for both vmlinux and arch/x86/boot/bzImage. This demonstrates that a bitwise-reproducible kernel is achievable for the target and validates the subsystem-by-subsystem manifest-diffing method as the path to extend reproducibility from vanilla upstream to the full WhatsApp TEE production kernel.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2584/)", "url": "https://lpc.events/event/20/contributions/2584/", "persons": [{"public_name": "Joshua Lilly"}]}, {"guid": "lpc20-c3737", "id": "lpc20-c3737", "title": "The last step to secure reproducible distribution kernels: Hash-based module integrity checking", "date": "2026-10-07T12:30:00+02:00", "start": "12:30", "duration": "00:30", "room": "Club B+C", "track": "LPC: Build Systems MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The kernels current module signature scheme does not work well together with reproducible builds. If the key is generated at build-time the build is not reproducible. A static key that is known to the public does not provide security, but a static key not known to the public does prevent public rebuilds of the kernel for validation purposes.\r\n\r\nCurrently distributions need to make a tradeoff:\r\n* Allow non-public reproducibility through static module signature keys. At the cost of complexity in build infrastructure and package definitions. (Debian)\r\n* Focus on reproducibility and disable module signatures (NixOS)\r\n* Focus on security and have an irreproducible kernel package (ArchLinux)\r\n\r\nI am proposing the replacement of module signatures for built-in modules with a merkle tree calculated at build-time.\r\nThis solves the problems outlined above and also avoids a lot of the complexity involved in the current implementation.\r\n\r\nAgenda:\r\n* Problem statement\r\n* Current proposal\r\n* Discussion\r\n\r\nDiscussion topics:\r\n* How to strip modules as part of this scheme?\r\n* Problems in the integration with kbuild.\r\n* How to interact with IMA?\r\n* Would it make sense to have a generic and reusable merkle tree implementation?\r\n\r\nCurrent series on LKML: https://lore.kernel.org/lkml/20260505-module-hashes-v5-0-e174a5a49fce@weissschuh.net/\r\nLWN article for the previous implementation: https://lwn.net/Articles/1012946/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2583/)", "url": "https://lpc.events/event/20/contributions/2583/", "persons": [{"public_name": "Thomas Weißschuh"}]}, {"guid": "lpc20-c3740", "id": "lpc20-c3740", "title": "What does \"buildable\" mean during a toolkit migration?", "date": "2026-10-07T13:00:00+02:00", "start": "13:00", "duration": "00:30", "room": "Club B+C", "track": "LPC: Build Systems MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Sugar has been in tree since April 2006. Its last toolkit transition, GTK2 to GTK3, ran from October 2011 to the 0.98 release in November 2012. The current one, GTK3 to GTK4 and X11 to Wayland, is in its second year across twelve repositories. I ported the toolkit and presented that work at [GNOME Asia Summit 2025](https://events.gnome.org/event/303/); this year I mentor the two contributors porting the [sugar shell](https://summerofcode.withgoogle.com/organizations/sugar-labs/projects/details/Yf2eiaqE) and the [activities](https://wiki.sugarlabs.org/go/Activities) set we call [Fructose](https://summerofcode.withgoogle.com/organizations/sugar-labs/projects/details/AwHyY0sr). The stack is deliberately half-migrated and will stay that way for some time.\r\n\r\nThe code side of a toolkit migration is documented. The build side is not, and it has cost this project more time than the porting.\r\n\r\nNothing detects that a set of GObject Introspection typelibs disagree about a major version. The shell requires eleven GI namespaces. One is the project's own C helper library, whose installed typelib was built against GTK3, loaded into a process that already holds GTK4. The process dies at import. In C this is a link error. In GI there is no build-time or package-time gate, and no way to ask whether a set of typelibs can share one process, even though the information is in the typelibs. We fixed it by bumping our own namespace from SugarExt-1.0 to SugarExt-2.0 so the two cannot be confused, which works and is what I would tell the next project to do. Nothing identified it as the problem. It took the first five weeks of a contributor's summer to find. It will recur for any GI-based project that migrates a toolkit while carrying its own introspected library.\r\n\r\nThe versions you have decides what you can test, and nobody has written that down. The shell puts a Wayland compositor inside a widget ([Casilda](https://gitlab.gnome.org/jpu/casilda)), so activities run as Wayland clients inside the shell. Casilda 1.2.1 is the last version that builds against wlroots 0.19. Version 1.2.2 moved to wlroots 0.20, and 1.2.4 raised the GTK requirement to 4.22.2. Our pinned nixpkgs gives us GTK 4.20.3 and wlroots 0.19.2. So a pin two layers away from our own code decides which Casilda we can have, and that decides what a reviewer can run. A contributor on Debian and a reviewer on Nix could not reproduce each other's bugs.\r\n\r\nEven then, a git checkout is not something you can build. Some files only exist in a release tarball: a config module built from a template, and compiled GSettings schemas. You have to make those by hand. One runtime dependency is packaged by no distribution. And the tree carries three build systems at once: autotools from 2006, Meson in the C library, and a pyproject in the new toolkit.\r\n\r\n## Questions I would like to put to the room:\r\n\r\n- Should typelib agreement be a build-time or package-time check? A typelib carries its dependency list version-qualified, readable without loading it. Debian lintian already requires that a package declare a strictly versioned dependency on the typelibs it needs. What I could not find is anything that takes a set of typelibs and answers whether they can share one process. Does that exist, or is there a reason not to build it?\r\n- How should a build system or a distribution represent a stack that is deliberately half-migrated, where the right answer to \"which version\" differs per repository and changes weekly?\r\n- What do you hand a new contributor so they can build a multi-repository stack mid-migration?\r\n- Is there anything for coordinating the patches distributions each end up carrying during an ecosystem-wide toolkit transition?\r\n\r\n## Reference material:\r\n\r\n- Shell migration, 188 files: https://github.com/sugarlabs/sugar/pull/1106\r\n- C helper library, autotools to Meson and GDK4 event porting: https://github.com/sugarlabs/sugar-ext/pull/6\r\n- Toolkit migration talk, GNOME Asia Summit 2025: https://www.youtube.com/live/WZ63lQ-DsOA?t=14725\r\n- GTK4 migration guide: https://docs.gtk.org/gtk4/migrating-3to4.html\n\n[Open in Indico](https://lpc.events/event/20/contributions/2588/)", "url": "https://lpc.events/event/20/contributions/2588/", "persons": [{"public_name": "Krish Pandya"}]}, {"guid": "lpc20-c3625", "id": "lpc20-c3625", "title": "Power Sequencing for Enumberable Busses - Driver Core Integrations?", "date": "2026-10-07T15:00:00+02:00", "start": "15:00", "duration": "00:25", "room": "Club B+C", "track": "LPC: Driver Core MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "On x86 / ACPI platforms, devices on enumerable busses can normally be seen directly by the OS. On device tree platforms, these devices sometimes require extra power sequencing like toggling regulator supplies or GPIO lines. Over the years most of these cases have been solved, but there are still some gaps.\r\n\r\nAs of kernel version v7.0, support for power sequencing generic PCI devices, ones that have no extra toggles that are not part of PCI specification, and M.2 M-key slots is available [[link][1]]. v7.1 then adds support for the PCI part of E-key slots [[link][2]].\r\n\r\nSupport for the USB part of M.2 E-key slots is WIP by the author [[link][3]]. Support for onboard USB devices and USB type A connectors is provided\r\nby the onboard device driver.\r\n\r\nThis session intends to give a quick overview of the current status and discuss whether parts of this could be moved or integrated at the driver core level. These include:\r\n\r\n - Bus code integration for acquiring power sequencers\r\n - Creating stub platform devices to provide power control functionality\r\n   - USB onboard devices\r\n   - PCI pwrctrl devices\r\n\r\nSuch mechanisms could then be reused for the MDIO bus.\r\n\r\n  [1]: https://lore.kernel.org/linux-pci/20260107-pci-m2-v5-0-8173d8a72641@oss.qualcomm.com/\r\n  [2]: https://lore.kernel.org/all/20260326-pci-m2-e-v7-0-43324a7866e6@oss.qualcomm.com/\r\n  [3]: https://lore.kernel.org/all/20260610084053.2059858-1-wenst@chromium.org/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2502/)", "url": "https://lpc.events/event/20/contributions/2502/", "persons": [{"public_name": "Chen-Yu Tsai"}]}, {"guid": "lpc20-c3626", "id": "lpc20-c3626", "title": "Reviving early platform drivers", "date": "2026-10-07T15:25:00+02:00", "start": "15:25", "duration": "00:25", "room": "Club B+C", "track": "LPC: Driver Core MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Certain critical subsystems - clocks, timers and interrupt controllers - sometimes need to be initialized before driver core is made available in driver_init(). To that end, we provide a set of macros: IRQCHIP_DECLARE(), CLK_OF_DECLARE(), TIMER_OF_DECLARE() which allow the kernel to call initialization functions based on compatibles either before reaching the point where actual platform devices matching these compatibles can be created or *instead* of creating them essentially bypassing the driver model entirely.\r\n\r\nThis results in the initialization routines not being able to use many APIs only available to real drivers and - for many modules - never registering with the driver core.\r\n\r\nI've worked on the idea of unifying these paths with a concept of \"early platform drivers\" back in 2018. That work never got anywhere but the \"hacky\" approach for early setup remains.\r\n\r\nI'd like to re-discuss the idea, it's pros and cons and provide possible solutions for the main contention point raised last time: the fact that my series did nothing to automatically convert existing invocations of the _DECLARE() macros to using early platform drivers.\r\n\r\n[1] https://lore.kernel.org/all/20180511162028.20616-1-brgl@bgdev.pl/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2503/)", "url": "https://lpc.events/event/20/contributions/2503/", "persons": [{"public_name": "Bartosz Golaszewski"}]}, {"guid": "lpc20-c3627", "id": "lpc20-c3627", "title": "Evolving support for sync_state to subsystems beyond genpd", "date": "2026-10-07T15:50:00+02:00", "start": "15:50", "duration": "00:25", "room": "Club B+C", "track": "LPC: Driver Core MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "At last LPC in Tokyo we discussed about the limitations of the sync_state support that quite recently was added to the generic PM domain (genpd) subsystem. The conclusion was to mainly focus on making it more fine grained, as this should address most of the problems. Attempts to implement this has been submitted to LKML [1]. Discussion and iterations of the series are moving forward, but a solution is yet to be landed.\r\n\r\nIn this regards, we also have the need to extend the support for sync_state to more subsystems beyond genpd, to move away from the broken the \"disable unused\" features that each subsystem currently provides. Moreover, ideally we prefer the support for sync_state to be adopted on a subsystem basis, rather than relying on a per driver based implementation, which isn't scaling. Attempts have been made to add support to the regulator and clock subsystems, while the support in the interconnect subsystem needs improvements.\r\n\r\nLet's discuss these topics and in particular how we can make subsystem specific implementations to coexist and play along with each other.\r\n\r\n[1]\r\n[PATCH v3 00/13] driver core / pmdomain: Add support for fined grained sync_state\r\nhttps://lore.kernel.org/all/20260508123910.114273-1-ulf.hansson@linaro.org/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2504/)", "url": "https://lpc.events/event/20/contributions/2504/", "persons": [{"public_name": "Ulf Hansson"}]}, {"guid": "lpc20-c3629", "id": "lpc20-c3629", "title": "Constification of sysfs attribute structures", "date": "2026-10-07T16:15:00+02:00", "start": "16:15", "duration": "00:25", "room": "Club B+C", "track": "LPC: Driver Core MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Sysfs attributes are used throughout the kernel to implement UAPI.\r\nSubsystems either use common attributes, like `kobj_attribute` and `device_attr` or define their own wrapper structures.\r\nThese structures are only descriptors defining the behavior of an attribute and normally never change.\r\n\r\nHistorically the attribute however are not marked as `const` and could be modified through their various callbacks. Such modifications are inherently racy and therefore bug-prone or even a vector for attackers to redirect control-flow.\r\n\r\nFor some time I have been working on making it possible to mark all the different attribute structures as `const` to fix these issues.\r\n\r\nAgenda:\r\n* Problem statement (see above)\r\n* Current state\r\n  * Which attributes *can* be marked `const` today?\r\n  * Which attributes are already converted.\r\n* Discussion (see below)\r\n\r\n* Discussion\r\n\r\nDiscussion topics:\r\n* Which attribute types are still missing?\r\n* How can subsystem maintainers convert their custom attribute types?\r\n* How to actually convert all the structure instances throughout the tree?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2505/)", "url": "https://lpc.events/event/20/contributions/2505/", "persons": [{"public_name": "Thomas Weißschuh"}]}, {"guid": "lpc20-c3628", "id": "lpc20-c3628", "title": "Hardware Cross-Dependencies - Solving the Unsolvable", "date": "2026-10-07T17:10:00+02:00", "start": "17:10", "duration": "00:25", "room": "Club B+C", "track": "LPC: Driver Core MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "We are seeing hard to solve cross-dependencies between different SoC subsystems (Rockchip, MediaTek, etc.). For example a power domain needing an I2C regulator, but the I2C regulator needing the I2C bus and the I2C bus driver needing a (different) power domain. This creates a cyclic dependency, since the power domains (or clocks) are usually all behind a single device.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2501/)", "url": "https://lpc.events/event/20/contributions/2501/", "persons": [{"public_name": "AngeloGioacchino Del Regno"}, {"public_name": "Sebastian Reichel"}]}, {"guid": "lpc20-c3630", "id": "lpc20-c3630", "title": "Synx: Cross-core synchronization", "date": "2026-10-07T17:35:00+02:00", "start": "17:35", "duration": "00:25", "room": "Club B+C", "track": "LPC: Driver Core MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "## Abstract\r\n\r\nModern SoCs increasingly run parts of a single pipeline (AI/ML,\r\nvision, camera, graphics, sensors) across a mix of Linux drivers\r\nand firmwares on remote processors (NPUs and AI processors, ISPs,\r\ncompanion cores). Coordinating that pipeline requires\r\nsynchronization objects that can be created, synchronously or\r\nasynchronously waited on, signaled, and released by *any*\r\nparticipant core, Linux and non-Linux, with lifetime tracked\r\nsomewhere no single core owns outright.\r\n\r\n`dma_fence` solves the local version of this problem well, but its\r\nlifetime and callback model assumes a single kernel's view of the\r\nworld. We've developed Synx, a global handle/refcount table for\r\nthis exact cross-processor case, and posted an RFC to dri-devel\r\nand linux-arm-msm describing the model and the specific properties\r\ndma-fence doesn't currently cover (refer supporting links).\r\n\r\nLetting any two remote processors signal each other directly,\r\nwithout routing through the Linux host, cuts latency and avoids an\r\nunnecessary CPU wake-up. The solution has shown power and\r\nperformance benefits in the last few generations of Qualcomm\r\nmobile and XR chipsets, and is gathering more use cases,\r\nspecifically ones involving AI pipelines.\r\n\r\nChristian König redirects us to solve remote signaling in\r\nuserspace: a userspace fence/signaling point model based on\r\ndma-buf, citing XE's userspace wait support, `eventfd`, and ROCm\r\nevents as precedent, with possible common ground centered around\r\n`eventfd`.\r\n\r\n## Discussion points\r\n\r\n(Supposed to evolve as email thread develops)\r\n- the viability of a userspace vs. kernel-space fence model\r\n- the current remote-signaling solutions from other vendors\r\n- scope as standalone or extend current framework. Define\r\n  interfaces.\r\n- model the subsystem crash recovery and cleanup\r\n\r\n## Key people\r\n\r\n- Bartosz Golaszewski\r\n- Dmitry Baryshkov, Srinivas Kandagatla (Driver Core MC; also\r\n  Qualcomm colleagues who reviewed Synx internally)\r\n- Christian König (engaged on the RFC thread)\r\n- Faith Ekstrand / Xe authors (cited by König)\r\n\r\n## Supporting links\r\n- https://lore.kernel.org/dri-devel/5f90bb35-994e-48bd-bf49-3001dcefa2ee@amd.com/\r\n- https://lore.kernel.org/linux-arm-msm/20260806051915.2234481-1-pravinku@quicinc.com/\r\n- formatted duplicate @ https://lore.kernel.org/dri-devel/20260806051915.2234481-1-pravinku@quicinc.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2507/)", "url": "https://lpc.events/event/20/contributions/2507/", "persons": [{"public_name": "Pravin Kumar Ravi"}]}, {"guid": "lpc20-c3631", "id": "lpc20-c3631", "title": "Managing IRQ mapping and deferred probing for ACPI static tables devices", "date": "2026-10-07T18:00:00+02:00", "start": "18:00", "duration": "00:25", "room": "Club B+C", "track": "LPC: Driver Core MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "In ACPI based system,devices can be created out of ACPI static tables entries (eg  ARM64 IORT, GTDT). For those devices, the GSI HW interrupt number is retrieved by reading table specific fields that are different for different static tables. Devices created out of static ACPI tables might be created before the interrupt controller drivers their GSI interrupt is routed to is probed, which means that when the platform device is created the IRQ domain that should be used to map the GSI into a virtual IRQ may not be registered yet.\r\n\r\nThis leaves us with two issues:\r\n\r\n - device drivers for devices created out of static tables can probe only after the interrupt controller driver their IRQ is routed to has probed\r\n - In order to map the virtual IRQ for those devices at device driver probe time, the static table GSI HW IRQ number must be stashed somewhere in the device object so that it can be retrieved and mapped to a virtual IRQ when the device driver is actually probed\r\n\r\nPrototyping for this solution is under way and a solution for ACPI namespace devices was already posted[1] (but that can't solve the problem for devices that are created out of static table entries).\r\n\r\nThis session would help define a way forward.\r\n\r\n[1] https://lore.kernel.org/lkml/20260505-gic-v5-acpi-iwb-probe-deferral-v1-0-b37b85998362@kernel.org/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2506/)", "url": "https://lpc.events/event/20/contributions/2506/", "persons": [{"public_name": "Lorenzo Pieralisi"}]}], "Club E (Floor 1)": [{"guid": "lpc20-c3622", "id": "lpc20-c3622", "title": "Creating self references safely", "date": "2026-10-07T10:00:00+02:00", "start": "10:00", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: Rust MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Self-reference is a common need in kernel code. In fact, this is what motivates the development of `pin-init`. So far, self-references can only be created with unsafe code with explicit use of `Opaque`. This is a discussion about on-going working to support safe creation of self references in the `pin-init` crate.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2498/)", "url": "https://lpc.events/event/20/contributions/2498/", "persons": [{"public_name": "Gary Guo"}]}, {"guid": "lpc20-c3618", "id": "lpc20-c3618", "title": "Reworking `Request` reference counting in the Rust block device driver API", "date": "2026-10-07T10:30:00+02:00", "start": "10:30", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: Rust MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The `kernel::block::mq::Request` type [1] sits on the I/O hot path of every Rust block device driver. A `Request` is jointly referenced by the block layer and the driver, with completion arriving on multiple asynchronous paths, so the type has to encode a non-trivial sharing and lifecycle model with minimal runtime cost.\r\n\r\nThe introduction of `Ownable` [2] gave us a general mechanism for types that oscillate between owned and reference-counted forms, and applying it to `Request` cleaned up parts of the API [3]. However, the resulting scheme remains hard to reason about for reviewers [4]. We would like to use an LPC session to walk through the proposed changes with the wider Rust-for-Linux audience to further the review process.\r\n\r\nTo anchor the discussion, we plan to bring the following content to the session:\r\n\r\n - A walk-through of the reworked reference counting scheme.\r\n - Benchmark results from `rnull` that quantify the cost of the scheme on representative I/O workloads.\r\n\r\nThe goal of the session is to surface concerns from the community, iron out pain points in the API shape, and build shared understanding of why the scheme looks the way it does — so that when the next version hits the list, the basic design is already broadly understood and accepted.\r\n\r\n[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/rust/kernel/block/mq/request.rs?h=v7.1-rc5#n24\r\n[2] https://lore.kernel.org/r/20260224-unique-ref-v16-0-c21afcb118d3@kernel.org\r\n[3] https://lore.kernel.org/r/20260216-rnull-v6-19-rc5-send-v1-5-de9a7af4b469@kernel.org\r\n[4] https://lore.kernel.org/r/87qzopwttw.fsf@kernel.org\n\n[Open in Indico](https://lpc.events/event/20/contributions/2494/)", "url": "https://lpc.events/event/20/contributions/2494/", "persons": [{"public_name": "Andreas Hindborg"}]}, {"guid": "lpc20-c3619", "id": "lpc20-c3619", "title": "dma_fence abstractions: Design and Challenges", "date": "2026-10-07T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: Rust MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The kernel's dma_fence subsystem lays at the heart of every graphics processing unit (GPU) driver. It is a primitive for synchronizing the state of jobs running on GPUs with receiver parties, notably userspace. A number of circumstances make the correct implementation and usage of both C and Rust dma_fence very challenging:\r\n\r\n - The highly asynchronous nature of GPUs, including the fact that they can hang and need to be reset.\r\n - The fact that fences can have an arbitrary number of consumers, both in other drivers and in userspace.\r\n - Various, partially optional, callbacks exist, with which a consumer can run into the code of a producer, whose module might unload at any time.\r\n\r\nSince GPUs can directly access system memory, an incorrect or racing representation of GPU job state by DmaFence could result in memory corruption regardless of Rust's memory safety guarantees.\r\n\r\nMoreover, dma_fences have so far not only been involved in various UAF and refcounting bugs, but are also often involved in deadlock conditions. While making memory bugs impossible was the primary design goal for the Rust abstractions, much attention was also paid to preventing deadlock.\r\n\r\nIn 2026, a shared design, development and upstreaming effort by various parties, notably the Nova and Tyr GPU drivers, has seen much progress. This talk shall give an overview over the general design, solved and persisting problems, and special challenges with Rust regarding these abstractions.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2495/)", "url": "https://lpc.events/event/20/contributions/2495/", "persons": [{"public_name": "Philipp Stanner"}]}, {"guid": "lpc20-c3621", "id": "lpc20-c3621", "title": "Tyr: A Status Update", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "00:25", "room": "Club E (Floor 1)", "track": "LPC: Rust MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Briefly cover the status of the Tyr project and discuss the current blockers in upstream, specially those related to missing Rust abstractions. This presentation intends to discuss and validate the job submission model, including the proposed GPUVM/JobQueue Rust abstractions and their current upstream status, showcasing the different designs between Tyr's initial implementation and what is actually likely to land on mainline.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2497/)", "url": "https://lpc.events/event/20/contributions/2497/", "persons": [{"public_name": "Daniel Almeida"}]}, {"guid": "lpc20-c3620", "id": "lpc20-c3620", "title": "Using Rust for out-of-tree kernel drivers", "date": "2026-10-07T12:25:00+02:00", "start": "12:25", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Rust MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Rust is expanding into more and more places, and it's becoming clear that Rust creates some unique challenges when it comes to drivers that are out-of-tree.\r\n\r\nLike all other Rust drivers, out-of-tree drivers written in Rust require abstractions for the subsystems they interact with. If the driver requires a subsystem that does not yet have abstractions, or if the abstractions exist but are missing some part of the API, then the driver may have to implement the abstraction directly within the driver. However, it can be tricky to implement abstractions (or extend existing abstractions) from outside of the kernel crate.\r\n\r\nIn this topic I would like to discuss approaches for tackling these issues, and also discuss ways in which we are unnecessarily making it more difficult to extend abstractions from drivers.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2496/)", "url": "https://lpc.events/event/20/contributions/2496/", "persons": [{"public_name": "Alice Ryhl"}]}, {"guid": "lpc20-c3624", "id": "lpc20-c3624", "title": "Bridging the C/Rust Divide: Replicating the PWM Subsystem's Success", "date": "2026-10-07T12:45:00+02:00", "start": "12:45", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Rust MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Problem Statement:\r\nIndependent developers driving new Rust bindings often face a major bottleneck: getting their work mainlined by hesitant C subsystem maintainers, and just as importantly, sustaining that collaboration post-merge. Translating modern Rust architectures to maintainers who evaluate designs strictly through C paradigms remains a massive hurdle.\r\n\r\nSession Focus:\r\nThe PWM subsystem recently proved to be a refreshing exception. Using the TH1520 SoC as a hardware target, I successfully upstreamed new PWM bindings by iterating extensively on RFCs and working closely with a supportive C maintainer.\r\n\r\nHowever, the work doesn't stop at the initial merge. The goal of this working session is to use the PWM experience to establish a repeatable playbook for cross-language collaboration. I will start by presenting concrete solutions that worked for PWM, and then open the floor to brainstorm how to replicate this success across the kernel.\r\n\r\nDiscussion Points:\r\nAfter a brief (10-minute) overview of the specific strategies that worked during the PWM review process, we will spend the rest of the session brainstorming solutions to the following:\r\n\r\n- Technical Mapping & The \"C Lens\": Concrete strategies for mapping established C expectations (callbacks, structs) to modern Rust traits. How do we design and explain these API boundaries so they intuitively click for a C maintainer and reduce their review burden?\r\n\r\n- Post-Merge Collaboration: How to maintain momentum after the bindings land. I will share my experience coordinating abstraction and driver fixes via IRC with the C maintainer. We will debate strategies for getting maintainers heavily involved and comfortable reviewing the Rust side on an ongoing basis.\r\n\r\n- \"Marketing\" the Abstractions: Once the initial bindings and driver are merged, how do we effectively market these new abstractions to the wider community? We will brainstorm how to encourage other developers to write new Rust drivers for the subsystem.\r\n\r\nhttps://mwilczynski.dev/posts/bringing-rust-to-the-pwm-subsystem/\n\n**Attachments:**\n- [rust-pwm-talk-final.pdf](https://lpc.events/event/20/contributions/2500/attachments/2019/4553/rust-pwm-talk-final.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2500/)", "url": "https://lpc.events/event/20/contributions/2500/", "persons": [{"public_name": "Michał Wilczyński"}]}, {"guid": "lpc20-c3623", "id": "lpc20-c3623", "title": "BPF CO-RE support in Rust", "date": "2026-10-07T13:05:00+02:00", "start": "13:05", "duration": "00:25", "room": "Club E (Floor 1)", "track": "LPC: Rust MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Writing BPF programs in the long past meant wrestling with Linux kernel version fragmentation. That problem was solved, many years ago, thanks to CO-RE (Compile Once, Run Everywhere) relocations. CO-RE is a mechanism that uses the BTF type format and its relocation entries (`BTF.ext`) to handle layout differences, by patching the loaded BPF bytecode with correct offsets that match the running kernel version.\r\n\r\nHowever, as of today, only C compilers (Clang, GCC) are able to emit these relocations, while the Rust ecosystem has been missing that final piece for 100% developer experience parity.\r\n\r\nIn this talk, we'll dive into the design and experimental implementation of native CO-RE support in the Rust compiler — from the `#[btf_relocatable]` attribute and `core::btf` field-info macros, through compiler lowering to the `llvm.bpf.preserve.field.info` intrinsic, to the final `BTF.ext` emission. We'll also discuss the trade-offs behind requiring explicit relocation queries rather than making ordinary field projection relocatable.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2499/)", "url": "https://lpc.events/event/20/contributions/2499/", "persons": [{"public_name": "Michal Rostecki"}]}, {"guid": "lpc20-c3807", "id": "lpc20-c3807", "title": "Welcome to the Confidential Computing Microconference", "date": "2026-10-07T15:00:00+02:00", "start": "15:00", "duration": "00:10", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Dhaval and Joerg welcome the attendees.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2639/)", "url": "https://lpc.events/event/20/contributions/2639/", "persons": [{"public_name": "Dhaval Giani"}]}, {"guid": "lpc20-c3808", "id": "lpc20-c3808", "title": "Improving TDX Linux integration: changes in TDX Migration and Attestation", "date": "2026-10-07T15:10:00+02:00", "start": "15:10", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Live migration and runtime attestation are two critical features for Confidential Computing to get right, not just in terms of fulfilling customer requirements, but also correct integration into common Linux codebase and overall code simplicity and maintainability.  Based on Linux community feedback, TDX architecture went through a few big changes last year wrt to Live Migration and Attestation to enable simpler Linux integration. \r\n\r\nIn this short talk we will share the key changes, as well as our key learnings in this area that could be useful for other architectures enabling these confidential computing features in Linux. We would also like to hear feedback from the community on other areas where such simplifications can make a great difference.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2340/)", "url": "https://lpc.events/event/20/contributions/2340/", "persons": [{"public_name": "Elena Reshetova"}]}, {"guid": "lpc20-c3809", "id": "lpc20-c3809", "title": "Arm CCA Realm Live Migration", "date": "2026-10-07T15:30:00+02:00", "start": "15:30", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Arm is developing Live Migration ABIs for the Arm Confidential Compute Architecture (CCA), with input and requirements from ecosystem partners. The ABIs are provided by the Realm Management Monitor (RMM), the trusted firmware component responsible for managing Realms.\r\n\r\nThe presentation will start with a short overview of the high-level CCA Live Migration design and the end-to-end process. It will then examine the assumptions and design choices underpinning the ABIs in three areas: core design, platform preconditions, and runtime mechanisms, relating each to the broader security, correctness, and practicality constraints of confidential live migration.\r\n\r\nFinally, the presentation will provide a basis for discussing how the emerging CCA Live Migration ABIs and Linux/KVM infrastructure for confidential-computing migration can inform one another.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2476/)", "url": "https://lpc.events/event/20/contributions/2476/", "persons": [{"public_name": "Mathias Brossard"}]}, {"guid": "lpc20-c3810", "id": "lpc20-c3810", "title": "CoVE in Action: the Landscape of Confidential VMs on RISC-V", "date": "2026-10-07T16:00:00+02:00", "start": "16:00", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "RISC-V CoVE (Confidential VM Extension) brings confidential computing — hardware-enforced isolation of tenant workloads from the hypervisor and cloud operator — to a fully open architecture.\r\nA lightweight TEE Security Manager (TSM) sits below the hypervisor and enforces per-VM memory isolation, while tenants verify their environment through a standard IETF RATS attestation flow. The hypervisor retains scheduling control — it simply cannot see inside a tenant's TEE Virtual Machine (TVM).\r\nWe demonstrate CoVE Deployment Model 1 running end-to-end on real RISC-V hardware, built on OpenSBI and integrated with Kata Containers and the confidential-containers project — bringing confidential computing to container runtimes operators already use. No proprietary extensions, no special hardware — just standard RISC-V silicon.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2472/)", "url": "https://lpc.events/event/20/contributions/2472/", "persons": [{"public_name": "Xiaoxia Cui"}, {"public_name": "Ruoqing He"}]}, {"guid": "lpc20-c3811", "id": "lpc20-c3811", "title": "SEV-TIO implementation challenges", "date": "2026-10-07T17:00:00+02:00", "start": "17:00", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "SEV-TIO is quite known by now, the upstream development is split in stages and continues. The current stages are set to support basic functionality.\r\n\r\nThe talk will focus on extended features and how AMD hardware/firmware is going to implement these. This includes:\r\n- huge pages handling in IOMMU and KVM, how RMP works and what TMPM does in PSMASH_IO.\r\n- IOMMU TLB flushing challenges: a hack for Turin CPU family and a proper fix in the Venice family (new behavior or invlpgb) and what Venice will do in addition to that.\r\n- Cbit and vTOM and how we can allow simultaneous private and shared access for the same device within the same VM + a (useless) way to implement “iommu=pt”-like behavior in the guest.\r\n- sev-guest SNP platform device and using the DMA layer for sharing memory with the hypervisor.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2473/)", "url": "https://lpc.events/event/20/contributions/2473/", "persons": [{"public_name": "Alexey Kardashevskiy"}]}, {"guid": "lpc20-c3812", "id": "lpc20-c3812", "title": "Extending Arm CCA Device Assignment to CXL Type-2 Accelerators", "date": "2026-10-07T17:20:00+02:00", "start": "17:20", "duration": "00:30", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "We are extending Arm CCA device assignment to CXL Type-2 accelerators so a Realm VM can receive such a device with a coherent device memory window. Standard RME-DA assigns a PCIe TDI to a Realm through TDISP, SPDM and IDE, protecting CXL.io traffic. A CXL Type-2 device also exposes a coherent CXL.mem window through HDM decoders and which confidential assignment must also secure.\r\n\r\nRMM v2.0 introduces a PDEV Stream object as a first-class handle for the device security channel and a COH_CMEM stream type for coherent off-chip accelerators - the right primitives to extend CCA to CXL Type-2. Several design problems remain unsolved: how the host TSM obtains and registers the CXL coherent memory range with RMM, how the guest TSM attests that range, and how to coordinate device probe with stream connect so the coherent range is always registered with RMM regardless of call ordering. This session will work through these open questions to align on a direction for upstream development.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2474/)", "url": "https://lpc.events/event/20/contributions/2474/", "persons": [{"public_name": "Ankit Agrawal"}]}, {"guid": "lpc20-c3813", "id": "lpc20-c3813", "title": "Deferring SWIOTLB Bounce to Reduce Heavy CPU Utilization", "date": "2026-10-07T17:50:00+02:00", "start": "17:50", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Coco VMs rely on bounce buffering to use the guest's vCPUs to encrypt and decrypt data for DMA. This memory copy is performed via the SWIOTLB bounce buffer.\r\n\r\nPersistent disk read operations handle completions within their storage interface’s interrupt handler. When SWIOTLB is disabled, the interrupt handler is invoked only after the DMA data transfer is completed. This makes the handler only responsible for quick clean up operations. With SWIOTLB enabled, the read data is currently entirely copied by a vCPU during this interrupt handler which dramatically increases handling time.\r\n\r\nThe memory copy is expensive and should not be done within an interrupt handler since it prolongs the time interrupting other tasks. This problem is exacerbated by each storage interface’s interrupt handler being pinned to run only a specific vCPU. Heavy disk read workloads can cause these pinned vCPUs to spend the entire duration of the workload in the storage interface’s interrupt handler thus starving other tasks. Google has seen cases of these workloads causing softlockups on the pinned vCPUs.\r\n\r\nI have a prototype which defers the SWIOTLB’s memory copy out of the interrupt handler and into a workqueue. This eliminates the softlockup problem. It also allows for the memory copy to be scheduled on other vCPUs; not just the ones pinned to the interrupt handlers. For VMs with a higher vCPU count, this approach increases bandwidth and IOPS. Although, deferring the work has the drawback of slightly decreasing bandwidth for VMs with a low number of vCPUs and slightly increasing latency regardless of vCPU count.\r\n\r\nI would like to gather feedback for my approach and discuss questions I have regarding its enablement. Is this slight latency increase tolerable? Should this feature be enabled by default for VMs with forced SWIOTLB or should the user of the guest kernel be responsible for enabling it? If we decide to enable it by default, should we only enable it for VMs with a higher number of vCPUs? If we decide the user of the guest kernel is responsible for setting it, how should they be able to set it?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2475/)", "url": "https://lpc.events/event/20/contributions/2475/", "persons": [{"public_name": "Ryan Afranji"}]}, {"guid": "lpc20-c3814", "id": "lpc20-c3814", "title": "PMU Event Filtering for Confidential Guests", "date": "2026-10-07T18:10:00+02:00", "start": "18:10", "duration": "00:20", "room": "Club E (Floor 1)", "track": "LPC: Confidential Computing MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "PMU Event filtering is a security feature that allows hypervisors to restrict which performance events guests can monitor, preventing potential side-channel attacks. However, when using hardware-acceleration PMU virtualization, the encrypted VMSA in SEV-ES and SEV-SNP creates a fundamental challenge: hypervisors cannot read or modify guest PMU states directly, which breaks PMC filtering with hardware-accelerated PMU virtualization and prevents confidential VMs from using upcoming AMD feature: Guest PMC Event Filtering.\r\n\r\nThis talk explores how PMC filtering can be restored for SEV-ES and SEV-SNP guests without weakening their isolation guarantees. The key idea is a cooperative model between guest and hypervisor that re-establishes the hypervisor's filtering authority even when it cannot touch the guest's encrypted state directly.\r\n\r\nWe will discuss the protocol design, implementation challenges, and how this approach restores hypervisor security control over guest PMC usage in confidential computing environments.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2477/)", "url": "https://lpc.events/event/20/contributions/2477/", "persons": [{"public_name": "Manali Shukla"}]}], "Club H (Floor 1)": [{"guid": "lpc20-c3784", "id": "lpc20-c3784", "title": "Introduction and Kickoff", "date": "2026-10-07T10:00:00+02:00", "start": "10:00", "duration": "00:02", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "\n\n**Attachments:**\n- [Sched and RT LPC2026.pdf](https://lpc.events/event/20/contributions/2637/attachments/1984/4500/Sched%20and%20RT%20LPC2026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2637/)", "url": "https://lpc.events/event/20/contributions/2637/", "persons": [{"public_name": "Vincent Guittot"}]}, {"guid": "lpc20-c3776", "id": "lpc20-c3776", "title": "Enable runtime modification of nohz_full and managed_irq housekeeping CPUs", "date": "2026-10-07T10:02:00+02:00", "start": "10:02", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "By using the cpuset isolated partition functionality in the Linux\r\nkernel, users are now able to change the set of \"isolcpus[=domain]\"\r\nHK_TYPE_DOMAIN housekeeping CPUs at runtime. This feature is used by\r\nsome Kubernetes based container orchestration platforms to enable the\r\ncreation of containers running latency sensitive workloads like DPDK.\r\n\r\nDomain isolation by itself doesn't provide enough CPU isolation, so the\r\nsystem has to be booted with a set of boot-time enabled nohz_full and\r\nmanaged_irq isolated CPUs which are then combined with runtime domain\r\nisolation to create the desired isolated CPUs for workloads that need\r\nthem. There are some wasted system overhead to have boot-time isolated\r\nnohz_full and managed_irq CPUs that are not actually being used in\r\nisolated cpuset partitons.\r\n\r\nEventually we would like to have nohz_full and managed_irq isolated\r\nCPUs created at runtime when they are needed. This talk is about the\r\nprogress we have made in this direction and additional future works\r\nthat are needed to achieve this goal.\n\n**Attachments:**\n- [2026 LPC - Dynamic nohz_full and managed_irq CPUs.pdf](https://lpc.events/event/20/contributions/2568/attachments/2013/4546/2026%20LPC%20-%20Dynamic%20nohz_full%20and%20managed_irq%20CPUs.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2568/)", "url": "https://lpc.events/event/20/contributions/2568/", "persons": [{"public_name": "Waiman Long"}]}, {"guid": "lpc20-c3777", "id": "lpc20-c3777", "title": "Bringing Proxy Execution’s benefits to Userland / Futexes", "date": "2026-10-07T10:24:00+02:00", "start": "10:24", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "More and more we’re seeing issues around priority (sometimes called performance) inversion of SCHED_NORMAL/BATCH tasks. Particularly if any sort of constraints are put on “background” deprioritized tasks. These background tasks will eventually grab an important lock, and then won’t be constrained and prevented from running for some extended period of time, resulting in all the important tasks becoming blocked waiting for them to release the lock. Since the tasks are fair tasks, the delays are not indefinite, but they still can be substantial and user visible.\r\n\r\nPI Futexes seem like a good solution here, but the underlying rt_mutex behavior doesn’t help SCHED_NORMAL tasks as rt_mutex priority inheritance isn’t used between SCHED_NORMAL tasks since ~v5.10 or so. Further, even on systems where kernels patch rt_mutexes do “nice inheritance” (as imperfect as that is) for NORMAL tasks, the strict rt_mutex handoff behavior results in pi-futex not performing as well as normal futexes.\r\n\r\nThus, there is a desire to preserve the performance characteristics of normal futexes, while also providing priority inheritance to avoid priority/performance inversions.\r\n\r\nProxy Execution has been a feature in development for many years now, which provides semantics similar to what is desired in this case. Proxy Execution works for in-kernel mutexes (and rw_sems), and provides priority-inheritance without the strict handoff ordering and performance overhead that rt_mutexes can cause.  For RT tasks, rt_mutexes and their strict behavior is still important, but for other sched-classes Proxy Execution provides much of the benefits without the costs.\r\n\r\nSo it would be nice to similarly enable futexes to benefit from Proxy Execution’s generalized form of priority inheritance and avoid the negative performance impact of PI futexes.\r\n\r\nUnfortunately, the existing normal futex API is insufficient to be used with Proxy Execution, as when a task is blocked on a futex lock, Proxy Execution has to understand who the owner of that lock is, so they can be run to release the needed lock. Thus we need to find a way to extend the normal futex API so that the lock owner is communicated to the kernel.\r\n\r\nProxy Execution is not yet fully upstream, so this discussion is a little premature, but since uAPI is important to get right, we wanted to start the discussion early so we can plan and work toward an acceptable solution.\n\n**Attachments:**\n- [LPC2026 - Proxy Enabled Futexes.pdf](https://lpc.events/event/20/contributions/2569/attachments/2021/4555/LPC2026%20-%20Proxy%20Enabled%20Futexes.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2569/)", "url": "https://lpc.events/event/20/contributions/2569/", "persons": [{"public_name": "John Stultz"}, {"public_name": "Suleiman  <> Souhlal"}]}, {"guid": "lpc20-c3778", "id": "lpc20-c3778", "title": "PREEMPT_RT: How a simple interface up event might break your realtime", "date": "2026-10-07T10:46:00+02:00", "start": "10:46", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Realtimers know: Resource configuration for RT enabled systems is key. RT applications rely on a proper system configuration and expect this configuration to stay unmodified as long as the application is alive.\r\n\r\nAs it turned out, Linux might silently reconfigure IRQ affinities of network adapters in a way that violates the expected system configuration. While we run into this kind of problem in the area of networking first, the\r\nproblem seems generic to all kind of \"multi queue devices\".\r\n\r\nWe ended up having two problematic situations:\r\n\r\n- RT applications (partially) breaking out of their previously requested system configuration as Linux ignores previously requested affinities during reconfiguration\r\n- non RT applications polluting isolated (RT) CPU cores via IRQs\r\n\r\nAnd there is even more flexibility on the horizon already: The proper system \r\nconfiguration might not be known at boot time. Using container runtimes for the deployment of RT applications requires an adaptive resource management that might change IRQ affinities at runtime.\r\n\r\nIn this session we will showcase a couple of shortcomings related to resource management in the networking area. Starting with how network drivers are\r\nviolating CPU isolation by implementing IRQ spreading, we want to discuss\r\n\r\n - How do we close the gap between cgroups (cpuset controller) and the IRQ core?\r\n - How should we adjust all the affected drivers to honor the cgroup configuration?\r\n - What APIs are necessary to get there?\n\n**Attachments:**\n- [PREEMPT_RT How a simple interface up event might break your realtime.pdf](https://lpc.events/event/20/contributions/2575/attachments/2007/4547/PREEMPT_RT%20How%20a%20simple%20interface%20up%20event%20might%20break%20your%20realtime-1.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2575/)", "url": "https://lpc.events/event/20/contributions/2575/", "persons": [{"public_name": "Florian Bezdeka"}]}, {"guid": "lpc20-c3779", "id": "lpc20-c3779", "title": "Understanding differences in results between timerlat and cyclictest", "date": "2026-10-07T11:08:00+02:00", "start": "11:08", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "The proposal is to discuss differences in results between timerlat and cyclictest and the reasons behind that. Once the reasons are understood, ways to reduce the differences could be sought. In addition, the discussion could include rtla feature parity with rt-tests, as well as between different rtla tools (osnoise, timerlat), and integrating rtla with other tools such as perf.\n\n**Attachments:**\n- [LPC-cyclictest-vs-timerlat.pdf](https://lpc.events/event/20/contributions/2636/attachments/2003/4533/LPC-cyclictest-vs-timerlat.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2636/)", "url": "https://lpc.events/event/20/contributions/2636/", "persons": [{"public_name": "Tomas Glozar"}, {"public_name": "John Kacur"}, {"public_name": "Luis Goncalves"}]}, {"guid": "lpc20-c3780", "id": "lpc20-c3780", "title": "Remaining EEVDF scheduling latency and lag improvement", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Recent improvements have been made in tasks ordering, scheduling latency and lag of the fair/EEVDF scheduler but some issues still remain and will involve more complex mechanisms. The talk will discuss possible solutions for a number of open issues:\r\nHow to fix the remaining out of range lag of tasks ?\r\nHow to further decrease the scheduling latency ?\r\nHow to select the best CPU to minimize scheduling latency?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2570/)", "url": "https://lpc.events/event/20/contributions/2570/", "persons": [{"public_name": "Vincent Guittot"}]}, {"guid": "lpc20-c3781", "id": "lpc20-c3781", "title": "Kernel Sched QoS Interface", "date": "2026-10-07T12:22:00+02:00", "start": "12:22", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Following last year discussion about userspace assissted scheduling [1], schedqos utility is announced [2] and a proposal for kernel interface to help address one of the QoS issues folks see in the wild, DVFS and migration latencies, was sent also [3].\r\n\r\nThe interface proposal is a simple extension to sched_attr, but has the goal of being extensible without requiring further addition to sched_attr.\r\n\r\nSome of the key areas to discuss:\r\n\r\n1. Deprecatability: We want to end up with baggage ABI we don't want to carry forward if internals change and a QoS no longer make sense.\r\n2. Extensibility: We want to allow almost arbitrary description of behavior without having to modify the interface.\r\n3. Discoverability: how can users know a set of QoS are available?\r\n\r\nCurrently there are two proposed users, rampup_multiplier to manage DVFS response time, and tag memory dependency between tasks for cache aware scheduling.\r\n\r\nThe latter had interesting discussions about cookie management and whether ownership should be in kernel space or userspace.\r\n\r\nWe will go through all open questions and hope to come up with a plan of what to do next.\r\n\r\n[1] https://lpc.events/event/19/contributions/2089/\r\n[2] https://lore.kernel.org/lkml/20260415000910.2h5misvwc45bdumu@airbuntu/\r\n[3] https://lore.kernel.org/lkml/20260504020003.71306-9-qyousef@layalina.io/\n\n**Attachments:**\n- [Kernel Sched QoS Interface - LPC 2026.pdf](https://lpc.events/event/20/contributions/2571/attachments/2106/4674/Kernel%20Sched%20QoS%20Interface%20-%20LPC%202026.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2571/)", "url": "https://lpc.events/event/20/contributions/2571/", "persons": [{"public_name": "Qais Yousef"}]}, {"guid": "lpc20-c3782", "id": "lpc20-c3782", "title": "Energy-Aware Scheduling on x86 Hybrid Topologies: Latency Analysis and Idle CPU Selection", "date": "2026-10-07T12:44:00+02:00", "start": "12:44", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "During OSPM 2026, there was an agreement to stop requiring schedutil to enable EAS on x86 platforms, which implies EAS may soon be active by default on these systems.\r\n\r\nEnergy-Aware Scheduling (EAS) places tasks by comparing estimated energy costs across performance domains, directing light tasks to power-efficient cores on asymmetric systems. The known trade-off is that EAS packing introduces runqueue contention when idle CPUs are available: tasks are packed onto fewer CPUs, and wakeups that land on already-busy CPUs incur queuing delay even when other CPUs sit idle.\r\n\r\nThis talk uses quantitative wakeup latency decomposition on x86 hybrid platforms as a starting point to motivate making EAS more aggressive in selecting idle CPUs. I examine where in find_energy_efficient_cpu() idle-CPU preference can be strengthened without abandoning the energy-efficiency objective, measure the resulting impact on tail latency (p99+) and energy consumption via platform power counters, and discuss how the latency–power trade-off compares to the packing baseline.\n\n**Attachments:**\n- [Ricardo-Neri-EAS-latency-idle.pdf](https://lpc.events/event/20/contributions/2574/attachments/2026/4562/Ricardo-Neri-EAS-latency-idle.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2574/)", "url": "https://lpc.events/event/20/contributions/2574/", "persons": [{"public_name": "Ricardo Neri"}]}, {"guid": "lpc20-c3783", "id": "lpc20-c3783", "title": "sparsemask: the missing generic plumbing and next step forward", "date": "2026-10-07T13:06:00+02:00", "start": "13:06", "duration": "00:22", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "As CPU counts grow, Linux scheduler scalability suffers from contention on global cpumasks — frequent atomic updates to shared cachelines become a measurable bottleneck on large core-count systems.\r\n\r\nTwo proposals address this: Steve Sistare's sparsmask, which distributes a cpumask across multiple cachelines to reduce contention [1], and Peter Zijlstra's sbm (sparse bitmap) [2], a simpler, topology-aware evolution of the same idea. While sbm effectively eliminates cacheline ping-pong, its generic infrastructure falls short in one critical area: CPU hotplug handling, where topological information for offline CPUs may be unavailable.\r\n\r\nThis talk covers:\r\n\r\n - **The gap**: shortcomings in the generic sbm layer for hotplug scenarios\r\n - **Peter's proposal for x86** to address the challenges with offline CPUs, and what's still needed to make sparsemask truly generic\r\n - **A scheduler-native alternative**: an orthogonal sbm implementation scoped to the scheduler, leveraging hotplug callbacks to dynamically size sbm allocations.\r\n\r\n\r\nPrevious version of this work was posted at [3] and was discussed at LPC2025.\r\n\r\nReferences:\r\n\r\n[1] https://lore.kernel.org/lkml/1541767840-93588-2-git-send-email-steven.sistare@oracle.com/\r\n[2] https://lore.kernel.org/lkml/20260324120008.GB3738010@noisy.programming.kicks-ass.net/\r\n[3] https://lore.kernel.org/lkml/20251208083602.31898-1-kprateek.nayak@amd.com/\n\n**Attachments:**\n- [sparsemask.pdf](https://lpc.events/event/20/contributions/2573/attachments/2054/4606/sparsemask.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2573/)", "url": "https://lpc.events/event/20/contributions/2573/", "persons": [{"public_name": "Prateek Nayak"}]}, {"guid": "lpc20-c3785", "id": "lpc20-c3785", "title": "Wrap-up", "date": "2026-10-07T13:28:00+02:00", "start": "13:28", "duration": "00:02", "room": "Club H (Floor 1)", "track": "LPC: Scheduler and Real-Time MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "\n\n[Open in Indico](https://lpc.events/event/20/contributions/2638/)", "url": "https://lpc.events/event/20/contributions/2638/", "persons": [{"public_name": "Vincent Guittot"}]}, {"guid": "lpc20-c3609", "id": "lpc20-c3609", "title": "Intro / Welcome", "date": "2026-10-07T15:00:00+02:00", "start": "15:00", "duration": "00:10", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "\n\n[Open in Indico](https://lpc.events/event/20/contributions/2488/)", "url": "https://lpc.events/event/20/contributions/2488/", "persons": []}, {"guid": "lpc20-c3610", "id": "lpc20-c3610", "title": "Bridging the VM Boundary: Scheduling Passthrough via pvsched and sched_ext", "date": "2026-10-07T15:10:00+02:00", "start": "15:10", "duration": "00:18", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "As production workloads increasingly transition to virtual machines for security isolation and resource consolidation in multi-tenant environments, traditional CPU scheduling faces a critical M:N preemption challenge. The host operating system schedules opaque virtual CPUs rather than the actual workload threads. Consequently, the host scheduler remains blind to the varying priorities and latency sensitivities of the guest threads running inside the VM. This leads to severe priority inversion; for instance, the host scheduler cannot differentiate between a vCPU running a low-priority batch or kernel system thread and one executing a latency-sensitive task (such as a critical helper daemon) nested within the same VM. Consequently, critical latency-sensitive work is starved, and physical resources are wasted under host CPU contention.\r\n\r\nTo resolve this, we propose a bidirectional VM Scheduling Passthrough architecture to bridge the VM boundary from a scheduling perspective. This model relies on cooperative, paravirtualized communication to enable host-side awareness and control:\r\n1. Guest-to-Host: The guest kernel exposes scheduling metadata (potential signals include thread-level priorities and latency requirements) to the host.\r\n2. Host-to-Guest / Host Control: The host leverages these guest signals to either (a) intelligently prioritize the execution of a given vCPU, or (b) in a more complete solution, directly select both the vCPU and the specific guest thread running on that vCPU to execute (this latter proposal is more aspirational, and would effectively give the host full scheduling control over the guest, voiding the need for guest scheduling or load balancing).\r\n\r\nImplementing such a model requires a clean separation of mechanism and policy. In line with upstream maintainer feedback, KVM should remain policy-free, acting purely as the communication conduit. We propose sched_ext as the ideal framework to house the scheduling policy, and pvsched as the communication mechanism to share data between host and guest. Running the policy in a host BPF scheduler allows for rapid iteration and workload-specific customization without modifying KVM or the core kernel.\r\n\r\nCurrent upstream efforts, notably the IBM patch series \"Introduce cpu_preferred_mask and steal-driven vCPU backoff\", attempt to address host preemption purely from the guest side. In this model, the guest monitors hypervisor steal time and flags heavily preempted vCPUs as \"non-preferred\" to guide guest-side task migration. While this provides a defensive mechanism, it is unidirectional and reactive. Furthermore, as highlighted by upstream maintainers, this approach faces significant limitations: it risks embedding scheduling policy within the hypervisor, and in high-overcommit scenarios where steal time is elevated across all cores, the guest-side mask degrades, leaving the guest scheduler with no viable execution targets.\r\n\r\npvsched (https://github.com/pvsched/) has undergone some discussion on the list already, and v3 is being prepared.\r\n\r\nIn this session, we want to discuss:\r\n- Interface Design: The updates in pvsched v3\r\n- sched_ext Integration: How sched_ext can ingest these guest signals to influence host scheduling decisions, and conversely, how it can export host scheduling desires back to the guest\n\n[Open in Indico](https://lpc.events/event/20/contributions/2482/)", "url": "https://lpc.events/event/20/contributions/2482/", "persons": [{"public_name": "Josh Don"}, {"public_name": "Vineeth Remanan Pillai"}]}, {"guid": "lpc20-c3611", "id": "lpc20-c3611", "title": "BPF-based Composable Idle cpumask Selection", "date": "2026-10-07T15:28:00+02:00", "start": "15:28", "duration": "00:18", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "All sched_ext schedulers currently use kfuncs to manage their idle cpumask using a hardcoded policy provided by the kernel. This lack of configurability of the current cpumask requires us to add policy through explicit masking operations directly in the scheduler code. This in turn leads to duplicating idle CPU selection logic across schedulers as it is difficult to factor it out.\r\n\r\nThis session discusses a new BPF-based subsystem for idle CPU mask selection. This subsystem abstracts the representation of the idle CPU set behind a common API that exposes explicit alternative policies to the user. The API is portable between schedulers and requires little code to adopt. Internally, the subsystem stores idle CPU information in arena-based data structures. Different structures (e.g., radix trees) provide different performance/scalability tradeoffs and can be tailored to different idle CPU selection policies.\r\n\r\nTopics for this session:\r\n    - Overview of the idle CPU selection subsystem\r\n    - Data structures for representing the idle CPU set, tradeoffs for each\r\n    - Representing policy in a flexible, extensible fashion through the idle selection API\r\n    - Using alternative CPU selection strategies as part of load balancing\n\n[Open in Indico](https://lpc.events/event/20/contributions/2483/)", "url": "https://lpc.events/event/20/contributions/2483/", "persons": [{"public_name": "Emil Tsalapatis"}]}, {"guid": "lpc20-c3612", "id": "lpc20-c3612", "title": "Taming latency spikes caused by lock holder and lock waiter preemption", "date": "2026-10-07T15:46:00+02:00", "start": "15:46", "duration": "00:18", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Preempting a lock holder — or failing to promptly schedule a just-woken\r\nlock waiter — extends the serialized critical section and produces severe\r\ntail-latency (P99) spikes: degraded server throughput, frame-time\r\nspikes and dropped frames in games. Applications hit this on both\r\nkernel-space locks and user-space primitives backed by futexes and SysV\r\nsemaphores. Existing techniques help but leave gaps: proxy execution\r\naddresses kernel-mutex priority inversion but not user-space futex waiters\r\nor counting semaphores, and time-slice extension protects a detected holder\r\nwhile doing nothing for the delayed waiter.\r\n\r\nWe define lock waiter preemption (LWP) as the dual of lock holder\r\npreemption (LHP): the scheduling delay a woken waiter suffers before it\r\nruns, which we have measured at 2–16 ms in production game and server\r\nworkloads. We will present these measurements and a prototype LHP/LWP\r\nmitigation built in a production sched_ext scheduler, then open three\r\nchallenges for community discussion:\r\n\r\n- efficiently identifying lock-related preemption from BPF;\r\n- exposing synchronization state between libc and sched_ext;\r\n- designing lightweight scheduler-assisted locking that improves latency\r\n  without sacrificing scalability.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2484/)", "url": "https://lpc.events/event/20/contributions/2484/", "persons": [{"public_name": "Changwoo Min"}]}, {"guid": "lpc20-c3613", "id": "lpc20-c3613", "title": "Making proxy execution compatible with sched_ext", "date": "2026-10-07T16:04:00+02:00", "start": "16:04", "duration": "00:26", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Proxy execution allows a waiting task (the \"donor\") to donate its execution context to a mutex owner, enabling the owner to continue running while the donor remains eligible on the runqueue.\r\n\r\nToday, proxy execution and sched_ext are mutually exclusive build-time options: a kernel cannot be built with both CONFIG_SCHED_PROXY_EXEC=y and CONFIG_SCHED_CLASS_EXT=y.\r\n\r\nThis limitation is problematic for Linux distributions and anyone who wants to ship a single kernel image while selecting features at runtime.\r\n\r\nAn RFC series proposing support for this integration has already been posted: https://lore.kernel.org/all/20260506174639.535232-1-arighi@nvidia.com/\r\n\r\nHowever, several design questions remain open. This session aims to discuss those issues, reach agreement on the overall approach, and define a concrete plan for moving the integration forward.\n\n**Attachments:**\n- [Making proxy-exeuction compatible with sched_ext.pdf](https://lpc.events/event/20/contributions/2481/attachments/2022/4556/Making%20proxy-exeuction%20compatible%20with%20sched_ext.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2481/)", "url": "https://lpc.events/event/20/contributions/2481/", "persons": [{"public_name": "Andrea Righi"}]}, {"guid": "lpc20-c3614", "id": "lpc20-c3614", "title": "Stickiness: Keeping tasks cache-warm in work-conserving LAVD scheduler", "date": "2026-10-07T17:00:00+02:00", "start": "17:00", "duration": "00:18", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Work-conserving schedulers prefer running tasks on idle CPUs\r\nimmediately, ensuring no processing capacity is wasted while work is\r\nwaiting. In the lavd select_cpu process, when a task wakes, the\r\nscheduler will do its best to seek an idle core and run the task over\r\nthere. However, this idle-oriented CPU selection generally prioritizes\r\nidle cores over the cache-warm cores, leading to more migrations,\r\nmaking the tasks cache-cold, and requiring L1/L2 caches and TLBs to be\r\nrefilled frequently. \r\n\r\nThe work-conserving mechanism works well in some scenarios. However,\r\nthere are cache-sensitive workloads such as edge routers using routing\r\ntables as in-memory KV stores. The migrations to the cold CPU have a\r\nglobal impact, and the cache refilling evicts the other cache lines\r\nand pulls the new ones in, making the cache contention worse and further\r\nimpacting the tail latency.\r\n\r\n\r\n---\r\nWe will present our measurements and open the floor on topics\r\nincluding:\r\n\r\n- **Warmth estimation**: How long does L1/L2/TLB state realistically\r\n  survive on a CPU, and could the kernel expose hardware signals\r\n  (e.g., PMU counters, cache-occupancy registers) usable at\r\n  scheduling-decision frequency?\r\n\r\n- **The wait-or-migrate decision**: Waiting requires predicting when\r\n  a busy CPU will become available (remaining slice + queue service\r\n  time, or queue load?). Which metrics should a scheduler maintain to\r\n  make that prediction accurate?\r\n\r\n- **The scheduler/userspace interface**: Userspace structures (such\r\n  as allocator per-CPU caches) suffer heavily from core migrations.\r\n  Should applications hint their locality needs to the scheduler, or\r\n  should the scheduler expose warmth and migration state to userspace?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2485/)", "url": "https://lpc.events/event/20/contributions/2485/", "persons": [{"public_name": "Gavin Guo"}]}, {"guid": "lpc20-c3615", "id": "lpc20-c3615", "title": "HFI plug in to scx_ext", "date": "2026-10-07T17:18:00+02:00", "start": "17:18", "duration": "00:18", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "This presentation explores how Intel HFI can be integrated with a sched_ext to improve task placement and power-performance efficiency on hybrid Intel systems. HFI provides real-time hardware guidance on which CPUs are better suited for performance- or efficiency-oriented work, or which to avoid, while sched_ext like LAVD supplies an adaptive scheduling framework capable of using that guidance at runtime. By converting HFI output into scheduler-readable CPU hints, the system can bias wakeup placement, avoid degraded cores, and better match task type to CPU capability without hard pinning or manual tuning.\n\n**Attachments:**\n- [LPC2026-scx-lavd-hfi.pptx](https://lpc.events/event/20/contributions/2486/attachments/2018/4552/LPC2026-scx-lavd-hfi.pptx)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2486/)", "url": "https://lpc.events/event/20/contributions/2486/", "persons": [{"public_name": "Srinivas Pandruvada"}]}, {"guid": "lpc20-c3616", "id": "lpc20-c3616", "title": "Automatic placement of accelerator workloads", "date": "2026-10-07T17:36:00+02:00", "start": "17:36", "duration": "00:26", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "Proposal\r\n\r\nOn modern multi-socket, multi-GPU systems, application performance is often limited not by compute availability but by poor CPU/GPU locality. Today, customers are frequently instructed to rely on strict node pinning (numactl) and disabling NUMA balancing in order to avoid costly cross-node memory accesses. While effective in some cases, this approach can be suboptimal, since it limits workloads to a subset of available resources and it also requires deep system knowledge from the user.\r\n\r\nIn this talk, we will explore how GPU-aware auto-affinitization can be implemented directly in the Linux scheduler using sched_ext, enabling dynamic and transparent placement of CPU tasks close to the GPUs they actively use. We discuss the challenges of integrating scheduler-driven task migration with NUMA balancing, handling mixed CPU/GPU thread groups, and avoiding resource over-concentration. Finally, we present design principles showing how scheduler-level techniques can outperform static affinity policies, while simplifying the user experience.\r\n\r\nKey Challenges\r\n\r\nInteraction with NUMA Balancing\r\n\r\nNaively migrating a task closer to its GPU can backfire if the task's memory remains allocated on a remote NUMA node. In such cases, migration may increase memory access latency instead of reducing it.\r\nKey questions explored:\r\nHow can sched_ext and NUMA balancing cooperate rather than conflict?\r\nWhen should migration be deferred or paired with memory migration?\r\n\r\nThread Aggregation and Shared State\r\n\r\nMany GPU-enabled applications use multi-threaded CPU components, where:\r\nOnly a subset of threads directly interacts with the GPU\r\nOther threads share memory, locks, or cache lines with GPU-driving threads\r\nMigrating only GPU-active threads may introduce new inefficiencies due to cross-node communication among threads of the same process.\r\n\r\nWe need to explore strategies for:\r\n\r\nSelective thread aggregation, migrating related threads together\r\nAvoiding overload of a single NUMA node or LLC\r\nBalancing locality benefits against parallel resource contention\r\n\r\nResource Saturation and Fairness\r\n\r\nAutomatically clustering tasks near GPUs risks oversubscribing CPUs, LLCs, or memory bandwidth on specific NUMA nodes. The scheduler must therefore avoid overloading a certain LLC or NUMA node, make optimal use of system resources and maintain fairness.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2487/)", "url": "https://lpc.events/event/20/contributions/2487/", "persons": [{"public_name": "Balbir Singh"}, {"public_name": "Lee Trager"}]}, {"guid": "lpc20-c3617", "id": "lpc20-c3617", "title": "Closing / Final Q&A", "date": "2026-10-07T18:02:00+02:00", "start": "18:02", "duration": "00:28", "room": "Club H (Floor 1)", "track": "LPC: sched_ext: The BPF extensible scheduler class MC", "type": "LPC Microconference", "language": "en", "abstract": "", "description": "\n\n[Open in Indico](https://lpc.events/event/20/contributions/2489/)", "url": "https://lpc.events/event/20/contributions/2489/", "persons": []}], "Conference Hall (Floor 4)": [{"guid": "oss-fd961227bca59c3f218de32ebd7bc56b", "id": "oss-fd961227bca59c3f218de32ebd7bc56b", "title": "How Uber Uses Intelligent Agents for Open Source Governance", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:20", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open Source compliance is no longer just about coping with legal headaches; between navigating the Cyber Resilience Act & managing strict SBOM mandates it is a critical regulatory hurdle. Enforcing these standards without slowing developer velocity is a giant challenge. To solve this, the Uber OSPO overhauled our ecosystem of 6 Monorepos, 4k microrepos & over 35k dependencies to move away from manual audits & remove the friction placed on our engineers.\n We built a system that scans our entire codebase every 24 hours, but detection is only half the battle. By integrating agentic tooling with our compliance policies & historical exception data, our system now makes calculated judgments on resolution versus escalation. The OSPO agent autonomously raises tickets, remediates issues & learns how to handle complex scenarios that would have required legal insight. This has automated our checks and eradicated high risk libraries from our codebase.\n It’s not all as complex as it looks though. With clear policies, legal alignment, and a commitment to learning by doing, any organisation can do this. I'll share Uber's blueprint for turning open source governance into an automated & smart engine.\n\n[Open in Sched](https://osselceu2026.sched.com/event/fd961227bca59c3f218de32ebd7bc56b)", "url": "https://osselceu2026.sched.com/event/fd961227bca59c3f218de32ebd7bc56b", "persons": [{"public_name": "Chris Howard"}]}, {"guid": "oss-9d41c0cd79ee49469c479cb6e161214e", "id": "oss-9d41c0cd79ee49469c479cb6e161214e", "title": "How Open Source Communities and OSPOs Are Responding To AI Assisted Contributions", "date": "2026-10-07T11:40:00+02:00", "start": "11:40", "duration": "00:20", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open source communities are entering a new phase as more contributions are created with AI assistance. This raises a practical question for the ecosystem: how should projects, maintainers, and companies handle AI-assisted contributions while preserving accountability, trust, and review quality? \n \n This session brings together two complementary perspectives:\n 1. An outside-in view of how open source communities are responding, including early observations on how such contributions are being identified and categorized, and \n 2. An inside-out view of what this shift means for OSPO strategy, compliance, and coordination across engineering, legal, IP, and security stakeholders. \n \n Rather than debating AI in the abstract, the talk focuses on concrete issues communities and companies are already facing, including human accountability, maintainer workload, traceability, stewardship, and software supply chain quality.\n \n Attendees will leave with a practical framework for discussing AI-assisted contributions inside their projects, OSPOs, and cross-functional governance teams.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9d41c0cd79ee49469c479cb6e161214e)", "url": "https://osselceu2026.sched.com/event/9d41c0cd79ee49469c479cb6e161214e", "persons": [{"public_name": "Norio Kobota"}, {"public_name": "Alin Jerpelea"}]}, {"guid": "oss-4b937db806935279d0463459884dfba4", "id": "oss-4b937db806935279d0463459884dfba4", "title": "Panel: The Latest From TODO Group: Advocacy, Community, and Our AI Initiatives", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The TODO Group’s mission is to empower and educate open source management best practices inside organizations through effective Open Source Program Offices (OSPOs) and similar initiatives. With the latest developments in AI, as well as the shift of importance in open source across different industries, several new initiatives have been spun up that the community has embraced with fresh energy.\n \n Join the TODO Group Steering Committee as they present the latest updates from the community, including a new Working Group focused on agentic AI tooling for OSPOs, changes to how our content is created and shared, as well as the growth in local events by TODO Group Ambassadors from around the world. The Steering Committee will also share the data they’re collecting in partnership with LF Research that informs ecosystem trends worth exploring and what the TODO Group community wants to focus on most in terms of learnings and growth.\n \n Plan on attending if you’re in an OSPO, looking to create one at your organization, or interested in helping to spin up new open source initiatives!\n\n[Open in Sched](https://osselceu2026.sched.com/event/4b937db806935279d0463459884dfba4)", "url": "https://osselceu2026.sched.com/event/4b937db806935279d0463459884dfba4", "persons": [{"public_name": "Natali Vlatko"}, {"public_name": "Georg Kunz"}, {"public_name": "Ana Jiménez Santamaría"}, {"public_name": "Ashley Wolf"}]}, {"guid": "oss-945c5544edd4a0741e61da8bfa4f2edb", "id": "oss-945c5544edd4a0741e61da8bfa4f2edb", "title": "Open Source as a Government Goal: Berlin’s Strategy for Digital Sovereignty – Lessons Learned", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:20", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Everyone is talking about digital sovereignty - but what happens when a federal state takes this concept seriously? In 2025, Berlin adopted an Open Source strategy to achieve innovation and digital independence through OSS, open standards, and collaboration.\n We report on how this strategy came about and what its implementation means in a complex administrative landscape. Seven measures form the backbone—from establishing an OSPO at ITDZ Berlin to identifying critical software dependencies to giving Open Source priority in procurement law. Behind each measure lie organizational, cultural, and legal challenges.\n What are the low-hanging fruits? Where do strategies reach their limits? And how do you keep a “learning” strategy alive - rather than letting it fizzle out? An honest account of progress and setbacks that shows what others - whether government agencies or companies - can learn from Berlin’s Open Source journey.\n\n[Open in Sched](https://osselceu2026.sched.com/event/945c5544edd4a0741e61da8bfa4f2edb)", "url": "https://osselceu2026.sched.com/event/945c5544edd4a0741e61da8bfa4f2edb", "persons": [{"public_name": "Marcel Scholze"}, {"public_name": "Florian Ebel"}]}, {"guid": "oss-efa1fbbf678b783395f1fecf28bc7b7b", "id": "oss-efa1fbbf678b783395f1fecf28bc7b7b", "title": "Strategic Approach To Demonstrating the Value of OSS Efforts", "date": "2026-10-07T14:45:00+02:00", "start": "14:45", "duration": "00:20", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "We’ve probably all had leadership question the value of our OSS efforts. It can be difficult to frame the value in ways that resonate with stakeholders and clearly articulate the benefits gained through continued OSS contributions. Taking a strategic approach that connects the OSS work with the broader goals and objectives of the organization can demonstrate the value of this work so that the organization can continue to allocate resources to the OSPO or other OSS teams.\n \n Using examples from my decades of experience in OSS, this talk will provide details about how to demonstrate value by focusing on how your OSS work helps the organization achieve their strategies and goals. Every organization has unique needs and goals based on what they are trying to achieve, so there is no “one size fits all” way of demonstrating value, but aligning your OSS strategy with your organization’s goals and focusing on the most strategic projects can help show the value of your efforts. This talk will help you reason about how OSS efforts allow your organization to achieve its goals along with framing and communicating that value in ways that resonate with leadership, funders, and stakeholders.\n\n[Open in Sched](https://osselceu2026.sched.com/event/efa1fbbf678b783395f1fecf28bc7b7b)", "url": "https://osselceu2026.sched.com/event/efa1fbbf678b783395f1fecf28bc7b7b", "persons": [{"public_name": "Dawn Foster"}]}, {"guid": "oss-1551fc3b6705ef3da49c2711e51f5639", "id": "oss-1551fc3b6705ef3da49c2711e51f5639", "title": "BoF: Open by Default or Intent: Inflection Points for Public Sector Open Source Decisions", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS BoF", "language": "en", "abstract": "", "description": "Many organizations have bought into the value of open source, but don't choose to open source everything. This Bird of a Feather session focuses on the inflection points for public sector organizations: what actually causes an organization to move projects from closed source to Open Source, or — just as importantly — to make a deliberate call that something should stay closed. The triggers are rarely just technical. Public Sector organizations may consider the ROI on open sourcing; whether the codebase, the team, and the organization are actually in a position to do this well; if there are regulatory obligations or policy considerations that push you towards being more open or closed. Sometimes the honest answer is that the perceived collaboration overhead (e.g. documentation, governance) may not be worth it for code that's considered throwaway or not ready for public consumption. Session participants will include researchers, representatives from InnerSource Commons and OSPOs in public sector organizations who have experience navigating these decisions.\n\n[Open in Sched](https://osselceu2026.sched.com/event/1551fc3b6705ef3da49c2711e51f5639)", "url": "https://osselceu2026.sched.com/event/1551fc3b6705ef3da49c2711e51f5639", "persons": [{"public_name": "Clare Dillon"}, {"public_name": "Remy DeCausemaker"}, {"public_name": "Johan Linåker"}, {"public_name": "Karel Rietveld"}]}, {"guid": "oss-5ac26cc7d506d0613a9fbdc3ba865584", "id": "oss-5ac26cc7d506d0613a9fbdc3ba865584", "title": "MCP and AI Protocols: Questions for Open Source Managers", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:20", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open protocols are creating a new layer of infrastructure for how AI agents connect to tools, data, and each other. For OSPOs and open source managers, this also creates a new governance surface: How should open source repositories document instructions for AI agents?; What policies are needed for AI-assisted contributions?; How can OSPOs help bring an open source perspective into agentic AI policies and processes while working with the teams responsible for security, legal and platform engineering?\n \n This talk will introduce the basic concepts behind the open agent protocol landscape, with a special focus on the Model Context Protocol (MCP), and explore how OSPOs can apply this knowledge to open source policies, developer experience, contribution workflows, and reporting\n \n The session will close with a few open questions and practical considerations for open source managers starting to explore this space, including how collaborative efforts such as TODO Group’s Agentic AI to Empower OSPOs initiative can help the community build in collaboration\n\n[Open in Sched](https://osselceu2026.sched.com/event/5ac26cc7d506d0613a9fbdc3ba865584)", "url": "https://osselceu2026.sched.com/event/5ac26cc7d506d0613a9fbdc3ba865584", "persons": [{"public_name": "Ana Jiménez Santamaría"}]}, {"guid": "oss-73df69bada8b3920cf52ec8ca81e5ec4", "id": "oss-73df69bada8b3920cf52ec8ca81e5ec4", "title": "AI Everywhere, Trust Nowhere: Navigating Open Source Security, \"AI Slop,\" and the New Attack Surface", "date": "2026-10-07T16:50:00+02:00", "start": "16:50", "duration": "00:20", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Artificial Intelligence is fundamentally changing the open-source ecosystem, promising unparalleled development velocity. However, this speed scales risk simultaneously. Open-source software (OSS) maintainers—already heavily resource-constrained and unevenly funded—are finding themselves caught in a crossfire of AI-driven complications.\n \nThis session, led by the Open Source Security Foundation (OpenSSF), breaks down the three critical security paradigm shifts introduced by AI:\n \nSecurely Using AI to Build Software: How insecure-by-default code suggestions, copied risks, and hallucinated packages compromise codebase integrity.\n \nUsing AI to Secure Software: The reality of how upstream maintainers are overwhelmed by a massive influx of automated vulnerability reports generated by AI bug hunters. \n AI as an Attack Surface: Moving past traditional DevSecOps to address MLSecOps pipeline vulnerabilities, including data poisoning, model theft, and container security across the machine learning lifecycle.\n \nAttendees will walk away with an understanding of OpenSSF’s recommended approach designed to shift the focus from cheap \"findings\" to valuable, validated \"fixes\".\n\n[Open in Sched](https://osselceu2026.sched.com/event/73df69bada8b3920cf52ec8ca81e5ec4)", "url": "https://osselceu2026.sched.com/event/73df69bada8b3920cf52ec8ca81e5ec4", "persons": [{"public_name": "Adrianne Marcum"}, {"public_name": "Christopher Robinson"}]}, {"guid": "oss-e3306949c2ac930658a3817671a01f00", "id": "oss-e3306949c2ac930658a3817671a01f00", "title": "Panel Discussion: Open Source in a Software-Defined World", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Many initially hardware-driven industries, undergo a profound transformation and become more defined by software like it is the case in the automotive industry. Driven by increasing software complexity, this shift demands unprecedented levels of collaboration and joint integration. As many organizations whose core business was not selling software accelerate towards a more software-defined world, a critical question is how to consume, grow, run and consume the involved Open Source projects to deliver lasting value. \n \n While many of the effects of open collaboration are not unique to a particular domain, the lessons learned from already more \"software-defined\" industries unlock invaluable insights that are collected in the TODO Group Business Guide. \n \n Taking the learnings from that guide, this panel will delve into how Open Source activities effectively contribute to reaching business goals. \n \n Join us to uncover enablers of sustainable Open Source development, learn from cross-industry successes, and equip your teams with the necessary competencies to thrive in the rapidly evolving software-defined world.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e3306949c2ac930658a3817671a01f00)", "url": "https://osselceu2026.sched.com/event/e3306949c2ac930658a3817671a01f00", "persons": [{"public_name": "Sven Jeroschewski"}, {"public_name": "Ana Jiménez Santamaría"}, {"public_name": "Cornelius Schumacher"}, {"public_name": "Agustin Benito Bethencourt"}, {"public_name": "Emily Omier"}]}], "Congress Hall (Floor 2)": [{"guid": "oss-a955170235befb1bfe0a2143ca62eda5", "id": "oss-a955170235befb1bfe0a2143ca62eda5", "title": "Keynote: Welcome & Opening Remarks", "date": "2026-10-07T09:00:00+02:00", "start": "09:00", "duration": "00:45", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/a955170235befb1bfe0a2143ca62eda5)", "url": "https://osselceu2026.sched.com/event/a955170235befb1bfe0a2143ca62eda5", "persons": [{"public_name": "Thierry Carrez"}, {"public_name": "LF Europe with Special Guests"}]}, {"guid": "oss-825045af27aa7d881084280103e846d7", "id": "oss-825045af27aa7d881084280103e846d7", "title": "Keynote: Technical Documentation for Everyone (And Their AI Agents, Too)", "date": "2026-10-07T09:50:00+02:00", "start": "09:50", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "In this session, you'll learn about the history and future of the Docsy technical documentation project, why you should care about documentation EVEN MORE in the age of AI, and how everyone can and should contribute to open source documentation.\n\n[Open in Sched](https://osselceu2026.sched.com/event/825045af27aa7d881084280103e846d7)", "url": "https://osselceu2026.sched.com/event/825045af27aa7d881084280103e846d7", "persons": [{"public_name": "Erin McKean"}]}, {"guid": "oss-d95921a8fb6f1de1dcaa4f3fbcfa4e54", "id": "oss-d95921a8fb6f1de1dcaa4f3fbcfa4e54", "title": "Keynote: Open Standards for Trusted Agentic Workloads", "date": "2026-10-07T10:05:00+02:00", "start": "10:05", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "Agentic workloads must securely connect to tools, data, and other agents while operating within consistent authorization and security boundaries. Open standards make this possible. We'll discuss how technologies like MCP and Cedar create an \"agent trust stack\" for interoperable and scalable agentic systems so that developers have the freedom to compose and extend their agentic architectures securely, wherever they want to build.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d95921a8fb6f1de1dcaa4f3fbcfa4e54)", "url": "https://osselceu2026.sched.com/event/d95921a8fb6f1de1dcaa4f3fbcfa4e54", "persons": [{"public_name": "Laura Tacho"}]}, {"guid": "oss-ebb2893dc76edb7f7b1d5da81a318a89", "id": "oss-ebb2893dc76edb7f7b1d5da81a318a89", "title": "Keynote: Open Source at a Crossroads: Geopolitics, Sovereignty, and the Fight to Stay Open", "date": "2026-10-07T10:15:00+02:00", "start": "10:15", "duration": "00:15", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "Open source was built on one belief: code has no passport. Nation-states are testing whether that holds.The EU’s Cyber Resilience Act burdens the ecosystem it depends on. US export controls threaten to erase the line between open and proprietary code — a protection open source has relied on for decades. China has made open source AI a national strategy pillar, building a parallel ecosystem resilient to Western sanctions. The 2024 removal of Russian Linux kernel maintainers showed that open source is no longer above the law of nations.\nNone of these actors set out to break the commons. But their decisions often made without open source expertise create tensions governance was never designed to handle: sovereignty-through-openness vs. sovereignty-through-restriction; what “open source first” means for companies that relicensed; what neutrality means when contributors face conflicting national laws; and whether open source AI becomes a geopolitical battleground or shared resource.\nEngage policymakers before they damage the ecosystem, build governance for a fragmented world, and recommit to the principle that openness is not a vulnerability — it is the source of our strength.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ebb2893dc76edb7f7b1d5da81a318a89)", "url": "https://osselceu2026.sched.com/event/ebb2893dc76edb7f7b1d5da81a318a89", "persons": [{"public_name": "Nithya Ruff"}, {"public_name": "Johan Linaker"}, {"public_name": "Adjunct Assistant Professor"}]}, {"guid": "oss-431ad8e585d3b71be4d2da9979acc0bd", "id": "oss-431ad8e585d3b71be4d2da9979acc0bd", "title": "Sponsor Activity", "date": "2026-10-07T10:45:00+02:00", "start": "10:45", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Discover openEuler @ AI Infra — the open-source OS for digital infrastructure. With the world's first supernode-oriented OS, it delivers memory unified addressing, low-latency heterogeneous communication, and global resource pooling for efficient AI training and inference. Visit our booth for more and get a laptop bag & storage bag!\n\nSponsor: OpenAtom openEuler\nLocation: Booth P3, Floor 2 - Congress Hall 2C Foyer in Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/431ad8e585d3b71be4d2da9979acc0bd)", "url": "https://osselceu2026.sched.com/event/431ad8e585d3b71be4d2da9979acc0bd", "persons": [{"public_name": "openEuler @ AI Infra"}]}, {"guid": "oss-e5b9a857340e2454e0728f54244c19d9", "id": "oss-e5b9a857340e2454e0728f54244c19d9", "title": "Sponsor Activity", "date": "2026-10-07T10:45:00+02:00", "start": "10:45", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Stop by the openKylin booth, join our activities, and enter for a chance to win exciting prizes—including the PocketClaw! Meet developers and open-source enthusiasts from around the world, connect with the openKylin community, and explore what’s next for open-source operating systems\n\nSponsor: openKylin\nLocation: Booth D2, Floor 2 - Congress Hall 2C Foyer in Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e5b9a857340e2454e0728f54244c19d9)", "url": "https://osselceu2026.sched.com/event/e5b9a857340e2454e0728f54244c19d9", "persons": [{"public_name": "The Great openKylin Lobster Lucky Draw"}]}, {"guid": "oss-4c7e9744e9f7c63546fb9834a6eb2980", "id": "oss-4c7e9744e9f7c63546fb9834a6eb2980", "title": "Sponsor Activity", "date": "2026-10-07T11:00:00+02:00", "start": "11:00", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Experience the future of app interfaces! Stop by our booth to see dynamic Generative UI built in real time with Flutter. Learn how AI agents render interactive, on-the-fly UI components seamlessly on every platform, and walk away with actionable code samples and swag! \n\nSponsor: Google Cloud\nLocation: Booth 31 at Floor 2 Foyer - Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4c7e9744e9f7c63546fb9834a6eb2980)", "url": "https://osselceu2026.sched.com/event/4c7e9744e9f7c63546fb9834a6eb2980", "persons": [{"public_name": "Build Dynamic Generative UI Experiences Live with Flutter and AI Agents"}]}], "Congress Hall Foyer 0 A (Floor 0)": [{"guid": "oss-1f60f4b4d201e88ca1ec1180574508ef", "id": "oss-1f60f4b4d201e88ca1ec1180574508ef", "title": "Registration & Badge Pick-Up", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "11:00", "room": "Congress Hall Foyer 0 A (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/1f60f4b4d201e88ca1ec1180574508ef)", "url": "https://osselceu2026.sched.com/event/1f60f4b4d201e88ca1ec1180574508ef", "persons": []}], "Congress Hall Foyer 0 B (Floor 0)": [{"guid": "oss-f79210e0d4aaa2acfcc82de257b67784", "id": "oss-f79210e0d4aaa2acfcc82de257b67784", "title": "Cloakroom", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "10:50", "room": "Congress Hall Foyer 0 B (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/f79210e0d4aaa2acfcc82de257b67784)", "url": "https://osselceu2026.sched.com/event/f79210e0d4aaa2acfcc82de257b67784", "persons": []}], "Congress Hall Foyer 3 B (Floor 3)": [{"guid": "oss-6ef62fae276efbc3151f7a1481e8fd93", "id": "oss-6ef62fae276efbc3151f7a1481e8fd93", "title": "Embedded Linux Community Hub", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "09:55", "room": "Congress Hall Foyer 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6ef62fae276efbc3151f7a1481e8fd93)", "url": "https://osselceu2026.sched.com/event/6ef62fae276efbc3151f7a1481e8fd93", "persons": []}], "Congress Hall Foyer 4 B (Floor 4)": [{"guid": "oss-d938987fb4e26b0144d68dcb40fc2916", "id": "oss-d938987fb4e26b0144d68dcb40fc2916", "title": "Women & Non-Binary Lunch", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "01:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "We’d like to invite all attendees who identify as women or non-binary to join each other for a networking lunch at the event. We will begin with a brief introduction and then attendees will be free to enjoy lunch and mingle with one another. All attendees must identify as a woman or non-binary and must be registered for the conference to attend.\n\n*We will do our best to accommodate all interested attendees, but please note that participation is on a first-come, first-served basis.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d938987fb4e26b0144d68dcb40fc2916)", "url": "https://osselceu2026.sched.com/event/d938987fb4e26b0144d68dcb40fc2916", "persons": []}, {"guid": "oss-0c76708dc0b9d72851e54d69aa7271e1", "id": "oss-0c76708dc0b9d72851e54d69aa7271e1", "title": "Ask the Expert Session: Chris Howard, Head of Open Source, on consuming OSS at scale", "date": "2026-10-07T15:05:00+02:00", "start": "15:05", "duration": "00:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Ask The Experts", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Ask Chris about consuming OSS at scale.\n\nCome sit down with some open source experts to gain knowledge 1:1 and ask all your pressing questions! No sign-up necessary. More information to come!\n\n[Open in Sched](https://osselceu2026.sched.com/event/0c76708dc0b9d72851e54d69aa7271e1)", "url": "https://osselceu2026.sched.com/event/0c76708dc0b9d72851e54d69aa7271e1", "persons": []}, {"guid": "oss-3b30c2f716d0b7c5e56b9e91c512cad6", "id": "oss-3b30c2f716d0b7c5e56b9e91c512cad6", "title": "Ask the Expert Session: Jan Altenberg, Director R&D, on Linux and Real-Time", "date": "2026-10-07T15:05:00+02:00", "start": "15:05", "duration": "00:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Ask The Experts", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Ask Jan about Linux and Real-Time.\n\nCome sit down with some open source experts to gain knowledge 1:1 and ask all your pressing questions! No sign-up necessary.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3b30c2f716d0b7c5e56b9e91c512cad6)", "url": "https://osselceu2026.sched.com/event/3b30c2f716d0b7c5e56b9e91c512cad6", "persons": []}, {"guid": "oss-1bf99a216bdf10738ef2079b3a93938b", "id": "oss-1bf99a216bdf10738ef2079b3a93938b", "title": "Ask the Expert Session: Ruth Suehle, Vice President, Open Source Strategy and Ecosystems, on foundations and governance", "date": "2026-10-07T15:05:00+02:00", "start": "15:05", "duration": "00:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Ask The Experts", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Ask Ruth about foundations and governance. \n\nCome sit down with some open source experts to gain knowledge 1:1 and ask all your pressing questions! No sign-up necessary. More information to come!\n\n[Open in Sched](https://osselceu2026.sched.com/event/1bf99a216bdf10738ef2079b3a93938b)", "url": "https://osselceu2026.sched.com/event/1bf99a216bdf10738ef2079b3a93938b", "persons": []}], "Forum Hall (Floor 2)": [{"guid": "oss-3e67131b17d2f738b0f224feefc3ed9a", "id": "oss-3e67131b17d2f738b0f224feefc3ed9a", "title": "GraphRAG: Building a Galactic Knowledge Layer for Enterprise AI", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Even a galactic empire can fail when its AI retrieves the right documents but misses the connections between them. Following one ambitious stormtrooper through a series of increasingly consequential knowledge failures, this talk explores how GraphRAG, graph-based retrieval, and graph memory have become a cornerstone of modern enterprise knowledge systems.\nBased on the O’Reilly book GraphRAG: The Definitive Guide by Stephen Chin, Michael Hunger, and Jesús Barrasa, the session provides a practical map of the patterns behind these systems. We begin with the limits of vector-only RAG when questions are connected, multi-hop, dynamic, or require an explainable evidence chain. From there, we cover knowledge graph construction from structured and unstructured data, ontology-guided extraction, entity resolution, and the roles of lexical, domain, and meta graphs. We examine hybrid retrieval using vector search, BM25, graph filtering, guided traversal, Cypher templates, Text2Cypher, graph embeddings, community detection, and query-focused summarization. We then connect retrieval to graph memory and context graphs that preserve conversations, reasoning traces, tool activity, reusable procedures, and changing operational state. Along the way, we address evaluation, provenance, access control, freshness, governance, and the trade-offs involved in moving these systems into production.\nAttendees will leave with a decision framework for designing enterprise knowledge systems that are accurate, explainable, adaptive, and capable of supporting agents beyond the demo.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3e67131b17d2f738b0f224feefc3ed9a)", "url": "https://osselceu2026.sched.com/event/3e67131b17d2f738b0f224feefc3ed9a", "persons": [{"public_name": "Stephen Chin"}]}, {"guid": "oss-b672ffb8dcd59f238632d1ea939ef0e9", "id": "oss-b672ffb8dcd59f238632d1ea939ef0e9", "title": "Off the Laptop, Into Production: An Open Source Stack for AI Agents on Kubernetes", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "AI agents are fast becoming how modern software gets built. But taking one from prototype to safe, production-grade operation is still genuinely challenging, and how they behave at scale remains largely uncharted. Agents are stochastic, so testing becomes continuous evaluation. They run code nobody wrote, so a shared kernel stops being a boundary you can trust. They decide their own network calls at runtime, so egress is no longer predictable. And they still need what any service needs: source control, CI/CD, observability, memory, and tool access.\n \n This session walks the full lifecycle of running agents on Kubernetes, open source the whole way. The \"outer loop\" (build, deploy, trace, evaluate) runs on tools like GitLab, Argo, Langfuse, Milvus, and MCP gateways. The \"inner loop\" (isolated execution) runs on the kubernetes-sigs Agent Sandbox CRD, gVisor, and FQDN-aware egress via Cilium. We'll show what maps cleanly from the platform you run, what changes for agents, and the production gotchas no quickstart warns you about, drawn from building these in the open with teams running from a handful of developer sandboxes to the hundreds of thousands that frontier-scale RL spins up.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b672ffb8dcd59f238632d1ea939ef0e9)", "url": "https://osselceu2026.sched.com/event/b672ffb8dcd59f238632d1ea939ef0e9", "persons": [{"public_name": "Brian Hammons"}, {"public_name": "Nirmal Mehta"}]}, {"guid": "oss-c4e52225e04cc251453807509763feaf", "id": "oss-c4e52225e04cc251453807509763feaf", "title": "Agent Gateway: The One Decision That Eliminates AI Engineering Complexity", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "As AI systems move from experimentation to production, engineering teams face a growing number of infrastructure decisions. How do you secure MCP servers without modifying them? How do you seamlessly transition and fail over across multiple LLM providers? How do you enforce token rate limits and usage policies for LLMs? How do you govern agent-to-agent and agent-to-MCP communication, control context growth, enforce security policies, observe traffic, and scale operations across environments? Rather than solving each challenge independently, organizations can adopt a single architectural pattern: the agent gateway. Through live demos, Lin introduces the agent gateway pattern and demonstrates how it simplifies AI infrastructure by eliminating the need for teams to repeatedly solve the same cross-cutting concerns. Using agentgateway, an open-source implementation of the pattern, she will show how to secure and federate MCP servers without modifying them, route, fail over, and rate limit LLM traffic across providers, enable advanced capabilities such as code mode and progressive disclosure, and operationalize AI workloads on Kubernetes.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c4e52225e04cc251453807509763feaf)", "url": "https://osselceu2026.sched.com/event/c4e52225e04cc251453807509763feaf", "persons": [{"public_name": "Lin Sun"}]}, {"guid": "oss-afec64973b81e396dcfa959aab31762b", "id": "oss-afec64973b81e396dcfa959aab31762b", "title": "Open Secure AI Alliance BoF", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "AI is reshaping both how software is built and how it is attacked, yet defenders often lack open, trustworthy tools to keep pace. This BoF creates a focused forum for security practitioners, maintainers, and newcomers to exchange experiences, ask questions, and learn about the Open Secure AI Alliance, a new Linux Foundation project.It introduces the Alliance's mission to advance AI security through open, collaborative work that produces practical defenses, shared knowledge, and accessible tools, helping defenders use frontier AI they can trust and control to safeguard software and AI agents.By enabling direct interaction and cross-project exchange, the session supports alignment, reduces duplication, and fosters collaboration in an evolving AI security landscape.\n\n[Open in Sched](https://osselceu2026.sched.com/event/afec64973b81e396dcfa959aab31762b)", "url": "https://osselceu2026.sched.com/event/afec64973b81e396dcfa959aab31762b", "persons": [{"public_name": "Mark Weatherford"}]}, {"guid": "oss-70d02dfdc1dbb02872cc369b2929a8f6", "id": "oss-70d02dfdc1dbb02872cc369b2929a8f6", "title": "From Single Agent To Production Swarm: Patterns for Building Reliable Multi-Agent Systems", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "AI agents are evolving from simple chatbots to coordinated systems that plan, collaborate, and execute real-world tasks. But moving from a working prototype to a production-grade multi-agent system is where most teams struggle.\n \n In this session, we will share battle-tested patterns from deploying agent swarms in industrial environments. We cover:\n The architectural shift from single-agent to multi-agent: when and why you need a swarm\n Comparing open source frameworks (LangChain, AutoGen, Strands Agents SDK) — strengths, trade-offs, and selection criteria\n Practical orchestration patterns: task delegation, shared memory, tool coordination via MCP (Model Context Protocol)\n Live demo: building a multi-agent system that collaborates to solve a real task\n Safety-first design: guardrails, execution boundaries, and observability for production\n Attendees will leave with a reusable architectural blueprint applicable to any open source agent framework.\n\n[Open in Sched](https://osselceu2026.sched.com/event/70d02dfdc1dbb02872cc369b2929a8f6)", "url": "https://osselceu2026.sched.com/event/70d02dfdc1dbb02872cc369b2929a8f6", "persons": [{"public_name": "Betty Zheng"}]}, {"guid": "oss-252639ab67686f5de19badb90fef515a", "id": "oss-252639ab67686f5de19badb90fef515a", "title": "Nine Seconds To Production: Security Governance for AI Agents", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "On April 24, 2026, an AI coding agent deleted a company's entire production database in nine seconds. Every customer record, every reservation, and every backup vanished. The system prompt explicitly told the agent never to execute destructive commands. It did it anyway. It was a chain of architectural failures: an agent improvising instead of stopping, overprivileged credentials, no human approval for high-risk actions, and backups inside the same blast radius. This session recreates the incident and rebuilds the security architecture live. You'll see how OPA enforces policy before tools execute, Falco detects suspicious runtime behavior, and OpenTelemetry captures structured reasoning traces for compliance-grade audit logs. We'll implement six defensive layers: pre-execution policy enforcement, runtime behavioral monitoring, structured audit logging, least-privilege execution roles, infrastructure deletion protection, and recovery systems isolated outside the agent trust boundary. Prompts are guidance. Infrastructure is enforcement. You'll leave with a vendor-neutral security architecture for deploying AI agents safely across any framework or LLM provider.\n\n[Open in Sched](https://osselceu2026.sched.com/event/252639ab67686f5de19badb90fef515a)", "url": "https://osselceu2026.sched.com/event/252639ab67686f5de19badb90fef515a", "persons": [{"public_name": "Jasdeep Singh Bhalla"}]}], "Forum Hall Foyer 0 (Floor 0)": [{"guid": "oss-c221bbf8e657e490a46aedbfec7d1f62", "id": "oss-c221bbf8e657e490a46aedbfec7d1f62", "title": "Cloud, Containers & Orchestration Community Hub", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "09:55", "room": "Forum Hall Foyer 0 (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c221bbf8e657e490a46aedbfec7d1f62)", "url": "https://osselceu2026.sched.com/event/c221bbf8e657e490a46aedbfec7d1f62", "persons": []}], "Forum Hall Foyer 1 (Floor 1)": [{"guid": "oss-165ff9968de0ddb91381de6f85561027", "id": "oss-165ff9968de0ddb91381de6f85561027", "title": "Linux Community Hub", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "09:55", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/165ff9968de0ddb91381de6f85561027)", "url": "https://osselceu2026.sched.com/event/165ff9968de0ddb91381de6f85561027", "persons": []}, {"guid": "oss-75fdb00934b7af52c99fc48c3cdb7e87", "id": "oss-75fdb00934b7af52c99fc48c3cdb7e87", "title": "Open AI & Data Community Hub", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "09:55", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/75fdb00934b7af52c99fc48c3cdb7e87)", "url": "https://osselceu2026.sched.com/event/75fdb00934b7af52c99fc48c3cdb7e87", "persons": []}, {"guid": "oss-4556d7fd72fc188fa2a93592de64935d", "id": "oss-4556d7fd72fc188fa2a93592de64935d", "title": "Open Source Leadership Community Hub", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "09:55", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4556d7fd72fc188fa2a93592de64935d)", "url": "https://osselceu2026.sched.com/event/4556d7fd72fc188fa2a93592de64935d", "persons": []}], "Forum Hall Foyer 3 (Floor 3)": [{"guid": "oss-203cf4eb284e73ebc5aaa72d60da1dc5", "id": "oss-203cf4eb284e73ebc5aaa72d60da1dc5", "title": "LF Education Learning Lounge: How Zephyr Is Shaping the Future of Embedded Development", "date": "2026-10-07T11:00:00+02:00", "start": "11:00", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk led by Benjamin Cabé in the Learning Lounge located on the 3rd Floor.\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/203cf4eb284e73ebc5aaa72d60da1dc5)", "url": "https://osselceu2026.sched.com/event/203cf4eb284e73ebc5aaa72d60da1dc5", "persons": []}, {"guid": "oss-64fe8c3c1ec7e09b96a7a4b199b5638b", "id": "oss-64fe8c3c1ec7e09b96a7a4b199b5638b", "title": "LF Education Learning Lounge: Choose Your Character", "date": "2026-10-07T12:30:00+02:00", "start": "12:30", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk led by Federica Nocerino in the Learning Lounge located on the 3rd Floor.\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/64fe8c3c1ec7e09b96a7a4b199b5638b)", "url": "https://osselceu2026.sched.com/event/64fe8c3c1ec7e09b96a7a4b199b5638b", "persons": [{"public_name": "Finding Your Role in Open Source. Your skills are your superpower. Your contribution is your quest."}]}, {"guid": "oss-155edabbf3ed2772feb08698e9afde06", "id": "oss-155edabbf3ed2772feb08698e9afde06", "title": "LF Education Learning Lounge: Don’t Cross Wires", "date": "2026-10-07T15:15:00+02:00", "start": "15:15", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk by Mary Campbell and Randi Armour in the Learning Lounge located on the 3rd Floor.\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/155edabbf3ed2772feb08698e9afde06)", "url": "https://osselceu2026.sched.com/event/155edabbf3ed2772feb08698e9afde06", "persons": [{"public_name": "Cross-Skill: Aligning Teams Around Smart “Learning Paths”"}]}], "Panorama Hall (Floor 1)": [{"guid": "oss-f25baa4e1f92fb5bc2eab0f10afcf3fd", "id": "oss-f25baa4e1f92fb5bc2eab0f10afcf3fd", "title": "What Is Linux Doing With My RAM?", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This talk will cover several memory management concepts and underlying principles to give the audience a better understanding about what happens to the RAM on a Linux system, and how to determine that on their own system, namely: - how much memory is used by userspace processes, the page cache, and the kernel itself - how to determine accurately how much memory is used by individual processes - why free memory is always eventually exhausted and what happens then - how to observe what the kernel is doing to make memory available for allocations, and recognize when it's struggling - what is the role of swap and why not fear swapping This includes explaining some key parts of files like /proc/meminfo and /proc/vmstat.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f25baa4e1f92fb5bc2eab0f10afcf3fd)", "url": "https://osselceu2026.sched.com/event/f25baa4e1f92fb5bc2eab0f10afcf3fd", "persons": [{"public_name": "Vlastimil Babka"}]}, {"guid": "oss-b90d172ccd52a57d0d0305c44e614ef8", "id": "oss-b90d172ccd52a57d0d0305c44e614ef8", "title": "How Secure Is Your OTA Update Flow Really? A Security Researcher's Look at RAUC, SWUpdate etc.", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Over-the-air update frameworks like RAUC, SWUpdate, and others have become the standard way to keep embedded Linux fleets patched in the field. With the EU Cyber Resilience Act raising the bar for product security, and a growing flood of vulnerabilities in open source dependencies, getting your update mechanism right matters more than ever.This talk takes a security researcher's view of the three most common update tools. We start with the fundamentals of secure update delivery and where it tends to go wrong: signature verification gaps, rollback and downgrade attacks, weak trust anchors, and insecure defaults. Each tool provides a different set of security mechanisms with their own subtle ways to fail. This talk will walk attendees through the update signing mechanisms of each tool and explain how to properly use them and what best practices apply.Attendees will leave knowing how to evaluate their own update pipeline, avoid the common misconfigurations, and choose and harden the right tool for their threat model.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b90d172ccd52a57d0d0305c44e614ef8)", "url": "https://osselceu2026.sched.com/event/b90d172ccd52a57d0d0305c44e614ef8", "persons": [{"public_name": "David Gstir"}]}, {"guid": "oss-1aaf0c2f66161cdfc2773569795672a8", "id": "oss-1aaf0c2f66161cdfc2773569795672a8", "title": "You're Measuring Memory Wrong: The Right Ways With DAMON", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Memory efficiency problems are notoriously hard to see. DAMON was built to change that — but many users collect data incorrectly, visualize it poorly, and walk away with wrong conclusions. The tool gets blamed. The real problem goes unfixed.\n \n This talk shows you the right ways to do it.\n \n We cover data collection first: configuring sampling and aggregation parameters, the tradeoffs, and setup mistakes that corrupt your data before analysis begins.\n \n We then walk through the visualization features in `damo` — heatmaps of access frequency across time and address space, working set size plots, and more. There is no single right visualization; we cover when to use each and how to read what it shows.\n \n We also highlight mistakes that lead users astray: misreading sampling artifacts as real patterns, choosing granularities that hide behavior, observing too briefly to catch periodic patterns, and more. For each, we show what misleading output looks like and how to fix it.\n \n By the end, you will know how to collect trustworthy DAMON data, pick the right visualization, and tell when your results are real versus when your setup is lying to you.\n\n[Open in Sched](https://osselceu2026.sched.com/event/1aaf0c2f66161cdfc2773569795672a8)", "url": "https://osselceu2026.sched.com/event/1aaf0c2f66161cdfc2773569795672a8", "persons": [{"public_name": "SeongJae (SJ) Park"}]}, {"guid": "oss-c3468a93e084d34d9fec54a04c8e6bb8", "id": "oss-c3468a93e084d34d9fec54a04c8e6bb8", "title": "FreeBSD as a Linux Platform: LinuxKPI, Linuxulator, and the Case for Convergence", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Linux dominates modern infrastructure, yet its monopoly on hardware support and application ecosystems creates a false premise, that Linux is the only viable platform. FreeBSD has quietly built two production grade compatibility layers that challenge this assumption.\n LinuxKPI implements Linux kernel APIs directly inside the FreeBSD kernel, enabling unmodified GPU, wireless, and RDMA drivers including but not limited to amdgpu, iwlwifi, and Mellanox OFED to compile and run natively. Contrary too emulation this is source-level API compatibility with negligible runtime overhead.\n The Linuxulator complements this at the userland boundary which is a high-performance syscall translation layer that executes unmodified Linux ELF binaries on the FreeBSD kernel, with measured overhead consistently under 2% for I/O-bound workloads.\n Combined with FreeBSD Jails and VNET, operators gain isolated Linux environments with native ZFS storage, DTrace observability, and a hardened network stack without a hypervisor.\n This talk examines the architecture of both layers, their production deployment patterns, and the upstream contribution model that keeps them current with Linux kernel releases.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c3468a93e084d34d9fec54a04c8e6bb8)", "url": "https://osselceu2026.sched.com/event/c3468a93e084d34d9fec54a04c8e6bb8", "persons": [{"public_name": "Moin Rahman"}]}, {"guid": "oss-ee7750a4d27d4ba8e6686f184611d863", "id": "oss-ee7750a4d27d4ba8e6686f184611d863", "title": "Modernizing Vmalloc With Maple Tree: Design, Challenges, and Trade Offs", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Linux has steadily evolved toward Maple Tree as the preferred infrastructure for range-based indexing. While Maple Tree transformed process address-space management, several core memory-management subsystems still rely on legacy rb-tree-based designs.\n \n This session uses the my vmalloc Maple Tree migration patch series as a case study to explore a broader question: what does it take to modernize a mature memory-management subsystem at the heart of the Linux kernel?\n \n Unlike VMAs, vmalloc combines range allocation, gap tracking, coalescing, and lazy reclamation used by drivers, architectures, modules, and core kernel services. More than a data-structure replacement, it demonstrates how foundational kernel infrastructure can evolve while preserving correctness and long-standing semantics.\n \n The talk covers the design motivations behind the transition, key trade-offs between augmented rb-trees and Maple Tree, scalability and metadata-efficiency improvements, and lessons learned from modernizing a core allocator. Attendees will gain insight into vmalloc internals, Maple Tree adoption beyond VMAs, and practical approaches for evolving Linux memory management infrastructure.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ee7750a4d27d4ba8e6686f184611d863)", "url": "https://osselceu2026.sched.com/event/ee7750a4d27d4ba8e6686f184611d863", "persons": [{"public_name": "Pranjal Arya"}]}, {"guid": "oss-e8be2fd655b5b5f33a89c6ea75805b00", "id": "oss-e8be2fd655b5b5f33a89c6ea75805b00", "title": "Sandlock: Rootless and Containerless Confinement for AI Agents", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Your AI agent just wrote some code and wants to run it on your machine. It can read your SSH keys, exfiltrate data to any host, and overwrite your project. How do you give it just enough freedom to be useful, and nothing more?\n \n This talk presents Sandlock, an AI agent sandbox for Linux that locks a process down in about 5 milliseconds using nothing but the kernel. No root. No cgroups. No containers. Spinning up a container or microVM per agent action means image builds, privileged setup, and a ~100 ms tax on every launch. Sandlock makes confinement cheap enough to wrap every command an agent runs.\n \n We will show how it composes three kernel features: Landlock for filesystem, network, and IPC scoping; seccomp-bpf for syscall filtering; and seccomp user notification, where a supervisor enforces memory limits, an IP and port allowlist, HTTP-level ACLs with zero-config HTTPS inspection, and a copy-on-write working directory.\n \n Live demos: pin an agent's egress to a single API, give it data access but no network, preview every file it would change before committing, and see real numbers (44x faster startup than Docker).\n\n[Open in Sched](https://osselceu2026.sched.com/event/e8be2fd655b5b5f33a89c6ea75805b00)", "url": "https://osselceu2026.sched.com/event/e8be2fd655b5b5f33a89c6ea75805b00", "persons": [{"public_name": "Cong Wang"}]}], "Room 4.3 (Floor 4)": [{"guid": "oss-c7af220b3a4ad99f0cad97baef4309ff", "id": "oss-c7af220b3a4ad99f0cad97baef4309ff", "title": "Zen Zone", "date": "2026-10-07T08:00:00+02:00", "start": "08:00", "duration": "10:30", "room": "Room 4.3 (Floor 4)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "All attendees may feel free to use the Zen Zone as needed. This is a quiet space for sensory relaxation, meditation, and worship. It is not to be used for conversations or as a workspace.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c7af220b3a4ad99f0cad97baef4309ff)", "url": "https://osselceu2026.sched.com/event/c7af220b3a4ad99f0cad97baef4309ff", "persons": []}], "Small Hall (Floor 0)": [{"guid": "oss-bbadc1459b6aca6b2df88a69326cb96e", "id": "oss-bbadc1459b6aca6b2df88a69326cb96e", "title": "Evolving the YAML Family (without Breaking the World)", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "YAML turned 25 this year.\n It is essential to Kubernetes, Docker, Ansible, CI pipelines, and config files for everything in between.\n That ubiquity is both a gift and a curse: every change risks breaking something, somewhere, silently.\n So how do you grow a data language that a billion files depend on without risk of catastrophe?\n \n Ingy döt Net helped invent YAML and he now maintains the YAML Specification and The YAML Family (libyaml, go-yaml, PyYAML, YAMLStar, YAMLScript etc).\n In this talk he'll show how he plans to grow YAML by extension: a plugin system that can deeply affect YAML behavior in completely configurable ways.\n Plugin APIs include schema association, tab indent, standard functions, comment support include i18n.\n This is being delivered first to go-yaml with the rest of the Family to follow.\n The work and its real world feedback will guide future changes to the specification.\n\n[Open in Sched](https://osselceu2026.sched.com/event/bbadc1459b6aca6b2df88a69326cb96e)", "url": "https://osselceu2026.sched.com/event/bbadc1459b6aca6b2df88a69326cb96e", "persons": [{"public_name": "Ingy döt Net"}]}, {"guid": "oss-2f2d31500df85eea4ffd8f2072acbe43", "id": "oss-2f2d31500df85eea4ffd8f2072acbe43", "title": "How Git Clone Took Down Our CI for 20 Days", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "One morning, CI across ~1,800 repos ground to a near-total halt. HTTP 401 from our code host, everywhere. Deterministic, not flaky. Valid tokens, healthy rate limits, but we our requests had been failing. We asked \"why?\".\n\nTwenty days and 17,863,537 log records later, we'd gone deeper into git's open source plumbing than we ever intended: how git negotiates HTTP auth, what it leaks in user-agents, which config knobs actually matter under load, and how its defaults, sensible on a laptop, behave pathologically behind Kubernetes NAT at 50,000 CI runs a day.\n\nThis talk is a forensic walkthrough of git's HTTP transport, told through an outage: the red herrings, the tcpdumps, the fixes that didn't work, the fix that did. You'll leave knowing what git clone really does when you're not looking, and how to configure it so it never makes you look guilty.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2f2d31500df85eea4ffd8f2072acbe43)", "url": "https://osselceu2026.sched.com/event/2f2d31500df85eea4ffd8f2072acbe43", "persons": [{"public_name": "Yathartha Goenka"}]}, {"guid": "oss-f2647cc09e5b5d76412cc9198ba7ceb8", "id": "oss-f2647cc09e5b5d76412cc9198ba7ceb8", "title": "Kata at Scale: The Hidden Cost of Running VMs Behind Every Container", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "There is a big difference between getting Kata Containers running in a proof of concept and operating a large multi-tenant Kata environment for years.\n \n This talk is a practical, vendor-neutral look at what becomes hard after the demo works. Once every pod carries a lightweight VM lifecycle behind it, platform teams are no longer operating only Kubernetes. They are also operating guest kernels, guest images, VMMs, hypervisor behavior, virtio devices, runtime and agent version skew, and a second debugging surface under the container platform.\n \n We will walk through production issues that show up at scale: guest kernel CVEs and regressions, host/guest kernel drift, CNI and tap-device networking, virtio-fs and storage durability semantics, fragmented observability, boot storms, vCPU oversubscription, memory accounting drift, NUMA behavior, GPU passthrough, VFIO/IOMMU lifecycle, upgrade matrices, and incident ownership.\n \n This is not a criticism of Kata. Kata solves a real open source isolation problem. The goal is to help operators understand the operational work required to run VM-isolated containers safely and sustainably in production.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f2647cc09e5b5d76412cc9198ba7ceb8)", "url": "https://osselceu2026.sched.com/event/f2647cc09e5b5d76412cc9198ba7ceb8", "persons": [{"public_name": "Kavitha Daula"}, {"public_name": "Nigel Douglas"}]}, {"guid": "oss-22dcf9c750d9feb74c113b741eb1afe0", "id": "oss-22dcf9c750d9feb74c113b741eb1afe0", "title": "Embracing Service-Oriented Connectivity Across OpenStack and Kubernetes", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern infrastructure platforms increasingly combine OpenStack VMs, Kubernetes Pods, managed platforms, and external services, yet connectivity models often remain fragmented across runtime boundaries and tied to infrastructure-specific constructs such as IP-based ACLs. This session presents how LY Corporation introduced a service-oriented connectivity model across OpenStack and Kubernetes environments. Rather than extending Kubernetes-native service mesh concepts to VM workloads, we introduced a runtime-independent service abstraction where connectivity and policy are defined consistently across VMs, Pods, PaaS instances, and external resources. Under this model, services become the primary unit for service discovery, authentication and authorization, ACL management, and traffic control, independent of the underlying runtime or network topology. A sidecar proxy enforces service-to-service policy consistently across both OpenStack-managed VMs and Kubernetes workloads. We cover the architectural design, OpenStack and Kubernetes integration for service registration and identity propagation, and lessons from migrating production workloads at scale.\n\n[Open in Sched](https://osselceu2026.sched.com/event/22dcf9c750d9feb74c113b741eb1afe0)", "url": "https://osselceu2026.sched.com/event/22dcf9c750d9feb74c113b741eb1afe0", "persons": [{"public_name": "Mitsuhiro Tanino"}, {"public_name": "Rei Shimizu"}]}, {"guid": "oss-bd16a236265e1a5bcbed46c5a265da2a", "id": "oss-bd16a236265e1a5bcbed46c5a265da2a", "title": "Life Finds a Way , Sandboxed Agents, Observable Verdicts", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "\"Life, uh, finds a way.\" So do AI agents. Give one a tool, and a prompt-injected README will teach it to spawn a shell. CVE-2025-59528 (CVSS 10.0) and Google's Antigravity sandbox escape proved the same thing twice in 2025: the agent didn't break the sandbox , either the sandbox was missing, or the electric fence was in the wrong place.\n This talk is a tour of Jurassic Park, rebuilt on Kubernetes. The paddock walls are containers. The electric fence is kubernetes-sigs/agent-sandbox, swapping gVisor for Kata Containers under the same CRD. The control room is OpenTelemetry where invoke_agent, execute_tool, and tool.policy_check spans turn every isolation verdict into queryable telemetry.\n We will deploy OpenClaw ,an open-source AI agent gateway inside a Sandbox resource on Cluster API, watch the agent attempt three different escapes, and ship policy decisions as first-class spans. Help shape OpenTelemetry semconv #3583 before the park opens.\n\n[Open in Sched](https://osselceu2026.sched.com/event/bd16a236265e1a5bcbed46c5a265da2a)", "url": "https://osselceu2026.sched.com/event/bd16a236265e1a5bcbed46c5a265da2a", "persons": [{"public_name": "Henrik Rexed"}]}, {"guid": "oss-0176b77746831cc16bd5bdd79f7d547c", "id": "oss-0176b77746831cc16bd5bdd79f7d547c", "title": "Teaching BIND9 New Tricks: A Rust Operator for Declarative DNS on Kubernetes", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Authoritative DNS is one of the last holdouts against declarative, GitOps-style management. BIND9 still serves a huge share of the world's zone data, but it's driven imperatively: hand-edited zone files, rndc reload, and brittle automation glued on top. bindy is an open-source Kubernetes operator, written in Rust on kube-rs, that closes the gap. It models zones and records as custom resources and continuously reconciles a running BIND9 against them, leaving no orphaned zone file behind. This talk walks through the architecture of bindy and its sibling projects, bindcar, a sidecar that exposes RNDC operations over a typed API, and hornet, a Rust zone-file parser, then digs into the operator-engineering lessons that transfer to anyone writing controllers in Rust. We'll cover splitting selection from synchronization to avoid reconcile loops, using the reflector and store, modeling ownership and status conditions, and where Rust and kube-rs paid off versus Go's controller-runtime. Attendees leave with a concrete, reusable pattern for wrapping any stateful, non-cloud-native daemon in a declarative Kubernetes API, and three open-source projects they can adopt, fork, or contribute to.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0176b77746831cc16bd5bdd79f7d547c)", "url": "https://osselceu2026.sched.com/event/0176b77746831cc16bd5bdd79f7d547c", "persons": [{"public_name": "Erick Bourgeois"}]}], "Solutions Showcase": [{"guid": "oss-c2723a18c518491363c6e120e79111de", "id": "oss-c2723a18c518491363c6e120e79111de", "title": "Solutions Showcase", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "09:55", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "The Solutions Showcase is your hub to network, explore sponsor exhibits, and learn how these organizations are shaping the future of the ecosystem.**In order to facilitate networking and business relationships at the event, you may choose to visit a third party’s booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), and details about the sponsored content or resources you interacted with. If you choose to interact with a booth or access sponsored content, you are explicitly consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.**\n\n[Open in Sched](https://osselceu2026.sched.com/event/c2723a18c518491363c6e120e79111de)", "url": "https://osselceu2026.sched.com/event/c2723a18c518491363c6e120e79111de", "persons": []}, {"guid": "oss-7467acc269850d6875d42f9111c55959", "id": "oss-7467acc269850d6875d42f9111c55959", "title": "Welcome Coffee", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "01:30", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/7467acc269850d6875d42f9111c55959)", "url": "https://osselceu2026.sched.com/event/7467acc269850d6875d42f9111c55959", "persons": []}, {"guid": "oss-bb8e618c74c426bf9912e4543f74a49d", "id": "oss-bb8e618c74c426bf9912e4543f74a49d", "title": "Coffee Break", "date": "2026-10-07T10:35:00+02:00", "start": "10:35", "duration": "00:45", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/bb8e618c74c426bf9912e4543f74a49d)", "url": "https://osselceu2026.sched.com/event/bb8e618c74c426bf9912e4543f74a49d", "persons": []}, {"guid": "oss-a22dbdd934f7af451e3fcd4e2445c393", "id": "oss-a22dbdd934f7af451e3fcd4e2445c393", "title": "Lunch (Provided Onsite for All Attendees)", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "01:30", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/a22dbdd934f7af451e3fcd4e2445c393)", "url": "https://osselceu2026.sched.com/event/a22dbdd934f7af451e3fcd4e2445c393", "persons": []}, {"guid": "oss-1072d47b27aca2f2b309cbbce5b92850", "id": "oss-1072d47b27aca2f2b309cbbce5b92850", "title": "Coffee Break", "date": "2026-10-07T15:05:00+02:00", "start": "15:05", "duration": "00:30", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/1072d47b27aca2f2b309cbbce5b92850)", "url": "https://osselceu2026.sched.com/event/1072d47b27aca2f2b309cbbce5b92850", "persons": []}], "South Hall 1 A (Floor 1)": [{"guid": "lpc20-c3748", "id": "lpc20-c3748", "title": "Short-Lived UDP and the Observability Gap: Challenges in Building Complete Flow Graphs for Identity-Based Policy", "date": "2026-10-07T09:30:00+02:00", "start": "09:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Identity-based micro-segmentation depends on building a complete graph of workload-to-workload communication. For TCP, this is tractable: connections have clear lifecycle events observable via sock_ops and inet_sock_set_state tracepoints, and conntrack entries persist long enough for user space collection. UDP has none of this, and in production Kubernetes environments, UDP is everywhere: DNS queries,NTP,syslog,SNMP custom service discovery protocols, and increasingly, QUIC.\r\n\r\nGenerally in production micro-segmentation deployment, 15-20% of observed flows are UDP-based, and we consistently undercount them by 30-40% compared to packet-capture ground truth. This means if you have some ML engine in place, then this ML-based policy engine generates policies with blind spots: it doesn't suggest rules for UDP flows it never observed, leaving them to hit default-deny and break applications after policy enforcement.\r\n\r\nWhat I'll cover:\r\n\r\n 1. **Why UDP flow observability is structurally harder**- TCP connections:\r\n    SYN creates conntrack entry -> observable via ctnetlink ->\r\n    inet_sock_set_state tracepoint marks lifecycle. UDP: first packet\r\n    creates a conntrack entry with a short timeout (30s default, 120s\r\n    for \"assured\"), and single-datagram exchanges (DNS request->response)\r\n    may age out before user space collects them. I'll present data from\r\n    production system showing the correlation between conntrack\r\n    timeout settings and UDP flow miss rates.\r\n 2. **Three approaches and their costs**- (1) Tracing every\r\n    udp_sendmsg/udp_recvmsg via kprobe/fentry: complete visibility but\r\n    3-5% throughput overhead on UDP-heavy workloads.\r\n    (2) Increasing conntrack UDP timeouts: reduces miss rate but bloats\r\n    conntrack table size (we measured 4x table growth) and increases\r\n    memory pressure. (3) BPF socket filter at cgroup level: catches\r\n    socket-level events but misses raw UDP (common in legacy workloads\r\n    that use raw sockets)\r\n 3. **Proposal**: lightweight UDP flow event via sock_ops- TCP already has\r\n    BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB and\r\n    BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB. I propose adding analogous\r\n    callbacks for UDP- BPF_SOCK_OPS_UDP_FIRST_SEND and\r\n    BPF_SOCK_OPS_UDP_FIRST_RECV- that fire once per unique (source,\r\n    dest, sport, dport) tuple within a configurable window. This gives\r\n    flow-level visibility without per-packet tracing overhead. I'll\r\n    present the proposed semantics, the kernel-side implementation\r\n    sketch, and the estimated overhead based on prototype measurements.\r\n 4. **Conntrack event reliability** at scale — Even for flows that conntrack\r\n    does capture, we lose 5-8% of ctnetlink events under high connection\r\n    rates (>50K new flows/sec) due to netlink socket buffer overflow.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2456/)", "url": "https://lpc.events/event/20/contributions/2456/", "persons": [{"public_name": "Tarun Shekher"}]}, {"guid": "lpc20-c3757", "id": "lpc20-c3757", "title": "Networking Performance Regression Testing", "date": "2026-10-07T10:00:00+02:00", "start": "10:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The Linux network stack is a performance-critical component of the Linux kernel that impacts service delivery, quality, and efficiency. Subtle changes might have far-reaching performance implications. In this presentation I describe an emerging project to build a reference setup for networking performance and efficiency experiments. The objectives for this project are twofold. The immediate goal is establishing a reference software stack and suite of benchmarking experiments that can be used for automatic regression testing during the regular development cycle of the Linux networking subsystem (netdev). On the other hand, having an established and meaningful reference setup wouldd also be highly beneficial for academic researchers to compare wider-ranging and ambitious research proposals with a well-known baseline that follows best practices for system and workload configurations. As such, it is hoped that a secondary benefit of such an initiative is bringing together Linux developers and academic researchers to benefit the entire open-source operating systems community.\r\n\r\nThe talk will present existing preliminary work in this project and solicit feedback, and most importantly it can hopefully serve as a starting point for a wider discussion and consultation. Given the diversity of workload scenarios, potential system configurations, and possible performance effects, conversations about the most representative experiments and metrics are critically important. Aside from fundamental questions, such as the specific nature of regression detection, there are practical questions in how to best integrate a test instance with the existing netdev infrastructure for test automation (NIPA) and how to best facilitate the replication of test instances for different purposes.\r\n\r\nAnother explicit objective for this project is to study system efficiency, including resource efficiency, in additional to pure performance. As computing infrastructure becomes a more and more significant energy consumer and hardware improvements might potentially slow down in the near- to mid-term future, it is important to prepare for a potentially resource-constrained future by being able to understand, measure, control, and reduce the resource overheads associated with various computing services.\n\n**Attachments:**\n- [talk.pdf](https://lpc.events/event/20/contributions/2465/attachments/2083/4647/talk.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2465/)", "url": "https://lpc.events/event/20/contributions/2465/", "persons": [{"public_name": "Martin Karsten"}]}, {"guid": "lpc20-c3753", "id": "lpc20-c3753", "title": "BIG TCP for UDP tunnels", "date": "2026-10-07T10:30:00+02:00", "start": "10:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "BIG TCP is a kernel feature that allows aggregating SKBs bigger than 64k, aiming to reduce per-packet overhead for high-throughput network traffic. Until now, it has mostly been practical for direct-routing deployments. A large class of production environments, including Kubernetes+Cilium setups, relies on UDP-based overlay networks, such as VXLAN and GENEVE.\r\n\r\nThis talk will walk through the challenges of adding BIG TCP support to encapsulated traffic, such as having to deal with multiple variations of IPv6 HBH extension header in every driver, which resulted in unification with BIG TCP IPv4 and dropping the HBH header from IPv6 too. This talk will also walk you through other gaps that prevented BIG TCP from working with UDP tunnels out of the box, as well as other related parts like adding support in tcpdump, and possible caveats. The performance numbers on Mellanox NIC will be included, showing gains with 1.5k and 8k MTU, as well as the software GSO paths when tunnel offloads are unavailable.\r\n\r\nThis effort resulted in two patchsets on LKML: \"BIG TCP without HBH in IPv6\" and \"BIG TCP for UDP tunnels\". The first part solves the issue with convoluted packet parsing in the fast path on driver level. The second part addresses the remaining gaps to handle encapsulated BIG TCP SKBs correctly, and switches to using UDP length = 0 for oversized aggregated packets and restoring the real length when parsing or segmenting such packets. It also takes care of checking the length of untrusted ingress packets.\r\n\r\nThe goal of this session is to gather feedback from users of overlay networking and driver authors for possible future improvements and evolution.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2461/)", "url": "https://lpc.events/event/20/contributions/2461/", "persons": [{"public_name": "Alice Mikityanska"}]}, {"guid": "lpc20-c3759", "id": "lpc20-c3759", "title": "TCP Multipath implementation with BPF", "date": "2026-10-07T11:00:00+02:00", "start": "11:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "As server platforms increasingly ship with multiple frontend NICs, there is a growing need to utilize all available network paths transparently — without application changes. We propose a BPF-based approach that leverages cgroup hooks at connect() time to perform client-side path selection across multiple NICs, effectively implementing a form of TCP multipath at the host level. To avoid the operational complexity of distributing and synchronizing per-host NIC topology maps across an entire fleet, we further propose encoding the multi-NIC topology information directly in TCP Options during the connection handshake. This allows peers to dynamically discover available paths and perform load balancing decisions locally using BPF programs. We will present the design, discuss how it interacts with dynamic container networking environments, and share early deployment experience.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2467/)", "url": "https://lpc.events/event/20/contributions/2467/", "persons": [{"public_name": "Raman Shukhau"}]}, {"guid": "lpc20-c3750", "id": "lpc20-c3750", "title": "MPTCP KTLS Support: Bringing TLS to Multipath TCP", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Multipath TCP (MPTCP) enables a device to simultaneously utilize multiple network interfaces for a single connection, providing enhanced redundancy, resilience, and bandwidth aggregation. Currently, an increasing number of network applications are beginning to support MPTCP, and some of them, such as NVMe over MPTCP and web servers like lighttpd, require TLS for MPTCP. However, MPTCP has historically lacked TLS support due to fundamental conflicts in how both protocols manage the Upper Layer Protocol (ULP) stack within the Linux kernel.\r\n\r\nThis proposal presents a solution to make MPTCP and TLS compatible. The main challenge is the tight coupling between TLS and TCP, which hardcodes many TCP-specific functions and conflicts over the ULP slot. It implemented MPTCP support on the TLS side by introducing a protocol operations abstraction layer that decouples TLS from TCP and implements MPTCP-specific functions, and enabled TLS configuration on the MPTCP side by applying TLS encryption exclusively at the non-fallback MPTCP socket level, rather than on individual subflows (TCP sockets). The implementation resolves this challenge, passes the newly added MPTCP TLS selftests, which mirror the existing TCP TLS test cases, and has been validated through extensive selftests and real-world use cases, including NVMe over MPTCP.\r\n\r\nLink: https://lore.kernel.org/all/cover.1782123118.git.tanggeliang@kylinos.cn/\n\n**Attachments:**\n- [LPC2026_MPTCP_KTLS_Support.pdf](https://lpc.events/event/20/contributions/2458/attachments/1983/4499/LPC2026_MPTCP_KTLS_Support.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2458/)", "url": "https://lpc.events/event/20/contributions/2458/", "persons": [{"public_name": "Geliang Tang"}]}, {"guid": "lpc20-c3755", "id": "lpc20-c3755", "title": "Native AF_VSOCK API for userspace device emulation", "date": "2026-10-07T12:30:00+02:00", "start": "12:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Several userspace VMMs emulate virtio-vsock devices entirely in userspace, and vhost-user-vsock provides a similar capability through the vhost-user protocol, to reduce the kernel attack surface or to run on platforms where vhost-vsock is not available. However, only the vhost-vsock kernel module, which emulates the virtio-vsock device in the host kernel, integrates directly with `AF_VSOCK`, so these backends expose Unix domain sockets to host applications, following the hybrid-vsock model introduced by Firecracker.\r\n\r\nIn the hybrid-vsock model, to connect to a guest, a host application opens a Unix socket and sends a text command like `\"CONNECT <port>\\n\"`. To receive connections from a guest, it listens on a separate Unix socket named `/path/to/uds_<port>`. This works, but it requires every host application to implement this ad-hoc protocol instead of using standard `AF_VSOCK` sockets, and the guest CID is not visible to the host kernel at all.\r\n\r\nThis talk explores a kernel interface that would let any process emulating a vsock device in userspace, such as the VMM itself or a vhost-user backend, register a guest CID and use `AF_VSOCK` sockets instead of Unix sockets, keeping the same one-socket-per-connection model that hybrid-vsock already uses. One possible approach is to introduce a new protocol type for `AF_VSOCK` (or a socket option) that allows a process to claim a CID through `bind()` and inject guest connections into the host's `AF_VSOCK` stack through the standard `accept()` and `connect()` calls, while the device emulation remains entirely in userspace. Host services would then reach these guests with a simple `connect(AF_VSOCK, guest_cid, port)`, exactly as they do with kernel vhost-vsock, and VMMs would need minimal changes to switch from `AF_UNIX` to `AF_VSOCK`. Because this interface operates at the `AF_VSOCK` level, it is not tied to virtio and could serve any existing or future vsock transport.\r\n\r\nTopics for discussion include: the right kernel API design, whether there are existing interfaces to follow or reuse, and how it should interact with network namespaces recently supported by `AF_VSOCK`.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2463/)", "url": "https://lpc.events/event/20/contributions/2463/", "persons": [{"public_name": "Stefano Garzarella"}]}, {"guid": "lpc20-c3758", "id": "lpc20-c3758", "title": "Possibility of Userspace Networking Drivers: TUNTAP, VDUSE and What's More?", "date": "2026-10-07T13:00:00+02:00", "start": "13:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Building a driver for a new NIC normally means writing a kernel module. Whether you upstream it or maintain it out of tree, it requires a lot of effort. Isn't there a lighter-weight approach?\r\n\r\nThis talk shows one way to write the driver logic in userspace, without writing a kernel module, while the device still shows up as a Linux network device like \"eth0\". This is possible with existing in-kernel mechanisms today, but it is not yet a complete solution. Let's discuss what is required for a userspace driver mechanism.\r\n\r\nMoving driver logic to userspace reduces the pain of maintaining out-of-tree kernel modules: you stop keeping up with kernel version changes and a critical bug in the driver does not crash the kernel. Other subsystems have similar concepts: FUSE for filesystems, ublk for block devices. The networking subsystem also has building blocks for processing networking in userspace, and they are divided into two groups.\r\n\r\nOne group keeps the network stack in kernel and hands packets off to userspace below the driver. TUNTAP is a classic example. It's a virtual device used for tunneling and virtual machines, and exchanges packets with userspace rather than with a wire. VDUSE is another example: it lets you implement a vDPA device in userspace, intended as a userspace backend for virtual networks of virtual machines and containers; combined with virtio-vdpa, it provides a function similar to TUNTAP.\r\n\r\nThe other group does the opposite: VFIO and UIO provide only a thin device-handling layer in the kernel and move the implementation above the driver, including the network stack, out to userspace.\r\n\r\nBy combining the two groups, and placing the actual driver logic in a userspace daemon between them, we can realize a NIC driver in userspace. One of its use cases is an FPGA-based NIC, which acts as a fully programmable NIC. Because its CPU-facing interface -- descriptor formats, register layouts, and so on -- is entirely up to the FPGA programmer, the driver variations are virtually unlimited.\r\n\r\nI have been experimenting with building userspace NIC drivers with TUNTAP/VDUSE and VFIO. For testing, I used an e1000e device emulated in a VM as a common simple device rather than special hardware. Unsurprisingly, there is a performance penalty due to packet copies, high CPU load of the userspace daemon, and so on. Both TUNTAP and VDUSE are also limited by their specific interfaces, such as statistics and netdev features. I'll introduce the various difficulties I faced and discuss how userspace network drivers should be built. Are TUNTAP/VDUSE and VFIO the right shape, or does Linux networking want its own dedicated mechanism? Is it possible to implement a driver's data path in BPF?\n\n[Open in Indico](https://lpc.events/event/20/contributions/2466/)", "url": "https://lpc.events/event/20/contributions/2466/", "persons": [{"public_name": "Toshiaki Makita"}]}, {"guid": "lpc20-c3749", "id": "lpc20-c3749", "title": "Modernizing NFS Direct I/O for PCI Peer-to-Peer DMA", "date": "2026-10-07T15:00:00+02:00", "start": "15:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "<br>High-performance storage environments increasingly rely on direct data movement between PCIe  endpoints, such as NVMe Controller Memory Buffers (CMB) or BAR memory. Today, NFS relies on standard page references (get_page) and doesn't support pinning pages for DMA, making the subsystem  pin-unaware. Furthermore, the legacy iterator APIs used in NFS are incapable of passing the required capability flags mandated by the GUP subsystem. Thus, NFS remains incompatible with P2PDMA due to this lack of pin-awareness.\r\n<br> This talk walks through the design challenges in enabling P2PDMA for the NFS Direct I/O path using a two-phased approach. The first phase involves an architectural modernization, i.e. migrating the Direct I/O path to use the modern iov_iter_extract_pages API. This transition introduces pin-awareness to the NFS request lifecycle. Additionally, it migrates the NFS Direct I/O from pages to folios. We have an on-going series posted upstream for the first phase:<br>[https://lore.kernel.org/all/20260603053033.3300318-1-praan@google.com][1] \r\n<br>**Plumber's Discussion: Transport-Level P2PDMA Capability Detection** \r\nThe second phase of this modernization addresses the detection and propagation of P2PDMA capabilities based on the underlying transport. Since NFS connections can dynamically migrate across different hardware interfaces or utilize multipathing (nconnect), P2PDMA support is a property of the active connection rather than a static server capability. This session focuses on the following architectural challenges:\r\n<br> - **Detection & Propagation:** Discuss & align on the proposed design for transport-level capability discovery. This would allow NFS to conditionally signal hardware P2PDMA support (via `ITER_ALLOW_P2PDMA`) to the GUP subsystem, potentially on a per-request basis.\r\n<br> - **Architectural Implications:** Discuss the cross-subsystem impact of this transport-centric approach. Key areas include managing state consistency across transport failover, the implications of dynamic device rebinding during re-connections, and the challenge of transport selection in multipath (nconnect) environments.\r\n<br>The talk is backed by the ongoing NFS Modernization and P2PDMA series upstream:\r\n- RFC: [https://lore.kernel.org/all/20260401194501.2269200-1-praan@google.com/][2]\r\n- On-going Series: [https://lore.kernel.org/all/20260616134000.2733403-1-praan@google.com/][1]\r\n\r\n  [1]: https://lore.kernel.org/all/20260616134000.2733403-1-praan@google.com/\r\n  [2]: https://lore.kernel.org/all/20260401194501.2269200-1-praan@google.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2457/)", "url": "https://lpc.events/event/20/contributions/2457/", "persons": [{"public_name": "Pranjal Shrivastava"}, {"public_name": "Shivaji Kant"}]}, {"guid": "lpc20-c3756", "id": "lpc20-c3756", "title": "swiotlb Under Pressure: High-Speed NICs in Confidential VMs", "date": "2026-10-07T15:30:00+02:00", "start": "15:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Systems that treat devices as untrusted protect themselves using confidential computing memory protection. Linux uses swiotlb to handle the necessary buffer bouncing transparently to drivers. For high-performance NICs operating at scale, however, the overhead of allocating and managing bounce buffers can substantially exceed the cost of the memory copies themselves.\r\n\r\nReceive queues create long-lived pressure on the swiotlb pool. Pages are DMA-mapped when they enter a page_pool and normally remain mapped while they are recycled, often until they leave the pool or the queue is destroyed. Across many receive queues, these mappings can retain a substantial portion of the available bounce-buffer memory, even after the pool has been increased to the largest practical size for the system. As occupancy increases, allocations search additional swiotlb areas and contend on their per-area locks. This primarily affects transmission, where an SKB’s linear area and fragments can each require a separate bounce-buffer allocation, copy, synchronization, and reclamation sequence.\r\n\r\nTo evaluate an alternative to per-mapping swiotlb bouncing, we implemented a prototype mlx5e datapath based on preallocated DMA-coherent staging memory. With 16 transmit-heavy TCP streams, one per queue, the swiotlb datapath reduced throughput by 70% relative to a baseline without buffer bouncing. The explicit staging datapath reduced this loss to 10–20%.\r\n\r\nIn this talk, we will compare the generic swiotlb approach with the driver-managed bounce buffers, present detailed measurements, and analyze the bottlenecks we identified. We will conclude by discussing what an upstream solution should look like: driver-specific staging buffers, a generic networking abstraction or improvements to swiotlb scalability.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2464/)", "url": "https://lpc.events/event/20/contributions/2464/", "persons": [{"public_name": "Dragoș Tătulea"}]}, {"guid": "lpc20-c3754", "id": "lpc20-c3754", "title": "KNOD: In-Kernel GPU Offload for Packet Processing", "date": "2026-10-07T16:00:00+02:00", "start": "16:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "At LPC 2025, we presented an early prototype for running XDP programs directly on an AMD GPU from within the Linux kernel, without CUDA, ROCm, or any userspace component in the data path.[1]\r\n\r\nSince then, the project has evolved into knod, an in-kernel network offload device, and an RFC patch set has been posted.[2] knod uses the GPU as a kernel-managed packet-processing accelerator: the kernel JIT-compiles an XDP program into GPU machine code, the NIC places packets directly in GPU-accessible memory, and the GPU processes them in parallel and returns XDP verdicts. The RFC extends the original XDP prototype into a generic offload-device model, with RX IPsec as an additional use case.\r\n\r\nMajor changes since LPC 2025 include a redesigned NIC-to-GPU path that allows the GPU to consume packets directly, support for divergent control flow in GPU-offloaded BPF programs, RDNA2 support, and optimizations to batching, dispatch, occupancy, and memory transfers. The current RFC reports up to 70 Mpps for a Katran-derived XDP workload and 80 Gbit/s for RX IPsec.\r\n\r\nThis talk will walk through how knod has evolved since LPC 2025 and discuss the remaining design and implementation challenges: the boundaries among the networking core, bpf, drm, and accelerator drivers; per-CPU map and queue-affinity semantics on accelerators; further performance optimization; support for additional GPU architectures; and the Generic Netlink/YNL control plane and its integration with existing tools.\r\n\r\n[1]: https://lpc.events/event/19/contributions/2267/ \r\n[2]: https://lore.kernel.org/netdev/20260719175857.4071636-1-ap420073@gmail.com/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2462/)", "url": "https://lpc.events/event/20/contributions/2462/", "persons": [{"public_name": "Taehee Yoo"}, {"public_name": "Hoyeon Lee"}]}, {"guid": "lpc20-c3752", "id": "lpc20-c3752", "title": "PCI data path optimization with CQE coalescing and new ethtool parameters", "date": "2026-10-07T17:00:00+02:00", "start": "17:00", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "To optimize the PCI data path on the Azure MANA NIC, we implemented support for Completion Queue Entry, or CQE, coalescing. In the regular receive path, each packet can generate a separate CQE that must be processed by the driver, increasing interrupt pressure and CPU & PCI overhead. CQE coalescing reduces this cost by **merging multiple CQEs into one aggregated completion** that represents several received network packets. This allows the driver to process more packets per interrupt and reduces the amount of per-packet overhead required in the fast path. The improvement is especially important on ARM64 platforms, where interrupt handling cost and cache efficiency can strongly affect networking throughput. In our measurements, CQE coalescing provided a throughput enhancement ranging from 33% to 62% while also increasing the number of packets handled per interrupt.\r\n\r\nWe also added **two new parameters to both the ethtool kernel API and the ethtool command line: ETHTOOL_A_COALESCE_RX_CQE_FRAMES and ETHTOOL_A_COALESCE_RX_CQE_NSECS** as suggested by netdev maintainers. These parameters expose CQE coalescing through the standard Linux networking configuration model instead of relying on a driver-specific private flag. The frame-based setting controls how many packet completions may be combined before a coalesced CQE is generated, while the time-based setting controls how long the device may wait before reporting the aggregated completion. Together, they allow administrators to tune the balance between throughput, CPU utilization, interrupt rate, and receive latency for different workloads. Other NIC drivers that support similar CQE coalescing behavior can adopt the same interface, improving consistency across Linux networking devices.\n\n**Attachments:**\n- [2026-LPC-CQE-v3.1.pdf](https://lpc.events/event/20/contributions/2460/attachments/2000/4529/2026-LPC-CQE-v3.1.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2460/)", "url": "https://lpc.events/event/20/contributions/2460/", "persons": [{"public_name": "Haiyang Zhang"}]}, {"guid": "lpc20-c3751", "id": "lpc20-c3751", "title": "Coroutines for Linux kernel", "date": "2026-10-07T17:30:00+02:00", "start": "17:30", "duration": "00:30", "room": "South Hall 1 A (Floor 1)", "track": "LPC: Networking Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "There are multiple kernel drivers which could benefit were it possible to somehow do coroutines in C. Coroutines would make these drivers easier to comprehend, extend with new code paths, and debug.\r\n\r\nThe most common use case lies in simplifying complex state machines. For example consider the main state machine `sfp_sm_main()` in `drivers/net/phy/sfp.c`. Each invocation executes code for a specific state, updates the state, and returns. The current implementation even relies on goto statements to jump between cases. As a result, understanding the control flow requires tracking disjointed code paths or drawing manual state diagrams.\r\n\r\nUsing coroutines, this logic can be transformed into a straightforward, linear sequence using standard loop and conditional structures (`if`, `for`, `while`). By leveraging GNU C computed gotos, we can implement mechanics similar to C++20's `co_await` and `co_return`. With some trickery, it is even possible to preserve variable values across suspension points.\r\n\r\nLet's explore hiding this underlying complexity behind clean, maintainable macros and discuss whether this approach can be safely implemented for production code.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2459/)", "url": "https://lpc.events/event/20/contributions/2459/", "persons": [{"public_name": "Marek Behún"}]}], "South Hall 1 B (Floor 1)": [{"guid": "lpc20-c3558", "id": "lpc20-c3558", "title": "TAB Q&A", "date": "2026-10-07T09:00:00+02:00", "start": "09:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "The Linux Foundation Technical Advisory Board (TAB) represents Linux Kernel project interests to the Linux Foundation. It also uses the pooled influence of its elected members to support the long term health of the project.\r\n\r\nThis open forum / panel discussion is an opportunity to learn about and discuss TAB initiatives and ongoing project needs.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2406/)", "url": "https://lpc.events/event/20/contributions/2406/", "persons": [{"public_name": "Dave Hansen"}, {"public_name": "David Hildenbrand"}, {"public_name": "Greg Kroah-Hartman"}, {"public_name": "Julia Lawall"}, {"public_name": "Kees Cook"}, {"public_name": "Miguel Ojeda"}, {"public_name": "Shuah Khan"}, {"public_name": "Steven Rostedt"}, {"public_name": "Theodore Ts'o"}]}, {"guid": "lpc20-c3500", "id": "lpc20-c3500", "title": "Cryptographic Proofs of Personhood: Solving the Kernel Web of Trust Problem in a Privacy-Preserving Manner", "date": "2026-10-07T10:00:00+02:00", "start": "10:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "In any open source software project, maintainer identity is becoming a critical problem.  How can you be confident that someone contributing a patch (or PR) is not a malicious adversary?  Attacks like the XZUtils compromise have heightened the concern around this sort of software supply chain attack, and the “North Korean developer” problem plagues both companies and open source projects.\r\n\r\nToday, the kernel uses the kernel.org PGP web of trust to mitigate this problem.  However, the technology that is used is outdated, leading to a system that is neither scalable nor private.  In this talk, we propose using a system built on cryptographic proofs of personhood as a better alternative for a cryptographic web of trust.  Informally speaking, cryptographic proofs of personhood allow us to build a decentralized, private reputation system, giving us all of the power of the existing web of trust, plus a whole new suite of functionalities.\r\n\r\nWe will explain the cryptographic principles behind proofs of personhood at a high level in a way that non-cryptographers can understand.  Then, we will explain how this technology can be applied to solve the web of trust problem.  Finally, we will demonstrate a fully functional, large implementation of proofs of personhood using entirely open source technology (standards and code) hosted in Linux Foundation Decentralized Trust.    The demonstration will show that such a solution is ready to be adopted by kernel.org for the web of trust.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2350/)", "url": "https://lpc.events/event/20/contributions/2350/", "persons": [{"public_name": "Drummond Reed"}, {"public_name": "Glenn Gore"}, {"public_name": "Hart Montgomery"}]}, {"guid": "lpc20-c3501", "id": "lpc20-c3501", "title": "A Loadable Crypto Module for FIPS Certification", "date": "2026-10-07T10:45:00+02:00", "start": "10:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "Many organizations require US Federal Information Processing Standard (FIPS) certification of the crypto code they are running. The certification process is lengthy (typically 12–18 months), but the bigger problem is that the way the crypto subsystem is built into the kernel makes the result unable to be reused across kernel updates. This is because FIPS certification is granted at the binary level by [NIST](https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology). In current kernels, the crypto subsystem is built directly into the main kernel image, so even a non-crypto kernel update — a scheduler fix, a driver addition — produces a new binary and invalidates the existing certification. Distributions are then forced through the full validation cycle again, making it extremely difficult to deliver timely kernel updates while maintaining FIPS compliance.\r\n\r\nThis talk presents a solution that has shipped in kernel 6.18 on Amazon Linux 2023 and is covered in an [LWN.net feature article](https://lwn.net/Articles/1073759/): decoupling the crypto subsystem from the main kernel and building it as a separate loadable module. The module, rather than the entire kernel, becomes the unit of certification. A subsequent kernel update that does not touch the module leaves the existing certification intact, and loading that certified module onto the updated kernel makes it FIPS-compliant automatically. When the crypto code itself needs updating, a new module can be submitted for certification while users continue running the previously certified one on newer kernels; the old module acts as a bridge, so users never have to choose between an updated kernel and FIPS compliance. \r\n\r\nWhile the existing kernel's module system already allows code to live outside the main kernel, this talk will present why the same approach cannot simply be used here, what falls short, and how the approach overcomes these obstacles in its design and implementation as shipped in production. It will also discuss what it needs to be as a unified upstream foundation that distributions can customize to satisfy different certification setting requirements.\r\n\r\n**References:**\r\n\r\n- Patch series: https://lwn.net/ml/all/20260418002032.2877-1-wanjay@amazon.com/\r\n- LWN article: https://lwn.net/SubscriberLink/1073759/95b3d4cd28506836/\r\n- AWS compute blog: https://aws.amazon.com/blogs/compute/introducing-modularized-kernel-cryptography-in-amazon-linux/\n\n[Open in Indico](https://lpc.events/event/20/contributions/2362/)", "url": "https://lpc.events/event/20/contributions/2362/", "persons": [{"public_name": "Jay Wang"}]}, {"guid": "lpc20-c3503", "id": "lpc20-c3503", "title": "From CVE to Fix in Minutes: AI-Augmented Security Lifecycle Management for Linux Distributions", "date": "2026-10-07T12:00:00+02:00", "start": "12:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "# Linux Plumbers Conference 2026 — Proposal\r\n\r\n---\r\n\r\n## Recommended Track\r\n\r\n**Distributions Microconference**\r\n\r\n> **Why this track:** The proposal centers on distro-level CVE lifecycle management — scanning, triage, patching, backporting, and release engineering — which sits squarely in the Distributions MC's scope. It addresses pain points shared by every LTS distro maintainer (Debian, Fedora, openSUSE, Alpine, etc.) and invites cross-distro collaboration on AI-assisted tooling.\r\n>\r\n> **Alternative tracks (if Distributions MC is not available):**\r\n> - *Security MC* — the CVE rescoring methodology and SLA-driven release model are directly relevant.\r\n> - *Tooling MC / Refereed Track* — the AI backporting agent and automated review pipeline are novel developer tooling contributions.\r\n\r\n---\r\n\r\n## Title\r\n\r\n**From CVE to Fix in Minutes: AI-Augmented Security Lifecycle Management for Linux Distributions**\r\n\r\n---\r\n\r\n## Abstract\r\n\r\nEvery day, hundreds of new CVEs are disclosed. For Linux distribution maintainers, the challenge is not *whether* vulnerabilities will arrive — it is how fast you can triage, patch, test, and ship fixes **at scale**. This session presents a production-proven, end-to-end pipeline that automates the full CVE lifecycle for a Linux distribution serving millions of deployed systems.\r\n\r\nWe cover five key stages and the design decisions behind each:\r\n\r\n### 1. Detection & Ingestion\r\nCVEs are continuously ingested from the National Vulnerability Database and cross-referenced against distro-specific package versions using scanning pipelines. Raw CVE feeds are noisy, so an automated triage layer checks whether a CVE actually affects the distribution by examining build configurations, internal dependency graphs, and shipped code paths.\r\n\r\n### 2. Distro-Specific Rescoring\r\nUpstream CVSS scores frequently misrepresent actual risk for a given distribution. We present a principled methodology for **rescoring CVEs against your own build configuration and hardening posture** — a vulnerability rated HIGH upstream may genuinely be LOW risk due to compiler flags (`-fstack-protector-strong`, `-D_FORTIFY_SOURCE=2`), disabled features, or sandboxing that neutralizes the attack vector. This directly combats alert fatigue and misallocated engineering effort.\r\n\r\n### 3. Automated Patching & AI-Powered Backporting\r\nOnce a CVE is confirmed, the pipeline automatically attempts the fix — preferring minor version (patch-level) upgrades when available, falling back to cherry-picking upstream patches. When neither works cleanly, an **AI-powered SWE (Software Engineering) Agent** backports patches to the distro's specific version, resolving merge conflicts, adapting to API renames, struct layout changes, and conditional compilation differences. The agent operates in an iterative build-feedback loop: apply patch → build → analyze errors → refine — producing a complete, buildable patch set with full provenance.\r\n\r\n**Case studies we'll share:**\r\n- Patches requiring adaptation across 3+ major version gaps\r\n- Handling renamed functions and refactored code paths\r\n- Fallback strategies when AI backporting fails and how we route to human experts with maximum context\r\n\r\n### 4. Automated Review Pipeline\r\nReviewing CVE patches is one of the most time-consuming bottlenecks in distro maintenance (15–30 min per PR). We built a **multi-stage automated review pipeline** that reduces human review time to ~1 minute:\r\n\r\n| Stage | Method | What It Checks |\r\n|-------|--------|-----------------|\r\n| Spec Validation | Deterministic | Version bumps, patch declarations, changelog format, signature updates |\r\n| Build Log Analysis | Heuristic | Errors, warnings, test failures from CI |\r\n| Semantic Patch Comparison | LLM-driven | Classifies match against upstream fix (exact / minor diff / clean backport / significant divergence), generates risk score |\r\n| Structured Report | Template (Jinja2) | Renders Markdown review posted directly to the PR |\r\n\r\nWe share accuracy metrics, prompt engineering techniques for reliable semantic diff analysis, and lessons learned from production deployment.\r\n\r\n### 5. SLA-Driven Release Engineering\r\nWe enforce strict SLAs tied to severity:\r\n\r\n| Severity | Fix SLA | Release Channel |\r\n|----------|---------|-----------------|\r\n| Critical | 5 business days | Fasttrack RPM release |\r\n| High | 10 business days | Fasttrack RPM release |\r\n| Medium | 30 business days | Monthly cadence |\r\n| Low | Next release | Monthly cadence |\r\n\r\nWe share the operational framework for tying CVE severity to release cadence and how end-to-end observability (CVE inflow trends, severity distribution, package hotspots, fix throughput) enables data-driven security posture management.\r\n\r\n---\r\n\r\n## Why This Matters to the Plumbers Community\r\n\r\n1. **Reproducible, Distro-Agnostic Blueprint** — The architecture (scan → triage → rescore → patch → AI-backport → test → review → ship) is not tied to any single distribution. Maintainers of Debian, Fedora, Alpine, Gentoo, or any custom enterprise distro can adopt the same pipeline patterns.\r\n\r\n2. **Tackles the Maintainer Shortage** — The Linux ecosystem faces a chronic shortage of security-focused maintainers. By automating 80%+ of the CVE lifecycle, small teams can maintain the security posture of a large distribution — directly addressing the sustainability crisis in open-source maintenance.\r\n\r\n3. **AI Backporting as a Shared Community Tool** — We want to start a conversation about building a **community-maintained backporting agent** that could serve multiple distributions. Every LTS distro, every stable kernel branch, and every enterprise vendor deals with backporting; a shared tool benefits everyone.\r\n\r\n4. **Distro-Specific Rescoring Should Be Standard Practice** — Most organizations blindly consume upstream CVSS scores. We propose a methodology that any distro can adopt to prioritize what truly matters for *their* configuration.\r\n\r\n5. **Faster Backporting = Smaller Exposure Windows** — AI-assisted backporting means vulnerabilities are patched sooner in stable releases, directly improving security for billions of deployed systems.\r\n\r\n---\r\n\r\n## Session Format\r\n\r\n**Preferred:** 30-minute presentation + 15-minute discussion  \r\n**Alternate:** 20-minute presentation (can condense to focus on backporting agent + review pipeline)\r\n\r\nWe can provide a **live demo** of:\r\n- The automated patching pipeline processing a real CVE\r\n- The AI backporting agent resolving a non-trivial merge conflict\r\n- The review pipeline generating a structured review report\r\n- The CVE observability dashboard\r\n\r\n---\r\n\r\n## Discussion Topics for the Microconference\r\n\r\nIf accepted as part of a broader discussion slot, we'd like to explore:\r\n\r\n- Could distros share a common AI backporting agent, and what would the interface/API need to be?\r\n- How do other distros handle the tension between automated patching speed and review thoroughness?\r\n- What test infrastructure is needed to validate AI-generated patches with high confidence?\r\n\r\n---\r\n\r\n## Speaker Bio\r\n\r\nKanishk Bansal is a Software Engineer working on Azure Linux distribution security infrastructure at Microsoft. His work spans CVE triage, AI-powered patch backporting, and intelligent code review systems for a production Linux distribution. He is passionate about applying AI to the critical but under-resourced work of open-source supply chain security.\r\n\r\n---\n\n[Open in Indico](https://lpc.events/event/20/contributions/2361/)", "url": "https://lpc.events/event/20/contributions/2361/", "persons": [{"public_name": "Kanishk Bansal"}]}, {"guid": "lpc20-c3504", "id": "lpc20-c3504", "title": "BPF_PROG_TEST_RUN: the hidden perils of testing.", "date": "2026-10-07T12:45:00+02:00", "start": "12:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "`BPF_PROG_TEST_RUN` has been a crucial tool for testing eBPF programs. Although it has been instrumental for XDP, as BPF spreads to other hookpoints (e.g., TC, sock_ops, struct_ops) that rely on complex data structures such as the SKB, we found that it provides an environment that diverges significantly from the kernel: it does not model these structures and instead defaults their state to zero. This leads to unfaithful test replication and test cases that may miss bugs that would occur in production. We verified three such scenarios in which a single zeroed field hides an entire branch of real kernel behavior.\r\n\r\nA simple, concrete instance is `skb->cloned`, which the harness hard-wires to zero so that every clone-branching helper only ever takes its fast path. Testing against open-source eBPF programs, we confirmed this produces silent semantic divergence: `bpf_skb_ecn_set_ce` returns success but never sets the CE bit when an skb is cloned and its IP header is unwritable: a path the harness cannot reach. The test therefore reports a pass while the corresponding production behavior differs, illustrating how one unmodeled bit lets both unit tests and verification tools built on `BPF_PROG_TEST_RUN` overlook real bugs.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2360/)", "url": "https://lpc.events/event/20/contributions/2360/", "persons": [{"public_name": "Lucas Castanheira"}, {"public_name": "Theophilus Benson"}]}, {"guid": "lpc20-c3506", "id": "lpc20-c3506", "title": "When Embedded Codecs Meet Graphics", "date": "2026-10-07T15:00:00+02:00", "start": "15:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: LPC Refereed Track", "type": "LPC Track", "language": "en", "abstract": "", "description": "In the current Linux kernel, video codecs split into two categories. Accelerators built into GPUs are implemented as thin drivers with userspace components exposing APIs such as Vulkan Video or VA-API. Everything else falls under the Video4Linux kernel API. This fragmentation adds complexity for both kernel and userspace developers. VA-API has stagnated and carries historical assumptions tied to Intel hardware, while Video4Linux, despite remaining relevant and widely deployed, has an aging memory model and resource queue mechanism that limits modern use cases. Vulkan Video, by contrast, is actively developed and designed with hardware-specific extensions in mind, making it a strong candidate for embedded use cases.\r\n\r\nThis talk proposes introducing a new class of embedded video codec drivers into Linux: thin, vendor-specific drivers modeled after GPU drivers, where the V4L2 kernel API is replaced by Vulkan Video, with the userspace driver implemented in Mesa. The goal is not to reinvent the wheel, but to replace an aging one. Such an approach would bring better buffer management through existing DRM memory helpers, modern explicit synchronization primitives already used by GPU drivers, and reduced kernel complexity by pushing codec-specific logic into userspace where it belongs.\n\n[Open in Indico](https://lpc.events/event/20/contributions/2354/)", "url": "https://lpc.events/event/20/contributions/2354/", "persons": [{"public_name": "Nicolas Dufresne"}]}, {"guid": "lpc20-c3549", "id": "lpc20-c3549", "title": "FUSE mostly-passthrough filesystems", "date": "2026-10-07T15:45:00+02:00", "start": "15:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "Many production FUSE filesystems do not need to reimplement the full filesystem stack.  They need to mirror an existing directory with full fidelity while intercepting only a small subset of operations for caching, tiering, HSM stub manifestation, or auditing.\r\n\r\nTo make these filesystems easier to build, we introduce [libfuse_passthrough][1] - a C++ library that handles all FUSE plumbing and exposes a lightweight module API where only the intercepted operations need to be implemented where everything else passes through automatically.\r\n\r\nThe library makes use of upstream kernel FUSE read/write passthrough, which allows open files to bypass the FUSE daemon entirely, and provides an experimental playground for the development of [more FUSE kernel passthrough operations][2].\r\n\r\nWe invite contributors and users with FUSE passthrough workloads to learn about our experience, discuss open problems, kernel interface requirements, and help shape the future of FUSE.\r\n\r\n  [1]: https://github.com/amir73il/libfuse/tree/libfuse_passthrough/passthrough\r\n  [2]: https://lore.kernel.org/fuse-devel/20260420221637.2631478-1-joannelkoong@gmail.com/\n\n**Attachments:**\n- [lpc-2026-libfuse-passthrough-slides.pdf](https://lpc.events/event/20/contributions/2367/attachments/1981/4495/lpc-2026-libfuse-passthrough-slides.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2367/)", "url": "https://lpc.events/event/20/contributions/2367/", "persons": [{"public_name": "Amir Goldstein"}]}, {"guid": "lpc20-c3550", "id": "lpc20-c3550", "title": "Defining the pkeys ABI", "date": "2026-10-07T17:00:00+02:00", "start": "17:00", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "We have been supporting pkeys [1] on Linux for 10 years now, and they\r\nare no longer specific to x86: arm64 and powerpc support them too.\r\nUnfortunately, important gaps remain in the kernel-user ABI, making it\r\ndifficult to deploy pkeys robustly for key use-cases.\r\n\r\npkeys work in a fairly simple way: the user allocates a new pkey and\r\nthen assigns that pkey to a VMA. Access to that VMA is then restricted\r\nby a user-controlled register, which defines RWX permissions for every\r\npkey.  The restrictions apply to both user and kernel accesses (uaccess\r\nand GUP).\r\n\r\nDifficulties arise when the kernel interrupts a user thread and then\r\naccesses its memory, or invokes a signal handler. In those cases, it is\r\nunclear which pkeys authority the kernel should use, whether userspace\r\nshould be able to configure it, and how to avoid spurious crashes or\r\nconfused deputy situations. This is what the current ABI is lacking.\r\n\r\nThis BoF is especially intended for arch/mm maintainers, libc/runtime\r\ndevelopers, and userspace developers already familiar with pkeys or\r\ndeploying pkey-based isolation. The goal is not to present a finished\r\ndesign, but to agree on the programming model that future ABI work\r\nshould follow.\r\n\r\nA few important use-cases are currently difficult or impossible to\r\nimplement robustly:\r\n\r\n* Isolating the alternate signal stack: mapping it with a non-default\r\n  pkey that only signal handlers are allowed to access.\r\n\r\n* Sandboxing with pkeys: preventing some context from accessing \r\n  even the default pkey (0).\r\n\r\nProblematic situations include:\r\n\r\n* Signal delivery [2]: signal handlers may be called asynchronously and\r\n  are conceptually independent of the interrupted context.\r\n  Userspace may need the pkey register to be reset to a specific value\r\n  both for writing the signal frame and invoking the signal handler.\r\n\r\n* rseq [3]: the kernel writes to the registered struct rseq when context\r\n  switching, which can happen at any point. This is again independent of\r\n  the interrupted context, which may not be allowed to write to that\r\n  struct.\r\n\r\n* io_uring worker threads: these are kernel threads that access user\r\n  memory asynchronously. They have their own pkey register value\r\n  restricting those accesses, but userspace is not currently able to\r\n  configure it.\r\n\r\n* Other cases, such as BPF helpers accessing user memory and\r\n  process_vm_readv(self) bypassing pkeys completely.\r\n\r\nAll these issues lead to a set of questions that we need to answer to\r\ncreate a consistent and unsurprising ABI:\r\n\r\n* Which contexts need a dedicated or userspace-configurable pkey\r\n  register value?\r\n\r\n* Are there accesses that should intentionally bypass pkeys, and if so,\r\n  how should that be documented?\r\n\r\n* Can these issues be handled with targeted fixes, or do we need a more\r\n  unified ABI design for asynchronous kernel access to pkey-protected\r\n  memory?\r\n\r\nAs Thomas Gleixner put it:\r\n\r\n> We really need to sit down and actually define a proper programming\r\n> model first instead of trying to duct tape the current ill defined\r\n> mess forever.\r\n\r\nThe intended outcome of this BoF is a shared direction for documenting\r\nand extending the pkeys ABI, so that pkeys can be used reliably as\r\nintra-process privilege boundaries rather than only as a best-effort\r\nhardening mechanism.\r\n\r\n[1] https://docs.kernel.org/core-api/protection-keys.html\r\n[2] https://inbox.sourceware.org/libc-alpha/fc31e639-f1eb-42d6-9dea-3665d9507f12@arm.com/\r\n[3] https://lore.kernel.org/all/87ikexhbah.ffs@tglx/\n\n**Attachments:**\n- [LPC26_pkeys_ABI.pdf](https://lpc.events/event/20/contributions/2366/attachments/2058/4613/LPC26_pkeys_ABI.pdf)\n\n[Open in Indico](https://lpc.events/event/20/contributions/2366/)", "url": "https://lpc.events/event/20/contributions/2366/", "persons": [{"public_name": "Kevin Brodsky"}]}, {"guid": "lpc20-c3551", "id": "lpc20-c3551", "title": "Virtio and Vhost-User Ecosystem for Production and Automotive Systems", "date": "2026-10-07T17:45:00+02:00", "start": "17:45", "duration": "00:45", "room": "South Hall 1 B (Floor 1)", "track": "LPC: Birds of a Feather (BoF)", "type": "LPC BoF", "language": "en", "abstract": "", "description": "The vhost-user protocol started as a simple QEMU feature, but it has grown into a standard used across the entire Linux virtualization community. Today, it powers production workloads in the cloud (e.g. QEMU and cloud-hypervisor), lightweight environments like libkrun, and modern automotive systems.\r\n\r\nHowever, as the ecosystem expands, we are hitting new \"plumbing\" bottlenecks. For example, the protocol specification is still stored inside the QEMU documentation, which makes it harder for other projects to participate in its growth. At the same time, automotive deployments are introducing strict new needs, such as safety certification, real-time performance, and long-term support, that impact everyone.\r\n\r\nThis BoF will bring developers and users together to address these challenges and other emerging topics across the ecosystem. Our goal is to establish better coordination, align technical roadmaps for both cloud and automotive, and build shared tests and tools to ensure all implementations work together.\r\n\r\nKey Discussion Topics:\r\n - vhost-user Specification Governance: Discuss official location for the vhost-user specification.\r\n - Automotive Virtualization Requirements & Reference Platforms: Coordinate deployment needs across Automotive platforms [1]\r\n - Real-time performance needs (camera, display, CAN)\r\n - Status Update: Ongoing work on vhost-user device (virtio-Media, virtio-can, virtio-rtc, etc)[2][3]\r\n - Graphics Stack Alignment: on roadmaps for shared dependencies like rutabaga_gfx across libkrun, crosvm, vhost-device-gpu [4]\r\n - Shared Virtio Message-Parsing Crates: Evaluate creating unified Rust crates for Virtio device specs to share virtqueue parsing logic across backends and VMMs.\r\n - Open questions about:\r\n     vhost-user Specification Refinements: Identify protocol gaps, missing features, and necessary standard improvements.\r\n     New Virtio/vhost-user Device Proposals.\r\n\r\n[1] https://source.android.com/docs/automotive/virtualization/reference_platform \r\n[2] https://lore.kernel.org/virtualization/ab2FlQTWUxl0KmlT@fedora/\r\n[3] https://github.com/rust-vmm/vhost-device/pull/944 \r\n[4] https://github.com/magma-gpu/rutabaga_gfx/issues/24\r\n\r\nKey Participants:\r\n  - Albert Esteve aesteve@redhat.com\r\n  - Stefano Garzarella sgarzare@redhat.com\r\n  - Sergio Lopez slp@redhat.com\r\n  - Manos Pitsidianakis manos.pitsidianakis@linaro.org\r\n  - Alex Bennee alex.bennee@linaro.org\r\n  - Matej Hrica mhrica@redhat.com\r\n  - Milan Zamazal mzamazal@redhat.com\r\n  - Gurchetan Singh gurchetansingh@google.com\r\n  - Jorge E. Moreira jemoreira@google.com\r\n  - Matias Vara Larsen mvaralar@redhat.com\r\n  - Dorinda Bassey dbassey@redhat.com\r\n  - Alberto Ruiz aruiz@redhat.com\r\n  - Erico Nunes ernunes@redhat.com\r\n  - John Ferlan jferlan@redhat.com\r\n  - Michael Tsirkin mst@redhat.com\r\n  - German Maglione gmaglion@redhat.com\r\n  - Stefan Hajnoczi stefanha@redhat.com\r\n  - Timos Ampelikiotis t.ampelikiotis@virtualopensystems.com\r\n  - Harald Mommer harald.mommer@oss.qualcomm.com\n\n[Open in Indico](https://lpc.events/event/20/contributions/2365/)", "url": "https://lpc.events/event/20/contributions/2365/", "persons": [{"public_name": "Dorinda Bassey"}, {"public_name": "Albert Esteve"}, {"public_name": "Stefano Garzarella"}]}], "South Hall 2 A (Floor 2)": [{"guid": "oss-e9a2948889b06a8f761cafd5d58cd217", "id": "oss-e9a2948889b06a8f761cafd5d58cd217", "title": "Sponsored Session: Agentic Search in OpenSearch: Fast, Local, and Domain-Aware", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Agentic search lets you ask questions in natural language and have OpenSearch plan and execute retrieval on your behalf. At its core, a Query Planner rewrites natural language into OpenSearch DSL using state-of-the-art LLMs. It works remarkably well, but not without real limitations worth confronting head-on:\n\nLatency is the biggest obstacle. Remote inference adds significant delay, and eCommerce search demands sub-100ms response times. Even the best results, delivered slowly, drive search abandonment.Local inference is the fix, with a catch. We'll demo cutting latency by hosting small language models (SLMs) locally within OpenSearch nodes using vLLM and Ollama. It's faster and cheaper, but SLMs lose quality on query rewrites. We'll show how fine-tuning on domain-specific data closes that gap: proving fine-tuned SLMs can beat state-of-the-art LLMs.Relevance stays generic, even with agentic search. We'll demonstrate how to ground it in user and business context using hybrid search and reranking.\nThis hands-on talk covers:Search latency with remote inferenceHosting SLMs locally with vLLM and OllamaAgentic search with local SLM inferenceImproving relevance with user and business contextFine-tuning SLMs for domain-specific query rewriting via Axolotl and LLaMA-Factory\n\n[Open in Sched](https://osselceu2026.sched.com/event/e9a2948889b06a8f761cafd5d58cd217)", "url": "https://osselceu2026.sched.com/event/e9a2948889b06a8f761cafd5d58cd217", "persons": [{"public_name": "Dotan Horovits"}, {"public_name": "Aswath Srinivasan"}]}, {"guid": "oss-0fa2c003ea3a2cfa40ecf32f3a1c9bbf", "id": "oss-0fa2c003ea3a2cfa40ecf32f3a1c9bbf", "title": "Sponsored Session: Not Every Prompt Needs Opus: Building Our Local LLM Strategy", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Over the past 2 months, we’ve been actively offloading a percentage of our company’s internal AI use to self-hosted LLMs on hardware we own. Learn about our motivations, the hardware/software we use, real-world use cases for open-weight LLMs at a 200-person technology company.\n\n\nWe’re early in this journey, but we’ll share what has worked for us so far including cost savings and lessons learned around adoption and balancing between local LLMs and frontier AI!\n\n[Open in Sched](https://osselceu2026.sched.com/event/0fa2c003ea3a2cfa40ecf32f3a1c9bbf)", "url": "https://osselceu2026.sched.com/event/0fa2c003ea3a2cfa40ecf32f3a1c9bbf", "persons": [{"public_name": "Ben Potter"}]}, {"guid": "oss-69188e0d902604c87d59d1eef30ff271", "id": "oss-69188e0d902604c87d59d1eef30ff271", "title": "Sponsored Session: Kubernetes Is the AI OS. Here's the Open Source Stack Running on Top of It", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Kubernetes has become the AI operating system (82% of container users run it in production and 66% use it for AI inference) but the real challenge is scaling inference, not training. Every prompt and every agent call runs inference, and standard Kubernetes routing is blind to the KV cache state and token dynamics that determine whether you hit your SLOs. This session covers the open stack the CNCF community is coalescing around to fix that: HAMi (now Incubating) for fractional GPU virtualization and hard accelerator isolation, Inference Gateway (GA) for model-aware traffic routing, llm-d (new CNCF Sandbox project) for cache and load-aware distributed inference, KServe (Incubating) for multi-model serving, and the KAR (Kubernetes AI Conformance Requirements) program now spanning 31 certified platforms. We’ll also cover four trends shaping the next 12 months of cloud native AI.\n\n[Open in Sched](https://osselceu2026.sched.com/event/69188e0d902604c87d59d1eef30ff271)", "url": "https://osselceu2026.sched.com/event/69188e0d902604c87d59d1eef30ff271", "persons": [{"public_name": "Jonathan Bryce"}, {"public_name": "Daniel Krook"}]}, {"guid": "oss-204fa3f5f26e7cf5d6e0d32b7f38869b", "id": "oss-204fa3f5f26e7cf5d6e0d32b7f38869b", "title": "Sponsored Panel: If AI Can Write Drivers, Why Do We Need Zephyr and Should We Make Zephyr AI Ready? Moderated by Andrei Aldea & Khasim Syed Mohammed, Texas Instruments Inc", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Generative AI is rapidly changing the way embedded software is developed. Today, developers can ask AI tools to generate peripheral drivers, board support packages, device tree overlays, test cases, and even complete application examples in seconds. As the cost of writing code continues to fall, it raises an important question for the Zephyr community: what role does Zephyr play in a world where AI can generate much of the software stack?\n\nIs Zephyr primarily a collection of drivers and APIs, or is its real value found in standardization, portability, maintainability, testing, community collaboration, and long-term ecosystem support? As AI-generated code becomes commonplace, does the importance of an open-source framework like Zephyr diminish—or become even more critical?\n\nThis panel brings together developers, maintainers, silicon vendors, and product teams to explore how AI is reshaping embedded software development. We will discuss the evolving relationship between AI-assisted coding and open-source frameworks, examine what remains difficult after code generation becomes easy, and debate which skills future embedded engineers should focus on developing.\n\nJoin us for a lively discussion on the future of embedded systems and whether Zephyr's greatest contribution is no longer the code it contains, but the platform, ecosystem, and community it enables.\n\n[Open in Sched](https://osselceu2026.sched.com/event/204fa3f5f26e7cf5d6e0d32b7f38869b)", "url": "https://osselceu2026.sched.com/event/204fa3f5f26e7cf5d6e0d32b7f38869b", "persons": []}, {"guid": "oss-001ef267666c3d33da2b86292a576b70", "id": "oss-001ef267666c3d33da2b86292a576b70", "title": "Your Network Is Already a Compute Platform. Time To Treat It Like One", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Network switches and routers are no longer passive packet forwarders. They have been running containers for some time already. But managing them still requires separate tools, CLIs, and workflows, and that creates real operational friction.\n \n Virtual Kubelet eliminates this. Network devices become Kubernetes nodes. Workloads are provisioned with standard kubectl commands. Device configuration is declared as Kubernetes resources with continuous drift detection. Telemetry flows through OpenTelemetry to any OTLP-compatible backend.\n \n This session demonstrates how to converge network and platform operations into a single control plane. We will demonstrate live provisioning of network devices and show how the CNCF ecosystem enables observability, security, and policy enforcement for edge deployments.\n\n[Open in Sched](https://osselceu2026.sched.com/event/001ef267666c3d33da2b86292a576b70)", "url": "https://osselceu2026.sched.com/event/001ef267666c3d33da2b86292a576b70", "persons": [{"public_name": "Eleni Grosdouli"}, {"public_name": "Josh Halley"}]}], "South Hall 2 B (Floor 2)": [{"guid": "oss-493e070cb9bf926f68ecbde73c0590da", "id": "oss-493e070cb9bf926f68ecbde73c0590da", "title": "Zephyr at 10: Scaling an Open Source RTOS for the Next Decade", "date": "2026-10-07T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Over the last decade, Zephyr has grown from a focused open source RTOS into one of the most widely adopted platforms for connected, secure, and portable embedded systems. That success brings new challenges: more architectures, more boards, more vendors, more contributors, more downstream users, and higher expectations around quality, security, safety, documentation, testing, and long-term maintenance.\n \n This talk looks at Zephyr’s evolution through the lens of project sustainability. It will highlight where the current model is working, where scaling pressure is becoming visible, and what the community needs to address to keep Zephyr healthy for the next 10 years. Topics include maintainer bandwidth, review latency, infrastructure load, test and sample growth, vendor enablement, downstream compatibility, long-term support, security updates, dependency management, and the tension between a unified upstream and the need for product- and platform-specific innovation.\n\n[Open in Sched](https://osselceu2026.sched.com/event/493e070cb9bf926f68ecbde73c0590da)", "url": "https://osselceu2026.sched.com/event/493e070cb9bf926f68ecbde73c0590da", "persons": [{"public_name": "Anas Nashif"}]}, {"guid": "oss-b4280b16c53e3989534b84a3e157d581", "id": "oss-b4280b16c53e3989534b84a3e157d581", "title": "Community Awards", "date": "2026-10-07T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/b4280b16c53e3989534b84a3e157d581)", "url": "https://osselceu2026.sched.com/event/b4280b16c53e3989534b84a3e157d581", "persons": []}, {"guid": "oss-733d2dfb4003c30641d21cdbdab770be", "id": "oss-733d2dfb4003c30641d21cdbdab770be", "title": "Ten Years of Zephyr: Replace Linux, or Work With It?", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "A decade after its launch, Zephyr has grown from a small RTOS into a capable, MMU-aware, userspace-supporting system running on application-class cores. So people keep asking: can it replace Linux? A better question is how the two can work together - and Zephyr already has what it needs to do that. This talk shows how Linux and Zephyr run side by side on the same SoC, using parts Zephyr ships today: the IPC service layer, OpenAMP and RPMsg for messaging between the two cores, mailbox and shared-memory backends, and the mechanisms that let Linux start and stop Zephyr firmware. Based on real work on NXP i.MX and i.MX RT platforms, I'll show how these pieces fit, and where the hard parts are - memory layout, buffer sizes, address translation, and shutdown order. The takeaway: after ten years, the interesting frontier isn't replacement. It's connecting the two so each kernel does what it's best at on the same chip.\n\n[Open in Sched](https://osselceu2026.sched.com/event/733d2dfb4003c30641d21cdbdab770be)", "url": "https://osselceu2026.sched.com/event/733d2dfb4003c30641d21cdbdab770be", "persons": [{"public_name": "Iuliana Prodan"}]}, {"guid": "oss-1148cc88d876fbae510f4d9152ba921c", "id": "oss-1148cc88d876fbae510f4d9152ba921c", "title": "From Reset To Main(): Porting Infineon TriCore AURIX To Zephyr", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Infineon's AURIX family of automotive microcontrollers is based on the TriCore architecture and is widely used across automotive systems, from powertrain and chassis control to safety-critical ECUs. This talk presents the upstream effort to add TriCore architecture support and enable Infineon AURIX TC3x and TC4x devices in Zephyr (https://github.com/zephyrproject-rtos/zephyr/pull/107516). Starting from CPU reset, we will walk through the key architecture bring-up steps required to reach the first Zephyr thread, including trap and interrupt handling, Context Save Area (CSA)-based context switching, and system timer integration. We will also cover the work required beyond the architecture layer, including SoC support, board enablement, and QEMU-based development and testing. Finally, we will discuss the challenges of upstreaming a new architecture into Zephyr, from toolchain and CI integration to HAL dependencies and ecosystem support, along with the remaining work needed for automotive and safety-critical systems.\n\n[Open in Sched](https://osselceu2026.sched.com/event/1148cc88d876fbae510f4d9152ba921c)", "url": "https://osselceu2026.sched.com/event/1148cc88d876fbae510f4d9152ba921c", "persons": [{"public_name": "Parthiban N"}, {"public_name": "Christoph Seitz"}]}, {"guid": "oss-bae76fcb8ba73ae8c843282ecc98d538", "id": "oss-bae76fcb8ba73ae8c843282ecc98d538", "title": "Practical End-to-End Traceability for Zephyr’s Path To Safety Certification", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "As part of the ongoing effort to achieve IEC 61508 certification, Zephyr's requirements capture process is underway. Yet there is still no clear picture of how these requirements trace to the tests that verify them or the code that implements them. Safety evidence is largely documented evidence, so the primary concern is generating auditable documents: requirement and test specifications, test reports, and traceability matrices. The challenge is collecting this evidence in a community-compatible way — low-friction processes and tooling that developers and maintainers will accept. This talk proposes a pipeline built on Zephyr's existing documentation tools (Doxygen/Sphinx) to extract the needed information from annotated source and tests, then trace it back against requirements into an end-to-end chain. Two demos are shown: a minimal working example against Zephyr itself, and a self-contained pipeline for a Zephyr module the authors maintain. Required process adaptations and guidelines are explained. The work is an open proposal for discussion; once agreed, it gives the community a scalable foundation to advance safety efforts, with concrete tasks contributors can pick up.\n\n[Open in Sched](https://osselceu2026.sched.com/event/bae76fcb8ba73ae8c843282ecc98d538)", "url": "https://osselceu2026.sched.com/event/bae76fcb8ba73ae8c843282ecc98d538", "persons": [{"public_name": "Tobias Kästner"}, {"public_name": "Andreas Kurz"}]}, {"guid": "oss-5541b37a6b5f911aa40fd4d7564deb72", "id": "oss-5541b37a6b5f911aa40fd4d7564deb72", "title": "CRA Readiness With SPDX 3 SBOMs in Zephyr", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "SBOMs for embedded firmware are harder than simple dependency lists. A Zephyr-based product typically combines upstream Zephyr code, vendor HALs, out-of-tree modules, binary blobs, generated files, Kconfig and devicetree configuration, and of course user/application code. Some of these pieces end up in the final firmware image, some do not, and yet it is important to have a clear picture of what was used, what was changed, and what actually shipped. This is what helps teams avoid chasing false positives, while still knowing when a new CVE might really affect them.\n \n In this talk, we will look at Zephyr’s SPDX-based SBOM generation, including its recently added support for SPDX 3.0. We will show why it is useful to describe not only _which_ components are present, but also _why_ they were pulled into the build and how they relate to each other.\n \n We will also discuss how build-aware SBOMs can directly support vulnerability management and help prepare for regulations such as the Cyber Resilience Act.\n\n[Open in Sched](https://osselceu2026.sched.com/event/5541b37a6b5f911aa40fd4d7564deb72)", "url": "https://osselceu2026.sched.com/event/5541b37a6b5f911aa40fd4d7564deb72", "persons": [{"public_name": "Benjamin Cabé"}]}, {"guid": "oss-5c428f8dcd02a4f4e84a668a5ff81ef3", "id": "oss-5c428f8dcd02a4f4e84a668a5ff81ef3", "title": "AI in Zephyr PSIRT: Lessons From the Front Line", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Zephyr’s security response is run by a small, mostly volunteer team handling a large and growing workload. Every vulnerability report must be triaged against a million-line codebase, confirmed in source, scored, mapped to a CWE, written up as a CVE record, documented for disclosure, and tracked across multiple release branches — often under embargo deadlines that don’t move. It’s repetitive, high-stakes work, and it’s exactly the kind of burden that burns maintainers out.\n \n This talk is a candid look at how we started using AI to help: grounding analysis in the source tree with file:line citations, drafting CVE records against a strict schema to prevent fabricated fields, and reducing release vulnerability accounting from hours to minutes. It covers what worked, what failed, and the guardrails we built to keep a human in the loop. You’ll leave with a practical blueprint and checklist for using AI in security response — and an honest view of where it helps and where it’s still a liability.\n\n[Open in Sched](https://osselceu2026.sched.com/event/5c428f8dcd02a4f4e84a668a5ff81ef3)", "url": "https://osselceu2026.sched.com/event/5c428f8dcd02a4f4e84a668a5ff81ef3", "persons": [{"public_name": "Flavio Vinicius Alvares Ceolin"}, {"public_name": "David Brown"}]}, {"guid": "oss-4252c11f302023bc1b71b43a534974f1", "id": "oss-4252c11f302023bc1b71b43a534974f1", "title": "Where Zephyr Fits in Space Computer Architecture", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Using Zephyr in space is not only a question of choosing an RTOS. A space computer is a system architecture: boot firmware, supervisor logic, watchdogs, safe mode, recovery paths, update policy, hardware monitoring, FPGA or SoC configuration, and the boundary between platform software and mission-specific applications all matter. This talk looks at Zephyr from that system-architecture point of view. Based on Space Cubics’ OBC development experience and recent Space Grade Linux discussions, it explores where Zephyr can fit in future space systems: mission RTOS, payload-controller OS, supervisor/control-plane OS, or companion to Linux. Space already has credible RTOS options, but Zephyr can bring value if the ecosystem develops a clear architectural story around boot, recovery, observability, hardware control, and responsibility boundaries. Attendees will leave with a practical checklist for evaluating Zephyr’s role in a space computer: what Zephyr should control, what should remain outside it, what must be recoverable after launch, and how to structure boot, update, monitoring, isolation, and fault-handling responsibilities.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4252c11f302023bc1b71b43a534974f1)", "url": "https://osselceu2026.sched.com/event/4252c11f302023bc1b71b43a534974f1", "persons": [{"public_name": "Yasushi Shoji"}]}], "South Hall 3 A (Floor 3)": [{"guid": "oss-c6467491adaf7dca7a02cce8780b0684", "id": "oss-c6467491adaf7dca7a02cce8780b0684", "title": "Embedded Linux Kernel Testing With Pytest", "date": "2026-10-07T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Testing drivers reliably across several versions of Linux (mainline, linux-next, stable, linux-cip, etc.) and several SoCs can be a challenging task, and it gets even more challenging if the whole process needs to be automated. \n \n In this talk we introduce a testing framework centered around pytest, that makes heavy use of pytest markers to describe the test SW and HW requirements, and we combine this with other open-source projects (like Yocto, LAVA, and GitLab CI/CD) to fully automate Linux kernel testing on embedded devices.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c6467491adaf7dca7a02cce8780b0684)", "url": "https://osselceu2026.sched.com/event/c6467491adaf7dca7a02cce8780b0684", "persons": [{"public_name": "Fabrizio Castro"}, {"public_name": "Chris Paterson"}]}, {"guid": "oss-6c05bb4f0fbc824572fc715f2dee20be", "id": "oss-6c05bb4f0fbc824572fc715f2dee20be", "title": "Reproducible Embedded Linux Testing From Laptop To CI To Scale", "date": "2026-10-07T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Kernel and embedded Linux engineers often need to reproduce a build or test from someone else. In practice this is still harder than it should be.\n \n A kernel may be built with one toolchain. The rootfs may come from a local build. Firmware may have changed. A model may need specific variables. Continuous Integration (CI) and lab runs may hide setup steps in scripts or jobs.\n \n Then someone asks:\n \n Can I reproduce this?\n \n Too often the answer is: not easily.\n \n This talk shows a practical way to make this better with modern open source tooling, and to show useful workflows that kernel and embedded engineers may not know about yet.\n \n We show how to build the kernel in a repeatable way, provide a known rootfs, boot the target, run tests, and collect logs.\n \n Then we use two Arm examples. One is an OP-TEE flow, where TF-A, U-Boot, and OP-TEE are part of the setup. The other is a CCA flow on QEMU-arm64 and FVP-aemva, where the model setup and software stack also matter.\n \n We use open source tools from the TuxSuite ecosystem, but the focus is the workflow. The same workflow can run on a laptop, in CI, in lab infrastructure, or at scale.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6c05bb4f0fbc824572fc715f2dee20be)", "url": "https://osselceu2026.sched.com/event/6c05bb4f0fbc824572fc715f2dee20be", "persons": [{"public_name": "Anders Roxell"}]}, {"guid": "oss-d0ba6e33e92b7db590bc343110cdc7e8", "id": "oss-d0ba6e33e92b7db590bc343110cdc7e8", "title": "Making Your CI Lab More Reliable", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "If you've ever built your own CI Lab, you've probably already faced some of these issues: - Remote power cycling of the boards (particularly when it requires pressing a push-button) - Managing remote debug console - Handling inrush current/power outage and surges - Handling boards with heterogeneous form factors - Handling remote GPIOS/accessories - Handling remote displays/ KVMs - Handling non-disruptive lab/board maintenance - Handling distributed CI labs At Baylibre, we've been dealing with CI Lab maintenance for many years, starting from 'scratch' (boards laying on shelves with wires all over the place) to standardised labs in server racks. In this presentation, we will share all the solutions we've found and developed to tackle all these issues, with the objective of improving the quality of our FOSS projects by making our CI labs reliable and easy to maintain.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d0ba6e33e92b7db590bc343110cdc7e8)", "url": "https://osselceu2026.sched.com/event/d0ba6e33e92b7db590bc343110cdc7e8", "persons": [{"public_name": "Patrick Titiano"}]}, {"guid": "oss-101c00d8e1473c3ca76efcdb3115eb99", "id": "oss-101c00d8e1473c3ca76efcdb3115eb99", "title": "20 Years of Quality Assurance for Embedded Linux Systems - The Good, the Bad, the Unexpected", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "More than 20 years ago the idea of transforming Linux into a real-time operating system resulted in the birth of the PREEMPT_RT development. But how could the real-time properties of such a complex system be tested? Due to the complexity of modern operating systems, such as Linux, and due to the fact that modern processors operate in a performant but non-deterministic way, appropriate methods for evaluating the real-time behaviour of a given system had to be established: That's why the OSADL QA Farm was born. While the initial focus of the QA Farm was (and still is) the long-term evaluation of the real-time properties of Embedded Linux systems, 20 years of operation with more than 100 systems have also brought many other insights to light - expected and unexpected. This presentation provides an overview of the quality assurance methods used at the OSADL QA Farm, the insights gained from numerous long-term measurements and latest developments, such as the integration of Zephyr systems.\n\n[Open in Sched](https://osselceu2026.sched.com/event/101c00d8e1473c3ca76efcdb3115eb99)", "url": "https://osselceu2026.sched.com/event/101c00d8e1473c3ca76efcdb3115eb99", "persons": [{"public_name": "Jan Altenberg"}]}, {"guid": "oss-f39800bccd148ef353454a444163098f", "id": "oss-f39800bccd148ef353454a444163098f", "title": "Debugging Heisenbugs: The Nightmare of Every Embedded Engineer", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Defined as bugs which disappear or change behavior when observed, every embedded engineer has come across one at some point. Some classic examples include bugs that stop reproducing after adding printk() statements, introducing new variables, connecting a debugger or even simply recompiling the same source code. The root causes of Heisenbugs range all the way from race conditions, memory corruption, alignment issues, cache incoherency, incorrect linker configurations to even hardware bugs. This talk walks through the debugging techniques which could be applied for debugging these Heisenbugs like static code analysis, memory analysis, diagnostic data collection, tracing and instrumentation, selective elimination of unrelated code paths, modifying assembly instructions at runtime; all without probing the observer’s effect. Beyond techniques, the talk aims to develop the intuition and thought process needed when confronting these bugs. The talk discusses how to distinguish between mere workarounds that mask the underlying issue vs actual fixes. Practical experiences in debugging real Heisenbugs will be shared along with their root causes, investigation approaches and the fixes.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f39800bccd148ef353454a444163098f)", "url": "https://osselceu2026.sched.com/event/f39800bccd148ef353454a444163098f", "persons": [{"public_name": "Beleswar Prasad Padhi"}]}, {"guid": "oss-d3ffc5ef6b0ba2ea332b22b0301136d1", "id": "oss-d3ffc5ef6b0ba2ea332b22b0301136d1", "title": "The Engineer's Guide To the Embedded Linux Galaxy: Navigating Failures and Bricked Devices", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Everyone can build a prototype, but shipping products is where the chaos begins. In this session, we explore embedded systems by discussing failures we have experienced as engineers, consumers, and industry observers. Navigating the vast open-source ecosystem of the embedded Linux galaxy and selecting the right tools for the job is a challenge. Instead of idealized architectural theory, we will share war stories and costly mistakes, facing the grim reality of bricked devices, maintenance costs and e-waste generation. We will be talking about a coffee machine that needs a technician to cross the galaxy to replace a PCB, an OTA update strategy that lacks the ability to upgrade offline devices with a USB stick, a smart home turned into a wreck when a bankruptcy leaves the IoT fleet permanently bricked and a final story on what happens when immovable object like legacy incident management meets unstoppable force like AI and CRA. This talk is for anyone working on an embedded Linux product, from junior developers to experienced engineers and managers. Since it is always better to learn from others' mistakes, you will walk away with insights that will help you improve your products.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d3ffc5ef6b0ba2ea332b22b0301136d1)", "url": "https://osselceu2026.sched.com/event/d3ffc5ef6b0ba2ea332b22b0301136d1", "persons": [{"public_name": "Leon Anavi"}, {"public_name": "Piotr Buliński"}]}, {"guid": "oss-3533ca5817881d15c2aabfb6323db6d1", "id": "oss-3533ca5817881d15c2aabfb6323db6d1", "title": "Demystifying Board Farms: Build a Mini Desktop Board Farm With Standard Tools and Hardware", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:20", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Large companies have built board farms for decades, providing both solid automated QA capabilities and short developer feedback loops. LAVA and Labgrid have emerged as standard tools. Although, today most small companies have not adopted those tools and practices, and too many developers spend time, constantly, on hardware set-up. Either standard tools are unknown, or two myths circulate: that LAVA is just for large-scale scenarios, and Labgrid is complex to set up. While at this, many create, instead, new in-house tools (wheel reinvention). This talk aims to reverse this, by showing two portable mini board farms: one using LAVA, and one using Labgrid. These two examples will act as comparison and demystification of these standard open-source tools, while showing common concepts. Both examples share a common open-source CI/CD (GitLab), and the physical layout: a portable 10-inch rack, which can sit on a desk (introduced only in recent years). Network, serial, power and cable management is done assembling off-the-shelf hardware. Board farm adoption, at any scale, can help teams to increase ergonomics, comfort, and determinism, for stress-free development, CI, and test workflows.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3533ca5817881d15c2aabfb6323db6d1)", "url": "https://osselceu2026.sched.com/event/3533ca5817881d15c2aabfb6323db6d1", "persons": [{"public_name": "Francesco Cervigni"}]}, {"guid": "oss-835848a5eacc7526ba2eec2a4eb6919e", "id": "oss-835848a5eacc7526ba2eec2a4eb6919e", "title": "Cukinia: A Lightweight Test Framework for Embedded Linux Systems", "date": "2026-10-07T16:50:00+02:00", "start": "16:50", "duration": "00:20", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Embedded Linux projects already have powerful testing frameworks, but they often come with requirements about infrastructure, dependencies, or target environments. In many firmware projects, developers need something simpler: a lightweight way to run system-level validation directly on the device, with minimal setup and no additional runtime requirements. Cukinia is an open-source test framework designed to make embedded Linux validation simple and accessible. Requiring only a POSIX shell, Cukinia can run directly on target devices even in production and integrates quickly into existing CI/CD workflows. With a collection of predefined test statements, developers can quickly create tests for system configuration, hardware interfaces, services, networking, storage, and more.\n\n[Open in Sched](https://osselceu2026.sched.com/event/835848a5eacc7526ba2eec2a4eb6919e)", "url": "https://osselceu2026.sched.com/event/835848a5eacc7526ba2eec2a4eb6919e", "persons": [{"public_name": "Kévin L'hôpital"}]}, {"guid": "oss-6d975f4819d9ee30db626f0c64c24b8a", "id": "oss-6d975f4819d9ee30db626f0c64c24b8a", "title": "Labgrid & Board Farming BOF", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Labgrid is a tool for both board farming and embedded systems testing. This session will include an overview of current developments and also provides a gathering for people interested or already using Labgrid.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6d975f4819d9ee30db626f0c64c24b8a)", "url": "https://osselceu2026.sched.com/event/6d975f4819d9ee30db626f0c64c24b8a", "persons": [{"public_name": "Rouven Czerwinski"}]}], "South Hall 3 B (Floor 3)": [{"guid": "oss-d53efb5f85825895fbe2a4b32caa4c1f", "id": "oss-d53efb5f85825895fbe2a4b32caa4c1f", "title": "Triaging CVEs for the Linux Kernel", "date": "2026-10-07T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Linux kernel currently sees around 60 CVEs per week. With the EU Cyber Resilience Act (CRA) rapidly approaching this creates a serious challenge for anyone shipping commercial products based on it: a lot of additional vulnerability management and compliance work.\n \n In this talk, we will introduce kernel-cve-triage, a tool developed under the umbrella of the Civil Infrastructure Platform (CIP). It addresses these compliance challenges with a unique approach, using the kernel’s Kconfig build configuration to determine which reported CVEs actually apply. With this method, we base our assessment only on the kernel source tree and its configuration and are build-system independent. This reduces false-positive CVEs by up to 95%, depending on the exact configuration and the set of vulnerabilities considered.\n \n We will also cover the key differences compared to another major kernel CVE automation tool: the Yocto Project and its cve-check. Finally, we will give an outlook and suggestions on how to improve the current situation for the Linux kernel's users.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d53efb5f85825895fbe2a4b32caa4c1f)", "url": "https://osselceu2026.sched.com/event/d53efb5f85825895fbe2a4b32caa4c1f", "persons": [{"public_name": "Christoph Steiger"}, {"public_name": "Negar Masoudifar"}]}, {"guid": "oss-9cfe0887a48aa3369fc971ba97ff5eb9", "id": "oss-9cfe0887a48aa3369fc971ba97ff5eb9", "title": "An Approach To Managing CVEs With Vendor Kernels", "date": "2026-10-07T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Managing vulnerabilities in the kernel has gotten more attention but also needs more effort due to the exploding number of CVEs. With the kernel now being a CNA since 2024, options have evolved, and most recently, since 596ad6c on openembedded-core/master, it has gotten \"easy\".\n \n But this is not working for vendor kernels, as they lag mainline and a rebase is impractical, if not impossible, due to the vendor delta.\n As vendor kernels are heavily used in the industry and a switch to linux-yocto is often not possible due to budget, timeline or vendor lock-in, a solution is needed.\n \n I've built a solution that locates the fix for each detected CVE on the matching stable branch, emits a candidate backport patch, verifies it applies cleanly, checks (via koverage, at line granularity) whether the affected code is compiled, and classifies results into actionable buckets.\n Output is a list of unaffected CVEs and a collection of patches for review. In my opinion, this is verified and evidence-backed patching rather than just a cherry-picked list.\n \n I'd like to present a solution (layer) which includes this workflow and start a broader discussion about the issue with vendor kernels.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9cfe0887a48aa3369fc971ba97ff5eb9)", "url": "https://osselceu2026.sched.com/event/9cfe0887a48aa3369fc971ba97ff5eb9", "persons": [{"public_name": "Jan Pfiffner"}]}, {"guid": "oss-c2d08773ae113ad80d795e959cef0849", "id": "oss-c2d08773ae113ad80d795e959cef0849", "title": "FIT Happens: How Secure Boot Wasn't", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Flat Image Tree (FIT) is Das U-Boot’s preferred boot image format and underpins billions of embedded Linux boot flows, with adoption extending into other bootloaders such as barebox. Its core idea of using the flattened device tree format for flexibility and code reuse, enabled widespread adoption, but also became a fertile source of subtle security flaws. This talk traces FIT’s evolution from a pragmatic design choice to a widely trusted format, highlighting how its structure led to recurring weaknesses, culminating in CVE-2026-33243, a decade-old vulnerability whose exploitation bypassed verified boot for millions of devices. Finally, Ahmad presents a proposal to improve FIT: a backwards-compatible scheme for whole-image signing that requires limited parsing, aiming to deliver stronger security guarantees without the format’s historical pitfalls.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c2d08773ae113ad80d795e959cef0849)", "url": "https://osselceu2026.sched.com/event/c2d08773ae113ad80d795e959cef0849", "persons": [{"public_name": "Ahmad Fatoum"}]}, {"guid": "oss-c775f1fe9f04d7f8497e04b986870b50", "id": "oss-c775f1fe9f04d7f8497e04b986870b50", "title": "Secure by Default in Embedded Linux: The Features You Are Probably Not Using", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Linux offers an impressive collection of security mechanisms, and recent years have added even more to the stack. Yet when reviewing embedded Linux products, I repeatedly run into a different problem: security features that are available, mature, and practical are simply not enabled. Many embedded projects still start from vendor examples, reference BSPs, or existing products. As a result, design decisions made years ago often become the default for the next generation of devices. This talk focuses on a set of practical security mechanisms that embedded developers can deploy from the beginning of a project with relatively little effort. Using examples from Yocto Project-based systems, we will examine features and tools such as: - overlayfs with its advanced features - filesystem permission hardening - seccomp-based system call filtering - fs-verity for file integrity protection - fscrypt for protecting data belonging to different users and use cases. We will discuss why they should be part of a base configuration and and show practical examples on how to do it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c775f1fe9f04d7f8497e04b986870b50)", "url": "https://osselceu2026.sched.com/event/c775f1fe9f04d7f8497e04b986870b50", "persons": [{"public_name": "Marta Rybczynska"}]}, {"guid": "oss-67715507be50c0c59c0e294bd06fced3", "id": "oss-67715507be50c0c59c0e294bd06fced3", "title": "SELinux in Embedded Linux: From Basics To Best Practices", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern vehicles employ a highly integrated architecture with a relatively small number of powerful Electronic Control Units (ECUs). Many of these ECUs run Linux and present a sizable attack surface. To mitigate the resulting threats, SELinux offers an enhanced mechanism for enforcing the principle of least privilege. Despite its strengths, SELinux remains complex and is not widely adopted. This talk offers a pragmatic introduction to SELinux, with concrete guidance you can apply to your embedded Linux project. This session will cover basic permissions and type enforcement in SELinux, including which permissions are required for an application start-up. It will introduce the reference policy and guide you through writing a first “hello-world” policy. We will also discuss SELinux in the context of Yocto. Finally, we will conclude with lessons learned from our experience in large-scale projects.\n\n[Open in Sched](https://osselceu2026.sched.com/event/67715507be50c0c59c0e294bd06fced3)", "url": "https://osselceu2026.sched.com/event/67715507be50c0c59c0e294bd06fced3", "persons": [{"public_name": "Tobias Kaufmann"}]}, {"guid": "oss-73f6fa03cc48aa962a699e6d1885a3fe", "id": "oss-73f6fa03cc48aa962a699e6d1885a3fe", "title": "OP-TEE Footguns: Lessons From the Integration Trenches", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "OP-TEE is a widely adopted Trusted Execution Environment (TEE) commonly used on ARM-based SoCs. While it is highly portable and often features strong vendor support, achieving a functionally working setup is only half the battle. There are surprisingly many pitfalls where a developer can successfully integrate OP-TEE, only to introduce subtle security misconfigurations that silently undermine the entire system's threat model. In this talk, Richard will outline the hidden security traps and integration challenges he has encountered over the past few years on custom hardware. Attendees will learn which footguns to watch out for, ultimately saving them the countless hours Richard spent debugging these exact issues.\n\n[Open in Sched](https://osselceu2026.sched.com/event/73f6fa03cc48aa962a699e6d1885a3fe)", "url": "https://osselceu2026.sched.com/event/73f6fa03cc48aa962a699e6d1885a3fe", "persons": [{"public_name": "Richard Weinberger"}]}, {"guid": "oss-330e3fa3678dfcd53b1dece9f653ec05", "id": "oss-330e3fa3678dfcd53b1dece9f653ec05", "title": "Securing Embedded Linux Buildsystems Against Supply Chain Attacks", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Embedded Linux build systems such as The Yocto Project and Buildroot rely on reused build artifacts and external inputs, while these represent an improvement in build time for subsequent builds, also create opportunities for supply chain attacks that are difficult to detect. This talk demonstrates practical attack vectors, showing how intermediate object files produced by make in Buildroot can be modified during the build to introduce malicious behavior without changing source code, and also demonstrate its possible to poison Yocto Project shared state (sstate) cache artifacts to propagate compromised binaries. These attacks are validated end-to-end by executing poisoned binaries in the final Linux image under QEMU. I will then present mitigation strategies, focusing on signing and verification of the sstate artifacts and improved control over build inputs. The discussion covers integration approaches and tradeoffs between security, performance, and developer workflows. Attendees will gain practical insight into real-world risks when creating customized Linux distributions and concrete steps to improve their build system's security.\n\n[Open in Sched](https://osselceu2026.sched.com/event/330e3fa3678dfcd53b1dece9f653ec05)", "url": "https://osselceu2026.sched.com/event/330e3fa3678dfcd53b1dece9f653ec05", "persons": [{"public_name": "Alejandro Enedino Hernandez Samaniego"}]}, {"guid": "oss-4c3a79eaa3fc11c1fe2bad3e1ad2db7f", "id": "oss-4c3a79eaa3fc11c1fe2bad3e1ad2db7f", "title": "Secure by Default: Building Locked-Down Embedded Linux Devices With Systemd", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern embedded Linux devices must balance security, maintainability, and operational flexibility. While the Linux kernel provides powerful security primitives such as namespaces, cgroups, eBPF, and dm-verity, integrating them consistently across products remains a challenge.\n \n This session explores how systemd has evolved beyond a traditional init system into a security and lifecycle management framework for embedded Linux platforms.\n \n Using practical examples, we will examine how systemd Portable Services enable immutable application deployment, how dm-verity protects software integrity from storage to execution, how systemd leverages eBPF for kernel-enforced sandboxing and policy enforcement, and how cgroup-based resource management can contain both faults and attacks.\n \n Attendees will learn how these mechanisms interact, how they can be integrated into Yocto-based systems, and how systemd can act as the orchestration layer between applications and modern Linux kernel security features.\n \n Rather than presenting isolated hardening techniques, this session introduces a practical architecture for designing maintainable, resilient, and secure-by-default embedded Linux products.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4c3a79eaa3fc11c1fe2bad3e1ad2db7f)", "url": "https://osselceu2026.sched.com/event/4c3a79eaa3fc11c1fe2bad3e1ad2db7f", "persons": [{"public_name": "Mohammad Abdoli"}]}], "South Hall 3 C (Floor 3)": [{"guid": "oss-dca1b54cf893853dee85f2e15346614d", "id": "oss-dca1b54cf893853dee85f2e15346614d", "title": "Asymmetric Multi-Processing (AMP) for Embedded - Where Are We?", "date": "2026-10-07T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern SoCs have a variety of CPU cores on board - e.g. on ARM we often see Cortex A, plus Cortex M, plus System Controllers. The number of cores is as increasing as the demands. Concepts like 'Software Defined Vehicle' (SDV) from the automotive sector is just one example for such complex demands. One obvious requirement is to run other OS than Linux on dedicated cores. Which means that resources like memory, clocks, pin control, power domains, etc. may not be under the sole control of Linux anymore. They now need to be shared and synchronized between all the participants. How does this work in practice? How do technologies like remoteproc, rpmsg, mailboxes, hardware spinlocks, virtio, and devicetree come into play here? How is their status-quo? And what about the non-Linux sides? What is open, what is proprietary, and how does this affect actual solutions? This talk is the result of a journey trying to support LinuxZephyr based AMP using a complete FreeSoftware stack on a Renesas community board.\n\n[Open in Sched](https://osselceu2026.sched.com/event/dca1b54cf893853dee85f2e15346614d)", "url": "https://osselceu2026.sched.com/event/dca1b54cf893853dee85f2e15346614d", "persons": [{"public_name": "Wolfram Sang"}]}, {"guid": "oss-1811d9b787aa62e47b8e76982c6c4688", "id": "oss-1811d9b787aa62e47b8e76982c6c4688", "title": "Marrying Device Tree and SCMI", "date": "2026-10-07T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Traditionally, Linux has been fully responsible for and in full control of all hardware components in an embedded system, as described by its Device Tree (DT). With the advent of heterogeneous System-on-Chips (SoCs) with multiple CPU cores (Application and Real-Time) and security technologies (Secure Boot, Trusted Environments, Virtualization), this is no longer the case. To avoid compromising system integrity, Linux must now be prevented from controlling system resources used by other CPU cores, and cannot be tasked with control of shared system resources, while Linux still needs to access these resources.\n \nThe Arm System Control and Management Interface (SCMI) is intended to solve this, by providing a firmware interface to handle access to system resources like clocks and power domains.\n \nIn this presentation, targeting Embedded Linux Developers and System Architects, Geert will give an overview of SCMI, and its impact on DT hardware description. He will discuss the challenges of supporting multiple evolving firmware versions and lineages, and possible solutions, based on experience gained while upstreaming Linux support for R-Car X5H, Renesas' fifth-generation automotive SoC.\n\n[Open in Sched](https://osselceu2026.sched.com/event/1811d9b787aa62e47b8e76982c6c4688)", "url": "https://osselceu2026.sched.com/event/1811d9b787aa62e47b8e76982c6c4688", "persons": [{"public_name": "Geert Uytterhoeven"}]}, {"guid": "oss-d38cfc104afe6a3631621ff9c7c5de3a", "id": "oss-d38cfc104afe6a3631621ff9c7c5de3a", "title": "When PWM Meets the Common Clock Framework: How To Write a (not So) Simple Linux PWM Driver", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Over time, Pulse Width Modulators went from simple devices with only an input clock and a prescaler to more complex ones.\n Nowadays, we can find PWM with several input clocks, several channels, shared and unshared prescalers among channels, and even bypasses which permits the PWM to act as a clock provider itself.\n \n This talk covers a presentation of PMW basics, how to write a kernel driver with the new PWM waveform internal API.\n Then, we will present a complex real life PWM device (Allwinner H616 PWM) and show how to leverage the power of the Common Clock Framework to help writing the kernel driver.\n We'll continue with use cases of the H616 PWM internal bypass, which short-cuts the PWM logic and outputs a sine wave.\n And finally, we'll show how to handle this bypass in the PWM driver and in the device tree.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d38cfc104afe6a3631621ff9c7c5de3a)", "url": "https://osselceu2026.sched.com/event/d38cfc104afe6a3631621ff9c7c5de3a", "persons": [{"public_name": "Richard Genoud"}]}, {"guid": "oss-67e7b9c1a7221d5ff6d88ef4eb6659d7", "id": "oss-67e7b9c1a7221d5ff6d88ef4eb6659d7", "title": "Signed, Sealed, Delivered: Yocto Project Reference Containers", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Containers ship everywhere, yet their software supply chain remains murky. Today's SBOM tools work backwards, scanning a finished image to guess what's inside — an approach prone to omissions and inaccuracies that the EU Cyber Resilience Act will make increasingly untenable.\n \n The Yocto Project uses a fundamentally different path. Because we build everything from source, we generate an accurate, complete SPDX 3.0 SBOM during the build, not after it — with full license and provenance information. In this presentation, we discuss a new approach that lets us build minimal, multi-layer OCI container images using standard Yocto tooling, with no special privileges required, to produce repeatable and auditable results.\n \n We will demonstrate end-to-end automation on the Yocto Project AutoBuilder: building reference container images, attaching SBOM and license attestations, signing them, and pushing to public registries. Attendees will leave understanding how reproducible builds, from source, close the container manifest gap — and how to consume these images today.\n\n[Open in Sched](https://osselceu2026.sched.com/event/67e7b9c1a7221d5ff6d88ef4eb6659d7)", "url": "https://osselceu2026.sched.com/event/67e7b9c1a7221d5ff6d88ef4eb6659d7", "persons": [{"public_name": "Tim Orling"}]}, {"guid": "oss-760993ccedf263c359549a69cc2c08ba", "id": "oss-760993ccedf263c359549a69cc2c08ba", "title": "Enabling High-Performance SPI NAND in Linux: PHY Tuning, DDR, and Beyond", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern OSPI NAND devices are pushing the Linux SPI memory stack beyond its original assumptions. Features such as DDR transfers, continuous read modes, multi-frequency operation, and PHY tuning promise substantial performance improvements, but at the cost of added complexity. Furthermore, there is no well-established standard for these implementations, leading vendors to adopt different approaches and assumptions that software must accommodate. This talk will walk through recent upstreaming efforts to enable advanced OSPI NAND capabilities in Linux. We will focus on one of the most challenging aspects: the introduction of fine-grained PHY tuning, which allows operating frequencies to be doubled or even tripled, enabling significantly faster transactions between the NAND device and the host controller. Introducing such features has raised a number of architectural challenges. We will discuss both the specifics of PHY tuning and the broader subsystem considerations required to support increasingly sophisticated flash devices. Particular attention will be given to integration challenges across the SPI-MEM and MTD stacks, as well as the lessons learned while upstreaming the solution.\n\n[Open in Sched](https://osselceu2026.sched.com/event/760993ccedf263c359549a69cc2c08ba)", "url": "https://osselceu2026.sched.com/event/760993ccedf263c359549a69cc2c08ba", "persons": [{"public_name": "Santhosh Kumar K"}, {"public_name": "Miquèl Raynal"}]}, {"guid": "oss-b60c8d1d0a660f62441871ed9672df70", "id": "oss-b60c8d1d0a660f62441871ed9672df70", "title": "A Clockwork Frequency: Bringing Spread Spectrum To the Linux Clock Subsystem", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Reducing electromagnetic interference (EMI) is often a key requirement for embedded products seeking EMC certification. Spread Spectrum Clocking (SSC) is a common hardware technique used to lower peak emissions by slightly modulating clock frequencies. This talk describes the journey of bringing SSC support to the Linux Clock Subsystem on platforms such as TI Sitara, STM32 and i.MX8M. The work started from customer requirements and platform-specific solutions, then evolved into a more generic approach integrated with the Linux clock framework and Device Tree. After a brief introduction to SSC and the real-world use cases behind this work, the talk explores the challenges of exposing SSC configuration through Linux abstractions. We will cover the design of new Device Tree bindings, the implementation of SSC support within the Linux clock framework, and the upstream review process that helped shape a reusable solution across different SoCs, highlighting how Linux can turn existing silicon capabilities into practical product solutions.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b60c8d1d0a660f62441871ed9672df70)", "url": "https://osselceu2026.sched.com/event/b60c8d1d0a660f62441871ed9672df70", "persons": [{"public_name": "Dario Binacchi"}]}, {"guid": "oss-d93342d36bd3a03ac52049857a09e284", "id": "oss-d93342d36bd3a03ac52049857a09e284", "title": "Porting Hafnium SPM to a Modern ARM SoC", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This talk clarifies what Hafnium secure partition manager is, where it is useful, and how to port it to a compatible SoC. First, Marek explains the ARM CPU core exception levels and security states, elaborates which software usually runs in the secure world, which does include TEEs, and clarifies why running only a single TEE instance may no longer be sufficient. Next, Marek introduces Hafnium secure partition manager, which allows running multiple isolated software instances in S-EL1, called secure partitions. Marek explains where Hafnium and secure partitions fit into the CPU security model, how other components of the firmware stack interact with Hafnium, and how Linux interacts with the software in secure partitions. Finally, Marek explains how Hafnium port to Renesas R-Car X5H was implemented, provides tips for debugging the Hafnium port, and elaborates in detail what changes were necessary to the rest of the firmware stack components, specifically TFA, OPTEE-OS and U-Boot, to make them compatible with the newly added Hafnium in S-EL2.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d93342d36bd3a03ac52049857a09e284)", "url": "https://osselceu2026.sched.com/event/d93342d36bd3a03ac52049857a09e284", "persons": [{"public_name": "Marek Vasut"}]}, {"guid": "oss-cc841624b909a6b5e724d22fb9d29742", "id": "oss-cc841624b909a6b5e724d22fb9d29742", "title": "ZBus for Linux", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "ZBus (Zephyr Bus) is a thread-to-thread message and data exchange protocol based on a bus topology. Since Zephyr v4.4.0, it also supports IPC between multiple Zephyr domains running on different CPU cores. While this fits well for homogeneous multicore systems, heterogeneous SoCs typically run different operating systems on different cores. A common ARM-based setup uses Linux on a Cortex-A core for high-level tasks and Zephyr on a Cortex-M core for real-time workloads. Communication between these environments requires data exchange across both cores and operating systems. Currently, the practical approach is to transfer raw bytes through RPMsg channels, requiring developers to implement custom protocols on both sides. ZBus for Linux bridges this gap by connecting Linux applications to a remote ZBus instance, enabling structured communication across heterogeneous systems. This talk presents the implementation of an early prototype, the challenges encountered, and the overall architecture of ZBus for Linux.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cc841624b909a6b5e724d22fb9d29742)", "url": "https://osselceu2026.sched.com/event/cc841624b909a6b5e724d22fb9d29742", "persons": [{"public_name": "Peter Fecher"}]}], "South Hall Foyer 2 (Floor 2)": [{"guid": "oss-fa86f67be1601ce8d16a83aa1897ab9d", "id": "oss-fa86f67be1601ce8d16a83aa1897ab9d", "title": "Zephyr Community Hub", "date": "2026-10-07T07:30:00+02:00", "start": "07:30", "duration": "09:55", "room": "South Hall Foyer 2 (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/fa86f67be1601ce8d16a83aa1897ab9d)", "url": "https://osselceu2026.sched.com/event/fa86f67be1601ce8d16a83aa1897ab9d", "persons": []}], "TBA": [{"guid": "oss-509718025ace54902b601b1eead3cbd9", "id": "oss-509718025ace54902b601b1eead3cbd9", "title": "LF Education Learning Lounge: CKNE", "date": "2026-10-07T13:00:00+02:00", "start": "13:00", "duration": "00:15", "room": "TBA", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk led by Alex Coma & Pablo Zaldívar in the Learning Lounge located on the 3rd Floor.\n\nLocation: LF Education Learning Lounge at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/509718025ace54902b601b1eead3cbd9)", "url": "https://osselceu2026.sched.com/event/509718025ace54902b601b1eead3cbd9", "persons": [{"public_name": "From Kubernetes Networking Skills to Verified Expertise"}]}, {"guid": "lpc20-b3821", "id": "lpc20-b3821", "title": "Evening Event", "date": "2026-10-07T19:30:00+02:00", "start": "19:30", "duration": "03:00", "room": "TBA", "track": "LPC: Social Events", "type": "LPC Social", "language": "en", "abstract": "", "description": "", "url": null, "persons": []}], "Terrace 2 A (Floor 2)": [{"guid": "oss-c09b0e009af578ed496e0f9355082f8f", "id": "oss-c09b0e009af578ed496e0f9355082f8f", "title": "Standardizing the Future: Navigating the Chaos of \"Open Source AI\"", "date": "2026-10-07T11:20:00+02:00", "start": "11:20", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Everyone claims their AI model is \"open source,\" but what does that actually mean when the weights, training data, and algorithms are hidden behind corporate walls?\nA deep dive into the battle over the definition of Open Source AI (referencing the Open Source Initiative's framework). We will discuss why standardizing this definition is critical to preventing corporate capture of the next generation of technology.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c09b0e009af578ed496e0f9355082f8f)", "url": "https://osselceu2026.sched.com/event/c09b0e009af578ed496e0f9355082f8f", "persons": [{"public_name": "Peter Farkas"}]}, {"guid": "oss-61ce8c87526d3c9ae4e2a07514260203", "id": "oss-61ce8c87526d3c9ae4e2a07514260203", "title": "Making the Kernel Chat: How To Get Debug Output", "date": "2026-10-07T13:30:00+02:00", "start": "13:30", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "When starting with Linux kernel development, beginners quickly encounter a frustrating roadblock: system crashes that produce absolutely no output, neither on the screen nor in the logs. Fortunately, Linux provides a rich toolbox designed to extract debug information even in the most desperate situations. The main challenge is knowing which tool fits a specific scenario and what data to expect. In this talk, Richard shares practical guidance on the debugging mechanisms he has relied on over his past decade of working inside the Linux kernel. Attendees will learn how to break through the silence by deploying the right tool for the right type of crash. Besides well known mechanisms such as earlyprintk, pstore, and ftrace, Richard will reveal lesser known Linux debugging gems used to capture logs from freezing systems, trace internal behavior, and retrieve postmortem panic data. By the end of the talk, beginners will have a clear and actionable roadmap for diagnosing actual kernel issues, ensuring they know exactly what to do the next time the kernel suddenly goes quiet.\n\n[Open in Sched](https://osselceu2026.sched.com/event/61ce8c87526d3c9ae4e2a07514260203)", "url": "https://osselceu2026.sched.com/event/61ce8c87526d3c9ae4e2a07514260203", "persons": [{"public_name": "Richard Weinberger"}]}, {"guid": "oss-04f4270a40c457063bcda1286dc8ed8e", "id": "oss-04f4270a40c457063bcda1286dc8ed8e", "title": "Derivative Work and Modification(s): Where Copyright and Open Source Software Collide - Yet Again", "date": "2026-10-07T14:25:00+02:00", "start": "14:25", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Talking points: • Copyright law as a (wrong) playing field for open source software • Working with what we have – the curious case of modifications • Modification of software – what does this mean practically (e.g., bug fix, alteration of existing code, new code) • Derivative work and modification in FOSS licensing • Practical cases and “risks” o Products o M&As Abstract: There are many legal concepts that create havoc in the open source world, but only a few are as “scary” as the concept of modification and derivative work. Copyright law concept are challenging to adopt in the software context. The ambiguity of the legislation as well as the case law in many jurisdictions, such as the US and many EU countries and institutes, is proof enough that this is a convoluted topic, and not just in theory. The practical impact of derivative works and modifications runs through the entirety of the open source compliance process. In this session, we will attempt to demystify the aforementioned concepts and possibly open up more questions for discussion.\n\n[Open in Sched](https://osselceu2026.sched.com/event/04f4270a40c457063bcda1286dc8ed8e)", "url": "https://osselceu2026.sched.com/event/04f4270a40c457063bcda1286dc8ed8e", "persons": [{"public_name": "Eleftheria Stefanaki"}, {"public_name": "Jimmy Ahlberg"}]}, {"guid": "oss-2bc8a1c17d0e0b3b98ab22e381dd437c", "id": "oss-2bc8a1c17d0e0b3b98ab22e381dd437c", "title": "Your Backup Data Doesn't Belong To You", "date": "2026-10-07T15:35:00+02:00", "start": "15:35", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "You can rebuild your infrastructure from a git repo and migrate workloads across clouds. Your backup data is locked in a proprietary format, on vendor hardware, encrypted with keys you don't fully control. This talk applies the open-source portability argument to resilience, and examines what genuine backup ownership actually requires: open formats, storage-backend independence, and key custody that stays with the data owner.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2bc8a1c17d0e0b3b98ab22e381dd437c)", "url": "https://osselceu2026.sched.com/event/2bc8a1c17d0e0b3b98ab22e381dd437c", "persons": [{"public_name": "Julien Castets"}]}, {"guid": "oss-67149b495a4aa8247e8ce0147c2addcd", "id": "oss-67149b495a4aa8247e8ce0147c2addcd", "title": "A Day in the Life of a CVE Remediator", "date": "2026-10-07T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This talk will focus on a day in the life of CVE remediators. It will go through the full process of identifying, resolving, upstreaming and following up CVEs in various dependencies. It will also go through the various Open Source tools that we use throughout the full process, touch on our experiences working upstream and go through how we are sharing this knowledge and experience internally.\n\n[Open in Sched](https://osselceu2026.sched.com/event/67149b495a4aa8247e8ce0147c2addcd)", "url": "https://osselceu2026.sched.com/event/67149b495a4aa8247e8ce0147c2addcd", "persons": [{"public_name": "Shubham Kalloli"}, {"public_name": "Cameron Scholes"}]}, {"guid": "oss-a35ba0429e809f1d9b69cfb4108847e4", "id": "oss-a35ba0429e809f1d9b69cfb4108847e4", "title": "5 Practical Tips To Improve Your Log File Analysis Efficiently", "date": "2026-10-07T17:25:00+02:00", "start": "17:25", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Linux now stands as the most widely used operating system for production and development environments, as it provides a lot of services (daemons) and tools for debugging. One core part are the log files which is widely used. You can use built-in commands such as less, grep, awk/sed or tail for log analysis, but there are times when you need some more advanced commands or tools that can help to investigate large log files efficiently. In this talk, you will learn five practical tips to view your log files for analysis. You will learn about Open Source tools that can make your job easier for your daily tasks. Join us to learn more about Linux, log analysis, aggregation tools, and the value of Open Source Community.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a35ba0429e809f1d9b69cfb4108847e4)", "url": "https://osselceu2026.sched.com/event/a35ba0429e809f1d9b69cfb4108847e4", "persons": [{"public_name": "Syed Usman Ahmad"}]}], "Terrace 2 B (Floor 2)": [{"guid": "oss-a3cfd80a941464df663e1d424e586573", "id": "oss-a3cfd80a941464df663e1d424e586573", "title": "Hacker Space", "date": "2026-10-07T08:00:00+02:00", "start": "08:00", "duration": "10:30", "room": "Terrace 2 B (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Discover a space, where you can collaborate, create, and explore new ideas with fellow attendees. Whether you’re here to learn or build, our space is open for everyone to enjoy throughout the conference!\n\n[Open in Sched](https://osselceu2026.sched.com/event/a3cfd80a941464df663e1d424e586573)", "url": "https://osselceu2026.sched.com/event/a3cfd80a941464df663e1d424e586573", "persons": []}], "Žofín Palace": [{"guid": "oss-7511cd11a33328d3f1bc710ebd0968ff", "id": "oss-7511cd11a33328d3f1bc710ebd0968ff", "title": "Attendee Reception", "date": "2026-10-07T18:30:00+02:00", "start": "18:30", "duration": "03:00", "room": "Žofín Palace", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Location: Žofín Palace, Slovanský ostrov 226, 110 00 Praha 1, Czechia\n\nJoin us at Žofín Palace to continue the conversations beyond the conference venue and step into a night of sophisticated spy-inspired glamour, timeless casino elegance, and classic Prague charm. The grand ballrooms offer the perfect backdrop to try your luck at classic casino tables, indulge in authentic Czech cuisine, and connect with peers.\n\nTo celebrate 35 Years of Linux, keep an eye out for the Agent 035 Scavenger Hunt for a chance to win exclusive prizes. Whether you are looking to spark new open source collaborations or simply enjoy the surroundings, it is set to be an unforgettable night.\n\nTo make it even more memorable, we have secured exclusive discounts on local Prague suit and dress rentals. Whether you dress up for the theme or come as you are, all attendees are welcome to join us for a great evening of connection and celebration. No matter your style for the evening, we kindly ask that bags and backpacks be left at your hotel prior to arrival to allow for smooth entry.\n\nThere are several ways to get to Zofin Palace from the Prague Congress Centre:\nIt’s approximately a 20-25 minute transit ride from the conference venue. Taxis and rideshares are also available outside of the Prague Congress Centre.\nLimited transportation will be provided for attendees with mobility or other accessibility needs to ensure a smooth and comfortable journey. Please inquire at the Registration Info Desk.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7511cd11a33328d3f1bc710ebd0968ff)", "url": "https://osselceu2026.sched.com/event/7511cd11a33328d3f1bc710ebd0968ff", "persons": []}]}}, {"index": 4, "date": "2026-10-08", "rooms": {"Chamber Hall (Floor 3)": [{"guid": "oss-d5f4abf462329ccfec90db4c87899625", "id": "oss-d5f4abf462329ccfec90db4c87899625", "title": "Linux Security Summit [Additional Fee; Pre-Registration Required]", "date": "2026-10-08T09:00:00+02:00", "start": "09:00", "duration": "08:00", "room": "Chamber Hall (Floor 3)", "track": "OSS: Co-located Events", "type": "OSS Co-located Event", "language": "en", "abstract": "", "description": "Linux Security Summit (LSS) is a technical forum for collaboration between Linux developers, researchers, and end users with the primary aim of fostering community efforts to analyze and solve Linux security challenges.\nLSS is where key Linux security community members and maintainers gather to present their work and discuss research with peers, joined by those who wish to keep up with the latest in Linux security development and who would like to provide input to the development process.\nTo learn more, visit the event website.\nHow to Register: Register for Linux Security Summit Europe as a stand alone event or add it to your Open Source Summit Europe registration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d5f4abf462329ccfec90db4c87899625)", "url": "https://osselceu2026.sched.com/event/d5f4abf462329ccfec90db4c87899625", "persons": []}], "Club A (Floor 1)": [{"guid": "oss-a22c18f046bdc8479fbe6e0e1217556e", "id": "oss-a22c18f046bdc8479fbe6e0e1217556e", "title": "Sponsored Session: Advancing Trust in Open Source: CIP IEC-62443-4-x Achievement and CRA Compliance Readiness", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "With increasing regulatory pressure and evolving cybersecurity requirements, product teams must navigate complex standards while maintaining speed to market.\nThis session provides a practical, implementation-focused deep dive into achieving IEC 62443-4-x compliance for components, alongside insights into aligning with the EU Cyber Resilience Act (CRA).\nWe will showcase how the CIP Security Workgroup has developed precise engineering artefacts—including IEC layer test suites and supporting documentation—that significantly reduce the effort required for compliance.\nIn addition, we will examine recent investigations into CRA requirements and demonstrate how IEC 62443-4-x compliance can help bridge critical gaps toward CRA readiness.\nAttendees will leave with actionable guidance, reusable assets, and a clear roadmap to streamline compliance efforts while future-proofing their products against regulatory demands.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a22c18f046bdc8479fbe6e0e1217556e)", "url": "https://osselceu2026.sched.com/event/a22c18f046bdc8479fbe6e0e1217556e", "persons": [{"public_name": "Dinesh Kumar"}, {"public_name": "Pasquale Nieddu"}]}, {"guid": "oss-a01844287199cb79a4a8732d07235161", "id": "oss-a01844287199cb79a4a8732d07235161", "title": "7 MCP Servers, 50+ Tools, Zero Duplicate Code: A 5-Minute Architecture Tour", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:10", "room": "Club A (Floor 1)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "We had a problem: every new integration meant writing the same code twice—once for our React dashboard, once for our AI assistant. JIRA, TestRail, Jenkins, GitHub—the duplication was unsustainable.\n \n MCP changed everything. In this lightning talk, I'll show how we built 7 MCP servers that now power both our dashboard AND our AI agents from a single source of truth. 50+ tools, used daily by Dev, QE, and Management teams.\n \n In 5 minutes, you'll see:\n \n - The architecture: FastAPI as a unified backend → MCP Servers → External APIs (JIRA, TestRail, Jenkins, GitHub, GSheets, Release Calendar, Risk Predictor)\n - The pattern: Thin MCP tools that call centralized APIs—one integration, two consumers\n - Real metrics: 10+ hours/week saved per engineer; release tracking, regression monitoring, and production health checks unified.\n - Why MCP wins: AI agents and dashboards evolve independently while sharing the same data layer.\n \n We eliminated duplicate code, reduced maintenance burden, and shipped faster. All code is open source.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a01844287199cb79a4a8732d07235161)", "url": "https://osselceu2026.sched.com/event/a01844287199cb79a4a8732d07235161", "persons": [{"public_name": "Harika Chebrolu"}]}, {"guid": "oss-6c04d22f39dadb117d5bc8c57f156a8e", "id": "oss-6c04d22f39dadb117d5bc8c57f156a8e", "title": "Sponsored Session: Building Secure and Compliant Critical Infrastructure with Open Source", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Critical infrastructure operators face growing pressure to modernize their systems while maintaining the highest levels of security, reliability, and regulatory compliance in an era shaped by regulations such as the EU Cyber Resilience Act (CRA) and NIS2. In this session, Hitachi shares two real-world modernization journeys with open source from the energy and railway sectors.\n\nThe first half focuses on Hitachi Energy’s adoption of Embedded Linux and Yocto for next-generation grid automation products. Hitachi Energy actively contributes to the modernization of energy systems, making electricity more accessible worldwide. In product development, adopting Embedded Linux and Yocto enhances flexibility and maintainability, with strong legal compliance, license management, and open-source collaboration. Hitachi Energy is rolling out Linux-based energy grid automation products and this talk covers their transition to embedded Linux via Yocto, addressing industry protocol support, impacts of the EU Cyber Resilience Act, OSS license challenges, and navigating these within a slow-evolving sector.\n\nThe second half presents Hitachi Rail’s modernization of mission-critical railway management systems using Keycloak, an an open source identity and access management platform. As railway systems become increasingly interconnected, cybersecurity and identity management have become fundamental architectural concerns. We show how secure-by-design principles were applied to modernizing legacy environments, with Keycloak. We also demonstrate how Keycloak helps address several IEC 62443-4-2 requirements and provides a strong foundation for meeting emerging regulatory expectations such as CRA.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6c04d22f39dadb117d5bc8c57f156a8e)", "url": "https://osselceu2026.sched.com/event/6c04d22f39dadb117d5bc8c57f156a8e", "persons": [{"public_name": "Benjamin Weber"}, {"public_name": "Bernhard Denner"}]}, {"guid": "oss-6530e0b8dbea461e200e36c133e4ac09", "id": "oss-6530e0b8dbea461e200e36c133e4ac09", "title": "Sponsored Session: LLM-Assisted Vulnerability Research in Yocto", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Yocto Project provides several building blocks for supply-chain security, including pinned sources, checksums, source mirroring, SBOM support, and reproducible builds. These mechanisms are invaluable, but only as strong as the code behind them.\n \nIn this talk, I will describe a project in which I used LLMs to assist security research on selected Yocto Project components. I will explain how candidate findings were identified, manually triaged, reproduced, and filtered before being reported upstream.\n \nThe talk will cover how I separated real issues from false positives, assessed whether suspicious code patterns were exploitable, prepared reports that maintainers could act on, and upstreamed patches where appropriate.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6530e0b8dbea461e200e36c133e4ac09)", "url": "https://osselceu2026.sched.com/event/6530e0b8dbea461e200e36c133e4ac09", "persons": [{"public_name": "Anders Heimer"}]}, {"guid": "oss-2b707c24c6d0eec75576cc94f9a349af", "id": "oss-2b707c24c6d0eec75576cc94f9a349af", "title": "Panel: Found It. Filed It. Forgotten? The Open Source Fix Problem in AI Era", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "We have become highly effective at finding vulnerabilities, accelerated by AI-driven analysis. We can scan at scale, assign scores, and generate reports with unprecedented speed. The breakdown happens after discovery.\n \n For many maintainers, security reports arrive as noise: limited context, unclear expectations, and little support to carry fixes through to completion. Backlogs grow, trust declines, and critical issues remain unresolved.\n \n This panel brings together security and open source leaders from Microsoft, Google and AWS to confront an uncomfortable reality: discovery is the easy part. Remediation, especially in shared infrastructure maintained by a small number of overextended contributors, is where the system fails.\n \n We will explore what actually helps maintainers move from report to resolution. What makes a report actionable? How do we reduce noise and avoid drive-by reporting? How do we support fixes through triage, patching, and downstream adoption without taking over projects?\n \n If you are a struggling maintainer or an industry consumer who wants to support OSS you depend on without overloading it, this session is for you. The focus is simple: fixes that land.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2b707c24c6d0eec75576cc94f9a349af)", "url": "https://osselceu2026.sched.com/event/2b707c24c6d0eec75576cc94f9a349af", "persons": [{"public_name": "Rao Lakkakula"}, {"public_name": "Bob Callaway"}, {"public_name": "Stormy Peters"}]}, {"guid": "oss-9569ccaf9ca5bbe1c13c564066999e20", "id": "oss-9569ccaf9ca5bbe1c13c564066999e20", "title": "OpenGrid: An Open-Source Electric Grid Modeling Ecosystem", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modeling underlies the grid we all rely on. Every decision to build a new power plant or transmission line starts with a model run, yet planning models are often opaque, expensive, and difficult to replicate. That lack of transparency, along with uneven access to high-fidelity tools and data, breeds distrust and delay in the planning processes essential to decarbonizing the grid and expanding energy access worldwide. Open-source planning tools are growing in number and capability, but real barriers to adoption remain. OpenGrid aims to build a shared infrastructure foundation for open-source modeling, so open tools and data can become a credible industry standard. This session introduces the OpenGrid initiative, announced as a project under Linux Foundation fiscal sponsorship, covering both the thinking behind it, the plans to build it out and how you can get involved.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9569ccaf9ca5bbe1c13c564066999e20)", "url": "https://osselceu2026.sched.com/event/9569ccaf9ca5bbe1c13c564066999e20", "persons": [{"public_name": "Alice Yake"}, {"public_name": "Ryan Attig"}]}], "Club E (Floor 1)": [{"guid": "oss-7c6a3ff402e8e2a5bdbc5b055c60fbf0", "id": "oss-7c6a3ff402e8e2a5bdbc5b055c60fbf0", "title": "Maven-Lockfile: Locking Down the JVM Supply Chain for Hermetic Builds", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern software projects depend on hundreds of third-party libraries, making reproducible and secure builds increasingly difficult. However, Maven, one of the most widely used Java build tools, has no native lockfile support. This leaves projects exposed to version drift, tampered artifacts, and dependency confusion attacks, while making hermetic builds difficult to achieve.\n \n Maven-lockfile addresses this by generating a cryptographic record of all resolved artifacts, including transitive dependencies, and validating them on every build. This enables frozen dependency sets for exact historical reproducibility. In collaboration with Red Hat, we extended maven-lockfile to systematically capture build extensions, BOMs, and other dynamically fetched artifacts required for hermetic builds, and compare it against Maven-native approaches like Trusted Checksums.\n \n To complete the workflow, we demo maven-lockfile alongside Hermeto, a CLI tool that pre-fetches dependencies into a local cache, enabling fully network-isolated builds.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7c6a3ff402e8e2a5bdbc5b055c60fbf0)", "url": "https://osselceu2026.sched.com/event/7c6a3ff402e8e2a5bdbc5b055c60fbf0", "persons": [{"public_name": "Aman Sharma"}, {"public_name": "Bruno Pimentel"}]}, {"guid": "oss-81c6f78f0dc2223d93b5b8b2221419a4", "id": "oss-81c6f78f0dc2223d93b5b8b2221419a4", "title": "Same Tag, Different Risk: Catching Semantic SBOM Drift Across Multi-Arch Containers", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This isn't just about Airtel but for every organisation as multi-arch OCI manifest list lets one image tag resolve to different binaries per architecture, teams treat that tag as a single security unit, yet the amd64, arm64 & riscv64 builds underneath frequently diverge, a base-image bump, a differently resolved dependency version or missing backport can leave one architecture patched against CVE while another silently isn't & no scanner today compares SBOMs across the architectures inside same manifest list, each platform image is scanned in isolation & reported as N separate, ostensibly fine results. Talk introduces manifest-list-aware SBOM differ that pulls every per-architecture image inside tag, generates SBOM for each & diffs them against each other rather than against historical baseline, flagging any package, version or vulnerability status that differs across architectures sharing same tag, the same Dockerfile & same assumed security posture across every platform it claims to support. We show this catching real drift in popular base images, demo CI gate that blocks a push when architectures diverge unexpectedly & discuss how it slots into existing signing pipelines.\n\n[Open in Sched](https://osselceu2026.sched.com/event/81c6f78f0dc2223d93b5b8b2221419a4)", "url": "https://osselceu2026.sched.com/event/81c6f78f0dc2223d93b5b8b2221419a4", "persons": [{"public_name": "Yogesh Sardana"}]}, {"guid": "oss-e283643e8ce739e15ac89c6cd0a8d233", "id": "oss-e283643e8ce739e15ac89c6cd0a8d233", "title": "Still Leading the Pack: Modernizing Kubernetes Supply Chain Security", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Container image signing, SBOMs, SLSA attestations.... five years ago, the Kubernetes project was a trailblazer securing its releases using these and other security features. Having developed its own tools and solutions, things \"just worked\" for the project, but security technologies evolve and so have we.\n \n Join us as as we dig deep to explore and compare the metadata the project started producing in 2021 with how modern supply chain tools expect them today.\n \n During this talk, we'll do an overview of the updates and modernization of the Kubernetes secure build process and tools. We will examine visually the quality improvements to the Kubernetes SBOMs, how we migrated the SLSA provenance we use to gate our releases to SLSA v1, signing into Sigstore bundles, and, most importantly, how the the toolchain built by K8s Release Engineering enables more than a hundred independently managed projects under the Kubernetes umbrella to build and ship security features to protect themselves and their users.\n \n Out tooling is available for anyone so perhaps we can inspire you to to the same for your projects!\n\n[Open in Sched](https://osselceu2026.sched.com/event/e283643e8ce739e15ac89c6cd0a8d233)", "url": "https://osselceu2026.sched.com/event/e283643e8ce739e15ac89c6cd0a8d233", "persons": [{"public_name": "Adolfo García Veytia"}, {"public_name": "Stephen Augustus"}]}, {"guid": "oss-81c0a3a24954bfe3f3eaa6553e2d232e", "id": "oss-81c0a3a24954bfe3f3eaa6553e2d232e", "title": "No Slides, No Pitches: What Practitioners Really Think of OpenSSF Tools", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Somewhere along the way, the security ecosystem started asking maintainers to add more steps, update more plugins, and generate more outputs, without asking what it costs them. At cdCon, the OpenSSF DevRel community ran two back-to-back sessions to fix that: first an open, no-pitches roundtable where practitioners told us where tools miss the mark, then a maintainer lightning round where the people who could act on that feedback were already in the room.\n \n This talk distills what came out of both. We'll cover the adoption gap (lots of awareness, far less implementation), why a year on this community still doesn't trust the SBOMs it generates, the recurring \"I have one security engineer — where do I start?\" problem, and the confusion created by too many badges and not enough wayfinding. Then we'll show how a wave of OpenSSF projects — from gittuf and Sigstore to OpenVEX, SBOMit, and the OSPS Baseline — are responding, including where there is work to do.\n\n[Open in Sched](https://osselceu2026.sched.com/event/81c0a3a24954bfe3f3eaa6553e2d232e)", "url": "https://osselceu2026.sched.com/event/81c0a3a24954bfe3f3eaa6553e2d232e", "persons": [{"public_name": "Katherine Druckman"}, {"public_name": "Kadi McKean"}, {"public_name": "Tabatha DiDomenico"}]}, {"guid": "oss-989b487428293d06915887718a313edf", "id": "oss-989b487428293d06915887718a313edf", "title": "Verifying ABI Compatibility Across Releases and CPU Architectures", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Package updates across multiple architectures and long-term release branches complicate pipeline testing. Source-level tests usually pass during a package upgrade, missing Application Binary Interface (ABI) changes that later break downstream images and containers at runtime.\n \n This talk introduces an extension to meta-binary-audit [1] that adds automated binary analysis to release CI pipelines for Yocto environments. Integrating libabigail into the pipeline reports exactly what changed in the binary interface before code is released.\n \n The session details the CI architecture, parallel binary audits across multiple architectures, and how to track symbol-level ABI changes during LTS uplifts, using the migration from Scarthgap to Wrynose as an example. Attendees will leave with practical methods to analyze these interface changes, evaluate compatibility across releases, and prevent broken downstream images.\n \n [1] https://github.com/Nordix/meta-binaryaudit/\n\n[Open in Sched](https://osselceu2026.sched.com/event/989b487428293d06915887718a313edf)", "url": "https://osselceu2026.sched.com/event/989b487428293d06915887718a313edf", "persons": [{"public_name": "Adarsh Jagadish Kamini"}, {"public_name": "Daniel Turull"}]}, {"guid": "oss-d207aca04f03d3bd4f284d285eeb7e89", "id": "oss-d207aca04f03d3bd4f284d285eeb7e89", "title": "From Source To Wheel: Solving Python's Bootstrapping Problem", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "When you run pip install numpy, pip downloads a pre-built binary someone else compiled. For most developers that's fine, but in regulated environments or anywhere supply chain integrity matters, it's a gap one that incidents like the LiteLLM PyPI compromise and fake DeepSeek packages have made harder to ignore. There's a bootstrapping problem too: building numpy needs setuptools, and building setuptools needs… setuptools. Every existing tool pip, uv, conda breaks this cycle by quietly downloading pre-built binaries. None give you a unified view of the full dependency tree, making it hard to audit what was built, from where, and in what order. This talk walks through an unsolved problem in Python packaging bootstrapping entire dependency trees from source and how Fromager tackles it using PEP 517. We'll cover: 1. Why pip install --no-binary :all: doesn't get you to \"built from source\" 2. Where pip, Nix, Spack, and Bazel each fall short 3. The two-stage discover/build split and the JSON artifacts it produces for auditing 4. Why building packages as collections keeps them ABI-compatible critical for stacks like PyTorch with CUDA/ROCm native code\n\n[Open in Sched](https://osselceu2026.sched.com/event/d207aca04f03d3bd4f284d285eeb7e89)", "url": "https://osselceu2026.sched.com/event/d207aca04f03d3bd4f284d285eeb7e89", "persons": [{"public_name": "Rohan Devasthale"}, {"public_name": "Christian Heimes"}]}], "Club H (Floor 1)": [{"guid": "oss-4644b498e017402b1ae94daee76c3d20", "id": "oss-4644b498e017402b1ae94daee76c3d20", "title": "Technical Writing in the Age of AI", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "With the advent of large language models, looking up human-made software documentation might seem like an antiquated and inefficient way of getting information. On top of that, Claude Code and similar tools can now crunch information straight from your JIRAs and conjure new pull requests at speeds that cannot be matched by even the most veteran documentation maker.\n \n So where does this leave you as a technical writer?\n \n Let us come together as professional technical communicators to grumble and bellyache, but mainly to share tips and insights on how to make the best of the paradigm shifts and upheavals that AI advancements now introduce to our work-life on a regular basis.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4644b498e017402b1ae94daee76c3d20)", "url": "https://osselceu2026.sched.com/event/4644b498e017402b1ae94daee76c3d20", "persons": [{"public_name": "Jiri Herrmann"}]}, {"guid": "oss-c5a1b419a94f7315862b675ab22b99a1", "id": "oss-c5a1b419a94f7315862b675ab22b99a1", "title": "Establishing a Documentation Process in an Open Source Community", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Many communities reach a point where knowledge has naturally concentrated in the hands of a few dedicated people. It happens organically. Someone steps up, carries the weight, and keeps things moving. But without a process to capture and distribute that knowledge, the community becomes fragile without ever meaning to. Contributors arrive eager and leave quietly. Decisions get made but are never recorded. Onboarding repeats itself because nothing was ever written down.\n This talk is about what happens when a community decides to change that. Drawing on experience as a maintainer and community manager, I will walk through the journey of building a documentation process from the ground up, not by writing more docs, but by shifting how the community thinks about knowledge itself. From auditing where knowledge lived, to creating structures for knowledge capture and decision documentation, forming a working group that distributed ownership, and building triage and mentorship pathways that made contribution genuinely accessible.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c5a1b419a94f7315862b675ab22b99a1)", "url": "https://osselceu2026.sched.com/event/c5a1b419a94f7315862b675ab22b99a1", "persons": [{"public_name": "V. Thulisile Sibanda"}]}, {"guid": "oss-72493007ca48c3e5b5adb12e8534d047", "id": "oss-72493007ca48c3e5b5adb12e8534d047", "title": "Building Resilience: The Future of Open Source", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Quietly over the course of 25 years, open source software evolved from a domain perceived as that of only hobbyists into the invaluable backbone of modern digital infrastructure. Sustaining that success for the future will require more than code. It requires resilience: a trait not of technology. but of people. Of community. With increasing regulation around the world, evolving cybersecurity requirements, burnt out contributors, and stagnant corporate participation and funding, how do we ensure the ecosystem’s continued success? The things that have worked for the first decades will not be the things that keep us going. Let’s look together at sustainability not only as a funding problem, but also from the perspectives of global policy changes, security, and other intertwined issues that face open source in the coming years.\n\n[Open in Sched](https://osselceu2026.sched.com/event/72493007ca48c3e5b5adb12e8534d047)", "url": "https://osselceu2026.sched.com/event/72493007ca48c3e5b5adb12e8534d047", "persons": [{"public_name": "Ruth Suehle"}]}, {"guid": "oss-f8aeb35932c98d0f13a783a81b13cadd", "id": "oss-f8aeb35932c98d0f13a783a81b13cadd", "title": "Diagrams & Dragons: Teaching Technical Writing to University Students the Open Source Way", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "For 4 years, the documentation team of Red Hat Czech has been teaching the fundamentals of technical writing to university students in Brno. \n \n The courses have been attended by students of IT as well as non-technical majors, and have been well received by both\n \n In this talk, we will share how we approached constructing the courses, what worked, what didn't, and how we refined the syllabus year-over-year to adapt to the recent turbulence in the world of technology.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f8aeb35932c98d0f13a783a81b13cadd)", "url": "https://osselceu2026.sched.com/event/f8aeb35932c98d0f13a783a81b13cadd", "persons": [{"public_name": "Jiri Herrmann"}]}, {"guid": "oss-944b127351efc5d8b1e448e294d3933f", "id": "oss-944b127351efc5d8b1e448e294d3933f", "title": "Open Source Maintainers Vs. The CVE Tsunami", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "AI-powered security models have fundamentally changed vulnerability discovery. What once took months of expert auditing now runs continuously at scale, flooding maintainers with vulnerability reports, coordinated disclosure requirements, patch demands, and CVE assignments. The industry celebrates AI finding more bugs; maintainers are drowning in the reports.\n \n This talk examines how maintainers of critical open-source infrastructure can adapt to handle the incoming wave. This requires new processes at all levels of the development process. Maintainers can use AI tooling to help differentiate slop requests from genuine vulnerabilities, use them to help automate and coordinate disclosures, and start proactively searching for these vulnerabilities so they never entered production in the first place. We'll give concrete examples and patterns that you can use to apply to your own works as a maintainer or security researcher.\n\n[Open in Sched](https://osselceu2026.sched.com/event/944b127351efc5d8b1e448e294d3933f)", "url": "https://osselceu2026.sched.com/event/944b127351efc5d8b1e448e294d3933f", "persons": [{"public_name": "Madelyn Olson"}, {"public_name": "Harkrishn Patro"}]}], "Congress Hall (Floor 2)": [{"guid": "oss-5db5e94b003045e291227f2dc3319142", "id": "oss-5db5e94b003045e291227f2dc3319142", "title": "Welcome Back", "date": "2026-10-08T09:00:00+02:00", "start": "09:00", "duration": "00:05", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/5db5e94b003045e291227f2dc3319142)", "url": "https://osselceu2026.sched.com/event/5db5e94b003045e291227f2dc3319142", "persons": [{"public_name": "Paula Grzegorzewska"}]}, {"guid": "oss-0d4454405c82bec9f457bc003045e4f5", "id": "oss-0d4454405c82bec9f457bc003045e4f5", "title": "Keynote: Sovereignty Requires Real Choice", "date": "2026-10-08T09:05:00+02:00", "start": "09:05", "duration": "00:15", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/0d4454405c82bec9f457bc003045e4f5)", "url": "https://osselceu2026.sched.com/event/0d4454405c82bec9f457bc003045e4f5", "persons": [{"public_name": "Tarek Becker"}]}, {"guid": "oss-72089ff39d95917159aec3f2ba69ee79", "id": "oss-72089ff39d95917159aec3f2ba69ee79", "title": "Keynote: From AI Runtime to System Agents: Reimagining Linux for the AI Era with openKylin", "date": "2026-10-08T09:25:00+02:00", "start": "09:25", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "As on-device foundation models, AI PCs and agentic applications converge, AI is evolving from an application-layer capability into a foundational service increasingly embedded within the operating system. For Linux distributions, the challenge is no longer simply hosting models, but providing reusable AI infrastructure that bridges model capabilities with real system functions.\n\nopenKylin is exploring this shift from \"AI on OS\" to \"AI for OS\". Its AI subsystem provides a unified runtime, inference services and developer interfaces, while a system-level agent framework exposes operating system capabilities as structured, verifiable tools, enabling bounded and auditable interactions with the desktop.\nThis session shares openKylin's architectural approach to operating systems in the age of AI, covering heterogeneous models and hardware support, abstraction of OS services into agent-accessible tools, and mechanisms for trustworthy execution through least-privilege design, policy enforcement and auditability. It also examines how Linux distributions may evolve beyond traditional software platforms into open, trusted and extensible foundations for intelligent computing.\n\n[Open in Sched](https://osselceu2026.sched.com/event/72089ff39d95917159aec3f2ba69ee79)", "url": "https://osselceu2026.sched.com/event/72089ff39d95917159aec3f2ba69ee79", "persons": [{"public_name": "Liu Min"}]}, {"guid": "oss-eb9fc194ec9ebb182ed9cbe3c2db6c09", "id": "oss-eb9fc194ec9ebb182ed9cbe3c2db6c09", "title": "Keynote: Red Hat Hardened Images: Zero CVEs, Zero Cost", "date": "2026-10-08T09:40:00+02:00", "start": "09:40", "duration": "00:05", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "The volume of CVEs has become impossible to manage by hand. Nearly 50,000 were tracked last year — 130 a day — and no team can triage, backport, and patch at that pace without dropping something critical.\n\nRed Hat Hardened Images take a fundamentally different approach: minimal, distro-less containers built as close to upstream as possible on a fully automated supply chain. The result is zero known CVEs at time of delivery — without a human in the loop until one is truly needed.\n\nIn five minutes, you'll learn what \"hardened images\" actually means in practice, how the automated supply chain delivers security at scale, and how to start using production-ready hardened images today at no cost.\n\n[Open in Sched](https://osselceu2026.sched.com/event/eb9fc194ec9ebb182ed9cbe3c2db6c09)", "url": "https://osselceu2026.sched.com/event/eb9fc194ec9ebb182ed9cbe3c2db6c09", "persons": [{"public_name": "N. Harrison Ripps"}]}, {"guid": "oss-879042bfcba0d342e92e65b0379bb5b6", "id": "oss-879042bfcba0d342e92e65b0379bb5b6", "title": "Keynote: Scaling with openEuler in AI Era", "date": "2026-10-08T09:50:00+02:00", "start": "09:50", "duration": "00:05", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/879042bfcba0d342e92e65b0379bb5b6)", "url": "https://osselceu2026.sched.com/event/879042bfcba0d342e92e65b0379bb5b6", "persons": [{"public_name": "Xinwei Hu"}]}, {"guid": "oss-cf6b9272c029d436b0ebfaf62eaaae4c", "id": "oss-cf6b9272c029d436b0ebfaf62eaaae4c", "title": "Keynote: The Future of Open Source Security in the Age of AI", "date": "2026-10-08T10:00:00+02:00", "start": "10:00", "duration": "00:15", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "Open source has been the single greatest accelerator of productivity in modern software development. As AI reshapes how software is built, and attacked, the priority is clear: we must use AI to reduce friction for maintainers, not create more work. Today, maintainers face a surge of AI-generated vulnerability reports that risks overwhelming the very people who sustain the global software supply chain. This keynote examines how the open source community (OpenSSF in particular) is turning AI from a source of noise into a force multiplier for defenders.\n\n\nJamie Thomas will highlight how maintainer-centered AI tooling, shared standards, and practical security techniques are being applied to restore balance at scale. These efforts focus on making security more actionable, automated, and sustainable, ensuring open source remains a resilient, trusted foundation for global innovation.\n\n\nJoin us as we outline a roadmap for systemic resilience, where the global community puts cutting-edge AI capabilities directly into the hands of maintainers to secure the software on which we all depend.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cf6b9272c029d436b0ebfaf62eaaae4c)", "url": "https://osselceu2026.sched.com/event/cf6b9272c029d436b0ebfaf62eaaae4c", "persons": [{"public_name": "Jamie Thomas"}]}, {"guid": "oss-c79008c42165f3e2bc32c433355d0cee", "id": "oss-c79008c42165f3e2bc32c433355d0cee", "title": "Sponsor Activity", "date": "2026-10-08T10:35:00+02:00", "start": "10:35", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Explore how openKylin is advancing the RISC-V Linux desktop for the AI era. See real-world engineering practices in hardware enablement, vector optimization, AI runtimes, and heterogeneous computing, and discover what it takes to build the next generation of AI-ready open-source desktops.\n\nSponsor: openKylin\nLocation: Booth D2, Floor 2 - Congress Hall 2C Foyer in Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c79008c42165f3e2bc32c433355d0cee)", "url": "https://osselceu2026.sched.com/event/c79008c42165f3e2bc32c433355d0cee", "persons": [{"public_name": "openKylin Lightning Talk: AI-Ready Linux on RISC-V"}]}, {"guid": "oss-9b00eb1be63180383124ba86bd61d67b", "id": "oss-9b00eb1be63180383124ba86bd61d67b", "title": "Sponsor Activity", "date": "2026-10-08T13:40:00+02:00", "start": "13:40", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Discover how Memorystore for Valkey optimizes production-scale AI agents using semantic caching. See how LLM caching and Valkey vector search eliminate redundant LLM queries, saving tokens and delivering microsecond response times. Learn to optimize AI tokenomics and scale multi-agent workflows within budget.\n\nSponsor: Google Cloud\nLocation: Booth 31, Floor 2 - Congress Hall 2C Foyer in Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9b00eb1be63180383124ba86bd61d67b)", "url": "https://osselceu2026.sched.com/event/9b00eb1be63180383124ba86bd61d67b", "persons": [{"public_name": "Slash AI Token Costs: Semantic Caching with Memorystore for Valkey"}]}, {"guid": "oss-c97b387037126cfb9be5b50526d8e88e", "id": "oss-c97b387037126cfb9be5b50526d8e88e", "title": "Sponsor Activity", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Enter to raffle to win a pair of Nothing headphones at the Coder booth. While you're there, learn how Coder gives AI coding agents secure environments to work in, cutting the setup time slowing your team down.\n\nSponsor: Coder\nLocation: Booth 23, Floor 2 - Congress Hall 2C Foyer in Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c97b387037126cfb9be5b50526d8e88e)", "url": "https://osselceu2026.sched.com/event/c97b387037126cfb9be5b50526d8e88e", "persons": [{"public_name": "Win a pair of Nothing headphones at the Coder Booth"}]}, {"guid": "oss-c7ab3049334672b6339fce6ad3917189", "id": "oss-c7ab3049334672b6339fce6ad3917189", "title": "Sponsor Activity", "date": "2026-10-08T17:30:00+02:00", "start": "17:30", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Meet fellow technology leaders, and expand your network at the Ericsson Software Technology booth. Join us for an informal networking session over an authentic Czech beer. Connect with peers, and exchange ideas on the latest in Open Source.\n\nSponsor: Ericsson\nLocation: Booth 27, Floor 2 - Congress Hall 2C Foyer in Solutions Showcase\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c7ab3049334672b6339fce6ad3917189)", "url": "https://osselceu2026.sched.com/event/c7ab3049334672b6339fce6ad3917189", "persons": [{"public_name": "Connect with your peers over a Czech Beer"}]}], "Congress Hall Foyer 0 A (Floor 0)": [{"guid": "oss-459c670376b01c0c2bd1f1b37eb24120", "id": "oss-459c670376b01c0c2bd1f1b37eb24120", "title": "Registration & Badge Pick-Up", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Congress Hall Foyer 0 A (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/459c670376b01c0c2bd1f1b37eb24120)", "url": "https://osselceu2026.sched.com/event/459c670376b01c0c2bd1f1b37eb24120", "persons": []}], "Congress Hall Foyer 0 B (Floor 0)": [{"guid": "oss-c4482eff1a48bec9ba33f8f502918037", "id": "oss-c4482eff1a48bec9ba33f8f502918037", "title": "Cloakroom", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:35", "room": "Congress Hall Foyer 0 B (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/c4482eff1a48bec9ba33f8f502918037)", "url": "https://osselceu2026.sched.com/event/c4482eff1a48bec9ba33f8f502918037", "persons": []}], "Congress Hall Foyer 3 B (Floor 3)": [{"guid": "oss-12f9e083b5e4ee15046d1582902d887f", "id": "oss-12f9e083b5e4ee15046d1582902d887f", "title": "Embedded Linux Community Hub", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "Congress Hall Foyer 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/12f9e083b5e4ee15046d1582902d887f)", "url": "https://osselceu2026.sched.com/event/12f9e083b5e4ee15046d1582902d887f", "persons": []}], "Congress Hall Foyer 4 B (Floor 4)": [{"guid": "oss-91c4b87529c58d0bab51e56456c452cc", "id": "oss-91c4b87529c58d0bab51e56456c452cc", "title": "Better Together Lunch", "date": "2026-10-08T12:20:00+02:00", "start": "12:20", "duration": "01:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "About the Better Together Lunch\nThe Better Together Lunch offers the opportunity for all event participants from marginalized communities (including race, gender, sexual orientation, and disability), and their allies, to join together to build connections to carry through the event and beyond. Our hope is that this event will help continue to increase the diversity both at the event as well as in the open source community as time goes on.\n\nNo pre-registration is required to attend. We do our best to accommodate everyone interested in joining, but please note that participation is on a first-come, first-served basis.\n\nWho Can Attend?\nAny event participant from a marginalized community (including race, gender, sexual orientation, and disability) and their ally guests. \n\nIs This Event Open to Allies?\nAttendees of the Better Together Lunch are welcome to invite (1) Ally to this event. \n\nWe encourage allies to support diversity in tech while at the event by seeking out and engaging with diverse attendees onsite.\n\nIf you are interested in learning about the other ways the Linux Foundation promotes inclusion and accessibility, visit our Inclusion & Accessibility page.\n\n[Open in Sched](https://osselceu2026.sched.com/event/91c4b87529c58d0bab51e56456c452cc)", "url": "https://osselceu2026.sched.com/event/91c4b87529c58d0bab51e56456c452cc", "persons": []}, {"guid": "oss-facbbb7144acaf309606fc1ede4c55b0", "id": "oss-facbbb7144acaf309606fc1ede4c55b0", "title": "Ask the Expert Session: Marta Rybczynska, Founder and CEO, on embedded security and the Yocto Project...and CRA", "date": "2026-10-08T15:20:00+02:00", "start": "15:20", "duration": "00:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Ask The Experts", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Ask Marta about embedded security and the Yocto Project...and CRA\n\nCome sit down with some open source experts to gain knowledge 1:1 and ask all your pressing questions! No sign-up necessary. More information to come!\n\n[Open in Sched](https://osselceu2026.sched.com/event/facbbb7144acaf309606fc1ede4c55b0)", "url": "https://osselceu2026.sched.com/event/facbbb7144acaf309606fc1ede4c55b0", "persons": []}], "Forum Hall (Floor 2)": [{"guid": "oss-05c9a89a07e8a101bc526db8359a7b72", "id": "oss-05c9a89a07e8a101bc526db8359a7b72", "title": "Just Keep Swimming: Benchmarking OSS Agent Memory on Kubernetes With OpenTelemetry", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Your AI agent is Dory. Every conversation it wakes up unable to remember a thing , so you, Marlin, re-explain everything every turn. Four open-source memory systems promise to fix that: Cognee, MemOS, Honcho, and MemPalace. But which architecture actually pays off in tokens, dollars, and resolved tasks? This talk runs two experiments. First, we benchmark all four backends head-to-head on a single Kubernetes substrate , same harness, same workloads, same OpenTelemetry Collector and rank them by token efficiency, cost per resolved task, and recall under contradiction. Then we test the question most teams haven't asked: is running an agent with memory worth it at all? We measure two real OSS agent frameworks , kagent (CNCF Sandbox) and sympozium with their built-in memory turned on, then turned off. Real workloads, real numbers. None of the four backends ships first-party OTel today; the Helm chart, OTel pipeline, and upstream PRs are how we close that gap for the ecosystem.\n\n[Open in Sched](https://osselceu2026.sched.com/event/05c9a89a07e8a101bc526db8359a7b72)", "url": "https://osselceu2026.sched.com/event/05c9a89a07e8a101bc526db8359a7b72", "persons": [{"public_name": "Henrik Rexed"}]}, {"guid": "oss-60555e82a5fd5e063bb4de58559917bf", "id": "oss-60555e82a5fd5e063bb4de58559917bf", "title": "Building Real-Time, Data-Aware Intelligence With Postgres & Model Context Protocol (MCP)", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Imagine asking an AI agent to analyze any data, only for it to hallucinate a schema that doesn't exist. This \"context gap\" is the primary barrier to reliable Data-Aware AI. While LLMs are brilliant reasoners, they are historically \"blind\" to the live, structured world of Postgres - until now! In this talk, we will explore how the Model Context Protocol (MCP) bridges this gap, transforming Postgres from a passive storage layer into an active reasoning engine. We’ll dive into the architecture of a Postgres MCP server, demonstrating how it provides agents with secure, structured access to schemas and metadata. By utilizing tools like pg_catalog and EXPLAIN, we enable LLMs to understand table relationships and optimize performance before running queries. Expect live demos and practical insights on making Postgres \"talk\" to AI safely and effectively. Key Takeaways: * How Postgres + MCP provides LLMs with correct, real-time database context. * Leveraging Postgres metadata and schema to eliminate SQL hallucinationcs. * Implementing secure, multi-tenant, and read-only access for AI agents. * Enabling AI agents to use EXPLAIN and other tools for self-optimization.\n\n[Open in Sched](https://osselceu2026.sched.com/event/60555e82a5fd5e063bb4de58559917bf)", "url": "https://osselceu2026.sched.com/event/60555e82a5fd5e063bb4de58559917bf", "persons": [{"public_name": "Yogesh Jain"}]}, {"guid": "oss-dad424e1058b4a0540020b9699a953eb", "id": "oss-dad424e1058b4a0540020b9699a953eb", "title": "Yukti: A Unified Inference Interface for Low-Latency Machine Learning in High-Energy Physics", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Machine learning is increasingly used in high-energy physics, particularly in trigger systems that process data at rates of 100 kHz while making real-time event selection decisions. The latency and reliability requirements demand highly optimized inference pipelines. While portable solutions such as ONNX Runtime simplify deployment, many applications rely on hardware-specific libraries like NVIDIA TensorRT and MIGraphX (via ROCm) for optimal performance. Code-generation approaches such as SOFIE offer additional efficiency but introduce integration complexity. We present a unified inference interface that abstracts backend-specific details while preserving performance. It enables execution across multiple inference libraries without data copies or user-side configuration changes. An offline processor converts trained models into backend-optimized plans, and a lightweight runtime loads and executes them through a common API with direct data access for heterogeneous environments.\n\n[Open in Sched](https://osselceu2026.sched.com/event/dad424e1058b4a0540020b9699a953eb)", "url": "https://osselceu2026.sched.com/event/dad424e1058b4a0540020b9699a953eb", "persons": [{"public_name": "Sanjiban Sengupta"}]}, {"guid": "oss-a533a839491960839042f705cbe3acd4", "id": "oss-a533a839491960839042f705cbe3acd4", "title": "Designing Permissioned AI Agents That Can Run Offline", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "AI agents are moving from chat interfaces into workflows that read files, call tools, modify state, and coordinate multiple services. In cloud-hosted designs, this often creates a fragile trust boundary: private data leaves the device, tools are authorized through broad API keys, and the user has limited visibility into what the agent can do. This talk presents an open-source, local-first architecture for permissioned AI agents that can operate offline on Linux edge or personal infrastructure. We will break down the architecture into model serving, retrieval, tool invocation, capability scoping, identity, audit logs, sandboxing, human approval, and fallback synchronization when connectivity returns. The session is not about a specific agent framework; it is about the system boundary around agents. Attendees will learn how to separate reasoning from action, how to map tools to least-privilege permissions, how to keep sensitive context local, and how to evaluate agent workflows when network access is unavailable or intentionally disabled.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a533a839491960839042f705cbe3acd4)", "url": "https://osselceu2026.sched.com/event/a533a839491960839042f705cbe3acd4", "persons": [{"public_name": "Reza Jelveh"}]}, {"guid": "oss-d2d39ea506395a0bab434811e3cc1a8d", "id": "oss-d2d39ea506395a0bab434811e3cc1a8d", "title": "Open Standards for Measuring Carbon, Energy, and Water in Software and AI", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Software’s environmental footprint, especially AI’s, is becoming a business, governance, and regulatory priority. The EU AI Act introduces environmental transparency expectations for general-purpose AI, while the CSRD expands sustainability reporting obligations to 50,000+ companies. As software and AI adoption accelerate, organizations are increasingly seeking consistent ways to measure carbon, energy, and water impacts across workloads and inference.\n \n The Green Software Foundation, a Linux Foundation project, is helping shape the open standards foundation for this transition:\n \n • SCI (ISO/IEC 21031:2024): the ISO-ratified standard for software carbon intensity\n • SEE: measuring software energy efficiency across workloads\n • SCI for AI: extending measurement to AI training, fine-tuning, and inference\n • SWE: addressing the growing water footprint of software and AI systems\n \n Drawing on direct experience chairing and co-leading these specifications, this session explores how these standards connect, align with emerging expectations such as the EU AI Act and CSRD, and help organizations build measurable, transparent, and sustainable software and AI systems.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d2d39ea506395a0bab434811e3cc1a8d)", "url": "https://osselceu2026.sched.com/event/d2d39ea506395a0bab434811e3cc1a8d", "persons": [{"public_name": "Navveen Balani"}]}, {"guid": "oss-93857d81e2827fe94e1bf0aad64513e9", "id": "oss-93857d81e2827fe94e1bf0aad64513e9", "title": "Your Agent Did What? Forensic Observability for Systems That Don’t Leave Obvious Footprints", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The GenAI observability space is fragmented right now. OpenInference, OpenLLMetry, framework-specific conventions are all solving the same problems with incompatible attribute names. That made sense when OTel’s GenAI support was thin. It makes less sense today.\n \n OTel is where this converges. Getting there from where most teams actually are isn’t obvious. Kasper and Adriana cover the current landscape, how the genainormalizer processor bridges the gap at the collector layer, and what a realistic path to OTel-native GenAI observability looks like.\n \n Then the harder question: your agent just deleted a database. What does your telemetry actually tell you? Non-deterministic systems don’t leave obvious footprints, and most teams discover that at the worst possible time.\n\n[Open in Sched](https://osselceu2026.sched.com/event/93857d81e2827fe94e1bf0aad64513e9)", "url": "https://osselceu2026.sched.com/event/93857d81e2827fe94e1bf0aad64513e9", "persons": [{"public_name": "Adriana Villela"}, {"public_name": "Kasper Borg Nissen"}]}], "Forum Hall Foyer 0 (Floor 0)": [{"guid": "oss-68bdeae834f76a369b8e0d7ac61be432", "id": "oss-68bdeae834f76a369b8e0d7ac61be432", "title": "Cloud, Containers & Orchestration Community Hub", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "Forum Hall Foyer 0 (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/68bdeae834f76a369b8e0d7ac61be432)", "url": "https://osselceu2026.sched.com/event/68bdeae834f76a369b8e0d7ac61be432", "persons": []}], "Forum Hall Foyer 1 (Floor 1)": [{"guid": "oss-51168446a34d126392f8370b72e6e236", "id": "oss-51168446a34d126392f8370b72e6e236", "title": "Linux Community Hub", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/51168446a34d126392f8370b72e6e236)", "url": "https://osselceu2026.sched.com/event/51168446a34d126392f8370b72e6e236", "persons": []}, {"guid": "oss-3d051e5f406ed637bedb4941a05cb043", "id": "oss-3d051e5f406ed637bedb4941a05cb043", "title": "Open AI & Data Community Hub", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3d051e5f406ed637bedb4941a05cb043)", "url": "https://osselceu2026.sched.com/event/3d051e5f406ed637bedb4941a05cb043", "persons": []}, {"guid": "oss-ef21d3f3382c5f6fb631091c7bfae78f", "id": "oss-ef21d3f3382c5f6fb631091c7bfae78f", "title": "Open Source Leadership Community Hub", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ef21d3f3382c5f6fb631091c7bfae78f)", "url": "https://osselceu2026.sched.com/event/ef21d3f3382c5f6fb631091c7bfae78f", "persons": []}], "Forum Hall Foyer 3 (Floor 3)": [{"guid": "oss-7eb3855a5d3f93278671bc479b8f4360", "id": "oss-7eb3855a5d3f93278671bc479b8f4360", "title": "LF Education Learning Lounge: The Next 35 Years: Building Trust in the Age of AI", "date": "2026-10-08T10:30:00+02:00", "start": "10:30", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk led by Flavia Cioanca in the Learning Lounge located on the 3rd Floor,\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7eb3855a5d3f93278671bc479b8f4360)", "url": "https://osselceu2026.sched.com/event/7eb3855a5d3f93278671bc479b8f4360", "persons": []}, {"guid": "oss-3042ca2fd52e70d9582775a9a5dcf161", "id": "oss-3042ca2fd52e70d9582775a9a5dcf161", "title": "LF Education Learning Lounge: From Campus to Community: How Academic Partnerships Expand Open Source Opportunities", "date": "2026-10-08T12:45:00+02:00", "start": "12:45", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk led by Justin Cappos in the Learning Lounge located on the 3rd Floor.\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3042ca2fd52e70d9582775a9a5dcf161)", "url": "https://osselceu2026.sched.com/event/3042ca2fd52e70d9582775a9a5dcf161", "persons": []}, {"guid": "oss-0873f8f16e67290c12b2f12b0ccb2174", "id": "oss-0873f8f16e67290c12b2f12b0ccb2174", "title": "LF Education Learning Lounge: RISC-V Isn’t Open Source. So What Makes It Open, and Why Does That Matter?", "date": "2026-10-08T13:15:00+02:00", "start": "13:15", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk by James De Ville in the Learning Lounge located on the 3rd Floor.\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0873f8f16e67290c12b2f12b0ccb2174)", "url": "https://osselceu2026.sched.com/event/0873f8f16e67290c12b2f12b0ccb2174", "persons": []}, {"guid": "oss-c82c1f863df79f9c54df9b75d98758b5", "id": "oss-c82c1f863df79f9c54df9b75d98758b5", "title": "LF Education Learning Lounge: 35 Years of Linux: The Open Source Engine Behind the Modern World", "date": "2026-10-08T15:30:00+02:00", "start": "15:30", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us for a 10-minute tip talk by Anna Hermansen in the Learning Lounge located on the 3rd Floor.\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c82c1f863df79f9c54df9b75d98758b5)", "url": "https://osselceu2026.sched.com/event/c82c1f863df79f9c54df9b75d98758b5", "persons": []}, {"guid": "oss-05090122e7e2bfb91249a121a322cc6e", "id": "oss-05090122e7e2bfb91249a121a322cc6e", "title": "LF Education Learning Lounge: Think You Know Linux? Take the Quiz", "date": "2026-10-08T17:45:00+02:00", "start": "17:45", "duration": "00:15", "room": "Forum Hall Foyer 3 (Floor 3)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Join us in the Learning Lounge, located on the 3rd Floor, for a quick, interactive quiz celebrating 35 years of Linux history, milestones, and fun facts.\nTest your knowledge, compete against fellow attendees, and win prizes!Join us for a 10-minute tip talk by Mary Campbell and Randi Armour in the Learning Lounge located on the 3rd Floor.\n\nLocation: Booth 53, Floor 3 - Forum Hall Foyer 3 at the Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/05090122e7e2bfb91249a121a322cc6e)", "url": "https://osselceu2026.sched.com/event/05090122e7e2bfb91249a121a322cc6e", "persons": []}], "Panorama Hall (Floor 1)": [{"guid": "oss-31e8d952f13e5a9d7b9190a771bcc1b2", "id": "oss-31e8d952f13e5a9d7b9190a771bcc1b2", "title": "When the Kernel Writes Its Own Code: Debugging Runtime-Generated Instructions", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "While most instructions the Linux kernel executes come from a standard compiler like GCC or Clang, the kernel can also patch itself at runtime: ftrace, kprobes, eBPF programs... Debugging these runtime-generated instructions is a whole new challenge, as we lack the usual debug data: symbol names, offsets, debug info. Fortunately, we can adapt our tooling to observe them. This talk explores practical debugging techniques for runtime-generated instructions, using eBPF as a concrete example: when a user loads an eBPF program, the kernel's JIT compiler emits native machine code. After a brief eBPF introduction, we will debug these programs and the surrounding generated code (trampolines, dynamic instrumentation, verifier patches...). Starting from standard debug information in bare binaries or exposed at runtime, we will gradually build up our toolkit: running a custom kernel under QEMU, taking control with GDB, debugging userspace and kernel space together, adding TUI and GDB scripts, and finally stepping through raw machine instructions. Aimed at developers familiar with C/kernel development, attendees will gain hands-on techniques and confidence for any kind of low-level analysis.\n\n[Open in Sched](https://osselceu2026.sched.com/event/31e8d952f13e5a9d7b9190a771bcc1b2)", "url": "https://osselceu2026.sched.com/event/31e8d952f13e5a9d7b9190a771bcc1b2", "persons": [{"public_name": "Alexis Lothoré"}]}, {"guid": "oss-f476189d7d138079b41dc293b685de81", "id": "oss-f476189d7d138079b41dc293b685de81", "title": "Building Your Own Linux Kernel CI on Commodity Platforms", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "While Continuous Integration (CI) has become a standard for most software projects via platforms like GitHub, testing massive, highly complex repositories like the Linux kernel has traditionally required bespoke environments. This limitation creates significant friction for new kernel contributors, out-of-tree module maintainers, and low-level system library authors attempting to validate compatibility against the latest development branches.\n \n This session details a practical architecture for running the latest development kernels entirely within commodity CI environments. There are two key components: a highly optimized, VM-tuned kernel configuration, and vmtest, an open-source utility that abstracts away the complexities of QEMU configuration, seamlessly maps the CI workspace as the virtual machine's root filesystem via the 9P protocol, and propagates test command return codes back to the runner.\n \n By the end of the session, attendees will gain the knowledge to build custom kernel CI workflows, leaving with a boilerplate GitHub Actions .yml from danobi/vmtest-action-demo to immediately deploy their own testing pipelines.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f476189d7d138079b41dc293b685de81)", "url": "https://osselceu2026.sched.com/event/f476189d7d138079b41dc293b685de81", "persons": [{"public_name": "Shung-Hsi Yu"}]}, {"guid": "oss-7550dd4be5404e6f632b718cfdbe58ef", "id": "oss-7550dd4be5404e6f632b718cfdbe58ef", "title": "Beyond Strace: Syscall Analysis the Wireshark Way", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Every Linux engineer knows the moment: a process is misbehaving, so you reach for strace, get a wall of text, and start grepping. It works - until the problem spans multiple processes, the output is too much to read, or you need to correlate what a process did to the system with what it did on the network. strace and bpftrace are excellent at capturing syscalls. They give you much less help analyzing them. Stratoshark, the Wireshark Foundation's newer tool, takes a different approach: it captures system calls and logs system-wide through the Falco libraries, then hands them to the same analysis engine that has served packet analysts for 25 years — display filters, coloring rules, follow-stream views, time correlation, and shareable capture files. In this talk I'll show, live, how a Wireshark user's instincts transfer directly to syscall troubleshooting, where Stratoshark beats reaching for strace, and — just as importantly — where the older tools are still the right call. Expect real debugging scenarios, honest limitations, and a clear picture of when this newer approach earns its place in your toolbox.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7550dd4be5404e6f632b718cfdbe58ef)", "url": "https://osselceu2026.sched.com/event/7550dd4be5404e6f632b718cfdbe58ef", "persons": [{"public_name": "Roland Knall"}]}, {"guid": "oss-812c772427ff1a8d3046cf9c1f0db9a6", "id": "oss-812c772427ff1a8d3046cf9c1f0db9a6", "title": "Beyond the 10-Year Promise: How CIP's Industrial-Grade Foundations Anchor the AI Era", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In April 2026, the Civil Infrastructure Platform (CIP) reached a historic milestone—its 10th anniversary—and delivered on its founding promise: a full 10-year support lifecycle for the CIP Super Long-Term Support (SLTS) Kernel. CIP is believed to be the first open-source community to sustain a 10-year kernel support commitment in practice. It is also the first OSS project to conform to both IEC 62443-4-1 and 4-2.\n At OSS Japan in December 2025, we looked \"towards\" this decade. This talk marks its completion—and turns to the next one. AI is accelerating software development at unprecedented speed while introducing new complexity and supply-chain risk into infrastructure that must run safely for decades. How do we sustain trust, security, and longevity when the software landscape shifts daily?\n We will revisit the strategies and engineering behind CIP's 10-year support and security certifications, then examine why this proven framework matters more than ever in the AI era. Attendees will leave with practical insight into protecting supply-chain integrity, navigating compliance, and building open-source foundations that endure technological disruption.\n\n[Open in Sched](https://osselceu2026.sched.com/event/812c772427ff1a8d3046cf9c1f0db9a6)", "url": "https://osselceu2026.sched.com/event/812c772427ff1a8d3046cf9c1f0db9a6", "persons": [{"public_name": "Yoshitake Kobayashi"}, {"public_name": "Urs Gleim"}]}, {"guid": "oss-e974d9fbdbfb9310e29fd29accb44efd", "id": "oss-e974d9fbdbfb9310e29fd29accb44efd", "title": "Plug-and-play Kernel CI: From Patch To PR Without a Test Lab", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "You maintain a kernel fork. Maybe it's an LTS branch, a distro kernel, or an embedded platform. You push a patch and wonder, will it boot? Will it break something that worked yesterday? Most CI solutions either need a full test lab you can't afford, or give you a virtme smoke test that won't catch real failures. We faced the same problem. 5 engineers, multiple kernels, no test lab budget. So we built a kernel CI pipeline that does real boot, real tests using nothing but GitHub Actions. The key difference from other CIs is that we don't use virtme. We boot a full disk image. The bugs that only show up during a real boot, module loading failures, get caught here. In this talk, I'll walk through how we boot real disk images in CI, run test suites against every patch, and catch regressions before they hit your branch, all without a test lab. I'll explain the pipeline design, demo the full cycle from patch to test results, and cover what it takes to go from \"nothing\" to a working multi-arch kernel CI. We're also making this pipeline portable and open for others to use. If you maintain a kernel and want real integration testing without the overhead of a test lab, this talk is for you.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e974d9fbdbfb9310e29fd29accb44efd)", "url": "https://osselceu2026.sched.com/event/e974d9fbdbfb9310e29fd29accb44efd", "persons": [{"public_name": "Shreeya Patel"}]}, {"guid": "oss-93e191741d79f8b5e89a237247777ef2", "id": "oss-93e191741d79f8b5e89a237247777ef2", "title": "Caching in the Storage Path - How To Gain Performance Without Loosing Data", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Every time you write data to or read data from a storage device in Linux, multiple caches are involved: the page cache (located in the memory) on the VFS layer, different kinds of caches on the storage devices (SSDs, HDDs) and controllers, and maybe filesystem-level or device mapper-level caches, too. The caches help you to boost the I/O performance, but they also increase the risk of data loss in case of a sudden power outage. Understanding and configuring these caches correctly can be challenging, in particular if you are running virtualized systems and you have to set QEMU caching parameters (writeback, none, writethrough, directsync, unsafe), too. In this talk, Werner explains how these caches work and shows you how to tune them for optimal performance while still being safe in case of a power outage.\n\n[Open in Sched](https://osselceu2026.sched.com/event/93e191741d79f8b5e89a237247777ef2)", "url": "https://osselceu2026.sched.com/event/93e191741d79f8b5e89a237247777ef2", "persons": [{"public_name": "Werner Fischer"}]}], "Room 4.3 (Floor 4)": [{"guid": "oss-04b3e1a7814f5a378aff7ad349896904", "id": "oss-04b3e1a7814f5a378aff7ad349896904", "title": "Zen Zone", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Room 4.3 (Floor 4)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "All attendees may feel free to use the Zen Zone as needed. This is a quiet space for sensory relaxation, meditation, and worship. It is not to be used for conversations or as a workspace.\n\n[Open in Sched](https://osselceu2026.sched.com/event/04b3e1a7814f5a378aff7ad349896904)", "url": "https://osselceu2026.sched.com/event/04b3e1a7814f5a378aff7ad349896904", "persons": []}], "Small Hall (Floor 0)": [{"guid": "oss-71b8b24a703bf9d8f9a4d3d5631b536a", "id": "oss-71b8b24a703bf9d8f9a4d3d5631b536a", "title": "From Fragile To Self-Healing: Operationalizing Etcd at Scale", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Running etcd across thousands of production Kubernetes clusters reveals critical failures: data corruption, quorum loss, member failures, and storage bloat, all capable of disrupting clusters. Managing these manually is complex, error-prone, and difficult to scale.\n \n In this talk, we will be sharing lessons from 8+ years of operating production-grade etcd at scale with close to zero manual intervention and how we built etcd-backup-restore to reliably automate tasks like scheduled backups, corruption detection, quorum loss recovery, member replacement, and scheduled defragmentation, with zero recorded data loss across thousands of clusters.\n \n Used in production by SAP Gardener, Akamai Cloud, StackIT, and Scaleway, etcd-backup-restore is now a Linux Foundation project under Linux Foundation EU via the NeoNephos Foundation, with an active maintainer community. We'll show what it takes to run etcd reliably at scale, and make it truly self-healing.\n\n[Open in Sched](https://osselceu2026.sched.com/event/71b8b24a703bf9d8f9a4d3d5631b536a)", "url": "https://osselceu2026.sched.com/event/71b8b24a703bf9d8f9a4d3d5631b536a", "persons": [{"public_name": "Shreyas Rao"}, {"public_name": "Ishan Tyagi"}]}, {"guid": "oss-253cd460ed9a480fea8e77fdc220884b", "id": "oss-253cd460ed9a480fea8e77fdc220884b", "title": "Own Your Stack: Sovereign Kubernetes From Bare Metal To Fleet", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "For a decade, the default answer to \"where does Kubernetes run\" was someone else's cloud. But lately, regulated organizations, telcos, banks, and the public sector are pulling sensitive workloads back onto hardware they own and operate — for cost, performance, sovereignty, and increasingly to run AI and GPU workloads they control. The hard part is doing that without giving up the automation the cloud offers.\n \n This talk covers the open-source stack for running your own bare metal, with each layer explained by the people who work on it. At the bottom, Metal3 turns physical servers into declarative Kubernetes resources and manages their lifecycle through the Kubernetes API. At the top, k0rdent manages fleets of those clusters with templates, policy, and drift detection. In the middle sits Cluster API, the standard both layers build on.\n \n We'll walk through the layers working as one — from a rack of bare metal to provisioned clusters to a managed fleet, on hardware we run ourselves. Attendees get a reference architecture, practical guardrails, and clear criteria for when this fits. We'll be honest about the trade-offs: slower provisioning and elasticity bounded by the servers you have.\n\n[Open in Sched](https://osselceu2026.sched.com/event/253cd460ed9a480fea8e77fdc220884b)", "url": "https://osselceu2026.sched.com/event/253cd460ed9a480fea8e77fdc220884b", "persons": [{"public_name": "Sunnatillo Samadov"}, {"public_name": "Bharath N R"}]}, {"guid": "oss-cace84818cd2eaca0374575287a8c2dd", "id": "oss-cace84818cd2eaca0374575287a8c2dd", "title": "Make YAML Dumb Again: The Config as Data Approach", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "01:30", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Building on my Google Summer of Code experience, this tutorial addresses one of the major challenges in open source software systems – at scale, file management results in overly complicated templates and bad composability. People put logic into YAML files resulting in non-debuggable pipelines while local modifications are wiped away by upstream updates.\n This tutorial delves into the idea of Configuration as Data with the help of kpt tooling allowing for logic separation from configuration files. The idea is to keep YAML \"dumb\" and pure data, which makes it fully predictable and WYSIWYG. \n You’ll get to use the example of the OpenTelemetry Demo - a complex e-commerce microservices application – by packing it in independent and dependent subpackages.\n Using KRM functions and custom Starlark scripts you'll:\n • switch from a shop selling astronomical equipment to a website offering flowers\n • localize languages, currencies, taxes\n • manage different deployments sizes (small/medium/large).\n As the last point you will use three way merging to allow applying upstream package updates while keeping all local changes safe.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cace84818cd2eaca0374575287a8c2dd)", "url": "https://osselceu2026.sched.com/event/cace84818cd2eaca0374575287a8c2dd", "persons": [{"public_name": "Liam Fallon"}, {"public_name": "Gergely Csatari"}]}, {"guid": "oss-88634a7897a3afe0717c233829a17bf5", "id": "oss-88634a7897a3afe0717c233829a17bf5", "title": "KubePACS: From Systems Research To Open Source Spot Instance Provisioning on Kubernetes", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Spot instances reduce cloud bills by up to 90%, but choosing which to use is a multi-dimensional puzzle where price, performance, interruption risk, and instance heterogeneity all interact. Kubernetes provisioners like Karpenter optimize a narrow slice of this problem, tightly coupled to a single cloud vendor, AWS. KubePACS is an open source project that separates the decision from the execution. A vendor-neutral optimizer computes the best mix of instance types for a workload's cost-performance-availability profile, then translates that into native configuration for the user's provisioner The talk goes deep into the system: the ILP-based selector for cost-performance-availability trade-offs, the GSS-driven optimizer that tunes them automatically, multi-node spot placement awareness for robust capacity across cloud providers, and clean integration with upstream Karpenter. Attendees see measured gains over baseline configurations and take away an architecture pattern for performance-aware spot instance provisioning. We close with our intent to grow KubePACS as an open source community effort and welcome contributors to shape what comes next.\n\n[Open in Sched](https://osselceu2026.sched.com/event/88634a7897a3afe0717c233829a17bf5)", "url": "https://osselceu2026.sched.com/event/88634a7897a3afe0717c233829a17bf5", "persons": [{"public_name": "Kyungyong Lee"}]}, {"guid": "oss-bc47ba40839311c8dcc739ca4252b11c", "id": "oss-bc47ba40839311c8dcc739ca4252b11c", "title": "Stateless by Design: Lessons From Building Infrastructure-as-Code Without Local State", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most IaC tools, Terraform chief among them, keep a local copy of state to plan changes, detect drift, and resolve references. That state file is also a known source of pain: it can go stale, get corrupted, and become a coordination bottleneck. What happens when an IaC system deliberately keeps no local state? Instead of a stored snapshot, every operation reconciles desired configuration against live state at apply time. That single choice shapes everything else, and not all of it is smooth sailing. Drawing on her experience building widely adopted open-source declarative CLIs, Prashansa unpacks the lessons she learned. The talk covers the tradeoffs statelessness forces: full-state sync versus additive configuration and when each fits, resolving references without a stored dependency graph, schema-aware diffing, and transparent reconciliation so users see what a tool does. It also covers production challenges: compatibility across platform versions, evolving schemas, and keeping behaviour predictable as systems grow. Attendees will leave understanding why most IaC tools rely on state, what gets simpler and harder without it, and how to weigh these tradeoffs in their own systems.\n\n[Open in Sched](https://osselceu2026.sched.com/event/bc47ba40839311c8dcc739ca4252b11c)", "url": "https://osselceu2026.sched.com/event/bc47ba40839311c8dcc739ca4252b11c", "persons": [{"public_name": "Prashansa Kulshrestha"}]}], "Small Theater (Floor 0)": [{"guid": "oss-92c7daa8497756ddeaa5c95e27c13438", "id": "oss-92c7daa8497756ddeaa5c95e27c13438", "title": "Gingerbread Decorating", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "00:45", "room": "Small Theater (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Time: 08:00 – 08:45 \nLocation: Small Theatre, Level 0\nPrague is known for its beautiful architecture, rich traditions, and, of course, perníčky — traditional Czech gingerbread cookies often decorated with intricate designs. Start your Thursday with a taste of Czech tradition and decorate your own perníček with icing and festive toppings. Make a sweet little Prague keepsake! Drop in anytime while supplies last.\n\n[Open in Sched](https://osselceu2026.sched.com/event/92c7daa8497756ddeaa5c95e27c13438)", "url": "https://osselceu2026.sched.com/event/92c7daa8497756ddeaa5c95e27c13438", "persons": []}], "Solutions Showcase": [{"guid": "oss-563304e12aa96688b44369d2b38bb136", "id": "oss-563304e12aa96688b44369d2b38bb136", "title": "Solutions Showcase", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "The Solutions Showcase is your hub to network, explore sponsor exhibits, and learn how these organizations are shaping the future of the ecosystem.**In order to facilitate networking and business relationships at the event, you may choose to visit a third party’s booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), and details about the sponsored content or resources you interacted with. If you choose to interact with a booth or access sponsored content, you are explicitly consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.**\n\n[Open in Sched](https://osselceu2026.sched.com/event/563304e12aa96688b44369d2b38bb136)", "url": "https://osselceu2026.sched.com/event/563304e12aa96688b44369d2b38bb136", "persons": []}, {"guid": "oss-bd03c9d33267791bc539472e87fcbdc6", "id": "oss-bd03c9d33267791bc539472e87fcbdc6", "title": "Welcome Coffee", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "01:00", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/bd03c9d33267791bc539472e87fcbdc6)", "url": "https://osselceu2026.sched.com/event/bd03c9d33267791bc539472e87fcbdc6", "persons": []}, {"guid": "oss-fea459124700fa60c367def751e10160", "id": "oss-fea459124700fa60c367def751e10160", "title": "Coffee Break", "date": "2026-10-08T10:20:00+02:00", "start": "10:20", "duration": "00:30", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/fea459124700fa60c367def751e10160)", "url": "https://osselceu2026.sched.com/event/fea459124700fa60c367def751e10160", "persons": []}, {"guid": "oss-00c11dea335e3f9abe91caa91cb4b958", "id": "oss-00c11dea335e3f9abe91caa91cb4b958", "title": "Lunch (Provided Onsite for All Attendees)", "date": "2026-10-08T12:20:00+02:00", "start": "12:20", "duration": "01:30", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/00c11dea335e3f9abe91caa91cb4b958)", "url": "https://osselceu2026.sched.com/event/00c11dea335e3f9abe91caa91cb4b958", "persons": []}, {"guid": "oss-b0e227d6a8852960034ad00f94e61f85", "id": "oss-b0e227d6a8852960034ad00f94e61f85", "title": "Coffee Break", "date": "2026-10-08T15:20:00+02:00", "start": "15:20", "duration": "00:30", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/b0e227d6a8852960034ad00f94e61f85)", "url": "https://osselceu2026.sched.com/event/b0e227d6a8852960034ad00f94e61f85", "persons": []}, {"guid": "oss-614b9959d25a54397ccc2dfd18bd5f34", "id": "oss-614b9959d25a54397ccc2dfd18bd5f34", "title": "Embedded Linux Conference Tech Showcase", "date": "2026-10-08T17:20:00+02:00", "start": "17:20", "duration": "01:00", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "We’re excited to host the Embedded Linux Technical Showcase at Open Source Summit and Embedded Linux Conference Europe 2026! This unique event brings the world of embedded Linux out into the open, literally. Unlike desktop or server environments, where Linux is front and center, embedded Linux often runs behind the scenes. The goal of this showcase is simple: “Seeing is believing!”\n\nThe showcase offers a chance to highlight the real-world applications of embedded Linux through hands-on demos, technical deep dives, and open-source projects. It’s a space for developers to share their work, exchange ideas, and learn directly from each other. By making these projects visible and accessible, we hope to inspire more developers to explore embedded Linux and contribute to its growth.\n\nIf you’re a speaker, the showcase is also a great opportunity to expand on your talk with a live demo or hands-on component, and spend more time connecting with attendees who want to dive deeper into your topic.\n\nInterested in participating or want to learn more? Visit this page for more information.\n\n[Open in Sched](https://osselceu2026.sched.com/event/614b9959d25a54397ccc2dfd18bd5f34)", "url": "https://osselceu2026.sched.com/event/614b9959d25a54397ccc2dfd18bd5f34", "persons": []}, {"guid": "oss-5b952a027ddadcd718c69dbee9b9909f", "id": "oss-5b952a027ddadcd718c69dbee9b9909f", "title": "LFX Mentorship Showcase", "date": "2026-10-08T17:20:00+02:00", "start": "17:20", "duration": "01:00", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "The LFX Mentorship Showcase is an opportunity for graduating mentees of the LFX Mentorship program to showcase the work they completed during their session term.\n\nThis event is free and open to all. Join us to explore the experiences of LF Mentorship Program mentees, discover the exciting projects they are working on, recruit fresh talent, and support new developer contributions.\n\nThe Linux Foundation’s Mentorship Program helps developers – many of whom are first-time open source contributors – gain the skills and experience necessary to contribute effectively to open source communities.\n\n[Open in Sched](https://osselceu2026.sched.com/event/5b952a027ddadcd718c69dbee9b9909f)", "url": "https://osselceu2026.sched.com/event/5b952a027ddadcd718c69dbee9b9909f", "persons": []}, {"guid": "oss-b3e1aaec5976973fd39e482e1960fd82", "id": "oss-b3e1aaec5976973fd39e482e1960fd82", "title": "Tux Trek", "date": "2026-10-08T17:20:00+02:00", "start": "17:20", "duration": "01:00", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Keep the momentum going after Day 2! Head to the Solutions Showcase for Tux Trek to unwind with drinks, appetizers, and great company. Expect a lively, collaborative evening where you can connect with sponsors, explore cutting-edge tech, and keep the conversations flowing.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b3e1aaec5976973fd39e482e1960fd82)", "url": "https://osselceu2026.sched.com/event/b3e1aaec5976973fd39e482e1960fd82", "persons": []}], "South Hall 1 A (Floor 1)": [{"guid": "oss-2107daed0ae00bc3c118473e564cd530", "id": "oss-2107daed0ae00bc3c118473e564cd530", "title": "Panel Discussion: OpenChain 2.0: Open Source Compliance in the Age of Automotive SBOM, Generative AI, and the CRA", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Ten years ago, the OpenChain Project launched at this very event. A decade on, it has built the global baseline for open source compliance, culminating in ISO/IEC 5230 — the \"1.0\" era. With Mary Meixia Wang as Executive Director, OpenChain now enters its next chapter, and this panel asks what \"2.0\" must deliver.\n \nTwo frontiers define the road ahead. First, Automotive SBOM: as vehicles become software-defined, the deepest supply chain anywhere needs SBOM practices scaling from silicon to OEM. Second, license compliance in the era of generative \n\nAI and \"vibe coding\": as more code is generated by AI than written by hand, licensing of models, training data, and AI-produced code raises questions traditional compliance never anticipated. Regulation such as the EU CRA adds urgency, making machine-readable SBOMs effectively mandatory and reinforcing the trust and security OpenChain pursues.\n \nThe panel goes beyond discussion: it first shares the community's latest work on these challenges — from the Automotive SBOM Guideline to evolving thinking on compliance for AI-generated code — then opens a cross-industry conversation on what the shift from 1.0 to 2.0 must deliver in practice.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2107daed0ae00bc3c118473e564cd530)", "url": "https://osselceu2026.sched.com/event/2107daed0ae00bc3c118473e564cd530", "persons": [{"public_name": "Moderated by Masato Endo"}]}, {"guid": "oss-c476fd93ce48d659ca1c3ded4ccc5725", "id": "oss-c476fd93ce48d659ca1c3ded4ccc5725", "title": "Measuring What Matters: Building an Open Source Health Model for the Npm Ecosystem", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open source software powers critical digital infrastructure across every industry. But, how do you know if the software you are depending on is actually healthy? A project that looks active may have one key maintainer. A package you've never heard of may be a single point of failure for thousands of downstream projects. npm's scale and deep dependency chains turn that uncertainty into real supply chain risk – remember Shai-Hulud?\n \n Based on learnings from open source community health analytics projects like CHAOSS, OpenSSF Scorecard, and GrimoireLabs, Bloomberg and AboutCode are building an open, data-driven framework that applies the Goal-Questions-Metrics methodology to assess project health across the npm ecosystem.\n \n This talk presents our npm Health Model and open source tooling, early findings, and how this approach can extend to other OSS project ecosystems. We are sharing the model, methodology, data, and tooling openly so other organizations can apply it to their own processes. Attendees will leave with a practical framework for assessing open source health at scale, and a path to contributing to this open effort.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c476fd93ce48d659ca1c3ded4ccc5725)", "url": "https://osselceu2026.sched.com/event/c476fd93ce48d659ca1c3ded4ccc5725", "persons": [{"public_name": "Adam Herzog"}, {"public_name": "Alyssa Wright"}]}, {"guid": "oss-d180025d1e9f3db598b0cabb805f87c8", "id": "oss-d180025d1e9f3db598b0cabb805f87c8", "title": "How To Talk To Your Lawyer About Open Source", "date": "2026-10-08T12:00:00+02:00", "start": "12:00", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Have you ever felt frustrated that your legal counsel simply does not seem to understand what you are saying? Or are you a lawyer who simply cannot understand why the developers you are trying to help can’t speak clearly? Then you are not alone, and this is the session for you! Lawyers and engineers often speak different languages, which can lead to frustration when collaborating in an open source setting. \n \n Removing friction between legal and engineering communication is no small task. However, doing so unlocks significant value: legal can provide clearer, more actionable advice and better understand risks, while engineers and developers gain a deeper understanding of that guidance. We will will share personal OSPO insights and practical strategies for enabling efficient, clear communication between these distinct functions. \n \n The goal is not to turn engineers into lawyers or lawyers into software developers, but rather helps both sides understand and support each other more effectively. Without a shared language between engineering and legal, messages to management risk getting lost in translation. With clear communication we can all work more efficient together!\n\n[Open in Sched](https://osselceu2026.sched.com/event/d180025d1e9f3db598b0cabb805f87c8)", "url": "https://osselceu2026.sched.com/event/d180025d1e9f3db598b0cabb805f87c8", "persons": [{"public_name": "Jimmy Ahlberg"}, {"public_name": "Georg Kunz"}]}, {"guid": "oss-b88f72f049c47150d945b5c66ab415cc", "id": "oss-b88f72f049c47150d945b5c66ab415cc", "title": "The Evolving OSPO: Driving Technology Governance and Strategic Value in the AI Era", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "As AI transforms the tech landscape through AI-generated code and new security threats, software supply chains and corporate environments face an unprecedented paradigm shift. Consequently, the OSPO's role is becoming more complex, requiring broad coordination across internal and external organizations. We will discuss how enterprises position their OSPOs to realize comprehensive strategic value—including governance and risk management—as well as the challenges they face.\n \n In this joint presentation, Mary Meixia Wang (Executive Director of OpenChain) and Hiroshi Ota (Senior Manager of the Governance & OpenTech Division leading the OSPO at LY Corporation and a W3C Advisory Board member) will deliver a dialogue exploring the strategic convergence of open source, technical standards, and corporate technology governance.\n \n To drive smooth operations and growth while mitigating technical risks, we will share the LY Corporation model. Through this case introduction, we will highlight the enterprise challenges such as the impact of AI and the expectations companies have for open-source communities like OpenChain. Responding to these realities, Mary will share OpenChain's global vision.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b88f72f049c47150d945b5c66ab415cc)", "url": "https://osselceu2026.sched.com/event/b88f72f049c47150d945b5c66ab415cc", "persons": [{"public_name": "Hiroshi Ota"}, {"public_name": "Meixia Wang"}]}, {"guid": "oss-7608f07218c0ceada68bbfccec8ad33d", "id": "oss-7608f07218c0ceada68bbfccec8ad33d", "title": "A Fork Load of Maintenance - Forking a Key Dependency", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The benefits of building software on top of open source solutions are well understood, such as avoiding reinventing the wheel, leveraging global expertise, and enabling interoperability. Another benefit is the ability to customise open source software for your use case, but in practice this will often be done by making a fork of the project, which can result in a significant maintenance overhead.\n \n This talk is a case study of the BBC's fork of dash.js, a JavaScript library for media playback that is a key dependency for BBC web and connected TV apps. We will explore the reasons why a fork is being maintained, what the costs and benefits have been, and what is being done to reduce the maintenance overhead going forwards, including contributing to the mainline and engaging with the community. Attendees will come away with a better understanding of why and why not to fork, and how to reduce the burden of maintaining a fork.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7608f07218c0ceada68bbfccec8ad33d)", "url": "https://osselceu2026.sched.com/event/7608f07218c0ceada68bbfccec8ad33d", "persons": [{"public_name": "Tom Sadler"}]}, {"guid": "oss-e88e9224d29ad574a92263e76c14d8a7", "id": "oss-e88e9224d29ad574a92263e76c14d8a7", "title": "What You Need To Know About Project Health", "date": "2026-10-08T15:00:00+02:00", "start": "15:00", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most organizations consuming open source have no systematic way to assess whether the projects they depend on are thriving, stagnating, or quietly dying. Scanners tell you about license, origin, and known vulnerabilities. Nothing tells you a maintainer is burning out or release cadence has silently stalled until it’s too late.\n \n This talk introduces project health as a missing layer of supply chain risk management. We’ll cover the core metrics that matter from the work of CHAOSS (Community Health Analytics for Open Source Software) and how they complement security-focused efforts like OpenSSF Scorecard.\n \n We’ll look at what’s ahead: making health data federated, queryable, and built into the tools and metadata infrastructure teams already use, so a health check becomes as automatic as a vulnerability scan. We’ll cover what’s being built now, what’s still unsolved, and how you can get involved.\n \n Leave with a practical framework for evaluating dependency health today, and understand where this ecosystem is headed: toward a future where operationalized open health data at scale makes project health visible, measurable, and actionable for everyone who depends on open source.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e88e9224d29ad574a92263e76c14d8a7)", "url": "https://osselceu2026.sched.com/event/e88e9224d29ad574a92263e76c14d8a7", "persons": [{"public_name": "Daniel Izquierdo Cortazar"}]}, {"guid": "oss-e29a196ff887d3c43c31eea36b0b4c54", "id": "oss-e29a196ff887d3c43c31eea36b0b4c54", "title": "Panel: Can University OSPOs Unlock Global Open Source Partnerships?", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "University researchers create innovative open source ecosystems that can reshape global digital infrastructure, however translating that work into sustainable partnerships with open source communities - and industry - remains difficult. Promising projects disappear based on funding cycles and student/faculty transience. Barriers to collaboration – IP issues, funding models, institutional culture – remain difficult to tackle. While these challenges are universal, the landscape looks different depending on in which part of the world you sit. Funding, technology transfer norms, and expectations from academic partners vary significantly between the EU and North American contexts. This panel brings together university OSPO practitioners to examine what a genuinely international model for university-industry open source collaboration could look like. They will share what's working in their ecosystems, where barriers lie, and whether shared infrastructure could bridge regional differences. The session includes space for audience input on what is most needed to make academic partnerships stronger at a global level.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e29a196ff887d3c43c31eea36b0b4c54)", "url": "https://osselceu2026.sched.com/event/e29a196ff887d3c43c31eea36b0b4c54", "persons": [{"public_name": "Stephanie Lieggi"}, {"public_name": "Nithya Ruff"}, {"public_name": "Clare Dillon"}, {"public_name": "Jacek Plucinski"}]}, {"guid": "oss-57e85c89677589f10f4ce3f7335f3516", "id": "oss-57e85c89677589f10f4ce3f7335f3516", "title": "Panel Discussion: Are Open Source Licenses for AI Models a Hallucination?", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "For decades, the Open Source Software world has run on a simple, elegant legal hack: standard open-source licenses (like GPL, BSD, or Apache 2.0) use copyright law to enforce openness and collaboration. But as the industry shifts to AI models are we are hitting a catastrophic legal wall? AI models and weights aren't code, they aren't traditional \"data\" either. Is the licensing regimes we have been reliant on for so long no longer an adequate solution for how to license AI Models and wights when we want to make them available and keep them as Open Source, and if so why do we keep on licensing them this way? \n \n This panel hopes to brings together experts from various fields and industries to discuss some of the challenges and potential risks you may run into then using or sharing AI models and wights under Open Source licenses, and explore some high level ideas of what mechanisms could be used instead of \"traditional\" Open Source licenses to keep the openness and collaboration we all depend on to further innovation.\n\n[Open in Sched](https://osselceu2026.sched.com/event/57e85c89677589f10f4ce3f7335f3516)", "url": "https://osselceu2026.sched.com/event/57e85c89677589f10f4ce3f7335f3516", "persons": [{"public_name": "Jimmy Ahlberg"}, {"public_name": "Eleftheria Stefanaki"}, {"public_name": "Andrew Katz"}]}], "South Hall 1 B (Floor 1)": [{"guid": "oss-3d928def23de587f6f8e2561caec441c", "id": "oss-3d928def23de587f6f8e2561caec441c", "title": "Community Update", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/3d928def23de587f6f8e2561caec441c)", "url": "https://osselceu2026.sched.com/event/3d928def23de587f6f8e2561caec441c", "persons": [{"public_name": "Ramon Roche"}]}, {"guid": "oss-c7e1f2fb3d70aeedd0c115b11c00fc93", "id": "oss-c7e1f2fb3d70aeedd0c115b11c00fc93", "title": "Fleet-Scale Bug Hunting in PX4", "date": "2026-10-08T11:10:00+02:00", "start": "11:10", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Running PX4 on thousands of devices surfaces errors that don't appear in lab testing or flight tests. The kind that only show up at a customer site, that you cannot reproduce locally, that disappear when you add or remove code in a completely unrelated module. This talk presents real incidents from running PX4 at commercial scale: problem descriptions, how debugging was done, and how the errors were fixed. For each incident we share the heuristics we use to quickly identify which part of the system to investigate, and the tools we use to diagnose Heisenbugs. We conclude with the hardware CI setup we built, including hardware tracing capabilities and describe how this can help to catch certain kinds of failures described in this talk. In addition we describe how this can be shared with upstream.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c7e1f2fb3d70aeedd0c115b11c00fc93)", "url": "https://osselceu2026.sched.com/event/c7e1f2fb3d70aeedd0c115b11c00fc93", "persons": [{"public_name": "Alexander Lerach"}]}, {"guid": "oss-1e696aafde2d91f46ee6f7d4e0643ea1", "id": "oss-1e696aafde2d91f46ee6f7d4e0643ea1", "title": "Learning To Navigate: Challenges of RL With PX4 as a Real-Time Controller", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Training an RL policy with PX4 as a real-time controller is often considered impractical due to SITL limitations, communication overhead, and strict safety constraints. In this presentation, I will share how I addressed these challenges during my master’s thesis to successfully train a navigation and obstacle avoidance policy using Isaac Sim and Isaac Lab.\n The talk focuses on the practical steps required to make PX4 compatible with unsupported simulators, including key preparations to enable stable SITL operation. I will discuss how to keep the PX4 SITL instance stable and continuously running throughout training.\n Additionally, I will cover methods for accessing PX4 state and control interfaces via MAVLink and ROS 2, and highlight how PX4’s built-in safety layers can unintentionally block RL training. Finally, I will present strategies to work around these constraints while preserving system stability and realism.\n\n[Open in Sched](https://osselceu2026.sched.com/event/1e696aafde2d91f46ee6f7d4e0643ea1)", "url": "https://osselceu2026.sched.com/event/1e696aafde2d91f46ee6f7d4e0643ea1", "persons": [{"public_name": "Kyrillos Adeeb"}]}, {"guid": "oss-fa00e8ab343543feee162b2e5b11ab1a", "id": "oss-fa00e8ab343543feee162b2e5b11ab1a", "title": "From Observing To Working: PX4-Powered Aerial Manipulators", "date": "2026-10-08T12:00:00+02:00", "start": "12:00", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Recently, drones have evolved from passive observers into active workers, enabling them to carry out physical work in the sky. This lightning talk shares recent advances in Aerial Manipulators (AM), where flying robots physically interact with their surroundings to perform tasks such as inspecting and maintaining offshore wind turbines. We showcase how PX4 is accelerating the move from lab research to real-world deployment with the journey of a field test of our open AM framework, Sarax (github/sarax), physically interacting with a wind turbine by the North Sea (youtu.be/Er0f0A97aG8). Alongside it, we highlight two research threads (with references to our open-source HW/SW and PRs). First, a PX4/Pixhawk compliant open standard-interface for active, high-power payloads (e.g. manipulator with a steel brush for surface maintenance) to enable modular AM. Second, developing PX4-powered omnidirectional and actively tilting-rotor aerial robots that enable dexterous physical tasks in windy environments. We close with next steps and open issues for PX4-powered aerial manipulators and an open invitation for the community to join forces and shape this future together.\n\n[Open in Sched](https://osselceu2026.sched.com/event/fa00e8ab343543feee162b2e5b11ab1a)", "url": "https://osselceu2026.sched.com/event/fa00e8ab343543feee162b2e5b11ab1a", "persons": [{"public_name": "Ayham Alharbat"}]}, {"guid": "oss-34df9bc5bed616bdbefda3d32193c0ad", "id": "oss-34df9bc5bed616bdbefda3d32193c0ad", "title": "Flying a Drone Onto a High Voltage Power Line", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Safely flying a drone close to high voltage power lines is a challenge. Making contact with a power line to install hardware on it is even more challenging. The line generates strong electromagnetic interference and there is no room for error in positioning. In this talk we will go through the challenges we faced with positioning, magnetic interference and changing payload weight. We will show how tailoring the PX4 parameters can address these challenges and compare this to our experience using a DJI M600 where all problems have to be accounted for by our own specialized software. Finally we will present an open problem with RTK degradation resulting in sudden position jumps which we have currently handled in our own software.\n\n[Open in Sched](https://osselceu2026.sched.com/event/34df9bc5bed616bdbefda3d32193c0ad)", "url": "https://osselceu2026.sched.com/event/34df9bc5bed616bdbefda3d32193c0ad", "persons": [{"public_name": "Mads Bornebusch"}]}, {"guid": "oss-0783b0a9fdba6ee38dcc528f78db0fcd", "id": "oss-0783b0a9fdba6ee38dcc528f78db0fcd", "title": "MAVLink: State of the Nation", "date": "2026-10-08T14:10:00+02:00", "start": "14:10", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "An update on MAVLink project and standardization: how we're aligning stakeholders around common definitions, why standardization takes as long as it does, and what PX4 is doing right now to be a better MAVLink citizen.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0783b0a9fdba6ee38dcc528f78db0fcd)", "url": "https://osselceu2026.sched.com/event/0783b0a9fdba6ee38dcc528f78db0fcd", "persons": [{"public_name": "Hamish Willee"}]}, {"guid": "oss-97e2bfcd42bca39c30003f41488a0e06", "id": "oss-97e2bfcd42bca39c30003f41488a0e06", "title": "Serial Passthrough in PX4: Accessing FC Serial Ports Over MAVLink", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "PX4 v1.18 introduces a serialpassthrough driver that lets any MAVLink client read from and write to flight controller serial ports. This talk walks through the design: how SERIAL_CONTROL messages are mapped to hardware UART ports and, on STM32F7/H7 boards, to ESC signal pins via a software bit-bang UART; How reply routing, buffer management, and channel exclusivity are handled. We also cover the MAVLink↔UART bridge pattern that makes the feature usable from standard host-side tools, and the PASSTHRU_EN mechanism for safely handing off ESC signal pins at boot. Whether you need to debug a serial peripheral over a telemetry link, configure an ESC remotely, or build custom tooling on top of SERIAL_CONTROL, this talk gives you the full picture.\n\n[Open in Sched](https://osselceu2026.sched.com/event/97e2bfcd42bca39c30003f41488a0e06)", "url": "https://osselceu2026.sched.com/event/97e2bfcd42bca39c30003f41488a0e06", "persons": [{"public_name": "Philipp Engljähringer"}]}, {"guid": "oss-3e183876f4581e907eff4dafaeb971fe", "id": "oss-3e183876f4581e907eff4dafaeb971fe", "title": "State of MAVSDK", "date": "2026-10-08T15:00:00+02:00", "start": "15:00", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "As a maintainer of MAVSDK I would like give an update on the current state of the project, specifically about changes and improvements coming with MAVSDK v4, such as: - New lightweight Python wrappers - New MavlinkDirect plugins - And lots of improvements under the hood\n\n[Open in Sched](https://osselceu2026.sched.com/event/3e183876f4581e907eff4dafaeb971fe)", "url": "https://osselceu2026.sched.com/event/3e183876f4581e907eff4dafaeb971fe", "persons": [{"public_name": "Julian Oes"}]}, {"guid": "oss-8aea181e64778ca814783106f6161043", "id": "oss-8aea181e64778ca814783106f6161043", "title": "SIH: A Flight Simulator That Lives Inside the Autopilot", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most PX4 simulation relies on an external simulator talking to the autopilot over a network bridge. SIH, the Simulator In Hardware, does the opposite: it is a single PX4 module that integrates the full rigid-body equations of motion right next to the flight stack. The same code runs as a SITL process on your laptop and, just as well, directly on the flight controller, feeding synthetic sensor data into the estimation pipeline while the board flies a virtual vehicle. This talk opens up SIH and shows how little there is between you and a flying model: how actuator outputs become forces and torques, are integrated through the equations of motion, and are reconstructed into noisy IMU, baro, GNSS, and airspeed signals that the rest of PX4 cannot tell from real hardware. We cover the vehicle types supported, the aerodynamic model that makes adding an airframe a matter of physics rather than plumbing, and how to launch, run, and extend SIH.\n\n[Open in Sched](https://osselceu2026.sched.com/event/8aea181e64778ca814783106f6161043)", "url": "https://osselceu2026.sched.com/event/8aea181e64778ca814783106f6161043", "persons": [{"public_name": "Marco Hauswirth"}]}, {"guid": "oss-75e108d0d6289b47f2e4cba512790224", "id": "oss-75e108d0d6289b47f2e4cba512790224", "title": "Keep It in the Air: Surviving Motor Failures in PX4", "date": "2026-10-08T16:10:00+02:00", "start": "16:10", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "What if losing a motor didn't mean losing the drone? This talk gives an end-to-end overview of how PX4 handles motor failure on multicopters: how it recognizes a failing motor, and the failsafe and control-allocation responses that decide what happens next.\n We'll then look at where motor-failure handling is heading: a new filter-based detection method that learns each motor's expected behavior to catch faults earlier, the tooling to calibrate it from real flight data, and a recovery that can keep a vehicle flying, and bring it home, after losing a motor.\n\n[Open in Sched](https://osselceu2026.sched.com/event/75e108d0d6289b47f2e4cba512790224)", "url": "https://osselceu2026.sched.com/event/75e108d0d6289b47f2e4cba512790224", "persons": [{"public_name": "Gennaro Guidone"}]}, {"guid": "oss-2b4726c640eae794a038c5f55b119b55", "id": "oss-2b4726c640eae794a038c5f55b119b55", "title": "Infected Drones: How Compromised Autonomous Systems Pwn Ground Control Stations", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern drone operations have moved from one pilot, one aircraft to multi-agent autonomous fleets. Dozens and even hundreds of vehicles now fly missions while only a handful of operators supervise from the ground. More drones, fewer ground stations, and the station is where all the value is, the operator, the mission data, a full-blown OS, and even access to other drones.\n \n For years, drone security researchers have focused on attacking the vehicle. I flip the target and show how a single infected drone becomes a beachhead, reaching up the command chain to own the very station meant to control it, and the fleet.\n \n This research audited six popular independent ground-control and middleware projects across the MAVLink ecosystem, Mission Planner, QGroundControl, MAVSDK, MAVProxy, MAVROS, and DroneKit and found the same broken trust boundary in all of them. The result is 14 findings rooted in one systemic flaw, including two novel full remote code execution chains against the operator's own machine.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2b4726c640eae794a038c5f55b119b55)", "url": "https://osselceu2026.sched.com/event/2b4726c640eae794a038c5f55b119b55", "persons": [{"public_name": "Nick Aleks"}]}, {"guid": "oss-444222a2e98edc480e2707e350370855", "id": "oss-444222a2e98edc480e2707e350370855", "title": "An Open-Source PX4 Swarm With Onboard ESP32-P4 Vision", "date": "2026-10-08T17:00:00+02:00", "start": "17:00", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "I want to share our bumpy road on Swarm Drone Challenge 2026 (ILA Berlin) with a team of two people and what two stubborn guys can achieve during weekends - 4th place. We built a swarm of 5 drones, each running PX4 for flight, coordinated by a ROS2 ground station and onboard with two ESP32-ser. microcontrollers. ESP32-P4 was dedicated to onboard ArUco vision and ToF obstacle sensing (no Linux SBC) and an ESP32-S3 handling MAVLink and micro-ROS comms over WiFi. I will cover architecture — PX4 + MAVLink + a ROS2 commander that assigns swarm roles and streams waypoints — and the onboard vision pipeline on bare microcontrollers. Comparison of Version 1.0 (single-MCU) vs Version 2.0 (dual-MCU) and why we shipped a deterministic Manhattan-grid navigation fallback when ArUco-EKF localization could not be deployed in time. Our solution was open-sourced - https://github.com/machmind-dev/drone-swarm-challenge-2026\n\n[Open in Sched](https://osselceu2026.sched.com/event/444222a2e98edc480e2707e350370855)", "url": "https://osselceu2026.sched.com/event/444222a2e98edc480e2707e350370855", "persons": [{"public_name": "Mindaugas Jonauskis"}]}], "South Hall 2 A (Floor 2)": [{"guid": "oss-657b609f1e090577d7db14666c12e49e", "id": "oss-657b609f1e090577d7db14666c12e49e", "title": "Demystifying Functional Safety in Zephyr RTOS", "date": "2026-10-08T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "There is an increasing demand for functional safety and certifying Zephyr RTOS from SoC vendors and companies wishing to make medical and automotive products. In the meantime, there is a lot of pushback from developers who believe that open source software is not compatible with the rigors and the processes required by functional safety.\n Alexandre Bailon is an active Zephyr developer who had no knowledge about functional safety. After attending numerous talks, he found himself facing more questions than answers.\n Alexandre Bailon will give the talk he would have expected as an open source developer. He will first explain what functional safety is and why this is a must-have for Zephyr RTOS.\n Then, he will try to address developers' concerns and tackle some common misconceptions they have. In addition, he will talk about the safety working group and how it aims to minimize the burden on contributors and maintainers while meeting certification requirements.\n To finish, he will discuss the current initiatives and opportunities for community involvement in advancing functional safety support in Zephyr.\n\n[Open in Sched](https://osselceu2026.sched.com/event/657b609f1e090577d7db14666c12e49e)", "url": "https://osselceu2026.sched.com/event/657b609f1e090577d7db14666c12e49e", "persons": [{"public_name": "Alexandre Bailon"}]}, {"guid": "oss-730e43eef393f51bbd0f768e0b11c782", "id": "oss-730e43eef393f51bbd0f768e0b11c782", "title": "Bringing IEC 60730 Class B Functional Safety To Zephyr", "date": "2026-10-08T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The IEC 60730 Class B standard defines safety requirements for automatic electrical controls in household appliances, mandating diagnostic mechanisms that ensure safe operation under fault conditions.\n Despite its widespread adoption, IEC 60730 implementations remain fragmented and vendor-specific, typically delivered as proprietary libraries tightly coupled to individual MCUs. This approach limits portability, duplicates engineering effort, and prevents meaningful integration with modern open-source ecosystems.\n This talk presents an open, reusable IEC 60730 Class B diagnostic framework built on Zephyr RTOS, demonstrating how functional safety mechanisms can be implemented in a portable and extensible way. The framework includes key diagnostics such as power-on self-tests, periodic runtime checks, watchdog supervision, and safe-state handling.\n This work establishes a foundation for standardizing safety mechanisms in Zephyr and aims to catalyze community collaboration around common APIs and reference implementations for safety-critical embedded systems.\n The session is targeted at embedded developers working on consumer appliances and industrial control systems.\n\n[Open in Sched](https://osselceu2026.sched.com/event/730e43eef393f51bbd0f768e0b11c782)", "url": "https://osselceu2026.sched.com/event/730e43eef393f51bbd0f768e0b11c782", "persons": [{"public_name": "Andrej Butok"}]}, {"guid": "oss-79e7253a983cf82f8706a1f55c5b3825", "id": "oss-79e7253a983cf82f8706a1f55c5b3825", "title": "Zephyr and Xen in Automotive Mixed-OS Systems: Building Safety Readiness and Upstream", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In automotive systems, interest is growing in OSS adoption, Software-Defined Vehicles (SDV), and mixed-criticality architectures. In initiatives such as AGL and SoDeV, configurations combining Linux, RTOSes, and hypervisors are becoming a key focus. In this context, Zephyr may be used as a small RTOS domain with a limited, well-defined role.\n \n This session views Zephyr and Xen as complementary components. Xen can provide domain isolation and resource partitioning, Linux can host high-level services and integration layers, and Zephyr can handle focused RTOS functions. It outlines role division in OSS-based automotive software.\n \n Functional safety is also important. The Zephyr Safety WG is advancing related activities, treating safety readiness not as certification itself but as a technical foundation—requirements, tests, and documentation—that the community can build together. This session discusses how automotive stakeholders can participate and contribute upstream.\n \n Based on Linux/AGL mixed-OS integration experience, this case study discusses what should be addressed when applying Zephyr and Xen to automotive systems and how these efforts can advance with the community.\n\n[Open in Sched](https://osselceu2026.sched.com/event/79e7253a983cf82f8706a1f55c5b3825)", "url": "https://osselceu2026.sched.com/event/79e7253a983cf82f8706a1f55c5b3825", "persons": [{"public_name": "Harunobu Kurokawa"}]}, {"guid": "oss-de8bfa78b867c88bff784916b9669342", "id": "oss-de8bfa78b867c88bff784916b9669342", "title": "Reverse Engineering Zephyr's Software Architecture for Safety-Critical Use", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Zephyr RTOS is increasingly relevant for safety-related and mixed-criticality systems, where qualification and certification must address standards such as IEC 61508 and ISO 26262. A key question is how to provide evidence that software components are independent, that freedom from interference is preserved, and that future changes can be assessed without redoing unnecessary qualification work. This session presents ongoing work on reverse engineering Zephyr's effective software architectural constraints using static analysis. Starting from concrete Zephyr configurations, we model components, observe calls and data accesses, identify dependencies, and compare the result with the project's intended layered architecture. The talk will show how this analysis supports safety arguments by making software-level independence explicit and checkable. It will also show how the same model enables Change Impact Analysis: when a qualified Zephyr version or configuration evolves, the model helps determine which components, assumptions, tests, and safety evidence are affected. This is essential to make Zephyr's safety effort sustainable over time and viable for safety-related development.\n\n[Open in Sched](https://osselceu2026.sched.com/event/de8bfa78b867c88bff784916b9669342)", "url": "https://osselceu2026.sched.com/event/de8bfa78b867c88bff784916b9669342", "persons": [{"public_name": "Roberto Bagnara"}]}, {"guid": "oss-c29ba82f4d8a41668804ab3da632a967", "id": "oss-c29ba82f4d8a41668804ab3da632a967", "title": "No Board, No Problem: Testing Zephyr Applications With Native_sim", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Zephyr makes it easy to build the same code for multiple board targets. native_sim lets you run (parts of) your zephyr application and associated tests as a regular Linux process, allowing reproducible runs, easy debugging and CI integration. In this talk, I will share what we learned structuring, testing, and debugging several real-world Zephyr applications: * The native_sim execution model: How time is handled * How to emulate hardware: Fake drivers, virtual bluetooth controllers, networking, PTY UART, emulators * Examples of what can be built using these primitives: * Connecting to the Android Emulator over BLE * Writing Zephyr tests using the Cucumber framework * ... * Tooling around native_sim: twister, sanitizers, GDB, code coverage * Integrating external binaries into twister through the pytest harness * Designing for testability: Separating business logic from hardware-dependent software units * When native_sim is not enough: Running tests in qemu or on real hardware The goal of this talk is to provide a broad overview about what is possible thanks to native_sim, hopefully inspiring new ideas on how to test code without ever touching hardware.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c29ba82f4d8a41668804ab3da632a967)", "url": "https://osselceu2026.sched.com/event/c29ba82f4d8a41668804ab3da632a967", "persons": [{"public_name": "Marco Widmer"}]}, {"guid": "oss-753b18e4a39039a62f1ec9646f02335c", "id": "oss-753b18e4a39039a62f1ec9646f02335c", "title": "Fake Drivers: A Practical Guide To Zephyr Test Doubles", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In Zephyr, subsystems, middleware, and application components typically depend on one or more lower-level device driver APIs. For testing these upper-level subsystems in isolation, the lower-level driver dependencies must still be satisfied. A popular software design pattern for this is to use test doubles. However, how can this be achieved in Zephyr without introducing test-specific changes to the upper-level subsystem? The solution is to use fake drivers. This presentation will explore various use cases for employing fake device drivers as test doubles, examine the structure of a fake driver implementation, and demonstrate how fake drivers can be used to not only satisfy test dependencies, but also facilitate test case isolation, driver API call inspection and instrumentation.\n\n[Open in Sched](https://osselceu2026.sched.com/event/753b18e4a39039a62f1ec9646f02335c)", "url": "https://osselceu2026.sched.com/event/753b18e4a39039a62f1ec9646f02335c", "persons": [{"public_name": "Henrik Brix Andersen"}]}, {"guid": "oss-33469d672f8951d658cc4e6852de6bda", "id": "oss-33469d672f8951d658cc4e6852de6bda", "title": "Stop Rewiring: Scale Embedded Hardware Testing", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Embedded test automation is often limited by something simple: wires. External loopback, testing another peripheral instance, validating a power domain, or connecting to external equipment can each require a different setup. As coverage grows, teams end up with custom fixtures, manual steps, fragile lab instructions, and CI systems that cannot reproduce a developer’s bench setup. This talk presents an open source framework that uses a low-cost, off-the-shelf FPGA board as a programmable routing fabric. It sits between the device under test and the rest of the setup, routing pins to loopbacks, other peripherals, boards, or tools. The framework is software-agnostic: it works with Zephyr, Linux, bare metal, or vendor SDK testing. Tests declare the needed connections, metadata describes the FPGA-to-device wiring, and the framework generates per-test Verilog, runs open source FPGA tools, and programs the FPGA. The talk will cover lessons from real tests, common peripheral limits, demo and how to reproduce this setup at a desk, in a lab, or in CI. Key benefits: *Low-cost off-the-shelf hardware *Open source software *Easier developer desk testing *More CI/CD regression coverage\n\n[Open in Sched](https://osselceu2026.sched.com/event/33469d672f8951d658cc4e6852de6bda)", "url": "https://osselceu2026.sched.com/event/33469d672f8951d658cc4e6852de6bda", "persons": [{"public_name": "Franklin Cooper"}]}, {"guid": "oss-5e3a87178e92b55b2809288e0ecfba94", "id": "oss-5e3a87178e92b55b2809288e0ecfba94", "title": "ZView: Non-Intrusive Runtime Observability for Zephyr", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Zephyr is a comprehensive ecosystem, but sometimes you want a better view of your system and end up reaching for shell, UART, printk, RTT, or tracing, all of which work, but all of which cost on-target code, pins, or configuration overhead, or even extra hardware.\n ZView is a live, non-intrusive, low-integration-cost runtime observability tool that provides an overview of how your application behaves (threads, heaps, allocation and fragmentation, CPU usage, and more) all in a TUI, using only your debug probe via SWD.\n It uses the debug access port to read kernel memory passively while the target keeps running. No instrumentation, no halt, no extra pins. ZView interprets what it reads, recognizing threads, heaps, and other kernel objects, turning raw memory into actionable runtime insights.\n This talk covers what ZView is, how it works, its limits, and where it can go next. The goal is to make ZView a standard part of the Zephyr debugging toolkit, with the community's help.\n\n[Open in Sched](https://osselceu2026.sched.com/event/5e3a87178e92b55b2809288e0ecfba94)", "url": "https://osselceu2026.sched.com/event/5e3a87178e92b55b2809288e0ecfba94", "persons": [{"public_name": "Paulo Santos"}]}], "South Hall 2 B (Floor 2)": [{"guid": "oss-744d0a3d4c4c9b23b51a9489de0208a0", "id": "oss-744d0a3d4c4c9b23b51a9489de0208a0", "title": "Network Subsystem Status and Overview", "date": "2026-10-08T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Network connectivity is important part of Zephyr. This talk will give information of current status of the network stack.\n\n[Open in Sched](https://osselceu2026.sched.com/event/744d0a3d4c4c9b23b51a9489de0208a0)", "url": "https://osselceu2026.sched.com/event/744d0a3d4c4c9b23b51a9489de0208a0", "persons": [{"public_name": "Jukka Rissanen"}]}, {"guid": "oss-cd868ee5f524f57fa49e96d01377a69c", "id": "oss-cd868ee5f524f57fa49e96d01377a69c", "title": "From TTEthernet To TSN on Zephyr: What Space Systems Teach Us About Deterministic Networking", "date": "2026-10-08T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Many spacecraft avionics and payload systems are already distributed embedded systems: onboard computers, payload controllers, sensors, and links must coordinate under strict reliability constraints. Aerospace has long used controlled onboard networks, from MIL-STD-1553 to Ethernet-based approaches such as TTEthernet. The next question is how open standards such as IEEE Time-Sensitive Networking (TSN) can work in open RTOS ecosystems such as Zephyr.\n \n Based on my experience with TTEthernet, Zephyr, micro-ROS, and space OBC development, this talk asks what TSN on Zephyr should become. TSN is not one feature: traffic shaping, scheduled transmission, redundancy, policing, configuration, time synchronization, and hardware support all matter. Linux already has a mature TSN operations model around user-space tools such as tc and linuxptp. Zephyr has no Linux-style userland, so TSN needs Zephyr-native APIs, shell commands, samples, diagnostics, and management interfaces.\n \n Attendees will learn why TSN matters for Zephyr, why Zephyr cannot simply copy Linux tooling, and what design questions remain for TSN-capable endpoints.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cd868ee5f524f57fa49e96d01377a69c)", "url": "https://osselceu2026.sched.com/event/cd868ee5f524f57fa49e96d01377a69c", "persons": [{"public_name": "Yasushi Shoji"}]}, {"guid": "oss-c577a20876ea7496e757b6589ad64cb5", "id": "oss-c577a20876ea7496e757b6589ad64cb5", "title": "Zephyr Network Buffers", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Zephyr has had its own abstraction for network buffers ever since the creation of its Bluetooth and Networking stacks that were part of the project's public launch back in 2016. The presenter is the original author of the buffer implementation and still acts as maintainer for it. The presentation will go through the original use cases, related design decisions, key terminology, and how the implementation has evolved over time as Zephyr has grown and received more users and requirements for the subsystem. The presentation will also go through common mistakes/oversights that user make when starting to use the APIs, and show some best practices to avoid them. Finally, there will be an overview of some of the latest enhancements and new convenience APIs of the network buffer subsystem.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c577a20876ea7496e757b6589ad64cb5)", "url": "https://osselceu2026.sched.com/event/c577a20876ea7496e757b6589ad64cb5", "persons": [{"public_name": "Johan Hedberg"}]}, {"guid": "oss-b0e7f5a4ecfb8ca99a9ebe6e6ccde610", "id": "oss-b0e7f5a4ecfb8ca99a9ebe6e6ccde610", "title": "Zephyr Documentation BoF", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Over the past few years, the Zephyr documentation has continued to evolve, with steady improvements to content structure, discoverability, consistency, and the overall contributor experience. One thing that has proven especially valuable is having a regular community check-in where we can openly discuss what is working, what still gets in the way, and where our documentation priorities should be headed next. Join this Birds of a Feather session to catch up on recent documentation improvements you may have missed, share feedback from your own experience using or contributing to the docs, and help shape what we should focus on in the year ahead.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b0e7f5a4ecfb8ca99a9ebe6e6ccde610)", "url": "https://osselceu2026.sched.com/event/b0e7f5a4ecfb8ca99a9ebe6e6ccde610", "persons": [{"public_name": "Benjamin Cabé"}]}, {"guid": "oss-482d2c3eef0290b7a571bb82e3f00363", "id": "oss-482d2c3eef0290b7a571bb82e3f00363", "title": "USB Development and Testing on Native Simulator", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Zephyr's new USB support has been in development for some time. It consists of USB device and USB host support. The new device support has been the default for the last two releases. Work on the device part also introduced initial support for the host stack at that time. This was primarily necessary to enable USB/IP support on the native_sim board. Johann will start with a brief overview of the current status of USB support. Johann will then present information on virtual device/host controllers and the virtual bus. These are not actually platform-dependent, but they are most often used with native_sim. Furthermore, he will explain how virtual device/host controllers make it possible to build USB applications for native_sim and then export them to a Linux client using USB/IP server support. Johan will demonstrate that the main benefit of virtual device/host support and native_sim is the ability to test hardware-independent USB code in CI, even on a pull request basis. For example, we can test the behavior of the host/device stack in response to invalid or undefined requests. Johann will either provide a few examples or point to the samples and specific tests in the repository.\n\n[Open in Sched](https://osselceu2026.sched.com/event/482d2c3eef0290b7a571bb82e3f00363)", "url": "https://osselceu2026.sched.com/event/482d2c3eef0290b7a571bb82e3f00363", "persons": [{"public_name": "Johann Fischer"}]}, {"guid": "oss-f70c22f1dc0929ed69d20e42e2bb01b2", "id": "oss-f70c22f1dc0929ed69d20e42e2bb01b2", "title": "Evolving Zephyr USB Host Stack: Enabling UVC, CDC-ECM and Hub With Real-World Lessons", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Zephyr USB host stack is still evolving and remains an experimental subsystem for many real-world applications. This session presents practical experience in enabling key USB host classes in Zephyr, including UVC (USB Video Class), CDC-ECM, and USB Hub support, along with a series of architectural improvements to the host stack. The presentation highlights the challenges and lessons learned while bringing these features to Zephyr, including attach/detach handling, dynamic class matching for composite devices, device lifecycle management across class drivers, the core stack, and UHC drivers, dynamic configuration selection, and limitations in current APIs. In addition, the session identifies gaps in the current USB host subsystem and outlines potential directions for future evolution. It aims to provide practical insights and guidance for developers working on USB host support in Zephyr.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f70c22f1dc0929ed69d20e42e2bb01b2)", "url": "https://osselceu2026.sched.com/event/f70c22f1dc0929ed69d20e42e2bb01b2", "persons": [{"public_name": "Mark Wang"}]}, {"guid": "oss-4186fca17b16b7b9a82c62365217ad0f", "id": "oss-4186fca17b16b7b9a82c62365217ad0f", "title": "Enabling Matter on Zephyr", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Matter is an open-source application-layer connectivity standard for connected home devices built on top of Wi-Fi and Thread, technologies that are both supported in Zephyr. Until recently, Matter support on Zephyr was primarily delivered through vendor-specific downstream SDKs, but there has been a growing effort to collaborate upstream in both the Matter and Zephyr communities to improve integration between the two projects. This session will explore the current state of Matter support in the Zephyr ecosystem, including how Matter is integrated today as an external middleware module. We will review ongoing development efforts across both projects to create a shared Zephyr platform abstraction layer for Matter, improve build system integration, maintenance and developer experience, and highlight opportunities for community contribution. Attendees will gain an understanding of the architecture of Matter on Zephyr, recent upstream developments, the roadmap for future integration work, and how they can contribute to the effort.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4186fca17b16b7b9a82c62365217ad0f)", "url": "https://osselceu2026.sched.com/event/4186fca17b16b7b9a82c62365217ad0f", "persons": [{"public_name": "Aksel Mellbye"}]}, {"guid": "oss-690aadce68a0c48c03b8686df6a36e75", "id": "oss-690aadce68a0c48c03b8686df6a36e75", "title": "A Generic RF PHY Driver API for Proprietary Protocols in Zephyr", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Zephyr has mature driver APIs for IEEE 802.15.4, Bluetooth, Wi-Fi, and LoRa but none for radios running proprietary or custom link-layer protocols. The gap is most acute in Sub-1GHz but applies equally to proprietary 2.4GHz radios used in audio, gaming peripherals, and industrial control.\n Current workarounds include using a protocol-specific API like ieee802154_radio_api or shipping standalone drivers and importing MAC assumptions that don't belong at the PHY. The result is duplicate code across out-of-tree drivers that lock applications to a single chip and block upstream contribution. The problem spans standalone transceivers and integrated SoCs across TI, Silicon Labs, Microchip, and ST.\n This talk revives Zephyr RFC #43201 (closed 2022) with a focused proposal: a new prop_rf driver API covering only physical-layer operations, leaving link-layer concerns to the application or protocol implementer. Three principles drive the design: applications port across vendors without API lock-in; vendor HALs remain free to expose custom features via device-specific extensions; and the API works for both external transceivers and integrated SoCs.\n\n[Open in Sched](https://osselceu2026.sched.com/event/690aadce68a0c48c03b8686df6a36e75)", "url": "https://osselceu2026.sched.com/event/690aadce68a0c48c03b8686df6a36e75", "persons": [{"public_name": "Sean Lyons"}, {"public_name": "David Fosca Gamarra"}]}], "South Hall 3 A (Floor 3)": [{"guid": "oss-b8ffde44a6bea702aa7883016edc5707", "id": "oss-b8ffde44a6bea702aa7883016edc5707", "title": "Taming the Safety Dragon With U-Boot and Linux", "date": "2026-10-08T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "U-Boot and Linux boot flows lack safety monitoring for mixed-criticality systems. We address this gap for low-criticality use cases and development stages where customers work toward safety certification on TI K3 SoCs, offering a flexible alternative to rigid safety-critical frameworks. This approach can be extended to any of the heterogeneous SoCs with safety hardware support. \n \nWe cover safety drivers in both U-Boot and Linux that increase the safety level of a system: Error Signaling Module (ESM) for error routing, Power-OK (POK) voltage monitors (upstreaming WIP), Voltage-Thermal Monitor (VTM), Timeout Gasket (TOG, upstreaming WIP), DDR Inline ECC for memory protection, and watchdog. In U-Boot, we leverage its sequential non-threaded flow to initialize ESM, POK, VTM, TOG, and DDR ECC via uclasses, establishing hardware safety guarantees before kernel handoff. In the kernel, we cover configuration and error handling of watchdog, and ECC for self-resets and synchronous aborts. DDR thermal self-refresh rate management and runtime monitoring of POK, VTM, and TOG via hwmon (WIP) will also be covered. Testing approaches via U-Boot cmdline tests and LTP-DDT will also be discussed.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b8ffde44a6bea702aa7883016edc5707)", "url": "https://osselceu2026.sched.com/event/b8ffde44a6bea702aa7883016edc5707", "persons": [{"public_name": "Neha Francis"}, {"public_name": "Josiitaa RL"}, {"public_name": "Santhosh Kumar K"}]}, {"guid": "oss-ada32b715038ce12222bc043eb3c5a52", "id": "oss-ada32b715038ce12222bc043eb3c5a52", "title": "Balancing Power Efficiency and Real-Time Performance on Intel Embedded Platforms", "date": "2026-10-08T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Achieving both low power consumption and deterministic real-time performance is a key challenge for modern embedded systems. Intel embedded platforms are widely deployed in industrial, medical, robotics, and other edge computing applications where strict timing requirements must be satisfied while maintaining energy efficiency. Traditional real-time system configurations often disable CPU frequency scaling and deep CPU idle states to minimize latency and jitter. While this approach can improve real-time responsiveness, it significantly increases power consumption and reduces battery life in power-constrained deployments.\n This proposal presents practical techniques for balancing power management and real-time performance on Intel embedded platforms running Linux with the PREEMPT_RT kernel. Based on experimental evaluation, we demonstrate that modern Intel power management features can be selectively enabled and tuned to reduce energy consumption while maintaining deterministic real-time behavior. These findings offer practical guidance for deploying power-efficient real-time applications on Intel edge platforms.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ada32b715038ce12222bc043eb3c5a52)", "url": "https://osselceu2026.sched.com/event/ada32b715038ce12222bc043eb3c5a52", "persons": [{"public_name": "Junxiao Chang"}]}, {"guid": "oss-73caf6e95bcc09037f60e07a94e38310", "id": "oss-73caf6e95bcc09037f60e07a94e38310", "title": "Real-time Performance Comparison of Linux, Zephyr and FreeRTOS", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In industrial and real-time applications, strict timing constraints can exceed the capabilities of standard Linux systems—even when enhanced with the PREEMPT_RT patch. As a result, developers increasingly deploy real-time operating systems (RTOS) on application-class cores (e.g., ARM Cortex-A) to meet deterministic requirements.\n This session presents a comparative study of latency characteristics measured on identical hardware platforms running Linux with PREEMPT_RT, Zephyr, and FreeRTOS. We first analyze how the PREEMPT_RT patch impacts kernel latency across different workload scenarios, highlighting both its strengths and practical limitations. We then extend the comparison to RTOS environments, focusing on scheduling latency and interrupt (IRQ) handling behavior under equivalent conditions.\n The results are based on systematic benchmarking and provide insight into latency trade-offs, determinism, and suitability of each system for industrial workloads. We will also provide industrial specific examples of target use-cases, where this performance numbers are key parameter.\n\n[Open in Sched](https://osselceu2026.sched.com/event/73caf6e95bcc09037f60e07a94e38310)", "url": "https://osselceu2026.sched.com/event/73caf6e95bcc09037f60e07a94e38310", "persons": [{"public_name": "Zbynek Fedra"}, {"public_name": "Mingkai Hu"}]}, {"guid": "oss-39260ded4c65e066eb0c4b5848a48ea7", "id": "oss-39260ded4c65e066eb0c4b5848a48ea7", "title": "Beyond Cyclictest: Evaluating Real-Time Linux Through Real Interrupt Workloads", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Real-time Linux systems are often judged with timer-based benchmarks such as cyclictest, a useful baseline for wakeup latency caused by scheduling and system activity. Yet many embedded workloads are driven by external events, not periodic timers: GPIO edges, network packets, serial I/O, or other hardware interrupts. In these systems, the critical value is the latency from an interrupt to a high-priority task. This talk asks how much end-to-end interrupt-driven latency timer-based benchmarks can explain, and where path-specific measurements are required. We revisit RT evaluation on modern PREEMPT_RT Linux by combining cyclictest with measurements for GPIO interrupt paths, network receive paths, and interrupt-to-userspace wakeups. Across scenarios with CPU isolation, IRQ affinity tuning, and other common RT optimizations, we compare what each method reveals and misses. For selected setups, we also compare kernel/PREEMPT_RT revisions and use ftrace to locate latency sources. Rather than treating one benchmark as a complete RT verdict, this session clarifies how timer-based results can inform, but not replace, measurements for practical interrupt-driven embedded workloads.\n\n[Open in Sched](https://osselceu2026.sched.com/event/39260ded4c65e066eb0c4b5848a48ea7)", "url": "https://osselceu2026.sched.com/event/39260ded4c65e066eb0c4b5848a48ea7", "persons": [{"public_name": "Koshiro Onuki"}]}, {"guid": "oss-940f11ff3943e8a28436ad1377a6463c", "id": "oss-940f11ff3943e8a28436ad1377a6463c", "title": "Beyond Best-Effort: Deterministic Real-Time Ethernet on Multi-Core Linux", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Industrial Ethernet protocols (EtherCAT, EtherNet/IP, PROFINET) require deterministic, low-latency packet processing that degrades when real-time and best-effort traffic compete for CPU resources. This work investigates the extent to which bounded latency behaviour can be achieved for real-time industrial traffic on a multi-core ARM Cortex-A53 SoC running PREEMPT_RT Linux while sharing a single Ethernet interface with concurrent best-effort traffic. The study demonstrates that both traffic types can coexist on a single physical port and be separated across cores using software-based techniques such as the XDP framework. To enforce bounded latency, CPU isolation, processor affinity, and real-time scheduling policies are applied to networking-related kernel threads and application tasks. Results compare real-time traffic latency and jitter across three configurations: no traffic steering, traffic steering to dedicated cores, and traffic steering with techniques to enforce bounded latency. The goal is a reproducible tuning guide for engineers deploying deterministic networking on Linux-based industrial platforms.\n\n[Open in Sched](https://osselceu2026.sched.com/event/940f11ff3943e8a28436ad1377a6463c)", "url": "https://osselceu2026.sched.com/event/940f11ff3943e8a28436ad1377a6463c", "persons": [{"public_name": "Meghana Malladi"}, {"public_name": "Schuyler Patton"}]}, {"guid": "oss-07a674bcb6a257705543139fca31b80c", "id": "oss-07a674bcb6a257705543139fca31b80c", "title": "Building Deterministic Heterogeneous Multicore Industrial Systems on MPUs", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "With the increasing availability of high-performance Arm® Cortex-A cores and multiple Cortex-M cores in modern MPUs, industrial systems are evolving toward heterogeneous multi-core architectures. For example, compute-intensive applications running on Linux with PREEMPT_RT on A cores, while deterministic real-time tasks running on A core with RTOS (Zephyr or FreeRTOS). This session will explore the key challenges and corresponding solutions in enabling efficient multi-OS deployment on a single MPU. Topics include: - Unified life cycle management for booting and orchestrating multiple operating systems across cores using TF-A, U-Boot, and Linux, and fast-boot optimization with TF-A mechanism. - High-performance inter-core communication mechanisms for low-latency data exchange - Resource sharing that allow different operating systems to access shared hardware IPs as isolated “virtual peripherals” The session provides practical insights into building efficient and deterministic heterogeneous systems for industrial applications.\n\n[Open in Sched](https://osselceu2026.sched.com/event/07a674bcb6a257705543139fca31b80c)", "url": "https://osselceu2026.sched.com/event/07a674bcb6a257705543139fca31b80c", "persons": [{"public_name": "Mingkai Hu"}]}, {"guid": "oss-c3d0d5f2841536ff7f0f0357b9cbb7e9", "id": "oss-c3d0d5f2841536ff7f0f0357b9cbb7e9", "title": "Using the Linux Tracing Infrastructure and eBPF for Latency Analysis", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Linux tracing infrastructure provides several methods for recording events in the operating system. Apart from many other use cases, tracing is often being used to identify the root cause of high latencies on Linux with enabled real-time configuration. The possibility of filtering and a fine granular selection of the events to be recorded reduces the overhead and therefor allows tracing of time critical sections with low impact on the runtime behavior. Events generated by the tracing infrastructure can also serve as a hook for eBPF programs, which run in a sandbox inside the kernel. These can be used for timing analysis within the kernel without the need of switching to userspace. This presentation will give a brief overview of the Linux tracing infrastructure, eBPF and how they can be used to analyze scheduling latencies on a Linux system with real-time requirements.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c3d0d5f2841536ff7f0f0357b9cbb7e9)", "url": "https://osselceu2026.sched.com/event/c3d0d5f2841536ff7f0f0357b9cbb7e9", "persons": [{"public_name": "Jan Altenberg"}]}, {"guid": "oss-7b53ef233050d633c1505e2f49e51eb6", "id": "oss-7b53ef233050d633c1505e2f49e51eb6", "title": "One Yocto Distro, Many Boards, Few Engineers", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "At balena, a 6 person team maintains 1 distro meta for 80+ boards across multiple Yocto versions. This talk unpacks the layer layout that make this level of scale possible. Maintaining one distro across multiple architectures and vendor BSPs is, above all, a separation-of-concerns problem. Centralizing every board in one BSP layer, forking vendor trees, or splitting repos without clear boundaries each trades one pain for another: merge hell or upgrade paralysis when vendors move at different speeds. Yocto's layer model is built for it but the boundaries are easy to miss. I learned it the hard way: managing boards from several vendors in a single BSP works at first, then fails to scale. During the session, you'll learn: - How to structure distro logic, version-specific, board and vendor layers - Anti-patterns from real projects - Strategies for on-boarding new hardware boards without duplicating distro logic or getting blocked by a lagging vendor BSP You will leave with a concrete layout to evaluate against your own BSPs and enough pointers using balenaOS’s oss repositories as a reference implementation to start migrating toward a maintainable global BSP.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7b53ef233050d633c1505e2f49e51eb6)", "url": "https://osselceu2026.sched.com/event/7b53ef233050d633c1505e2f49e51eb6", "persons": [{"public_name": "Yann Cardaillac"}]}], "South Hall 3 B (Floor 3)": [{"guid": "oss-0e72f336752a403f27b7903879d8010b", "id": "oss-0e72f336752a403f27b7903879d8010b", "title": "Enabling Multi-Stream Camera Sensors in Linux: RGB+IR Streams and Embedded Metadata", "date": "2026-10-08T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Camera sensors are evolving beyond single-stream models to generate multiple concurrent streams like RGB+IR video and embedded metadata alongside image data. Supporting these sensors in Linux introduces new challenges for the V4L2 and media controller subsystem, particularly around per-stream configuration and stream identification.\n \n This talk presents two practical use cases for enabling multi-stream cameras in Linux. First, RGB+IR sensor support through V4L2 control framework extensions using array-based controls, enabling independent per-stream configuration while preserving a unified sensor model. Second, sensors transmitting embedded metadata, leveraging RAW sensor model proposed by Sakari Ailus, internal pads for metadata propagation, and data-type filtering in V4L2 bridge drivers to separate and route metadata and image streams.\n \n Ref (lkml) : [PATCH v11 00/66] Generic line based metadata support, internal pads\n \n These concepts are demonstrated through POC implementations on TI AM62A platform using OV2312 and IMX219 sensors, with integration into GStreamer and libcamera.\n \n Attendees will gain practical insight into Linux multi-stream camera sensor implementation\n\n[Open in Sched](https://osselceu2026.sched.com/event/0e72f336752a403f27b7903879d8010b)", "url": "https://osselceu2026.sched.com/event/0e72f336752a403f27b7903879d8010b", "persons": [{"public_name": "Rishikesh Donadkar"}, {"public_name": "Devarsh Thakkar"}]}, {"guid": "oss-e287ffead7ccd9fd53df7df82e2de4a4", "id": "oss-e287ffead7ccd9fd53df7df82e2de4a4", "title": "Multi-Display Pipelines on Allwinner: Upstream Kernel DRM To Mesa3D", "date": "2026-10-08T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most Allwinner based products still runs on vendor BSP kernels with out-of-tree display drivers. But with recent upstream Linux Kernel improvements, its now possible to simultaneously drive multiple display panels over different interfaces like LVDS and MIPI, using mainline DRM subsystem on Allwinner A133 and A523 SoCs.\n \n In this talk, I will share my experience bringing up a multi-display setup with 2 x LVDS and 1 x MIPI panels on Allwinner A133 using upstream kernel [1] and [2]. We will go through how the Allwinner display engine works, what the device tree topology looks like when you have multiple active display pipelines, and what DRM/KMS changes matters to get this working correctly.\n \n We will also look at the userspace side - how a compositor like Weston handles multi-display and the limitations you hit in practice. I will cover some of the real problems I hit during bringup, not just the happy path.\n \n [1]: https://lore.kernel.org/linux-sunxi/a5f6aeb1-b038-462e-8989-c4da65966134@linumiz.com/\n [2]: https://lore.kernel.org/linux-sunxi/02b20361-23cf-4aa7-8f85-875261e6cdc9@linumiz.com/\n\n[Open in Sched](https://osselceu2026.sched.com/event/e287ffead7ccd9fd53df7df82e2de4a4)", "url": "https://osselceu2026.sched.com/event/e287ffead7ccd9fd53df7df82e2de4a4", "persons": [{"public_name": "Parthiban N"}]}, {"guid": "oss-ccd87b86489a6c67f7d6e642eca41346", "id": "oss-ccd87b86489a6c67f7d6e642eca41346", "title": "Evolving Video4Linux2 To Support Modern Camera Use Cases", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern camera use cases are realized by complex pipelines of several IPs blocks that process frames produced by an image sensor to deliver great looking images to applications. Support for the most advanced use cases is implemented by time-multiplexing the underlying hardware resources, performing job scheduling at the hardware/firmware level and orchestrating the image processing steps across multiple drivers and IPs. The Video4Linux2 kernel subsystem currently doesn't provide any abstraction for drivers and applications to fully support modern designs and vendors that intend to make use of the capabilities of their hardware had so far worked around this limitations by implementing downstream solutions. This talk describes the most recent and the forthcoming developments in the Video4Linux2 kernel framework to support modern camera use cases, including but not limited to multi-driver pipelines, multi-context time multiplexing of hardware resources and job scheduling, with practical examples from the field on recent SoC designs.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ccd87b86489a6c67f7d6e642eca41346)", "url": "https://osselceu2026.sched.com/event/ccd87b86489a6c67f7d6e642eca41346", "persons": [{"public_name": "Jacopo Mondi"}]}, {"guid": "oss-a4688e0f5e5c9b7ed31ac030b0c278fc", "id": "oss-a4688e0f5e5c9b7ed31ac030b0c278fc", "title": "FOSS Camera Support for the Qualcomm OPE ISP", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Until recently camera software stacks have mainly been a proprietary closed source affair. Thanks to the linux-media and libcamera communities this has been slowly changing. We are happy to present the first Free and Open Source Software stack for a Qualcomm camera hardware ISP, the Offline Processing Engine found on the QRB2210 (Agatti) SoC used on the Arduino UNO Q SBC. Using a standard mainline V4L2 ISP kernel driver together with libcamera. This talk will cover the following topics: * Overview of the Qualcomm camera subsystem architecture * Mainline V4L2 ISP kernel driver for the Agatti OPE block * CAMSS libcamera pipeline-handler and camss IPA for OPE * Image processing steps supported by the presented FOSS stack * Future plans for more image processing steps * Future plans for supporting the ISP on other Qualcomm SoCs\n\n[Open in Sched](https://osselceu2026.sched.com/event/a4688e0f5e5c9b7ed31ac030b0c278fc)", "url": "https://osselceu2026.sched.com/event/a4688e0f5e5c9b7ed31ac030b0c278fc", "persons": [{"public_name": "Hans de Goede"}, {"public_name": "Loic Poulain"}]}, {"guid": "oss-486268246a5074e540f387ed8e951227", "id": "oss-486268246a5074e540f387ed8e951227", "title": "Cursed Camera Connectors", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "An exploration into the complexities of physically connecting cameras to your embedded development board, and configuring them through device tree, and hopefully how we can make it easier in the future! Small board computers are now prolific with their ability to connect RAW MIPI cameras directly to the board, and now that libcamera provides an open camera stack, connecting cameras to all your favourite boards should be easy. But it's not. The connectors might have 15, 22 or 30 pins. The functions of each pin differ between boards. There's TypeA and TypeB cables.... And they better not be too long! The lack of standardisation means it can still be difficult to connect your camera, and the combinatorial explosion of potential device tree overlays will soon become unmaintainable. Lets look at suggestions that have been around for a decade already, and where that work is now leading to make connecting cameras easier!\n\n[Open in Sched](https://osselceu2026.sched.com/event/486268246a5074e540f387ed8e951227)", "url": "https://osselceu2026.sched.com/event/486268246a5074e540f387ed8e951227", "persons": [{"public_name": "Kieran Bingham"}]}, {"guid": "oss-31527a1b46bd5d989996e8ccb33fbd2f", "id": "oss-31527a1b46bd5d989996e8ccb33fbd2f", "title": "From Power Sequences To Zink: Mainlining Hardware Accelerated 3D for RISC-V", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "RISC-V is evolving into a capable desktop replacement, driven by boards like the Lichee Pi 4A, but a major barrier remains: the lack of a fully open, upstream graphics stack. This talk explores enabling hardware accelerated graphics on modern RISC-V SoCs by extending the open source Imagination PowerVR driver for the TH1520. We dive into the architectural challenges of this port, including the complex power sequencing that necessitated the new pwrseq-thead-gpu driver. We break down how the kernel DRM driver interacts with the Mesa PVR Vulkan driver, and how leveraging the Zink translation layer finally brings standard OpenGL desktop acceleration to the platform. Finally, we cover the current mainline status and next steps for the StarFive JH7110 display controller integration. Key Takeaways / What Attendees Will Learn: - Porting the open PowerVR driver to the RISC-V TH1520 SoC. - Implementing kernel power sequencing (pwrseq) for complex GPU domains. - Interacting between DRM, Mesa Vulkan, and Zink for desktop GL support. - Current mainline status of the JH7110 Display Controller. https://mwilczynski.dev/posts/riscv-gpu-zink/\n\n[Open in Sched](https://osselceu2026.sched.com/event/31527a1b46bd5d989996e8ccb33fbd2f)", "url": "https://osselceu2026.sched.com/event/31527a1b46bd5d989996e8ccb33fbd2f", "persons": [{"public_name": "Michał Wilczyński"}]}, {"guid": "oss-07a7438c9f423f6a37d22bb481e4ffa5", "id": "oss-07a7438c9f423f6a37d22bb481e4ffa5", "title": "WPE Hands-On: Writing a Launcher for Embedded Devices With the New WPEPlatform API", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "WPE WebKit is the WebKit port for Linux-based embedded devices, powering Web-based user interfaces on platforms such as set-top boxes, smart appliances, and industrial systems. With the 2.54 release, a stable version of the new WPEPlatform API is now available, radically simplifying how the Web engine is embedded: thanks to built-in support for Wayland, DRM/KMS, and headless rendering, libwpe and external backends are no longer needed unless you target a different platform. Zero-copy buffer sharing via DMA-BUF is also available for efficient video and graphics pipelines on modern Linux kernels and supported platforms. After a quick introduction to WPE WebKit, the session will demonstrate the new API in practice, showing how simple it has become to write a custom launcher to run Web-based applications on embedded devices. It will also offer practical guidance for migrating existing integrations to WPEPlatform, whether they are based on Cog or built directly on the legacy API. Whether you are evaluating WPE for the first time or maintain devices already shipping it and wonder what it means for you, this talk will help you get started with the next generation of the WPE public API.\n\n[Open in Sched](https://osselceu2026.sched.com/event/07a7438c9f423f6a37d22bb481e4ffa5)", "url": "https://osselceu2026.sched.com/event/07a7438c9f423f6a37d22bb481e4ffa5", "persons": [{"public_name": "Mario Sanchez-Prada"}]}, {"guid": "oss-4d20ed55d33d73251295e8971fb090e1", "id": "oss-4d20ed55d33d73251295e8971fb090e1", "title": "State of Embedded Linux", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This talk offers a comprehensive look at what's changed in the embedded Linux world over the past year. Walt will walk through the latest kernel developments most relevant to embedded developers, survey key userspace projects shaping modern embedded designs, and cover the broader community, industry, and legal landscape — from the status of major processor architectures to initiatives at the Linux Foundation and beyond. Whether you're tracking changes to subsystems you already rely on or looking for new tools and techniques to improve your workflow, this session will help you stay current in a fast-moving ecosystem. Come find out what's new, what's shifting, and what it means for your embedded Linux work.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4d20ed55d33d73251295e8971fb090e1)", "url": "https://osselceu2026.sched.com/event/4d20ed55d33d73251295e8971fb090e1", "persons": [{"public_name": "Walt Miner"}]}], "South Hall 3 C (Floor 3)": [{"guid": "oss-a6e45dbb7ca498270ac3642ab4deab38", "id": "oss-a6e45dbb7ca498270ac3642ab4deab38", "title": "Fast, Safe, and Asleep: Bringing Runtime PM To Modern IOMMUs", "date": "2026-10-08T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern IOMMUs are deployed across wildly different environments. In enterprise servers, they require massive scalability, heavy virtualization support, and a zero-tolerance policy for lock contention. On the other hand, as these high-performance IOMMUs increasingly find their way into mobile, automotive, and edge SoCs, aggressive dynamic power management becomes mandatory.\n \n Using arm-smmu-v3 as a case study, this talk explores the design challenges in integrating the Linux Runtime Power Management (RPM) framework into high-performance IOMMU drivers. Modern IOMMU drivers operate primarily with in-memory data structures, rely on HW-shared queues and are designed for lockless, concurrent access, often from strictly atomic contexts.\n \n The RPM framework’s reliance on locks fundamentally clashes with this lockless architecture and atomic execution constraints. This session walks through the design choices evaluated while implementing runtime power management for a modern IOMMU driver, without sacrificing its lockless, concurrent, and efficient behavior. \n \n The talk is backed by the arm-smmu-v3 RPM Series upstream: lore.kernel.org/all/20260601215909.3958732-1-praan@google.com/\n\n[Open in Sched](https://osselceu2026.sched.com/event/a6e45dbb7ca498270ac3642ab4deab38)", "url": "https://osselceu2026.sched.com/event/a6e45dbb7ca498270ac3642ab4deab38", "persons": [{"public_name": "Pranjal Shrivastava"}]}, {"guid": "oss-36a82adb09c0602a8ec1b9527e18141c", "id": "oss-36a82adb09c0602a8ec1b9527e18141c", "title": "A/B Updates in a Secure Boot Environment", "date": "2026-10-08T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In a system with \"secure boot\", you want to lock down most aspects of the system, in particular the bootloader.\n \n On the other hand, implementing A/B updates requires to keep a writable bootloader environment to implement several aspects of A/B updates: adapting the kernel command line to the active partition, counting boot attempts and implementing recovery after deploying a defective update. Without a careful implementation, this could open the door to altering the sequence of boot commands or to introducing unwanted kernel parameters, therefore breaking the security of the bootloader and the rest of the system.\n \n Both secure boot and A/B updates techniques are well documented, but most often without considering their mutual requirements. In this presentation, I will share solutions I found and used in a recent project. I will also share implementation details with U-Boot and the Yocto Project.\n\n[Open in Sched](https://osselceu2026.sched.com/event/36a82adb09c0602a8ec1b9527e18141c)", "url": "https://osselceu2026.sched.com/event/36a82adb09c0602a8ec1b9527e18141c", "persons": [{"public_name": "Michael Opdenacker"}]}, {"guid": "oss-28179cd32e71cbc9c7c3afbd83a492f2", "id": "oss-28179cd32e71cbc9c7c3afbd83a492f2", "title": "No Reboot Required: Over-the-Air Updates for Immutable Filesystems", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Designing immutable filesystems is becoming the default for embedded Linux development: they're more secure, easier to reason about, and resilient to field drift. But they make a once-easy thing surprisingly awkward: a one-line fix to a single script means shipping a whole new rootfs and rebooting the device.\n systemd-sysext addresses half this problem by merging extension images onto /usr/ at runtime, with integrity enforced via dm-verity. But sysext is the activation mechanism only — it says nothing about how those signed images reach a fleet of devices in the first place.\n This talk walks through a working proof-of-concept that closes the gap: a verity-signed sysext image, delivered over the air through a standard OTA framework, merged live onto a read-only Ubuntu rootfs, with health checks and automatic rollback on failure — all without a single reboot.\n This talk covers the architecture end to end, the non-obvious operational gotchas, and an honest accounting of what this approach does and doesn't replace.\n\n[Open in Sched](https://osselceu2026.sched.com/event/28179cd32e71cbc9c7c3afbd83a492f2)", "url": "https://osselceu2026.sched.com/event/28179cd32e71cbc9c7c3afbd83a492f2", "persons": [{"public_name": "Jana Perić"}]}, {"guid": "oss-5a542e327526ce07565bc837874521f3", "id": "oss-5a542e327526ce07565bc837874521f3", "title": "Navigating the Complexity of Modern SoC Bootflows", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The last decade has shown a clear trend in dramatically increasing the boot process of modern SoC. If the i.MX6 bootflow reads like a short novel, the i.MX95 or TI K3 bootflow is a whole encyclopedia. Today's heterogeneous SoCs combine CPUs of different types — Cortex-R/M cores alongside the application-class Cortex-A — and boot now begins on one of the smaller cores before handing control over to the Cortex-A. There are good reasons for this, such as meeting functional-safety requirements, but it is also a real burden for system designers who simply want to run Linux on the Cortex-A cores and make use of the GPU or VPU. Each new component needs its own firmware: ideally built from open source, though closed-source pieces remain in the chain. The result is no shortage of cryptic acronyms — TF-A, FF-A, TEE, SCMI, PSCI, SCP, FIP. This talk sheds some light into the dark. It explains what each of these components actually does and how they fit together. Attendees will leave able to map this general picture onto their own SoC, see which parts are open source and which are not, and know where to look when the bootflow misbehaves.\n\n[Open in Sched](https://osselceu2026.sched.com/event/5a542e327526ce07565bc837874521f3)", "url": "https://osselceu2026.sched.com/event/5a542e327526ce07565bc837874521f3", "persons": [{"public_name": "Marco Felsch"}]}, {"guid": "oss-deb876bf5a810b378079c4e96e88cfb6", "id": "oss-deb876bf5a810b378079c4e96e88cfb6", "title": "10 Years of Bootable Containers in Production", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "While bootc has been gaining a lot of momentum over the last few years, we had been using a similar technology in production for over a decade. This timeline has given us long enough to go through the whole life-cycle of thousands of devices: initial provisioning, operating, delivering updates, and decommissioning. Though our system is based on Yocto and Moby and specifically tailored for over 100 different (mostly edge/embedded) device types, it shares the same core principle of modern bootable container architecture: shipping the OS as a container image and configuring the init system to boot directly into it. During the session, you will learn: * How to boot into a containerized rootfs. * How to manage state, persistent data, and OS updates via container registries over unstable networks. * Lessons learned from 10 years of using bootable containers on 100+ different edge hardware types. Prerequisites: Attendees should have a general understanding of OCI containers, Dockerfiles, and container registries.\n\n[Open in Sched](https://osselceu2026.sched.com/event/deb876bf5a810b378079c4e96e88cfb6)", "url": "https://osselceu2026.sched.com/event/deb876bf5a810b378079c4e96e88cfb6", "persons": [{"public_name": "Michal Toman"}]}, {"guid": "oss-8c44137e7a3ef684558b63e499eddc48", "id": "oss-8c44137e7a3ef684558b63e499eddc48", "title": "Rsinit -- A Tiny Initramfs Toolbox for Embedded Systems", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:20", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Traditionally, embedded systems were simple enough that an initramfs was not needed at all. This has changed in the last recent years with new requirements, often related to verified boot. That means that additional steps are now needed before the rootfs can be mounted. Existing solutions, such as the Yocto initramfs-framework have significant drawbacks. The resulting initramfs is quite big (multiple megabytes) which has a noticeable impact on the boot time. And while the shell scripts make it easy to customize, robust error handling is difficult. In this talk, Michael will introduce rsinit (https://github.com/pengutronix/rsinit), a single-binary-initramfs for embedded systems, written entirely in Rust. It is tiny (less than 200 KiB), very fast and \"just works\" for simple use-cases. Alternatively, it can be uses as a library crate to build a fully custom binary. Beyond being small, it brings the full power of Rust to the initramfs, which allows building additional features (such as splash screens or read-ahead) without pulling in further dependencies. Michael will present the existing features, explain the design choices and give an overview of what is planed for the future.\n\n[Open in Sched](https://osselceu2026.sched.com/event/8c44137e7a3ef684558b63e499eddc48)", "url": "https://osselceu2026.sched.com/event/8c44137e7a3ef684558b63e499eddc48", "persons": [{"public_name": "Michael Olbrich"}]}, {"guid": "oss-f782ee5be360e4da4e23d2a097527f2a", "id": "oss-f782ee5be360e4da4e23d2a097527f2a", "title": "LibreCar: Android Auto on Mobile Linux", "date": "2026-10-08T15:00:00+02:00", "start": "15:00", "duration": "00:20", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Android Auto requires Google's device integrity checks before it will connect to a car head unit, which by design locks the protocol to stock Android. Mainline mobile Linux phones have no path to car integration as a result. LibreCar is an open-source implementation of the Android Auto protocol for the phone side. It lets any mainline Linux phone connect to a head unit wirelessly over Bluetooth and Wi-Fi, or wired over USB, without depending on Android or Google. . This talk walks through what it takes to open a session with a head unit, how to compose and stream the video output it expects, and how to read touch input back from the interface.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f782ee5be360e4da4e23d2a097527f2a)", "url": "https://osselceu2026.sched.com/event/f782ee5be360e4da4e23d2a097527f2a", "persons": [{"public_name": "Petr Hodina"}]}, {"guid": "oss-d61ffe1eceb5c19aa9eb0c4efdcdd262", "id": "oss-d61ffe1eceb5c19aa9eb0c4efdcdd262", "title": "Journey of a Massive Internal Kernel Rework", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "While changes to the internal kernel APIs and design are possible, that doesn't mean they are easy.\n \n In preparation for a larger work to make the DRM subsystem support video output pipelines with hot-pluggable components, we have been working for the past two years to change the lifetime of `struct drm_bridge` in the DRM subsystem. This required changing the semantics of a dozen internal APIs and adaptations to more than 50 drivers.\n \n This talk is not about the content of the changes but rather about the process to achieve it: the initial steps to find the best strategy, the continuation to convert all APIs, bugs introduced and reacting to them, working on lots of drivers without the chance to test them, dead ends encountered, tools used, the time required for the whole process, and the community interactions in the whole time span.\n \n The focus will be on lessons learnt and which strategies worked better, and ultimately how to make a similar kind of massive conversion in the most efficient (and least frustrating!) way.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d61ffe1eceb5c19aa9eb0c4efdcdd262)", "url": "https://osselceu2026.sched.com/event/d61ffe1eceb5c19aa9eb0c4efdcdd262", "persons": [{"public_name": "Luca Ceresoli"}]}, {"guid": "oss-44baa92013710411fea03834a328b944", "id": "oss-44baa92013710411fea03834a328b944", "title": "BoF: Bring Linux DRM Display Panel Support in the Modern Age", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS BoF", "language": "en", "abstract": "", "description": "Since the introduction of the first Samsung DSI panel, the Linux DRM panel API became an important piece of software used to enable displays across very different hardware architectures. However, the panel support API hasn't evolved much since then.\n \n Currently, the API is showing its age alongside modern graphics stacks. It doesn't support the atomic DRM API and lacks the ability to adapt the power setup while changing DRM modes. Furthermore, it doesn't support the advanced features that new Display Driver ICs (DDIC) heavily rely on, such as standby and advanced power states, advanced color management, dynamic rate switching, command mode self-refresh and more.\n \n Neil will present you the history of the panel API from its origins, outline its current architectural limitations, and lead this BoF to discuss how to bring Linux DRM Display Panel support into the modern age. This open discussion will focus on how to collaboratively solve all those missing features to support modern devices and close the widening gap with downstream vendor support.\n\n[Open in Sched](https://osselceu2026.sched.com/event/44baa92013710411fea03834a328b944)", "url": "https://osselceu2026.sched.com/event/44baa92013710411fea03834a328b944", "persons": [{"public_name": "Neil Armstrong"}]}], "South Hall Foyer 1 (Floor 1)": [{"guid": "oss-13a4a1632b1757f2e1af91fa27e9ffd7", "id": "oss-13a4a1632b1757f2e1af91fa27e9ffd7", "title": "PX4 Community Hub", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "South Hall Foyer 1 (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/13a4a1632b1757f2e1af91fa27e9ffd7)", "url": "https://osselceu2026.sched.com/event/13a4a1632b1757f2e1af91fa27e9ffd7", "persons": []}], "South Hall Foyer 2 (Floor 2)": [{"guid": "oss-3fd6750834e3626cd6a1defaa185a521", "id": "oss-3fd6750834e3626cd6a1defaa185a521", "title": "Zephyr Community Hub", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "10:20", "room": "South Hall Foyer 2 (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3fd6750834e3626cd6a1defaa185a521)", "url": "https://osselceu2026.sched.com/event/3fd6750834e3626cd6a1defaa185a521", "persons": []}], "Terrace 2 A (Floor 2)": [{"guid": "oss-c5b51fed66430fae4bbe808913331241", "id": "oss-c5b51fed66430fae4bbe808913331241", "title": "K8s Dungeon Crawl: Learning Kubernetes Controllers and Webhooks Through a Roguelike Project", "date": "2026-10-08T10:50:00+02:00", "start": "10:50", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In this session, we’ll explore Kubernetes controllers, CRDs, and admission webhooks using K8s Dungeon Crawl: a modified roguelike game where in-game monsters are represented by live Kubernetes resources running in the cluster. As gameplay unfolds, the Kubernetes control plane becomes part of the game itself. Monsters are represented as Kubernetes Deployments, dungeon entities are modeled as CRDs, and admission webhooks dynamically mutate and validate cluster behavior as gameplay progresses. Using KubeBuilder, we’ll walk through how controllers and webhooks interact with the Kubernetes API while demonstrating reconciliation loops, admission control, CRDs, declarative state management, runtime policy enforcement, and event-driven Kubernetes behavior. The session demonstrates controllers reconciling game and cluster state, mutating and validating admission webhooks, GitOps deployment using Helm and Argo CD, and observability with Prometheus and Grafana. Rather than treating Kubernetes concepts as abstract control-plane mechanics, this session turns them into visible gameplay interactions that make Kubernetes behavior easier to understand and reason about.\n\n[Open in Sched](https://osselceu2026.sched.com/event/c5b51fed66430fae4bbe808913331241)", "url": "https://osselceu2026.sched.com/event/c5b51fed66430fae4bbe808913331241", "persons": [{"public_name": "Kim Schaefer"}]}, {"guid": "oss-e1124812305654d76fdd61baef5e673e", "id": "oss-e1124812305654d76fdd61baef5e673e", "title": "Hardening Your Software Supply Chain, Pin Your Actions and Patch Your Dependencies", "date": "2026-10-08T11:40:00+02:00", "start": "11:40", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "2026 has been a big year for supply chain attacks. Shai-Hulud, TeamPCP and others are determined to weaponise open source to hack our communities. \n \nIn this talk I'll show you tools and techniques you can use to defend your projects against them, and common pitfalls\n\n[Open in Sched](https://osselceu2026.sched.com/event/e1124812305654d76fdd61baef5e673e)", "url": "https://osselceu2026.sched.com/event/e1124812305654d76fdd61baef5e673e", "persons": [{"public_name": "Richard Tweed"}]}, {"guid": "oss-d8123afcaba10651301269a5a1932326", "id": "oss-d8123afcaba10651301269a5a1932326", "title": "Observability Signals Outages Before They Happen: Lessons from MySQL", "date": "2026-10-08T13:50:00+02:00", "start": "13:50", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most MySQL incidents don't start with downtime, they start with small changes that go unnoticed for weeks or months.\n \n This session focuses on operational trend analysis rather than real-time monitoring. We'll explore how growing full table scans, rising temporary table usage, lock contention, redo log pressure, buffer pool inefficiencies, and index bloat can reveal future performance and stability issues long before users are affected.\n \n Through practical examples, attendees will learn how to identify meaningful signals, separate noise from actionable insights, and build lightweight monitoring approaches that provide long-term visibility into database health.\n \n Whether you're a DBA, SRE, platform engineer, or developer responsible for production systems, you'll leave with a practical framework for understanding MySQL health over time.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d8123afcaba10651301269a5a1932326)", "url": "https://osselceu2026.sched.com/event/d8123afcaba10651301269a5a1932326", "persons": [{"public_name": "Igor Donchovski"}]}, {"guid": "oss-d9d2a343c3fe19879118d37f9851eeda", "id": "oss-d9d2a343c3fe19879118d37f9851eeda", "title": "Ship Less: Scoping Open Source Contributions That Actually Merge", "date": "2026-10-08T14:40:00+02:00", "start": "14:40", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most first contributions fail before the code does. They try to solve too much, touch too many files, and stall in review while the maintainer waits for a smaller entry point that never comes. Adding HTTPS support to proxy-chain, a Node.js proxy library used across the web-scraping ecosystem, taught me this the hard way. My first attempt was comprehensive: tunnel support, byte accounting, certificate handling, the works. It went nowhere. What merged was a version that did one thing and stopped. We'll use that contribution as a case study in scoping. The technical context matters, because it's a great example of hidden complexity: TLS changes proxy semantics in ways that aren't obvious until you're counting bytes and realising the handshake traffic your code never sees is inflating every number. But the talk is really about the decisions behind the code - how to identify what \"done\" looks like before you start, how to read a maintainer's priorities from their issue tracker, and how to negotiate a PR boundary that gets merged rather than praised and ignored. You'll leave with a framework for scoping contributions that ship, and a clearer sense of when doing less is the right call.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d9d2a343c3fe19879118d37f9851eeda)", "url": "https://osselceu2026.sched.com/event/d9d2a343c3fe19879118d37f9851eeda", "persons": [{"public_name": "Yurii Bliuchak"}]}, {"guid": "oss-88311676d1637d03b91a722f6488e5ce", "id": "oss-88311676d1637d03b91a722f6488e5ce", "title": "Ask for Help Like a Pro!", "date": "2026-10-08T15:50:00+02:00", "start": "15:50", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open source communities are like a busy marketplace from some fantasy book. They are crowded, full of magic, and have all kinds of information. You will meet there many different characters: the wizards who saw everything twice and have every answer; the newbies who just landed and are completely lost; or the jumpy folks looking desperately for some quick fix for their production issue. It can be an intimidating place and it can be hard to find the right answers. This talk will try to help you navigate it. What are the differences between commercial support and community help? How do you find the right channel for your questions? What are the things you should always include when asking for help with some problem? How to deal with confidential data in your logs or configurations? This talk will try to answer all these questions and more. It will help you to ask for help like a pro and get the best answers quickly to get your systems up and running as soon as possible.\n\n[Open in Sched](https://osselceu2026.sched.com/event/88311676d1637d03b91a722f6488e5ce)", "url": "https://osselceu2026.sched.com/event/88311676d1637d03b91a722f6488e5ce", "persons": [{"public_name": "Jakub Scholz"}]}, {"guid": "oss-83ad0b28e09014ddd4615fe5203837f1", "id": "oss-83ad0b28e09014ddd4615fe5203837f1", "title": "How One Open Source Program Changed the Direction of My Career", "date": "2026-10-08T16:40:00+02:00", "start": "16:40", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In 2018, I applied to an open source program with no expectations. I wasn't from a well-known college. I didn't have a strong professional network. Like many students, I was simply looking for a way to learn, gain experience, and figure out where my career was headed. That single application led to opportunities I could never have predicted. Over the next few years, open source introduced me to mentors, global communities, speaking opportunities, internships, scholarships, leadership roles, and eventually a full-time career in technology. More importantly, it changed how I viewed learning, collaboration, and my own potential. This session is a personal story about how one open source opportunity created a ripple effect that shaped an entire career. Along the way, I'll share the practical lessons I learned about contributing to projects, building relationships within communities, overcoming self-doubt, and creating opportunities that don't exist in traditional classrooms. Whether you're a student, an aspiring contributor, this talk offers a realistic look at how community-driven programs can create life-changing opportunities.\n\n[Open in Sched](https://osselceu2026.sched.com/event/83ad0b28e09014ddd4615fe5203837f1)", "url": "https://osselceu2026.sched.com/event/83ad0b28e09014ddd4615fe5203837f1", "persons": [{"public_name": "Saumya Singh"}]}], "Terrace 2 B (Floor 2)": [{"guid": "oss-434e418d0fc7a846851521791b85ebce", "id": "oss-434e418d0fc7a846851521791b85ebce", "title": "Hacker Space", "date": "2026-10-08T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Terrace 2 B (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Discover a space, where you can collaborate, create, and explore new ideas with fellow attendees. Whether you’re here to learn or build, our space is open for everyone to enjoy throughout the conference!\n\n[Open in Sched](https://osselceu2026.sched.com/event/434e418d0fc7a846851521791b85ebce)", "url": "https://osselceu2026.sched.com/event/434e418d0fc7a846851521791b85ebce", "persons": []}]}}, {"index": 5, "date": "2026-10-09", "rooms": {"Chamber Hall (Floor 3)": [{"guid": "oss-69e8c5c5007f65111d09b628842e99ff", "id": "oss-69e8c5c5007f65111d09b628842e99ff", "title": "Patching Is Only Half of the Problem: How OSERA Helps Financial Institutions Grow the OSS Supply Chain Resiliency (and Create Opportunities for Maintainers)- Gabriele Columbro, FINOS & Francesco Beltramini, ControlPlane", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Chamber Hall (Floor 3)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/69e8c5c5007f65111d09b628842e99ff)", "url": "https://osselceu2026.sched.com/event/69e8c5c5007f65111d09b628842e99ff", "persons": []}, {"guid": "oss-a9b2c7d36da59f13115fffeff3821413", "id": "oss-a9b2c7d36da59f13115fffeff3821413", "title": "Workshop: Operationalizing the Cyber Resilience Act (Boxed Lunch Included)", "date": "2026-10-09T12:45:00+02:00", "start": "12:45", "duration": "01:15", "room": "Chamber Hall (Floor 3)", "track": "OSS: Workshop", "type": "OSS Workshop", "language": "en", "abstract": "", "description": "As of Sept 11, 2026, the EU CRA mandates short-window reporting for actively exploited vulnerabilities to ENISA. Yet, Linux Foundation research shows 66% of the ecosystem remains unprepared. Hosted by the OpenSSF Global Cyber Policy WG, this 75-minute interactive workshop shifts the conversation from abstract legal theory to operational realities many of us are currently facing.Following a 10-minute briefing, small groups will stress-test real-world CRA challenges in a community-feedback-inspired session that unites enterprise engineers, security officers, stewards, open source developers. Topics include: governance, open source particularities and CRA personas across varying PDE classifications, secure-by-design mandates, risk assessments, due diligence, SBOMs, vulnerability management and reporting obligations. We conclude with a synthesis of mapping live insights directly to the OpenSSF roadmap and our work group activities for the upcoming quarters.Come to CRA it and lunch together! Whether you are an enterprise architect trying to keep your product compliant, a steward, or an upstream developer, this workshop offers to tackle your specific use cases.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a9b2c7d36da59f13115fffeff3821413)", "url": "https://osselceu2026.sched.com/event/a9b2c7d36da59f13115fffeff3821413", "persons": [{"public_name": "Dan Appelquist"}, {"public_name": "Roman Zhukov"}, {"public_name": "Madalin Neag"}, {"public_name": "Megan Knight"}]}, {"guid": "oss-e0b2c971386c6d9b786bf18eab260a30", "id": "oss-e0b2c971386c6d9b786bf18eab260a30", "title": "Workshop: Linux Containers In (Less Than) 100 Lines of Shell", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "01:30", "room": "Chamber Hall (Floor 3)", "track": "OSS: Linux", "type": "OSS Workshop", "language": "en", "abstract": "", "description": "Using just shell commands, can we create a \"decent\" container–something like the degree of isolation provided by a Docker or Podman container? If we work at it, we can come reasonably close. Furthermore, we can do so using less than 100 lines of shell commands. Along the way we can learn quite a bit about the nature of a container and the Linux kernel mechanisms used to implement containers. In this session, we'll see how to use a few standard shell commands, plus the ever useful Busybox tool, to create a simple container. That container will have a root filesystem, employ Linux namespaces to provide isolation, and have an associated control group (cgroup) that allows us to limit the resources that the processes in the container can consume. Our container will have a superuser, and we’ll consider what it means to be superuser inside a container while at the same time being unprivileged outside the container.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e0b2c971386c6d9b786bf18eab260a30)", "url": "https://osselceu2026.sched.com/event/e0b2c971386c6d9b786bf18eab260a30", "persons": [{"public_name": "Michael Kerrisk"}]}], "Club A (Floor 1)": [{"guid": "oss-d5bbb81f57c92356e793ffc775d54d7e", "id": "oss-d5bbb81f57c92356e793ffc775d54d7e", "title": "Safety Critical Software BoF", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Interest in safety critical open source software is high, yet opportunities to connect and openly discuss challenges remain limited. This BoF creates a focused forum for practitioners and newcomers to exchange experiences, ask questions, and gain visibility into existing projects and initiatives.\n \n It also highlights the role of initiatives such as the Linux Foundation ELISA project as a central interface within the ecosystem, helping to connect efforts across communities, share practices, and make ongoing work more discoverable. The project brings together horizontal working groups covering features, processes, architecture, and tooling, while also addressing vertical domains such as automotive, aerospace, space, railways, and medical. This reflects the growing relevance of Linux and open source in safety critical systems.\n \n By enabling direct interaction and cross project exchange, the session supports alignment, reduces duplication, and fosters collaboration in an evolving safety critical OSS landscape. \n \n Participants at all levels of experience are encouraged to join, contribute their perspective, and engage with the community.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d5bbb81f57c92356e793ffc775d54d7e)", "url": "https://osselceu2026.sched.com/event/d5bbb81f57c92356e793ffc775d54d7e", "persons": [{"public_name": "Philipp Ahmann"}, {"public_name": "Olivier Charrier"}]}, {"guid": "oss-a64d5f2f9ed69332ba7956a5c7e1ee77", "id": "oss-a64d5f2f9ed69332ba7956a5c7e1ee77", "title": "A Safety BOM Is a Contract: Producing and Consuming the SPDX Functional Safety Profile", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "SPDX 3.1's Functional Safety profile recently grew to model a safety case end to end: requirements and their refinement, verification, pass/fail evaluations, evidence, and assumptions of use. It standardizes how a safety case is exchanged, but not how one is produced, nor what a consumer does with one received. We demonstrate SEGkit, a prototype, open-source, project-agnostic engine that extracts a design and evidence graph from content repositories to recompute a verdict over the graph—a judgment recomputed from content, not merely recorded—and detects which evidence goes stale as code evolves; in this talk we also show how we plan to use it within Zephyr to automate safety evidence creation. This makes SEGkit interesting to projects maintaining their safety BOM as well as downstream users who want to work with one. For the latter case we argue a received BOM is best consumed as a contract—its requirements and evidence being guarantees and its assumptions the conditions the consumer must discharge against its own case. Lastly, we talk about what the profile might add for machine-checkable discharge: assumptions as checkable conditions, linked to the guarantees they constrain.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a64d5f2f9ed69332ba7956a5c7e1ee77)", "url": "https://osselceu2026.sched.com/event/a64d5f2f9ed69332ba7956a5c7e1ee77", "persons": [{"public_name": "Tobias Kästner"}, {"public_name": "Nicole Pappler"}]}, {"guid": "oss-02c62448cae565b6040ec07f87366bb5", "id": "oss-02c62448cae565b6040ec07f87366bb5", "title": "Let's Perform a Hazard Assessment!", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "A hazard assessment is “a process that allows the identification and evaluation of potential hazards related to [...] system function regardless of the details of its implementation” (SAE ARP4761A, section C.1). The outcome of a hazard assessment has far-reaching consequences for overall project design and the degree of engineering rigor required during development. In this session, Chuck will take the audience through a hazard assessment exercise based on a simplified model and describe the effects of the assessment on the design and development process. In addition to exposing the audience to a relatively simple but rigorous method for thinking about failure conditions during design, Chuck will also touch on gaps in non-safety-critical software engineering that can benefit from best practices developed by the safety engineering community.\n\n[Open in Sched](https://osselceu2026.sched.com/event/02c62448cae565b6040ec07f87366bb5)", "url": "https://osselceu2026.sched.com/event/02c62448cae565b6040ec07f87366bb5", "persons": [{"public_name": "Chuck Wolber"}, {"public_name": "Pete Brink"}]}, {"guid": "oss-3ea6c493323e89aa447f2dbb0dc2e759", "id": "oss-3ea6c493323e89aa447f2dbb0dc2e759", "title": "Failure Propagation in Linux: Challenges for Safety Qualification", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Linux was not developed around fault-containment properties expected of safety-certifiable software. The linear map lets kernel code access memory across userspace ownership boundaries, so corruption can affect another process or container. Shared slab/page allocators and per-CPU caches compound this risk: corrupted state may remain latent and later affect unrelated subsystems. MMIO can cause external interference when a faulty driver accesses the wrong register or device because of corrupted state or an incorrect Device Tree or ACPI-derived base address. Building on ELISA Linux Features WG (LFSCS) work, we use ks-nav call-tree artifacts to show that even narrow services depend on shared infrastructure across subsystems. Reducing the configuration lowers function count but also usability; restoring functionality introduces transitive dependencies, so assessment cannot be limited to newly enabled code. These findings challenge treating Linux as safe by default or relying on proven-in-use arguments alone. In a monolithic, shared-address-space kernel, fault containment and qualification scope must be demonstrated, not assumed.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3ea6c493323e89aa447f2dbb0dc2e759)", "url": "https://osselceu2026.sched.com/event/3ea6c493323e89aa447f2dbb0dc2e759", "persons": [{"public_name": "Alessandro Carminati"}]}, {"guid": "oss-16cd3d309c1e7ed9b6a5b6bdef9b066c", "id": "oss-16cd3d309c1e7ed9b6a5b6bdef9b066c", "title": "Feasibility of an Open-Source Linux Platform for Autonomous Train Operation", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Autonomous train operation requires a new generation of computing platforms capable of running AI-based perception, sensor fusion, and safety-critical control functions. Traditionally, railway systems have been delivered as tightly integrated proprietary hardware-software stacks, limiting software reuse, innovation, and vendor independence.\n This talk presents the results of the Automated Train research project and explores whether a Linux-based platform can become the foundation for safety-critical rail applications. We examine the technical feasibility of using Linux to support mixed-criticality workloads while meeting stringent railway safety requirements.\n Beyond technology, we discuss a fundamental challenge for open source in regulated industries: how can continuously evolving software be certified in environments governed by legally binding functional safety standards?\n Finally, we explore the governance and business implications of a shared open-source platform for the railway sector. The lessons learned extend far beyond railways and provide a blueprint for applying Linux and open-source collaboration to other safety-critical and sovereign digital infrastructure domains.\n\n[Open in Sched](https://osselceu2026.sched.com/event/16cd3d309c1e7ed9b6a5b6bdef9b066c)", "url": "https://osselceu2026.sched.com/event/16cd3d309c1e7ed9b6a5b6bdef9b066c", "persons": [{"public_name": "Daniel Weingaertner"}, {"public_name": "Sebastian Hetze"}]}, {"guid": "oss-e0109bfc26e44dee4447f7e3ee7ac31a", "id": "oss-e0109bfc26e44dee4447f7e3ee7ac31a", "title": "TLA+ in the Age of AI-Assisted Engineering", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Club A (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Over several decades, TLA+ has been immensely useful for finding safety and liveness issues in concurrent and distributed systems. As developers of Apalache, the symbolic model checker for TLA+, our work with engineers has changed how we think specification tooling should look. Three obstacles to adoption arise repeatedly: (1) the steep learning curve, (2) the gap between formal specs and the code, and (3) scalability issues.This talk reflects on our 10 year journey with TLA+ into the age of AI. We first show how we addressed (1) through a less mathematical syntax and modern developer experience. For (2) and (3), model-based testing and proofs have long been promising, but traditionally required too much expert labor. Frontier AI tooling changes this balance: it lowers onboarding costs, helps generate test drivers, and can automate proof work to a useful degree.At the same time, formal tooling allows us to gate AI-generated code, catching plausible but incorrect implementations. We argue that AI and formal tooling complement each other, making both more practical.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e0109bfc26e44dee4447f7e3ee7ac31a)", "url": "https://osselceu2026.sched.com/event/e0109bfc26e44dee4447f7e3ee7ac31a", "persons": [{"public_name": "Igor Konnov"}, {"public_name": "Thomas Pani"}]}], "Club E (Floor 1)": [{"guid": "oss-3108eb0e96eb09bee5b0ac962f4981a5", "id": "oss-3108eb0e96eb09bee5b0ac962f4981a5", "title": "500,000 Containers, 5 Minutes, 10x Load: Scaling Uber’s Container Registry for Disaster Recovery", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Kraken is Uber's open-source P2P container registry. It serves 23 petabytes of data daily with 99.9% reliability. However, during recovery from a complete regional failure, Kraken was pushed over its historical peak load by 10 times. It had to distribute over 100,000 container images every minute. The registry that \"just worked\" became the bottleneck blocking disaster recovery. Adding capacity proved insufficient. So, the team reworked the caches and tuned download parallelism. But closing such a large performance gap required architectural changes. If downloads are too slow, move the data closer to the client. If you cannot serve everything at once, tier images by criticality. These optimizations eventually broke Uber’s deployment throughput record. This talk presents a case study of evolving Kraken to deliver 10x performance under extreme load - the architectural changes, necessary trade-offs, and hard-won lessons. All optimizations are open-sourced in Kraken.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3108eb0e96eb09bee5b0ac962f4981a5)", "url": "https://osselceu2026.sched.com/event/3108eb0e96eb09bee5b0ac962f4981a5", "persons": [{"public_name": "Sambhav Jain"}, {"public_name": "Anton Kalpakchiev"}]}, {"guid": "oss-d134532b2f7b63e701d81f6e5af2ca92", "id": "oss-d134532b2f7b63e701d81f6e5af2ca92", "title": "From Vulnerability Debt To Autonomous Remediation: Building a Self-Healing Container Image Pipeline", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Managing vulnerabilities across large fleets of container images remains a persistent challenge in cloud-native environments. In our platform, patching a single critical image often required several engineer-days of manual effort, creating remediation backlogs and compliance risk. To address this, we built a self-healing vulnerability remediation pipeline using open source technologies across the container lifecycle. This session presents the architecture behind the system, including automated dependency updates with Dependabot, reproducible image rebuilds with DALEC, continuous OS-level patching using Project Copacetic, and deployment validation through staged rollout pipelines. We will share the engineering decisions, trade-offs, and lessons learned while reducing remediation time from days to minutes and eliminating approximately 90% of manual patching effort. We will also discuss integrating an AI-assisted remediation agent for complex fixes and the safeguards used to validate and govern AI-generated changes in production environments.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d134532b2f7b63e701d81f6e5af2ca92)", "url": "https://osselceu2026.sched.com/event/d134532b2f7b63e701d81f6e5af2ca92", "persons": [{"public_name": "Priyanka Bettadapura"}]}, {"guid": "oss-a0c3b916de70e942c17f3f45386ba86a", "id": "oss-a0c3b916de70e942c17f3f45386ba86a", "title": "The PVC Must Die: How a Workflow Engine Rethought Data Sharing With Trusted Artifacts", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "When a CI/CD pipeline runs each step as a separate Kubernetes Pod, those Pods need a way to pass data to one another. Tekton chose the obvious Kubernetes-native answer: a shared persistent volume. Clone code in step one, build it in step two, both read from the same disk. Simple. It wasn't. Shared volumes meant pinning Pods to the same node, which broke autoscaling. Users hit storage limits, leaked volumes after failures, and spent more time debugging infrastructure than building pipelines. Each fix created new edge cases. Then a different question: what if steps didn't share a disk at all? What if each step uploaded what it produced, and the next downloaded and verified it, with cryptographic hashes at every handoff? That's Trusted Artifacts. The shared volume disappears, and in its place you get a verifiable chain of trust: every handoff is hashed, signed, and traceable. A storage problem became a security feature. This talk traces that journey: the design that seemed right, the years of workarounds, and the moment the team stopped fixing the plumbing and rethought the architecture. It's for anyone who's wondered whether to keep patching a leaky abstraction or tear it out.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a0c3b916de70e942c17f3f45386ba86a)", "url": "https://osselceu2026.sched.com/event/a0c3b916de70e942c17f3f45386ba86a", "persons": [{"public_name": "Vincent Demeester"}]}, {"guid": "oss-e177bdfe24776b6bfd04423af645c1f3", "id": "oss-e177bdfe24776b6bfd04423af645c1f3", "title": "Two Sides of the Same Coin: What Software and Data Research Repositories Can Learn From Each Other", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Research data repositories and software package registries serve different audiences, but they answer the same four questions: \n - who published this and can we trust them\n - has it been tampered with\n - where did it come from\n - how long will it stay available and verifiable? \n \n Both communities have answered them in parallel, different vocabularies, different tooling, little exchange.\n \n This talk maps that exchange both ways, grounded in my work on Djehuty (behind 4TU.ResearchData) and as a maintainer of TUF and in-toto and an OpenSSF Securing Software Repositories contributor.\n \n Data repositories can borrow from software: delegated, verifiable signing (TUF, Sigstore), in-toto provenance for AI training data, and the OpenSSF security-maturity model.\n \n Software registries can borrow from data: FAIR's verifiable provenance, persistent identifiers (DOIs, ORCIDs) for durable SBOMs, OAIS preservation against dependency rot, and pre-publication curation.\n \n It closes on the problem neither has solved: permanence versus incident response revoking trust without deleting an immutable, citable record.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e177bdfe24776b6bfd04423af645c1f3)", "url": "https://osselceu2026.sched.com/event/e177bdfe24776b6bfd04423af645c1f3", "persons": [{"public_name": "Kairo De Araujo"}, {"public_name": "Victoria Poļaka"}]}, {"guid": "oss-06b0a256294bd124bc47fdd4d848b1ad", "id": "oss-06b0a256294bd124bc47fdd4d848b1ad", "title": "How We Stopped Shai Hulud V4: Hunting a Self-Replicating Npm Worm With AI Toolchain Poisoning", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Club E (Floor 1)", "track": "OSS: Packages & Images & Containers", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Shai Hulud worm family has stalked the npm supply chain across multiple variants, stealing credentials from developer and CI environments, propagating via stolen npm and GitHub identities, poisoning workflows, and carrying a dead switch that can wipe home directories on command. Version four just crossed a new line. SANDWORM_MODE, deployed across 19 malicious npm packages, keeps the full prior playbook and adds AI toolchain poisoning via MCP server injection into Claude Code, Claude Desktop, Cursor, and Windsurf. The rogue MCP server uses prompt injection to instruct AI assistants to silently exfiltrate SSH keys, AWS credentials, and LLM API tokens from nine providers, without alerting the user. We present the full story: the Shai Hulud lineage, how the obfuscated three-layer loader was detected, how 19 packages were linked to one operator, how a bidirectional CI worm loop was built from a weaponized GitHub Action, and how coordinated takedown with npm, GitHub, and Cloudflare dismantled the infrastructure, along with what the dormant polymorphic engine tells us about where version five is heading.\n\n[Open in Sched](https://osselceu2026.sched.com/event/06b0a256294bd124bc47fdd4d848b1ad)", "url": "https://osselceu2026.sched.com/event/06b0a256294bd124bc47fdd4d848b1ad", "persons": [{"public_name": "Kush Pandya"}]}], "Club H (Floor 1)": [{"guid": "oss-05c1f2d2174cb5e6a44286725e4a6b9a", "id": "oss-05c1f2d2174cb5e6a44286725e4a6b9a", "title": "Proofs of Personhood: Managing Identity in the Age of AI", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "“On the internet, nobody knows you’re a dog,” the famous New Yorker comic goes, and that aphorism couldn’t ring truer today. In a world of AI agents, how can we be sure that we (or our agents) are interacting with other trusted, reputable systems and agents rather than impersonators or scammers? As open source maintainers, how can we be sure that new contributors are responsible, trustworthy individuals rather than adversarial state actors, helping to thwart compromises like the XZUtils attack? More generally, how do we deal with digital identity in the age of AI?\n \n Our proposal is to use cryptographic proofs of personhood. These can be built from a decentralized, privacy-preserving reputation system, which we can build with tools and standards we have developed in several projects in LFDT. The session will cover some background on how proofs of personhood work, including privacy guarantees from cryptography (at a beginner level). Then, we will explain some applications in agentic AI and open source software maintenance. Finally, we will give an end-to-end demo of how our systems work in practice which will include audience participation in a “verifiable trust graph”.\n\n[Open in Sched](https://osselceu2026.sched.com/event/05c1f2d2174cb5e6a44286725e4a6b9a)", "url": "https://osselceu2026.sched.com/event/05c1f2d2174cb5e6a44286725e4a6b9a", "persons": [{"public_name": "Hart Montgomery"}, {"public_name": "Drummond Reed"}, {"public_name": "Glenn Gore"}]}, {"guid": "oss-9b6b9aee456da4e0c479135c930f1a05", "id": "oss-9b6b9aee456da4e0c479135c930f1a05", "title": "Building Trust in the AI Era: Agent-to-Agent Communication With DIDs and VCs", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "As AI moves from isolated chatbots to autonomous agent ecosystems, the \"identity problem\" becomes a critical security bottleneck. How does an agent verify the legitimacy of a requestor before executing a sensitive task? Traditional API keys are insufficient for dynamic, decentralized agent interactions. This session explores a cutting-edge extension to the Linux Foundation A2A protocol that leverages Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs) to establish high-assurance trust and bridges the gap between Decentralized Identity standards and AI, creating a secure backbone for the next generation of agent interoperability. We will dive into the technical design of integrating OpenID for Verifiable Presentations (OID4VP) into agent communication flows. Attendees will learn how this proposed extension moves beyond static credentials to enable granular, verifiable Authentication (AuthN) and Authorization (AuthZ) for autonomous tasks. Beyond the protocol basics, we will analyze different patterns for VC presentation—comparing interactive vs. automated flows—and evaluate diverse wallet options, ranging from cloud-based agent wallets to secure edge implementations.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9b6b9aee456da4e0c479135c930f1a05)", "url": "https://osselceu2026.sched.com/event/9b6b9aee456da4e0c479135c930f1a05", "persons": [{"public_name": "Alexander Shcherbakov"}]}, {"guid": "oss-b2b49dae329b8024eb98cee0da155d72", "id": "oss-b2b49dae329b8024eb98cee0da155d72", "title": "Why We Fixed It Upstream: A Telco Perspective", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Working in telco infrastructure means regulatory compliance isn't optional. When a CVE drops, we can't wait a quarter. We can't backport locally. We have to fix it upstream, and we have to do it fast. This constraint forced us to ask harder questions about how we collaborate with open source projects.\n \n At Ericsson we maintain bare metal Kubernetes using Metal3, Cluster API, and Ironic. Over the past few years, we've learned that regulatory pressure actually makes us better engineers. It forced us to build real relationships with upstream maintainers, contribute more thoughtfully, and think long term instead of short term.\n \n This talk explores what changed in how we work with upstream projects when we couldn't carry local patches. We'll talk about the specific practices that work when your infrastructure depends on fast, reliable upstream collaboration. You'll hear about what changed in how we communicate with maintainers, how we structure our releases, and what we learned about contributing upstream that applies whether you're bound by regulation or not.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b2b49dae329b8024eb98cee0da155d72)", "url": "https://osselceu2026.sched.com/event/b2b49dae329b8024eb98cee0da155d72", "persons": [{"public_name": "Jan Melen"}]}, {"guid": "oss-41250a91325ac6d70dfc3dd6e61747f2", "id": "oss-41250a91325ac6d70dfc3dd6e61747f2", "title": "State of the OSS Union: Assessing Your Stack’s Autonomy Under EU Law", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open source is the bedrock of European digital sovereignty, but a wave of aggressive new EU legislation is transforming how organizations must build, source, and secure their digital environments. Navigating this shift requires unpacking complex regulatory mandates and understanding their operational impact on modern enterprise and cloud software architecture.\n \n This fast-paced session strips away the legal jargon to deliver a real-time status update on Europe’s changing digital roadmap. We will analyze the mandatory software bill-of-materials (SBOM) rules of the Cyber Resilience Act (CRA) and the open standards driving the Interoperable Europe Act. Crucially, we dive into the European Commission's freshly unveiled Cloud and AI Development Act (CADA) to unpack its cloud sovereignty tiers and its \"open-source first\" procurement principles.\n \n Moving from compliance theory to practical execution, attendees will gain a concrete framework to audit their own production IT stacks. We will walk through the web-based SUSE Cloud Sovereignty Self-Assessment tool to measure true autonomy using weighted SEAL (Sovereignty Effective Assurance Level) metrics.\n\n[Open in Sched](https://osselceu2026.sched.com/event/41250a91325ac6d70dfc3dd6e61747f2)", "url": "https://osselceu2026.sched.com/event/41250a91325ac6d70dfc3dd6e61747f2", "persons": [{"public_name": "Emiel Brok"}]}, {"guid": "oss-360a19084b4a524440649af9fa4a07db", "id": "oss-360a19084b4a524440649af9fa4a07db", "title": "When the LLMs Come Knocking: Surviving AI-Powered Vulnerability Reports", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "Club H (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In early 2026 our vulnerability inbox suddenly exploded. Tekton, the Kubernetes-native CI/CD framework we maintain, received more security reports in four months than in all the previous years combined: detailed, with working reproducers and CVSS scores. Many were genuinely valid. They were also, overwhelmingly, AI-generated. LLM-powered research has changed the game. Tools now audit codebases systematically and surface real bugs humans missed for years: a path traversal reading arbitrary files from the controller pod, an SSRF exfiltrating cloud credentials, a JSON injection enabling RCE. These aren't hallucinations, and they arrive faster than a small team can patch, disclose, and backport. But the flood carries noise too: variants of fixed CVEs, reports that misunderstand the threat model, duplicates. The challenge has shifted from \"find vulnerabilities\" to \"triage an AI-accelerated firehose without your disclosure process collapsing.\" This is an honest, in-progress survival guide from maintainers living through it: how triage holds up under pressure, how we separate signal from noise, what we got right, and what we got wrong.\n\n[Open in Sched](https://osselceu2026.sched.com/event/360a19084b4a524440649af9fa4a07db)", "url": "https://osselceu2026.sched.com/event/360a19084b4a524440649af9fa4a07db", "persons": [{"public_name": "Vincent Demeester"}]}], "Conference Hall (Floor 4)": [{"guid": "oss-81cc92ca0da4490cd006019f1cc25a6c", "id": "oss-81cc92ca0da4490cd006019f1cc25a6c", "title": "This Talk Is Already Out of Date: Planning for the Long Term in a Short Term World", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Successful Open Source projects have always had to balance the need to work towards long term sustainability and growth with meeting shorter term issues such as immediate funding and human resourcing needs. Projects would generally work to an annual rhythm to align with budgeting and funding decisions made by corporate supporters, and annual planning cycles were in many places well established. However, this rhythm has been hugely impacted by the new age of AI and the pivots in focus of the commercial tech industry. Long term planning feels impossible, and funding work sustainably feels increasingly out of reach when projects are reliant on companies engaged in an AI arms race. Once-robust human processes now move too slowly to be effective, and the key individuals that still need to be a part of this new world increasingly feel like they are a day late and a dollar short for everything. This talk looks at how the human side of Open Source is being affected by these shifts, and how communities can consider how to respond to these challenges.\n\n[Open in Sched](https://osselceu2026.sched.com/event/81cc92ca0da4490cd006019f1cc25a6c)", "url": "https://osselceu2026.sched.com/event/81cc92ca0da4490cd006019f1cc25a6c", "persons": [{"public_name": "Rebecca Rumbul"}]}, {"guid": "oss-17a083d2df77204a6139b97ef6a6d903", "id": "oss-17a083d2df77204a6139b97ef6a6d903", "title": "Burnout in Open Source: A Structural Problem We Can Fix Together", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "I'm a psychologist and researcher at the [Software Stewardship Lab](https://stewardshiplab.org/). Moved by the extent of burnout among Open Source developers, I have written what I believe to be the most comprehensive report to date on burnout in Open Source. This entailed a review of the academic literature, a qualitative analysis of online discussion in the OSS community, and interviews with OSS maintainers.\n \n I present 5 factors my research identified that contribute to developer burnout: difficulty getting paid, workload and time commitment, maintenance work as unrewarding, toxic community behaviour and hyper-responsibility. I discuss 3 structural changes we can make to address developer burnout: make it easier for OSS developers to get paid, distribute maintenance responsibilities, and strengthen developer community, solidarity and capacity for advocacy. Finally, I preview the findings of a follow-up study I am currently undertaking exploring the impact of the rise of AI coding on OSS developer burnout, including where it is exacerbating existing causes of burnout, and where it might help alleviate them.\n\n[Open in Sched](https://osselceu2026.sched.com/event/17a083d2df77204a6139b97ef6a6d903)", "url": "https://osselceu2026.sched.com/event/17a083d2df77204a6139b97ef6a6d903", "persons": [{"public_name": "Miranda Heath"}]}, {"guid": "oss-dbe90fded263776c47051da8d98b992b", "id": "oss-dbe90fded263776c47051da8d98b992b", "title": "Sustainable Communities - Risks and Remedies", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Whether you care about open source projects for the success of your business or to retain your basic human right to access digital technology, it is in your interest to understand the risks these communities face and what you can do to mitigate them.\n \n This presentation will provide you with a list of risk factors, from bad practices to mindset, that imapct the sustainability of open source communities. The talk will provide details of studies and real-life experiences to outline why certain behaviors, practices and approaches, most often without any bad intentions, are harmful to the open source ecosystem.\n \n You will also receive tools and actionable steps to improve the sustainability of the open source projects you care about. The session will also give you ideas how to implement practices into your workflow, whether you are relying on open source software as a buiness or as an individual.\n\n[Open in Sched](https://osselceu2026.sched.com/event/dbe90fded263776c47051da8d98b992b)", "url": "https://osselceu2026.sched.com/event/dbe90fded263776c47051da8d98b992b", "persons": [{"public_name": "Ildiko Vancsa"}]}, {"guid": "oss-b44c230f9a5ab6715f86a336d767632a", "id": "oss-b44c230f9a5ab6715f86a336d767632a", "title": "Voluntary Transparency, Involuntary Security: A Maintainer's Guide To CRA Readiness", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The enforcement window for the EU Cyber Resilience Act (CRA) is arriving, triggering corporate compliance panic. While individual open-source developers and volunteer maintainers have zero obligations under the CRA, their downstream commercial adopters face mandatory due diligence requirements. How do Maintainers survive being bombarded with manual security questionnaires and subtle attempts to shift regulatory liability upstream?\n \n The co-chair of the OpenSSF Global Cyber Policy Working Group and co-creator of the CRA Readiness Guide for Maintainers will walk you through converting the OpenSSF voluntary checklist into automated repository-level defenses. Attendees will see how to deploy the open-source OSPS Baseline Scanner GitHub Action to perform security gap analysis, expose standardized project postures via machine-readable security-insights.yaml files, and anchor liability disclaimers into repositories to push due-diligence burdens back downstream.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b44c230f9a5ab6715f86a336d767632a)", "url": "https://osselceu2026.sched.com/event/b44c230f9a5ab6715f86a336d767632a", "persons": [{"public_name": "Roman Zhukov"}]}, {"guid": "oss-6e971368e1072cf79b5de2e0b73d373b", "id": "oss-6e971368e1072cf79b5de2e0b73d373b", "title": "A Strategic Outlook for Digital Commons: Technology, Communities, and Governance", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "Conference Hall (Floor 4)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Sovereignty rhetoric is creating new openings for commons-based approaches to organising around, governing, and investing in public digital infrastructure that works for a plurality of Member States. This is partly what is proposed via ongoing initiatives like the Digital Commons EDIC and the Open Internet Stack. That said, the European Commission risks absorbing them while adopting largely statist, protectionist, or purely industrial framings that hollow out their meaning.\n \n This talk navigates that tension directly, drawing on research from the NGI Commons project to offer a clear-eyed account of where things stand and what communities, researchers, and advocates can do about it. This talk begins by mapping these concepts with precision: what each means, how they relate, and why the distinctions matter for anyone trying to advance a genuinely commons-based agenda as part of these existing initiatives.\n \n From there, the talk examines the current EU policy moment: the sovereignty turn, the competitiveness and industrial policy logic now dominating digital debates, the AI race framing, and what these shifts mean for the digital commons and the EU’s broader tech sovereignty ambitions.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6e971368e1072cf79b5de2e0b73d373b)", "url": "https://osselceu2026.sched.com/event/6e971368e1072cf79b5de2e0b73d373b", "persons": [{"public_name": "Karolina Gyurovszka"}]}], "Congress Hall (Floor 2)": [{"guid": "oss-d9fb8bc9ca4bf5ec1a703995e4f77ad8", "id": "oss-d9fb8bc9ca4bf5ec1a703995e4f77ad8", "title": "Welcome Back", "date": "2026-10-09T09:00:00+02:00", "start": "09:00", "duration": "00:05", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/d9fb8bc9ca4bf5ec1a703995e4f77ad8)", "url": "https://osselceu2026.sched.com/event/d9fb8bc9ca4bf5ec1a703995e4f77ad8", "persons": [{"public_name": "Mirko Boehm"}]}, {"guid": "oss-b2cef2e88a0c00f019a17ba78413915a", "id": "oss-b2cef2e88a0c00f019a17ba78413915a", "title": "Keynote: The Boring Layer: What AI Is Building On, and Who Owns It", "date": "2026-10-09T09:05:00+02:00", "start": "09:05", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "Something exciting is happening. The cost of building personalized software, software that fits your specific needs, is collapsing. AI made the writing cheap, but open source is what makes it yours: read it, patch it, ship it, no permission required. The most interesting software to use is the one that solves your exact problem. \n\n The reality hits when you realize maintaining it is the hard part. Every change you make is a change you carry, until upstream absorbs it or you give up. Whether upstream absorbs it depends on who upstream answers to. Redis answered to one company, and when that company changed the license, the ground moved under everyone standing on it. Every protocol AI now depends on has that same single answer, and hasn't been tested yet. We'll tell you why contributing to open source still matters even when AI will build you exactly what you want.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b2cef2e88a0c00f019a17ba78413915a)", "url": "https://osselceu2026.sched.com/event/b2cef2e88a0c00f019a17ba78413915a", "persons": [{"public_name": "Madelyn Olson"}]}, {"guid": "oss-44814a3cf2f06d53b6703d5df5df835f", "id": "oss-44814a3cf2f06d53b6703d5df5df835f", "title": "Keynote: From Open Source to Agentic Systems: Building the AI Native Era", "date": "2026-10-09T09:15:00+02:00", "start": "09:15", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "Open source underpins today’s cloud native and AI systems, from Linux and Kubernetes to emerging agentic frameworks. In this keynote Microsoft explores how open standards, collaborative governance, and shared security investments are shaping the agentic future of cloud computing. We’ll also cover how we’re applying lessons learned from the cloud native ecosystem to power the infrastructure of the AI native era, through collaboration on open source projects and interfaces.\n\n[Open in Sched](https://osselceu2026.sched.com/event/44814a3cf2f06d53b6703d5df5df835f)", "url": "https://osselceu2026.sched.com/event/44814a3cf2f06d53b6703d5df5df835f", "persons": [{"public_name": "Ryan Waite"}]}, {"guid": "oss-097860357b6432bd8333d25f0ac35ac1", "id": "oss-097860357b6432bd8333d25f0ac35ac1", "title": "Keynote: Munich After LiMux: More Open Source Than Ever", "date": "2026-10-09T09:25:00+02:00", "start": "09:25", "duration": "00:15", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/097860357b6432bd8333d25f0ac35ac1)", "url": "https://osselceu2026.sched.com/event/097860357b6432bd8333d25f0ac35ac1", "persons": [{"public_name": "Dr. Laura Dornheim"}]}, {"guid": "oss-8dc275380401d26e51f4e67a85372a67", "id": "oss-8dc275380401d26e51f4e67a85372a67", "title": "Keynote: From a Thousand Private Agents to One Open Garden", "date": "2026-10-09T09:40:00+02:00", "start": "09:40", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "Thousands of companies are currently solving the same problem in parallel: each writing their own code-writing agents, their own review prompts, their own quality gates, all privately deriving the same thing from the same public standards. But excellent engineering is not a competitive differentiator. It is infrastructure. Why would we all reinvent the same wheel? We did not each write our own kernel, we should not each write our own 'code writing' agents. Let's instead unify our efforts.\n\nThis talk introduces the AI Flower, a public capability architecture that codifies roughly 150 IT activities, defines excellence for each one grounded in industry standards, and maps their dependencies and risks into a living, regenerable knowledge graph: an open, tool-agnostic base for AI constitutions, agent skills, and quality gates that any engineer, team, educator, or company can build on.\n\nThe framework is deliberately concrete, so every claim in it can be challenged. That is the point. I will share what exists, what still needs validation, the foundation being established to govern it, and how you can contribute, because defining excellent engineering in the AI era is work that belongs to all of us, in the open.\n\n[Open in Sched](https://osselceu2026.sched.com/event/8dc275380401d26e51f4e67a85372a67)", "url": "https://osselceu2026.sched.com/event/8dc275380401d26e51f4e67a85372a67", "persons": [{"public_name": "Juliette van der Laarse"}]}, {"guid": "oss-d12cc5d351f82c6c64e88c1de17efebb", "id": "oss-d12cc5d351f82c6c64e88c1de17efebb", "title": "Keynote: Linus Torvalds, Creator of Linux & Git, in Conversation with Dirk Hohndel, Head of Ericsson Software Technology, Ericsson", "date": "2026-10-09T09:55:00+02:00", "start": "09:55", "duration": "00:30", "room": "Congress Hall (Floor 2)", "track": "OSS: Keynote Sessions", "type": "OSS Keynote", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/d12cc5d351f82c6c64e88c1de17efebb)", "url": "https://osselceu2026.sched.com/event/d12cc5d351f82c6c64e88c1de17efebb", "persons": []}, {"guid": "oss-7cf2f226a3e83e0f13b68cad869145c1", "id": "oss-7cf2f226a3e83e0f13b68cad869145c1", "title": "Sponsor Activity", "date": "2026-10-09T10:30:00+02:00", "start": "10:30", "duration": "00:10", "room": "Congress Hall (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "AI acceleration is driving CVE volume toward 100,000 annually, overwhelming traditional security triage. Learn how to patch at AI speed across your stack. We demonstrate how Project Hummingbird eliminates base image scanner noise, Lightwell delivers signed, SLA-backed application dependency backports, and Akrites coordinates upstream open-source disclosures at global scale.\n\nSponsor: Red Hat\nLocation: Booth P1, Floor 2 - Congress Hall 2C Foyer in Solutions Showcase\n\n\n\n\nIn order to facilitate networking and business relationships at the event, you may choose to visit a third party's booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7cf2f226a3e83e0f13b68cad869145c1)", "url": "https://osselceu2026.sched.com/event/7cf2f226a3e83e0f13b68cad869145c1", "persons": [{"public_name": "Patching CVEs at AI Speed: from Base Images to Enterprise Applications to Open Source (+Raffle)"}]}], "Congress Hall Foyer 0 A (Floor 0)": [{"guid": "oss-20d113ae3e0acc6a88ee5c064b7483b1", "id": "oss-20d113ae3e0acc6a88ee5c064b7483b1", "title": "Registration & Badge Pick-Up", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "08:50", "room": "Congress Hall Foyer 0 A (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/20d113ae3e0acc6a88ee5c064b7483b1)", "url": "https://osselceu2026.sched.com/event/20d113ae3e0acc6a88ee5c064b7483b1", "persons": []}], "Congress Hall Foyer 0 B (Floor 0)": [{"guid": "oss-b3ac95295ae8dae7b576a698da8d9db2", "id": "oss-b3ac95295ae8dae7b576a698da8d9db2", "title": "Cloakroom", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "10:35", "room": "Congress Hall Foyer 0 B (Floor 0)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/b3ac95295ae8dae7b576a698da8d9db2)", "url": "https://osselceu2026.sched.com/event/b3ac95295ae8dae7b576a698da8d9db2", "persons": []}], "Congress Hall Foyer 1 B (Floor 1)": [{"guid": "oss-a749aa6cf54f1941bf3d6a8b9907f57a", "id": "oss-a749aa6cf54f1941bf3d6a8b9907f57a", "title": "Digital Trust Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Congress Hall Foyer 1 B (Floor 1)", "track": "OSS: Digital Trust", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a749aa6cf54f1941bf3d6a8b9907f57a)", "url": "https://osselceu2026.sched.com/event/a749aa6cf54f1941bf3d6a8b9907f57a", "persons": []}, {"guid": "oss-396c1009c4ce6d8a54dd15ef8236a661", "id": "oss-396c1009c4ce6d8a54dd15ef8236a661", "title": "Safety-Critical Systems Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Congress Hall Foyer 1 B (Floor 1)", "track": "OSS: Safety-critical Software", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/396c1009c4ce6d8a54dd15ef8236a661)", "url": "https://osselceu2026.sched.com/event/396c1009c4ce6d8a54dd15ef8236a661", "persons": []}], "Congress Hall Foyer 3 B (Floor 3)": [{"guid": "oss-8ec06e7bc5e5ae597596b8f140d99205", "id": "oss-8ec06e7bc5e5ae597596b8f140d99205", "title": "Embedded Linux Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Congress Hall Foyer 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/8ec06e7bc5e5ae597596b8f140d99205)", "url": "https://osselceu2026.sched.com/event/8ec06e7bc5e5ae597596b8f140d99205", "persons": []}], "Congress Hall Foyer 4 B (Floor 4)": [{"guid": "oss-9fd7a13a6d6b678b52c954c4fd352883", "id": "oss-9fd7a13a6d6b678b52c954c4fd352883", "title": "Ask the Expert Session: Greg Kroah-Hartman, Linux Kernel Maintainer & Fellow, on the Linux Kernel", "date": "2026-10-09T10:35:00+02:00", "start": "10:35", "duration": "00:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Ask The Experts", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Ask Greg about the Linux Kernel.\n\nCome sit down with some open source experts to gain knowledge 1:1 and ask all your pressing questions! No sign-up necessary. More information to come!\n\n[Open in Sched](https://osselceu2026.sched.com/event/9fd7a13a6d6b678b52c954c4fd352883)", "url": "https://osselceu2026.sched.com/event/9fd7a13a6d6b678b52c954c4fd352883", "persons": []}, {"guid": "oss-722374ac964e468c10e46bcf36b357c6", "id": "oss-722374ac964e468c10e46bcf36b357c6", "title": "Ask the Expert Session: Steven Rostedt, Software Engineer, on Tracing and Real-Time", "date": "2026-10-09T10:35:00+02:00", "start": "10:35", "duration": "00:30", "room": "Congress Hall Foyer 4 B (Floor 4)", "track": "OSS: Ask The Experts", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Ask Steven about Tracing and Real-Time\n\nCome sit down with some open source experts to gain knowledge 1:1 and ask all your pressing questions! No sign-up necessary.\n\n[Open in Sched](https://osselceu2026.sched.com/event/722374ac964e468c10e46bcf36b357c6)", "url": "https://osselceu2026.sched.com/event/722374ac964e468c10e46bcf36b357c6", "persons": []}], "Forum Hall (Floor 2)": [{"guid": "oss-84e79e95e4675d2f439ebb70782b7064", "id": "oss-84e79e95e4675d2f439ebb70782b7064", "title": "Scaling OSS Code Quality With Multi-Agent Swarms", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Development teams are seeing a rapid increase in code contributions, many of them from AI tools and pair-programming copilots. As AI-generated code increases, human reviewers can quickly get overwhelmed.\n \n The instinct to throw \"an AI reviewer\" at the problem mostly doesn't work. A single agent produces shallow comments, misses context, and either over-flags or under-flags depending on how it's prompted.\n \n This talk presents a pattern that works better, built and demonstrated from scratch: three specialized reviewing agents in parallel, followed by a developer agent that applies the fixes. One reviewer focuses on architecture, one on security, one on test coverage. When all three finish, a fourth agent rewrites the code to address each issue and opens a new PR for human sign-off.\n \n The architecture is adaptable: teams with data sovereignty requirements can swap the hosted model for a self-hosted open-weight alternative (Llama 3, Mistral) served via vLLM or Ollama. \n \n Attendees leave with a concrete, working pattern they can adapt to their own projects, and a clearer picture of where AI can genuinely reduce review bottlenecks.\n \n Includes live demo.\n\n[Open in Sched](https://osselceu2026.sched.com/event/84e79e95e4675d2f439ebb70782b7064)", "url": "https://osselceu2026.sched.com/event/84e79e95e4675d2f439ebb70782b7064", "persons": [{"public_name": "Vikram Vaswani"}]}, {"guid": "oss-9d02c808a00936c8797df12c6a5a6c25", "id": "oss-9d02c808a00936c8797df12c6a5a6c25", "title": "Look MA, No GPUs! Experiment and Develop LLMs Without GPU Support", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "It's hard to experiment, let alone develop applications, for LLMs when access to GPUs is restricted. But what if you could do your development on CPUs? This session demonstrates how to deploy vLLM on a local Kubernetes cluster using Kind and Podman Desktop, running entirely on a CPU-only laptop. The presentation covers building a minimal environment, deploying vLLM containers, and running inference against models like Gemma-3 and Qwen2.5. A live benchmark comparison between vLLM and llama.cpp reveals when each runtime excels across different model sizes and hardware profiles. The session then extends the workflow to production-grade serving with KServe, including autoscaling and model lifecycle management. Attendees will learn how to deploy and test vLLM locally without GPUs or cloud resources, understand when to choose vLLM versus llama.cpp based on model size and hardware, and extend a local setup to production-grade serving with KServe.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9d02c808a00936c8797df12c6a5a6c25)", "url": "https://osselceu2026.sched.com/event/9d02c808a00936c8797df12c6a5a6c25", "persons": [{"public_name": "Alexon Oliveira"}]}, {"guid": "oss-92f702d55fc3e7e20f1fa1a13449ac9d", "id": "oss-92f702d55fc3e7e20f1fa1a13449ac9d", "title": "Lightning Talk: 97% of MCP Tools Have Quality Defects & Here's How We Measured Them", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:10", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Silent failures in MCP tool invocation aren't random. They trace back to a single root cause: tool descriptions that are too vague for agents to reliably select the right tool.\n A SAIL Research study of 856 tools across 103 MCP servers found 97% have at least one quality defect, 56% fail to clearly state what the tool does, and 89% provide no guidance on when not to use it. A second study of 10,831 servers confirmed that well-written descriptions get selected 260% more often, improving task success rates by ~6 points.\n Working with the Glama founder, I developed TDQS (Tool Definition Quality Score) : an open-source framework scoring MCP tools across six dimensions: Purpose Clarity, Usage Guidelines, Behavioral Transparency, Parameter Semantics, Conciseness, and Contextual Completeness.\n This talk covers how TDQS was built, what scoring thousands of real-world servers revealed, and how the open-source community can adopt it as a quality standard for MCP tool authorship.\n\n[Open in Sched](https://osselceu2026.sched.com/event/92f702d55fc3e7e20f1fa1a13449ac9d)", "url": "https://osselceu2026.sched.com/event/92f702d55fc3e7e20f1fa1a13449ac9d", "persons": [{"public_name": "Om Shree"}]}, {"guid": "oss-16de0eb57a8f789e24c6bc2176ae2691", "id": "oss-16de0eb57a8f789e24c6bc2176ae2691", "title": "Lightning Talk: Real Observability for Self-Hosted LLMs on Ubuntu", "date": "2026-10-09T14:10:00+02:00", "start": "14:10", "duration": "00:10", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Running LLMs near devices or in constrained edge environments changes the observability problem. A small model can answer successfully while still being unusable: first token arrives too late, prompts burn scarce CPU/RAM budget, output is malformed, or gateway/model-selection errors hide behind green Linux and container metrics.\n \n This session walks through a reproducible, CPU-first Ubuntu demo for resource-constrained self-hosted LLMs. It uses small Ollama models (llama3.2:1b and qwen3.5:2b) on the same CPU workload with MicroK8s, Juju, COS Lite, Tempo, a FastAPI OpenAI-compatible gateway, and Canonical's Charmed OpenTelemetry Collector. The gateway emits OpenTelemetry GenAI spans, metrics, and trace-correlated logs; Prometheus, Loki, Tempo, Grafana, and Alertmanager turn them into an LLM golden-signals view.\n \n Using recorded normal, slow, expensive, error, and low-quality scenarios, attendees will see how time-to-first-token, token usage, traces, alerts, and quality signals reveal whether a local model is useful within tight compute constraints. The model comparison shows why embedded and edge AI decisions need measured latency/cost/quality trade-offs, not just 'the model runs.'\n\n[Open in Sched](https://osselceu2026.sched.com/event/16de0eb57a8f789e24c6bc2176ae2691)", "url": "https://osselceu2026.sched.com/event/16de0eb57a8f789e24c6bc2176ae2691", "persons": [{"public_name": "Shardul Deshpande"}]}, {"guid": "oss-049f2b887550c830109cf4ac284ad91f", "id": "oss-049f2b887550c830109cf4ac284ad91f", "title": "Building Fine-Grained Permissions for AI Agents", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This talk could prevent the next big data breach. Building enterprise-ready AI poses challenges around data security, scalability, and integration, especially in compliance-regulated industries. We're already seeing security breaches with AI Agents in the news. This is a complex problem - Imagine having N users, M Agents and O actions. How do you design permissions around that? This session will cover how modern permissions systems can ensure AI Agents have access only to authorized data. The talk will look at why the Google Zanzibar model of authorization which uses Relationship-Based Access Control (ReBAC) is well suited for fine-grained authorization at scale. The talk covers the nuts and bolts of how a Google Zanzibar system works under the hood, and how to apply it to AI Agents with techniques such as pre-filteration and post-filteration. The talk will also include a live code demo implementing authorization for AI Agents + RAG using Open Source tools such as Weaviate, Langchain, and SpiceDB.\n\n[Open in Sched](https://osselceu2026.sched.com/event/049f2b887550c830109cf4ac284ad91f)", "url": "https://osselceu2026.sched.com/event/049f2b887550c830109cf4ac284ad91f", "persons": [{"public_name": "Sohan Maheshwar"}]}, {"guid": "oss-55a8ab344559ce82c3b765130e9c9bd5", "id": "oss-55a8ab344559ce82c3b765130e9c9bd5", "title": "When Coding Agents Cheat: Measuring the Security of AI-Generated Code With an Open Benchmark", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Vibe coding is now the norm, and more open-source code is AI-generated. But is it secure?\n \n We present the Agent Security League, an open leaderboard built on SusVibes (200 real-world tasks, 108 OSS projects, 77 CWEs). Unlike benchmarks frontier labs cite to showcase progress, SusVibes evaluates what developers actually use: a harness coupled with an LLM, not the model alone. Across 15+ combinations — GPT-5.5, Gemini 3.5, Fable 5 — with agents like Cursor and Claude Code, functional correctness can exceed 80%, yet our best fair security score is 29%.\n \n This means ~7/10 working AI patches leave the bug open.\n \n Strikingly, even models (e.g., Fable 5) that lead model-only benchmarks score no better on security once wrapped in a real agent.\n \n Agents also cheat: early on they reverse-engineered fixes from git history, inflating scores up to 42×. Our 3-layer pipeline—prompt hardening, workspace sanitization, LLM-based anti-cheating eval—nearly killed that, but memorization of upstream fixes from training data persists.\n \n We show cheating examples, share fair results, what actually improves security, and argue anti-cheating and contamination controls must be standard for agentic benchmarks.\n\n[Open in Sched](https://osselceu2026.sched.com/event/55a8ab344559ce82c3b765130e9c9bd5)", "url": "https://osselceu2026.sched.com/event/55a8ab344559ce82c3b765130e9c9bd5", "persons": [{"public_name": "Luca Compagna"}]}, {"guid": "oss-d48967fcdc57604b8e655c3857fb3f59", "id": "oss-d48967fcdc57604b8e655c3857fb3f59", "title": "From Hours To Minutes: Building Production-Ready Agentic Systems on Kubernetes", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Forum Hall (Floor 2)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Agentic AI systems are rapidly evolving from research experiments into production workloads. However, while building a proof-of-concept agent can take only a few hours, building a reliable, scalable, and observable agentic platform remains a significant challenge.\n \n This session explores how modern open source technologies can be combined to build production-ready agentic systems on Kubernetes. We will walk through a complete architecture that includes large language models, agent orchestration, retrieval systems, tool execution, memory management, observability, and infrastructure automation.\n \n Using technologies such as Kubernetes, Kubeflow, LangGraph, Model Context Protocol (MCP), vector databases, and open-source serving frameworks, we will demonstrate how to move from a simple agent prototype to a resilient platform capable of supporting enterprise-scale workloads.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d48967fcdc57604b8e655c3857fb3f59)", "url": "https://osselceu2026.sched.com/event/d48967fcdc57604b8e655c3857fb3f59", "persons": [{"public_name": "Purnanand Kumar"}, {"public_name": "Dipali Chatterjee"}]}], "Forum Hall Foyer 0 (Floor 0)": [{"guid": "oss-7f576841e26638bcc75ec423f85ad132", "id": "oss-7f576841e26638bcc75ec423f85ad132", "title": "Cloud, Containers & Orchestration Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Forum Hall Foyer 0 (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7f576841e26638bcc75ec423f85ad132)", "url": "https://osselceu2026.sched.com/event/7f576841e26638bcc75ec423f85ad132", "persons": []}], "Forum Hall Foyer 1 (Floor 1)": [{"guid": "oss-e344d1b44963d317a6f3ac514873db22", "id": "oss-e344d1b44963d317a6f3ac514873db22", "title": "Linux Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e344d1b44963d317a6f3ac514873db22)", "url": "https://osselceu2026.sched.com/event/e344d1b44963d317a6f3ac514873db22", "persons": []}, {"guid": "oss-bd9f390f89aa79da9b788345ff93da4a", "id": "oss-bd9f390f89aa79da9b788345ff93da4a", "title": "Open AI & Data Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: Open AI & Data", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/bd9f390f89aa79da9b788345ff93da4a)", "url": "https://osselceu2026.sched.com/event/bd9f390f89aa79da9b788345ff93da4a", "persons": []}, {"guid": "oss-52c4ee52a04bc1f646e78d8fba8227da", "id": "oss-52c4ee52a04bc1f646e78d8fba8227da", "title": "Open Source Leadership Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Forum Hall Foyer 1 (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/52c4ee52a04bc1f646e78d8fba8227da)", "url": "https://osselceu2026.sched.com/event/52c4ee52a04bc1f646e78d8fba8227da", "persons": []}], "Multiple Locations": [{"guid": "oss-453b582a68ca9c8f43872eb4f6b8e22d", "id": "oss-453b582a68ca9c8f43872eb4f6b8e22d", "title": "5k Fun Run", "date": "2026-10-09T06:45:00+02:00", "start": "06:45", "duration": "01:15", "room": "Multiple Locations", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Time: Meet at 06:45; Activity from 07:00 – 08:00\nMeeting Location One: Holiday Inn Prague\nMeeting Location Two: Novotel Praha Wenceslas Square\nLace up your sneakers – it’s time for the Fun Run! Whether you’re walking, jogging, or chasing a personal best, we’ve got a pace group to match your stride. This all-levels activity is a great way to start your day, so don’t forget to bring your running gear. Join us for a morning of movement, energy, and great company!\nRunning guides will be stationed at both meeting locations listed above. Participants may choose to start from whichever location is most convenient.\n\nParticipation is complimentary, with space available on a first-come, first-served basis.\nParticipants must be registered for Open Source Summit & Embedded Linux Conference Europe 2026, have their event badge, and are responsible for bringing their own running attire and water.\n\n[Open in Sched](https://osselceu2026.sched.com/event/453b582a68ca9c8f43872eb4f6b8e22d)", "url": "https://osselceu2026.sched.com/event/453b582a68ca9c8f43872eb4f6b8e22d", "persons": []}], "Panorama Hall (Floor 1)": [{"guid": "oss-29fbb8b5193e0dbe036af1f133c8cde5", "id": "oss-29fbb8b5193e0dbe036af1f133c8cde5", "title": "An Native API for Linux Systems With Systemd + Varlink", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Modern Linux based distributed systems generally rely on bespoke \"agent\" services on each node for introspecting their state or issuing operations.\n \n In this talk I'd like to explain systemd's vision of improving and cleaning up this logic, with the ultimate goal of avoiding any local agents but nonetheless making the system nicely introspectable and accessible, with modern technologies.\n \n For this, we'll talk about the Varlink IPC system, and the numerous Varlink APIs systemd provides these days. We'll also cover the HTTP Varlink proxy, which opens up these APIs in a web-native way, with modern authorization mechanisms. We'll also discuss systemd's metrics collection/report generation subsystem, it's cryptographic properties and remote access to it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/29fbb8b5193e0dbe036af1f133c8cde5)", "url": "https://osselceu2026.sched.com/event/29fbb8b5193e0dbe036af1f133c8cde5", "persons": [{"public_name": "Lennart Poettering"}]}, {"guid": "oss-65e739de3fa9ec6d00df7b808da44bf6", "id": "oss-65e739de3fa9ec6d00df7b808da44bf6", "title": "The Little-Known Mechanism for Securely Parameterizing Systemd Services", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In this talk I'd like to discuss the \"systemd Credentials\" concept, which was introduced back in systemd v250 and became a powerful mechanism for parameterizing Linux systems and services.\n \n These credentials can be passed into systems and services, can be authenticated and encrypted by TPMs. They can be acquired from SMBIOS, via Cloud IMDS services, the UEFI System Partition, or local file systems and IPC. They have a well-defined life-cycle, and can be securely inherited down the process, container and VM hierarchy.\n \n We'll compare them with other ways to parameterize systems and services, such as the kernel command line or environment blocks, and explain why systemd's credentials are often the much better approach.\n\n[Open in Sched](https://osselceu2026.sched.com/event/65e739de3fa9ec6d00df7b808da44bf6)", "url": "https://osselceu2026.sched.com/event/65e739de3fa9ec6d00df7b808da44bf6", "persons": [{"public_name": "Lennart Poettering"}]}, {"guid": "oss-0757b136b186ca094b65ee289976121b", "id": "oss-0757b136b186ca094b65ee289976121b", "title": "Keeping Track of Resources in the Kernel - Overview and Pitfalls of Resource Management Mechanisms", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "While C is a spartan language by design and, as such, doesn't offer any automatic memory management, the linux kernel over the years has acquired several mechanisms that attempt to make it easier for developers to keep track of resources and control their lifetime.\n \n These mechanisms use C compiler extensions for scope-based memory management, count object references, or rely on control flow provided by the lower-level subsystem code. They can also be an arbitrary mixture of multiple approaches.\n \n As the C compiler by definition is unable to enforce ownership or reference counting and scope correctness, the users of these helpers must still leverage them correctly and respect the API contract.\n \n The kernel has struggled with object lifetime issues for decades now and, while there are legitimate issues with the design of certain subsystems, some of these issues resulted from incorrect use of the kernel resource management APIs. A good example of this is scheduling devres actions for devices that will never be bound to drivers.\n \n This talk will present different resource management mechanisms in the kernel along with examples of how to use them correctly and what mistakes to avoid.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0757b136b186ca094b65ee289976121b)", "url": "https://osselceu2026.sched.com/event/0757b136b186ca094b65ee289976121b", "persons": [{"public_name": "Bartosz Golaszewski"}]}, {"guid": "oss-0a14d852dfe56c8011e96d0f1f259d51", "id": "oss-0a14d852dfe56c8011e96d0f1f259d51", "title": "Anatomy of a Mainline Linux Driver", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Getting a driver into mainline Linux is a great step, but it is very different from downstream development. In downstream, the people writing the driver are often not the ones making the final product. Because of this, they have to implement 100% of the hardware features. But in the end, maybe only 60% of these features are actually used by product integrators. This creates dead code and increased driver complexity. In this talk, I will show you the anatomy of a mainline Linux driver and guide you on how to write it for the upstream tree inclusion. We will see how to write generic code that is easy for the community to maintain in the long term. We will talk about using and extending existing kernel frameworks instead of making custom control paths or abusing current interfaces, which helps reduce ecosystem fragmentation. For embedded systems, we will also see how to make clean and extensible Device Tree bindings. I will explain why we need to drop untestable downstream features to keep the code clean. Finally, we will look at how to format and check your patchset with tools like checkpatch, smatch, and new AI tools like Sashiko to ensure high kernel quality.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0a14d852dfe56c8011e96d0f1f259d51)", "url": "https://osselceu2026.sched.com/event/0a14d852dfe56c8011e96d0f1f259d51", "persons": [{"public_name": "Neil Armstrong"}]}, {"guid": "oss-b3bb919eaef21e96de0bf9d56f6f6d75", "id": "oss-b3bb919eaef21e96de0bf9d56f6f6d75", "title": "Who Watches the Watcher? Hardening eBPF in Production Security Deployments", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "eBPF has become the backbone of modern Linux security tooling. Cilium, Tetragon, Falco, etc they all depend on eBPF's ability to hook kernel execution paths and enforce policy without a kernel patch or reboot. But there's a question the community has been slow to ask: who secures eBPF itself?\n Working on bpfman, an eBPF program manager, exposed me to the trust assumptions baked into how programs get loaded, pinned, and granted kernel access. This talk covers what I found concrete attack surfaces that show up in real deployments, not theory.\n \n We'll cover: the verifier's historical CVEs and what they reveal about its actual threat model, privilege escalation through CAP_BPF and unprivileged eBPF in distros that ship with it enabled, what program signing protects and what it quietly doesn't, and LSM hooks on BPF program loading that most teams aren't using yet.\n The second half: BPF token scoping, how Ubuntu and Fedora are locking down the attack surface without breaking legitimate tooling,and a threat model checklist you can apply to your own eBPF deployment the same week.\n If you're running eBPF-based security tooling in production, this is the talk I wished existed before I started.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b3bb919eaef21e96de0bf9d56f6f6d75)", "url": "https://osselceu2026.sched.com/event/b3bb919eaef21e96de0bf9d56f6f6d75", "persons": [{"public_name": "Hanshal Mehta"}]}, {"guid": "oss-6070b776e7cf2611aecd5375a24e37cb", "id": "oss-6070b776e7cf2611aecd5375a24e37cb", "title": "A Surprisingly Hard Question: How Much Memory Does My System Use?", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Panorama Hall (Floor 1)", "track": "OSS: Linux", "type": "OSS Talk", "language": "en", "abstract": "", "description": "When everything runs smoothly, memory usage is just another metric. But when out-of-memory situations strike, or you are tasked with cutting a workload's RAM in half, it suddenly becomes the most important metric in your system.\n \n While Linux exposes dozens of memory-related counters, answering basic questions is notoriously difficult. Developers and system administrators often struggle to pinpoint exactly how much memory the system is actually using, what the true footprint of a single application is, and how much memory that application can safely consume before causing issues.\n \n In this talk, Richard will demystify Linux memory metrics and break down how the OS organizes memory across kernel and userspace.\n \n Attendees will learn how to accurately read and make sense of Linux memory counters, giving them a better understanding of how internal memory management actually works. The session will also cover practical techniques for debugging memory-related issues and OOM kills, leaving the audience with actionable ways to optimize their application memory footprints.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6070b776e7cf2611aecd5375a24e37cb)", "url": "https://osselceu2026.sched.com/event/6070b776e7cf2611aecd5375a24e37cb", "persons": [{"public_name": "Richard Weinberger"}]}], "Room 4.3 (Floor 4)": [{"guid": "oss-3deb46613e23c3558f11297f6811f5c3", "id": "oss-3deb46613e23c3558f11297f6811f5c3", "title": "Zen Zone", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "08:50", "room": "Room 4.3 (Floor 4)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "All attendees may feel free to use the Zen Zone as needed. This is a quiet space for sensory relaxation, meditation, and worship. It is not to be used for conversations or as a workspace.\n\n[Open in Sched](https://osselceu2026.sched.com/event/3deb46613e23c3558f11297f6811f5c3)", "url": "https://osselceu2026.sched.com/event/3deb46613e23c3558f11297f6811f5c3", "persons": []}], "Small Hall (Floor 0)": [{"guid": "oss-fe9380dd8e7c8653386a7fd0cf122d94", "id": "oss-fe9380dd8e7c8653386a7fd0cf122d94", "title": "Lightning Talk: Declarative Systems Still Have Hidden State", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:10", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Declarative infrastructure promises reproducibility: desired state is defined, controllers reconcile drift, and redeployments should behave predictably.\n \n Except they often don’t.\n \n This talk explores the hidden operational state declarative systems quietly depend on: webhook certificates cached in cluster resources, infrastructure dependencies that survive deletion, controller ordering assumptions, persistent node state, and lifecycle coupling reconciliation engines cannot see.\n \n These problems become especially visible when infrastructure spans multiple systems or workloads take minutes rather than seconds to initialize.\n \n Using real operational examples from Kubernetes and GitOps environments, this lightning talk examines why “delete and redeploy” frequently fails to produce clean state and why many reliability problems are actually hidden state-management problems.\n \n The core lesson: declarative systems still depend on operational history, even when the infrastructure appears fully declarative.\n\n[Open in Sched](https://osselceu2026.sched.com/event/fe9380dd8e7c8653386a7fd0cf122d94)", "url": "https://osselceu2026.sched.com/event/fe9380dd8e7c8653386a7fd0cf122d94", "persons": [{"public_name": "Kim Schaefer"}]}, {"guid": "oss-86d0ac6d9cf2a2908afc3729166196c3", "id": "oss-86d0ac6d9cf2a2908afc3729166196c3", "title": "Lightning Talk: Beyond Immutable Machines: Introducing Cluster API In-Place Updates", "date": "2026-10-09T11:25:00+02:00", "start": "11:25", "duration": "00:10", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Cluster API (CAPI) is by now a relatively mature project with many adopters using it in production already for years. Despite this, or perhaps rather thanks to it, CAPI keeps evolving, growing and adding new features. In this session, I'll present one of the most recent features: in-place updates.\n \n In-place updates marks an important change to a fundamental assumption in CAPI. Traditionally, the Machines were considered mostly immutable. Any change required a replacement where new Machines were created and old Machines deleted. This method of operation has served CAPI well, and continues to do so, but it is not without pain points. With in-place updates, it is now finally possible to avoid replacement. This opens the door for unique use-cases and solutions, such as Talos, where each node's lifecycle can be managed through a built-in controller in the node itself.\n \n Come learn about this new feature in CAPI, and how to make use of it!\n\n[Open in Sched](https://osselceu2026.sched.com/event/86d0ac6d9cf2a2908afc3729166196c3)", "url": "https://osselceu2026.sched.com/event/86d0ac6d9cf2a2908afc3729166196c3", "persons": [{"public_name": "Lennart Jern"}]}, {"guid": "oss-0e3283c9f95b080981f796c02ef6ccae", "id": "oss-0e3283c9f95b080981f796c02ef6ccae", "title": "Lightning Talk: Prove It: Is Your Kubernetes App Cloud Native?", "date": "2026-10-09T11:35:00+02:00", "start": "11:35", "duration": "00:10", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Everyone claims their app is cloud-native. But how to prove it?\n \n CNTi Testsuite, an open-source Linux Foundation project, provides automated tests that validate cloud-native best practices such as security, scalability, and upgradability. While designed for telecom CNFs, it works for any Kubernetes application.\n \n In this lightning talk, I’ll show how you can run CNTi Testsuite in minutes to objectively measure cloud-native maturity and uncover hidden gaps in Kubernetes workloads.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0e3283c9f95b080981f796c02ef6ccae)", "url": "https://osselceu2026.sched.com/event/0e3283c9f95b080981f796c02ef6ccae", "persons": [{"public_name": "Martin Matyáš"}]}, {"guid": "oss-de50121faf2d761c723a69a6be5e2a5b", "id": "oss-de50121faf2d761c723a69a6be5e2a5b", "title": "The Bill That Fixes Itself: Trustworthy Agentic FinOps \"with Legs\"", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Cloud cost dashboards are everywhere. Closed loops are not. Most FinOps practice ends at a recommendation a human may or may not apply, and even applied savings drift back the moment someone bumps a SKU in the console. This talk shows how we replaced manual cost reviews across a multi-cloud landscape. We started with all PaaS estate with an always-on agentic loop built on open source: a pluggable LLM (wrapper) reasoning layer driven by a state machine, Argo Workflows running a 6 hour collect, analyse, act pipeline, OpenTelemetry unifying metrics from both clouds, CloudEvents standardising approvals across Service Bus and Pub/Sub, and Crossplane as the enforcement engine whose 30 second reconciliation makes every saving permanent. We cover the three layer policy model (E.g. Git rules, Azure Policy, GCP Org Policy) that keeps the agent inside its mandate, and the trust gates that earned it autonomy: recommendation-only until FinOps validated over 80% of proposals across 30 days, then graduated rollout by action class, with production databases never automated. We close with real savings data (40 to 70% on storage, 60 to 70% on dev databases) and the failure modes we hit on the way.\n\n[Open in Sched](https://osselceu2026.sched.com/event/de50121faf2d761c723a69a6be5e2a5b)", "url": "https://osselceu2026.sched.com/event/de50121faf2d761c723a69a6be5e2a5b", "persons": [{"public_name": "Pratik Mohapatra"}]}, {"guid": "oss-748502e1a0b6d13f003bc5e9e50ecc96", "id": "oss-748502e1a0b6d13f003bc5e9e50ecc96", "title": "Container Metrics on Diverse Hardware: Driving Observability, Efficiency, and Real-Time Autoscaling", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Uber runs about 4 million containers on over 150,000 hosts. Our fleet includes a mix of cgroupv1 and v2 hosts, multiple cloud providers, and multiple Linux kernel versions. Tracking container performance at this massive scale is a difficult engineering challenge, including the cost of storing them. We currently process 60 million data points every second to keep everything running smoothly. We run Cadvisor and open-source Nvidia and AMD GPU metrics exporters to reliably and affordably collect and store these metrics. This infrastructure is vital for our real-time autoscaling, which ensures our services stay online. We also use these metrics to track memory usage and keep costs low for our AI workloads. Despite maintaining all the critical use cases, we have saved around $ 4 million compared to last year by changing how we collect and store data. We will share how we use these metrics to detect and prevent system failures before they affect users. Attendees will learn practical patterns for operating container metrics at scale. We will also discuss the hard lessons we learned while building a reliable metrics system for a complex global fleet.\n\n[Open in Sched](https://osselceu2026.sched.com/event/748502e1a0b6d13f003bc5e9e50ecc96)", "url": "https://osselceu2026.sched.com/event/748502e1a0b6d13f003bc5e9e50ecc96", "persons": [{"public_name": "Sambhav Jain"}, {"public_name": "Digvijay Singh Shekhawat"}]}, {"guid": "oss-72c1f8482286a57d96a3ef673802f48b", "id": "oss-72c1f8482286a57d96a3ef673802f48b", "title": "Cutting Storage and Network Costs with Streaming Compression in Valkey", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Memory is one of the most expensive parts of running a distributed cache, but the cost does not stop there. In a replicated system, the same data is paid for more than once: it sits in memory, gets written to disk during snapshots, and is sent over the network to replicas, sometimes across regions where bandwidth is expensive.Valkey (a fork of Redis) now supports streaming compression at the points where bytes are most costly to store or move. The surprising result is that compression, though expected to slow the system down, often makes it faster, because the compute spent compressing data is cheaper than the I/O spent moving the uncompressed version.This talk explains how streaming compression works in Valkey 9.2 and where it fits into the snapshot and replication paths. We show how Valkey can snapshot up to 77% faster, sync replicas up to 73% faster, and produce artifacts up to 70% smaller than today. Replication shows a similar pattern, cutting up to 75% of the network cost of replicating across regions.Attendees will leave understanding how a well-placed compression layer can reduce storage, network usage, replication lag, and recovery time without much added complexity.\n\n[Open in Sched](https://osselceu2026.sched.com/event/72c1f8482286a57d96a3ef673802f48b)", "url": "https://osselceu2026.sched.com/event/72c1f8482286a57d96a3ef673802f48b", "persons": [{"public_name": "Sarthak Aggarwal"}]}, {"guid": "oss-4342a437920af019bace1d54bb0ac895", "id": "oss-4342a437920af019bace1d54bb0ac895", "title": "Cloud Native Open RAN Across 1,000 Km: A GitOps Deployment With Duranta and Sylva", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "Small Hall (Floor 0)", "track": "OSS: Cloud & Orchestration", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The telco industry has been on a cloudification journey for over a decade. In the context of Radio Access Networks (RAN), this deep transformation is primarily driven by Open RAN initiatives. This talk illustrates how RAN is gradually embrassing cloud native benefits. Key synergies between Sylva and Duranta open-source projects are driving this transformation: \n - Sylva provides a telco-grade cloud stack, enabling scalable and reliable cloud infrastructure. \n - The Duranta project focuses on developing RAN network functions using cloud-native design patterns to promote innovation and interoperability. \n \n A live demo will highlight the role of Open RAN interfaces in Duranta. It will showcase a FluxCD-based GitOps deployment of Duranta’s Open RAN Distributed Unit (O-DU), Centralized Unit Control Plane (O-CU-CP), and Centralized Unit User Plane (O-CU-UP) network functions on a Telco Cloud. The deployment will follow the Sylva GitOps approach. Sylva will orchestrate multiple Telco Clouds to showcase central, regional, and far-edge deployment scenarios across two labs located approximately 1,000 km apart.\n\n[Open in Sched](https://osselceu2026.sched.com/event/4342a437920af019bace1d54bb0ac895)", "url": "https://osselceu2026.sched.com/event/4342a437920af019bace1d54bb0ac895", "persons": [{"public_name": "Karim Boutiba"}, {"public_name": "Guillaume Grao"}]}], "Solutions Showcase": [{"guid": "oss-74c1320146ff07fa49aacd416c5b7df9", "id": "oss-74c1320146ff07fa49aacd416c5b7df9", "title": "Solutions Showcase", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "The Solutions Showcase is your hub to network, explore sponsor exhibits, and learn how these organizations are shaping the future of the ecosystem.**In order to facilitate networking and business relationships at the event, you may choose to visit a third party’s booth or access sponsored content. You are never required to visit third party booths or to access sponsored content. When visiting a booth or participating in sponsored activities, the third party will receive some of your registration data. This data includes your first name, last name, title, company, address, email, standard demographics questions (i.e. job function, industry), and details about the sponsored content or resources you interacted with. If you choose to interact with a booth or access sponsored content, you are explicitly consenting to receipt and use of such data by the third-party recipients, which will be subject to their own privacy policies.**\n\n[Open in Sched](https://osselceu2026.sched.com/event/74c1320146ff07fa49aacd416c5b7df9)", "url": "https://osselceu2026.sched.com/event/74c1320146ff07fa49aacd416c5b7df9", "persons": []}, {"guid": "oss-611b1605f4d5646f531306694c8149d0", "id": "oss-611b1605f4d5646f531306694c8149d0", "title": "Welcome Coffee", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "01:00", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/611b1605f4d5646f531306694c8149d0)", "url": "https://osselceu2026.sched.com/event/611b1605f4d5646f531306694c8149d0", "persons": []}, {"guid": "oss-e86fc71cfb41b75324dcf337b0710f8c", "id": "oss-e86fc71cfb41b75324dcf337b0710f8c", "title": "Coffee Break", "date": "2026-10-09T10:35:00+02:00", "start": "10:35", "duration": "00:30", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/e86fc71cfb41b75324dcf337b0710f8c)", "url": "https://osselceu2026.sched.com/event/e86fc71cfb41b75324dcf337b0710f8c", "persons": []}, {"guid": "oss-46566942bc64c214b6a2e24ef7f17ae3", "id": "oss-46566942bc64c214b6a2e24ef7f17ae3", "title": "Lunch (Provided Onsite for All Attendees)", "date": "2026-10-09T12:35:00+02:00", "start": "12:35", "duration": "01:25", "room": "Solutions Showcase", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "\n\n[Open in Sched](https://osselceu2026.sched.com/event/46566942bc64c214b6a2e24ef7f17ae3)", "url": "https://osselceu2026.sched.com/event/46566942bc64c214b6a2e24ef7f17ae3", "persons": []}], "South Hall 1 A (Floor 1)": [{"guid": "oss-a737b20ffa81d3e0a52662c93c216f06", "id": "oss-a737b20ffa81d3e0a52662c93c216f06", "title": "From Using To Leading: How a Grid Operator Leverages Open Source Strategically", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "As the energy system transitions into a highly digital, data-driven ecosystem, grid operators face mounting complexity, rising costs, and increasing pressure to deliver scalable and future-proof solutions. In this context, open source is no longer a technical preference. It is becoming a strategic necessity.\n \n In this session, Alliander shares how it has repositioned open source as a key enabler of its digital strategy. We show how a clear vision helps maximize public value, accelerate innovation, strengthen digital sovereignty, and improve transparency, while maintaining control over long-term costs.\n \n We introduce three guiding principles: Open Source First, Building Together, and Confidence in Openness. We also highlight practical implications, from embedding open source in procurement to actively contributing and opening internal solutions.\n \n This session offers a concrete example for executives on how to move from ad hoc use of open source to a coherent, organization-wide strategy. Reducing duplication, optimizing investments, and strengthening collaboration across the energy ecosystem, including within LF Energy.\n\n[Open in Sched](https://osselceu2026.sched.com/event/a737b20ffa81d3e0a52662c93c216f06)", "url": "https://osselceu2026.sched.com/event/a737b20ffa81d3e0a52662c93c216f06", "persons": [{"public_name": "Jonas van den Bogaard"}]}, {"guid": "oss-108f6139637b80c80b8984370164ed16", "id": "oss-108f6139637b80c80b8984370164ed16", "title": "What Hides Below 10,000+ SBOMs of a Foundation", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "It all started with the simple question: \"Do we have all exceptions for license dependecies for all the projects?\" \n \n As you can imagine this is not a question most organizations can answer out of the blue. \n To solve this we started not only generating SBOMS for every single project in the CNCF., but also every Subproject that has a release. \n Along the way we hit every wall: inconsistent release processes, license resolution dead ends, CVE matching at scale, and the discovery that generation is maybe 20% of the problem.\n We will dig into the full pipeline we built. Automated SBOM generation at scale, auto discovery of Repositories, experimenting with differnet SBOM generation tools, hitting Git limits, license enrichment via deps.dev and ClearlyDefined, vulnerability cross-referencing via OSV, and OpenVEX for suppression.\n After we finished this we realized that 10,000+ SBOMs are useless if you cannot search, query, or govern them. So we built an open source toolchain for the whole thing.\n \n You will learn how to build a toolchain for Supply Chain at a sclae that supports a foundation and you can also use in organizatiosn that is fully Open Source and Apache 2 licensed.\n\n[Open in Sched](https://osselceu2026.sched.com/event/108f6139637b80c80b8984370164ed16)", "url": "https://osselceu2026.sched.com/event/108f6139637b80c80b8984370164ed16", "persons": [{"public_name": "Mario Fahlandt"}]}, {"guid": "oss-ee2c15ab4313df3cdbd0eb3b492e6470", "id": "oss-ee2c15ab4313df3cdbd0eb3b492e6470", "title": "The Hard Limits of a (de)-centralized OSPO", "date": "2026-10-09T12:15:00+02:00", "start": "12:15", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Starting up an OSPO is not an easy task - let alone for 300+ companies. That's the scale and problem space we face in the highly federated and distributed enterprise of E.ON. \n \n One of Europe's biggest energy utility provider has it all: critical infrastructure, regulations, services for millions of customers, purpose built hardware, SaaS businesses, an unfathomable amount of suppliers and engineers all over the place. \n \n So before we could even start with our own ideas about the OSPO management we needed to get a hold of the status quo at E.ON for any kind of engineering and business operations. Two years after starting the OSPO we're far from done doing that yet, but we already established quite a bunch of successful initiatives. \n \n We'll present our idea of an Hub-and-Spoke-OSPO, targeted initiatives for distinct parts of the business, curing pain points, building recurring collaborations within the enterprise and how to become more visible as 2-person-OSPO with nearly 80.000 coworkers.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ee2c15ab4313df3cdbd0eb3b492e6470)", "url": "https://osselceu2026.sched.com/event/ee2c15ab4313df3cdbd0eb3b492e6470", "persons": [{"public_name": "Sebastian Grüner"}, {"public_name": "Benjamin Rilz"}]}, {"guid": "oss-86fba3ca26393ae1815534dddfe0b3db", "id": "oss-86fba3ca26393ae1815534dddfe0b3db", "title": "OpenChain in Central and Eastern Europe: Year One", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:20", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "One year ago, we created the OpenChain Meridian 22 Work Group for Central and Eastern Europe. In this year, our community has grown to include members from Poland, Hungary, Finland, Romania, Bulgaria, Greece, and other countries. We promoted OpenChain and our WG formally at open source and security events in Serbia, Slovenia, and Bulgaria, and informally in other parts of Europe and the world. We work in close collaboration with other open source communities to organize free events across Europe.\n \n This talk is a retrospective on this past year of expanding the OpenChain community in the region. We will showcase the interesting topics we focus on in our WG, and share the lessons we learned along the way. We would like to use the talk to promote the WG locally.\n \n The first part of the talk will focus on the journey: how we launched the OpenChain Meridian 22 WG, our promotion activities, and the topics we have tackled so far.\n \n The second second part, about the takeaways: what makes this region special, why we received attention mostly from security communities, and other such curiosities.\n \n The last part will be an overview of the co-located event we are organizing with the community.\n\n[Open in Sched](https://osselceu2026.sched.com/event/86fba3ca26393ae1815534dddfe0b3db)", "url": "https://osselceu2026.sched.com/event/86fba3ca26393ae1815534dddfe0b3db", "persons": [{"public_name": "Vladimir Slavov"}, {"public_name": "Nikola Babadzhanov"}]}, {"guid": "oss-77ed8249c490535507852d68a07ba5be", "id": "oss-77ed8249c490535507852d68a07ba5be", "title": "CRA Compliance Paths and Where the Real Responsibility Sits", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The EU CRA is now law, yet confusion persists across the software ecosystem. Many developers still fear personal liability for upstream contributions, while organizations struggle to understand what compliance actually requires.\n This talk clarifies the four CRA compliance pathways: Self-Assessment, Standards, 3rd party Conformity Assessment, and the EUCC, and explains how they apply across the software supply chain.\n \n We demystify the CRA’s approach to open source, focusing on OSS stewards such as foundations and legal entities, and their limited obligations compared to manufacturers. A key message: upstream contributors and individual maintainers have no direct CRA compliance responsibilities.\n We also examine supply chain security implications, including the need for stronger upstream-downstream collaboration, better dependency transparency, and clearer security ownership at integration points. Misinterpretation of CRA roles risks shifting compliance burden incorrectly upstream, undermining ecosystem resilience.\n Attendees will leave with a clear understanding of CRA responsibility boundaries, compliance routes, and the role of open source in a secure European software supply chain.\n\n[Open in Sched](https://osselceu2026.sched.com/event/77ed8249c490535507852d68a07ba5be)", "url": "https://osselceu2026.sched.com/event/77ed8249c490535507852d68a07ba5be", "persons": [{"public_name": "Madalin Neag"}]}, {"guid": "oss-940d6f8a396887d31f4897f41c1c49e5", "id": "oss-940d6f8a396887d31f4897f41c1c49e5", "title": "One Scan To Rule Them All: Towards Shared Open Data Infrastructure", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Open source supply chain decisions such as what to depend on, what to ship, and what to trust are only as good as the open data behind them. \n \n The organizations working hardest to produce that open data are largely doing it in parallel. OpenSSF Scorecard scans 1.3 million packages a week. ClearlyDefined has scanned over 55 million and AboutCode over 20 million, both with ScanCode. We share the same problem: we're scanning and rescanning the same packages for the same (or similar) data.\n \n That redundancy has real costs. Compute, maintainer time, and contributor energy spent on work that's already done is capacity not spent on expanding coverage, improving accuracy, or hardening infrastructure.\n \n It's time to build together. This talk is a conversation about what it would look like to join forces on open software supply chain data, produced with open source tools and backed by open standards with shared infrastructure and aligned and unlocked datasets for wider usage. We'll explore where our data models overlap, where they diverge, and what collaboration would require, so we all can get sustainable, high-quality, and open supply chain data at ecosystem scale faster together.\n\n[Open in Sched](https://osselceu2026.sched.com/event/940d6f8a396887d31f4897f41c1c49e5)", "url": "https://osselceu2026.sched.com/event/940d6f8a396887d31f4897f41c1c49e5", "persons": [{"public_name": "Philippe Ombredanne"}, {"public_name": "Stephen Augustus"}]}, {"guid": "oss-171122ff24a3c0f2c06c8f89e5d34b0b", "id": "oss-171122ff24a3c0f2c06c8f89e5d34b0b", "title": "Running OSPOs at Scale: Hard-Won Lessons From Germany Industry", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 1 A (Floor 1)", "track": "OSS: OSS Enabling & Management", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most organizations know they should manage open source strategically and efficiently. Few know how to actually do it when you're moving fast, resources are tight, and a supply chain incident can land on the front page.\n \n Over the past several years, we've helped build and run Open Source Program Offices across multiple large German automotive and technology organizations. This session distills what actually worked - and what didn't.\n \n We'll share concrete lessons on: getting buy-in from C-level to developer teams; surviving and learning from supply chain security incidents; scaling compliance without drowning engineers in process; using AI to cut OSPO workflow overhead; and growing open source contribution and compliance culture.\n \n Along the way, we'll show how we used OSS Review Toolkit (ORT), a Linux Foundation project, as the automation backbone - and what we learned making it work in large, regulated industries.\n \n You'll leave with a clearer picture of what it takes to scale open-sourcing and compliance in a regulated industry, and the mistakes worth skipping.\n\n[Open in Sched](https://osselceu2026.sched.com/event/171122ff24a3c0f2c06c8f89e5d34b0b)", "url": "https://osselceu2026.sched.com/event/171122ff24a3c0f2c06c8f89e5d34b0b", "persons": [{"public_name": "Thomas Steenbergen"}, {"public_name": "Helio Chissini de Castro"}]}], "South Hall 1 B (Floor 1)": [{"guid": "oss-ab606dc8340e9c09a18dd09cbc6475f4", "id": "oss-ab606dc8340e9c09a18dd09cbc6475f4", "title": "Pairing PX4 and ROS 2 Through Micro XRCE-DDS and Zenoh-pico, a Comparison", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Since Micro XRCE-DDS replaced Fast-RTPS in PX4 version 1.14 the support for direct communication between ROS 2 and PX4 never stopped improving.\n With PX4 stable version 1.17 recently released and version 1.18 close to enter its beta testing phase this presentation aims to cover the latest changes, imporvents and limitations of the Micro XRCE-DDS and Zenoh-pico interfaces.\n The presentation will also compare the two communication methods to give the audience all the information necessary to choose the best approach given their requirements and application contraints.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ab606dc8340e9c09a18dd09cbc6475f4)", "url": "https://osselceu2026.sched.com/event/ab606dc8340e9c09a18dd09cbc6475f4", "persons": [{"public_name": "Beniamino Pozzan"}]}, {"guid": "oss-2c0ab08b37b41f3abd5fa0c972a32a49", "id": "oss-2c0ab08b37b41f3abd5fa0c972a32a49", "title": "Cryptographic Flight Security: Implementing Hardware-Enforced FAA Remote ID and Trusted Identities", "date": "2026-10-09T11:25:00+02:00", "start": "11:25", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Global regulatory shifts—driven by strict NDAA requirements and EASA U-Space mandates—require drone manufacturers to implement verifiable supply chain security. Software-only implementations of FAA Remote ID remain vulnerable to key spoofing and firmware tampering. This session delivers a practical breakdown of how to enforce a hardware root of trust by embedding physical Secure Elements (like the OPTIGA Trust M) into open flight controllers running PX4 and NuttX.\n We will bypass high-level concepts to dive straight into the embedded architecture:\n Configuring the SPI/I2C bus interface between the flight MCU (PSoC C3M) and the security peripheral.\n Modifying the NuttX driver layer to offload ECDSA signing keys for broadcast messages without blocking safety-critical flight loop threads.\n Structuring secure boot sequences to protect downstream firmware from local physical exploits.\n We will share timing benchmarks showing how to manage cryptographic latency within standard PX4 task frequencies to build compliant systems without sacrificing real-time flight performance.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2c0ab08b37b41f3abd5fa0c972a32a49)", "url": "https://osselceu2026.sched.com/event/2c0ab08b37b41f3abd5fa0c972a32a49", "persons": [{"public_name": "Ashok Kumar"}]}, {"guid": "oss-674728bb6496502ef00a60e28a883ffa", "id": "oss-674728bb6496502ef00a60e28a883ffa", "title": "Why Switch To External Flight Modes?", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "When it comes to controlling PX4 from a companion computer, developers are often spoiled for choice - leading to confusion about which architecture best suits their specific mission requirements. Historically, Offboard Mode has been the go-to default, but the evolution of the PX4 ecosystem has introduced powerful alternatives like External Flight Modes and the native ROS 2 Control Interface. This session provides a technical breakdown of how PX4 handles companion computer inputs under both paradigms. We will explore how External Flight Modes register directly with PX4's internal mode manager, allowing custom autonomy apps to behave like native flight modes with built-in safety boundaries. Attendees will learn the differences between these methods, the performance benefits of moving to the ROS 2 bridge, and a practical migration path to transition legacy offboard code into robust, external ROS 2 applications.\n\n[Open in Sched](https://osselceu2026.sched.com/event/674728bb6496502ef00a60e28a883ffa)", "url": "https://osselceu2026.sched.com/event/674728bb6496502ef00a60e28a883ffa", "persons": [{"public_name": "Dawid Rudy"}]}, {"guid": "oss-10b39847a81a82c90d631cf2d745b6e6", "id": "oss-10b39847a81a82c90d631cf2d745b6e6", "title": "A Tour of the New EKF2", "date": "2026-10-09T12:15:00+02:00", "start": "12:15", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "EKF2 is the heart of PX4's navigation, and over the past few years it has quietly received a series of improvements that make it more accurate, more robust, and easier to work with. In this talk I'll walk through the most significant ones. We'll start with a short recap of the filter's architecture, then cover the move to a proper error-state formulation, along with its symbolic derivation and code generation using SymForce. We'll then see how this makes it easy to add a new state or measurement, as we did for the terrain state. From there we'll turn to round-earth navigation, paired with a position-dependent gravity model, which replaces the flat-earth assumptions to support long-range and high-latitude flight. We'll also look at how the Joseph-stabilized covariance update not only makes the filter more numerically stable, but also lets us perform partial updates, which we rely on heavily in the magnetometer and optical-flow fusion. Finally, we'll look ahead at the next changes coming to EKF2 and some of the ideas we're exploring.\n\n[Open in Sched](https://osselceu2026.sched.com/event/10b39847a81a82c90d631cf2d745b6e6)", "url": "https://osselceu2026.sched.com/event/10b39847a81a82c90d631cf2d745b6e6", "persons": [{"public_name": "Mathieu Bresciani"}]}, {"guid": "oss-6653e58744416a3b82114bf564967b58", "id": "oss-6653e58744416a3b82114bf564967b58", "title": "Adding ESP32/Xtensa Silicon and Custom Boards To PX4", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This talk will introduce a new MCU architecture that PX4 only recently supported: the Xtensa ESP32. Using it as a walk-through, we'll demonstrate the software components needed to add your own custom board, contribute to or expand existing MCU architecture support, and highlight how PX4's compile process is designed to be agnostic to the underlying MCU architecture. Some highlights will be: How PX4 interacts with NuttX at a low level, and why that relationship is central to bringing up new hardware The role of the High Resolution Timer (HRT) in PX4's timekeeping, and what it takes to implement it for a new architecture The difference between Menuconfig and boardconfig, and when to use each when defining your board's peripherals and pin allocation How PX4's build system sets up the compilation environment for NuttX, and how to configure it for your specific board How PX4 is designed to be MCU-agnostic, and what that means in practice when working at the boundary between PX4 and NuttX\n\n[Open in Sched](https://osselceu2026.sched.com/event/6653e58744416a3b82114bf564967b58)", "url": "https://osselceu2026.sched.com/event/6653e58744416a3b82114bf564967b58", "persons": [{"public_name": "Henry Kotzé"}]}, {"guid": "oss-e36b17062155979ff6caa320eb0b227b", "id": "oss-e36b17062155979ff6caa320eb0b227b", "title": "PX4 on Open Silicon: Flight Control and AI Workloads on Multi-Core RISC-V", "date": "2026-10-09T14:20:00+02:00", "start": "14:20", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "While PX4 is open source, the underlying hardware often remains tied to proprietary vendor black boxes. This creates a gap for PX4 developers and sovereignty-sensitive applications that need an inspectable full stack all the way down to silicon. This session presents CORE-ET, a fully open-source RISC-V platform that can scale from a 16-hardware-thread Erbium configuration to systems with more than 2000 cores. We will show a simulation demo of Erbium running PX4 alongside onboard AI: PX4/control runs on two hardware threads, while the remaining 14 run workloads such as vision, depth, VIO, or object detection. We will discuss the porting structure, real-time capabilities, and measurements needed to show flight control running alongside local inference. The result is a path toward drones where both software and hardware are open and inspectable.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e36b17062155979ff6caa320eb0b227b)", "url": "https://osselceu2026.sched.com/event/e36b17062155979ff6caa320eb0b227b", "persons": [{"public_name": "Afonso Oliveira"}]}, {"guid": "oss-1590f850c73d3d9f22424543bbf5c7f4", "id": "oss-1590f850c73d3d9f22424543bbf5c7f4", "title": "The PX4 Airspeed Pipeline", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Airspeed sits at the center of fixed-wing flight. It determines how much lift the wings generate, how effective the control surfaces are, and ultimately how the aircraft can be controlled. As a result, it influences nearly every aspect of flight, from stability and maneuvering to energy management. Yet the airspeed value used throughout PX4 is far from a simple sensor reading. Behind a seemingly simple number lies a surprisingly large stack of sensor physics, conversions, calibration procedures, validation logic, control scaling, and TECS handling. This talk traces the airspeed pipeline end-to-end: from pitot-tube measurements, through IAS → CAS → TAS conversion, in-flight calibration, and validation, to the controllers that ultimately use it. We'll also examine real-world failure modes from the PX4 community and show how to diagnose them from flight logs.\n\n[Open in Sched](https://osselceu2026.sched.com/event/1590f850c73d3d9f22424543bbf5c7f4)", "url": "https://osselceu2026.sched.com/event/1590f850c73d3d9f22424543bbf5c7f4", "persons": [{"public_name": "Mahima Yoga"}]}, {"guid": "oss-8dc30f398b6852a02a28c6cbf564cafd", "id": "oss-8dc30f398b6852a02a28c6cbf564cafd", "title": "Total Energy Control: A Deep Dive Into TECS in PX4", "date": "2026-10-09T15:10:00+02:00", "start": "15:10", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Total Energy Control System (TECS) coordinates throttle and pitch to manage a fixed-wing vehicle's airspeed and altitude as a single energy problem — but for many users it remains a black box of tuning parameters. This talk opens it up. We start from first principles, deriving how TECS balances kinetic and potential energy and why throttle and pitch are the natural levers to control them. We then cover the controller's concept, its architecture in PX4, a structured approach to tuning, and the shortcomings every operator eventually hits. Finally, we distill seven years of hands-on TECS tuning into the heuristics and hard-won insights that don't appear in the documentation. Whether you're tuning your first fixed-wing or maintaining a fleet, you'll leave with a clearer mental model of what TECS is really doing.\n\n[Open in Sched](https://osselceu2026.sched.com/event/8dc30f398b6852a02a28c6cbf564cafd)", "url": "https://osselceu2026.sched.com/event/8dc30f398b6852a02a28c6cbf564cafd", "persons": [{"public_name": "Silvan Fuhrer"}]}, {"guid": "oss-d06fe53094a9e5a270b9a85ff4cb111b", "id": "oss-d06fe53094a9e5a270b9a85ff4cb111b", "title": "VTOL Control Architecture - A Birds-eye View", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Is it a multicopter? Is it a fixed-wing? Not quite: It is a quantum superposition of both, and only upon flipping the transition switch we can observe the VTOL state with certainty. VTOL vehicles bridge the design space between either pure vehicle type and enable long, efficient flights combined with accurate and soft landings. However, they challenge our software engineering and architecture skills, and properly supporting all VTOL vehicles in PX4 is quite the balancing act. In this talk, we will go over the architecture and implementation decisions that connect those two vehicle types within a running system. We will visit some VTOL specific features and see where they slot in, and finally we will conclude with possible paths for further improving VTOL support in PX4.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d06fe53094a9e5a270b9a85ff4cb111b)", "url": "https://osselceu2026.sched.com/event/d06fe53094a9e5a270b9a85ff4cb111b", "persons": [{"public_name": "Balduin Dettling"}]}, {"guid": "oss-906a2bf52051d4fad90244df8d379eb1", "id": "oss-906a2bf52051d4fad90244df8d379eb1", "title": "From Gazebo Simulation To Flight Operations: Developing a Production Precision Landing System", "date": "2026-10-09T16:00:00+02:00", "start": "16:00", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Autonomous VTOL aircraft require reliable, precision landing capabilities to enable real world applications from package delivery to infrastructure inspection. This session presents a complete open-source precision landing system built on ROS 2 and PX4, covering the full development lifecycle from high fidelity simulations to flight tested deployment.\n \n We'll walk through how we developed, validated, and refined a multi-sensor perception and control stack that achieves centimeter-level landing accuracy using only commodity sensors and open-source tools. The system uses AprilTag fiducials for dock detection, fuses visible and infrared camera streams with a Kalman filter for robust pose estimation, and executes a phased descent state machine with real-time PID control.\n \n The presentation covers:\n Simulation first development: Building a Gazebo SITL environment with realistic sensor models \n ROS 2 + PX4 integration: Bridging autopilot and perception via micro-XRCE-DDS, \n Production deployment: Lessons learned scaling from lab prototype to field-tested hardware. Practical guidance on composing a production system from ROS packages, PX4 firmware, and community-contributed modules.\n\n[Open in Sched](https://osselceu2026.sched.com/event/906a2bf52051d4fad90244df8d379eb1)", "url": "https://osselceu2026.sched.com/event/906a2bf52051d4fad90244df8d379eb1", "persons": [{"public_name": "Andrei Cuenca"}]}, {"guid": "oss-524f933dfacc31ee191a0f28a9d9cbe1", "id": "oss-524f933dfacc31ee191a0f28a9d9cbe1", "title": "Robotics Is Becoming Distributed Systems - Lessons Learned Building Multi-UAV Architectures", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "PX4 and MAVSDK have made controlling individual drones remarkably accessible. Building systems around fleets, however, introduces a different class of challenges. While developing a distributed multi-UAV architecture, we repeatedly discovered that many problems that initially appeared to be robotics problems were, in fact, distributed-systems problems. Task execution, telemetry aggregation, observability, fault tolerance, and fleet coordination quickly became more important than vehicle control itself. This talk presents the architectural lessons that emerged from this work. It covers the separation of control and orchestration, the shift from commands to tasks, event-driven architectures, spatial state, and observability. A recurring theme is that fleet management can be viewed as a space-time scheduling problem involving heterogeneous resources. From this perspective, many challenges beyond individual vehicles are problems of state, scheduling, and coordination. The session connects PX4 and MAVSDK with ideas from distributed systems and scheduling theory, highlighting reusable patterns for scalable autonomous systems.\n\n[Open in Sched](https://osselceu2026.sched.com/event/524f933dfacc31ee191a0f28a9d9cbe1)", "url": "https://osselceu2026.sched.com/event/524f933dfacc31ee191a0f28a9d9cbe1", "persons": [{"public_name": "Pawel Sawicki"}]}, {"guid": "oss-b8dc6b09f8d99b0afae28197c8284f16", "id": "oss-b8dc6b09f8d99b0afae28197c8284f16", "title": "Self-Defending Swarms: MAVLink Signing Meets Peer-Consensus Exclusion Onboard PX4", "date": "2026-10-09T16:50:00+02:00", "start": "16:50", "duration": "00:20", "room": "South Hall 1 B (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This isn't just about Airtel but for every organisation as MAVLink has supported per-message signing since MAVLink 2, yet almost no real-world PX4 fleet enables it, because key distribution, rotation & revocation across dozens of airborne vehicles has no production-ready tooling, so most swarms still accept any correctly formatted command from whatever radio reaches them. A single spoofed ground station or one drone with cloned key can inject commands rest of swarm has no way to reject. Talk introduces swarm-native trust layer that issues short-lived, mission-scoped MAVLink signing keys from a lightweight onboard authority, lets every drone verify signatures independently without round-tripping to a ground station & adds a peer-consensus exclusion protocol so that if one drone starts broadcasting commands inconsistent with its own attested mission profile, the rest of swarm votes to ignore it mid-flight without operator intervention. We demonstrate this on PX4 SITL & real hardware over a Zenoh-based inter-drone link, show a live command-injection attack being rejected by consensus & discuss key rotation strategy under degraded or fully lost ground-station connectivity mid-mission.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b8dc6b09f8d99b0afae28197c8284f16)", "url": "https://osselceu2026.sched.com/event/b8dc6b09f8d99b0afae28197c8284f16", "persons": [{"public_name": "Yogesh Sardana"}]}], "South Hall 2 A (Floor 2)": [{"guid": "oss-9d594fa4b21bb68eab4503547b583490", "id": "oss-9d594fa4b21bb68eab4503547b583490", "title": "Clocks in Zephyr: A Practical Guide for BSP Developers (Lesson Learned From a Real Porting)", "date": "2026-10-09T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Clocks are easy to ignore until your first Zephyr BSP port — when UART, SPI, or DMA suddenly depend on device tree properties you have never touched.\n This beginner-friendly talk explains how clocks work in Zephyr today: clocks as phandle-arrays (like pwms and gpios), the meaning of #clock-cells, and how DT macros connect DTS to driver code. We separate three everyday questions: enabling a clock, selecting its source, and reading its rate — mapped to clock_control_on(), clock_control_configure(), and get_rate().\n We then cover practical porting decisions any SoC author faces: what to describe in device tree at boot, what to leave to runtime (for example power management), and common mistakes — wrong cells, gates versus muxes and over-modelling hardware in DT.\n Finally, we look at where Zephyr is heading: RFCs for a Clock Management Subsystem propose richer clock trees and predefined clock states, closer to how silicon is wired. You will leave with a reusable mental model for today’s APIs and a map of tomorrow’s direction.\n Audience: developers new to Zephyr, BSP porters, and device tree authors. No prior clock-driver experience required.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9d594fa4b21bb68eab4503547b583490)", "url": "https://osselceu2026.sched.com/event/9d594fa4b21bb68eab4503547b583490", "persons": [{"public_name": "Martin Hoff"}]}, {"guid": "oss-61cbd3bc5345b3a09dc2e98a1dd2673f", "id": "oss-61cbd3bc5345b3a09dc2e98a1dd2673f", "title": "Apps, Not Firmware: A Service-Oriented Application Layer for Zephyr", "date": "2026-10-09T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Microcontroller firmware is monolithic: one image, one failure domain, where a bug anywhere can crash everything. Yet modern MCUs ship with memory protection (MPU, MMU, or PMP), and Zephyr already has the isolation pieces - userspace, memory domains, kernel-object capabilities, watchdogs, zbus - never assembled into an application model.\n \n This talk presents a service-oriented application layer for Zephyr: multiple memory-isolated apps running as managed units, each reaching hardware and the network only through a capability-gated service broker, so a misbehaving app cannot corrupt, starve, or crash its neighbors.\n \n We build the missing keystone - an app-group lifecycle and a service broker - on top of existing Zephyr, and demonstrate it live: two isolated apps share one Wi-Fi stack, each making independent network requests; one hangs and another faults, both are killed and reclaimed, while the healthy app runs on. We close with hardware lessons and upstreamable RFC targets.\n\n[Open in Sched](https://osselceu2026.sched.com/event/61cbd3bc5345b3a09dc2e98a1dd2673f)", "url": "https://osselceu2026.sched.com/event/61cbd3bc5345b3a09dc2e98a1dd2673f", "persons": [{"public_name": "Sylvio Alves"}]}, {"guid": "oss-b90f8f1cd9557825739d0bfdb7caf773", "id": "oss-b90f8f1cd9557825739d0bfdb7caf773", "title": "Zenbedded: Bringing Ros2_control Closer To the Embedded World", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Robot Operating System (ROS) is the de facto standard open-source middleware for building robot software, providing standardized messaging, tooling, and reusable components. ros2_control is a hardware-agnostic control framework focusing on the modular composition of control systems for robots, sharing of controllers as well as real-time performance.\n \n Bringing ros2_control to embedded systems usually means bolting heavy DDS serialization and a bridge process onto microcontrollers. Zenbedded fixes this. It is a monolithic Zephyr, Zenoh, and ROS 2 framework built specifically for ros2_control. We put the transport, the RTOS client library, and the host-side hardware_interface plugin into one tight repository.\n On the wire, we use a multi-tier transport that moves along a spectrum. You can choose between fully ROS-observable but slightly slower, or fully binary-encoded and fast, depending on what your control loop actually needs.\n You'll leave with a pattern for running ros2_control on Zephyr-class hardware and a feel for working with ROS and ros2_control. We'll demo the stack balancing a real inverted pendulum on an ESP32, where latency is the difference between upright and toppled.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b90f8f1cd9557825739d0bfdb7caf773)", "url": "https://osselceu2026.sched.com/event/b90f8f1cd9557825739d0bfdb7caf773", "persons": [{"public_name": "Christoph Froehlich"}]}, {"guid": "oss-bc2f8049e1f5a0c639b7a6d43d69abf0", "id": "oss-bc2f8049e1f5a0c639b7a6d43d69abf0", "title": "Libiio on Zephyr: A Unified API for Industrial I/O Across Linux and RTOS Targets", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "libiio is an open source C library developed by Analog Devices for interfacing with Industrial I/O (IIO) devices - ADCs, DACs, IMUs, RF transceivers, temperature sensors, and more. It underpins a broad ecosystem of host-side tools including Scopy, pyadi-iio, and MATLAB, all of which connect to targets over network, serial, or USB transports. This talk walks through the architecture and practical mechanics of the port. We will cover how libiio's external backend integrates with Zephyr's device model, allowing any driver that implements the IIO device driver API to appear as a first-class IIO device. We will look at built-in bridge drivers that wrap any Zephyr ADC, DAC, or sensor device into an IIO device. We will also cover how the module integrates into the Zephyr build system using Kconfig, device tree, and snippets to enable libiio with minimal changes to an application. We will demonstrate a Zephyr board being queried from Scopy and pyadi-iio, and close with a look at what is in progress - trigger support for deterministic sampling and streaming, and a USB transport as a complement to the existing UART and network transports.\n\n[Open in Sched](https://osselceu2026.sched.com/event/bc2f8049e1f5a0c639b7a6d43d69abf0)", "url": "https://osselceu2026.sched.com/event/bc2f8049e1f5a0c639b7a6d43d69abf0", "persons": [{"public_name": "Maureen Helm"}, {"public_name": "Pete Johanson"}]}, {"guid": "oss-2d6a30ac833cb2435f659954861e5ac6", "id": "oss-2d6a30ac833cb2435f659954861e5ac6", "title": "Amalgamation", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Amalgamation is a build strategy used by projects like sqlite3 that combines C sources files into a single source file for various reasons. One such reason is to give the compiler greater visibility across the program for performance gains. sqlite3 claims 5-10% net performance gains in doing so.\n \n Does applying the technique to parts of Zephyr net us any gains? If so why and where, and what are the trade offs involved?\n\n[Open in Sched](https://osselceu2026.sched.com/event/2d6a30ac833cb2435f659954861e5ac6)", "url": "https://osselceu2026.sched.com/event/2d6a30ac833cb2435f659954861e5ac6", "persons": [{"public_name": "Tom Burdick"}]}, {"guid": "oss-ee8a07064b1f9e852dcb51a4cfc0131e", "id": "oss-ee8a07064b1f9e852dcb51a4cfc0131e", "title": "In-depth AI application analysis in Zephyr with Zephelin and the Instrumentation Subsystem", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:20", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "When developers work on computationally heavy applications on constrained devices, such as AI-enabled sensor analysis in Zephyr RTOS, they need to delve into the execution details to identify bottlenecks and perform optimizations.The open source Zephelin tracing and profiling library, an External Module for Zephyr RTOS, provides an easy way to trace the execution of applications in real-time while collecting detailed information about the system state. It allows to collect traces from devices at a configurable level of detail, from user-defined events up to every single call in the application, and later display them in Zephelin Trace Viewer. Apart from traces,the viewer displays resource usage and statistics specific to the executed AI models, using runtimes like LiteRT or microTVM, capturing information about the executed layers, their hyperparameters, resource usage and execution time.This talk discusses how integrating Zephelin and Trace Viewer into the workflow helps develop Zephyr products with AI/ML inference workloads, and how the addition of the new Instrumentation Subsystem in Zephyr, created alongside Zephelin, allows for even more detailed performance analysis.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ee8a07064b1f9e852dcb51a4cfc0131e)", "url": "https://osselceu2026.sched.com/event/ee8a07064b1f9e852dcb51a4cfc0131e", "persons": [{"public_name": "Greg Latosinski"}]}, {"guid": "oss-db9cb7d0ef7a160b028b66b204c158c1", "id": "oss-db9cb7d0ef7a160b028b66b204c158c1", "title": "Linkable Loadable Extensions and the Extension Developer Kit", "date": "2026-10-09T15:10:00+02:00", "start": "15:10", "duration": "00:20", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Linkable Loadable Extensions (LLEXT) subsystem supports loading and linking ELF files at runtime, enabling developers to add sandboxed plugin-like functionality to Zephyr applications. This session offers a discussion of how LLEXT works and how it can work for you, as well as an overview of the Extension Developer Kit (EDK). The EDK allows users to build extensions without building the main binary, enabling teams working on complex firmware to neatly divide efforts between individual loadable modules and the main binary.\n\n[Open in Sched](https://osselceu2026.sched.com/event/db9cb7d0ef7a160b028b66b204c158c1)", "url": "https://osselceu2026.sched.com/event/db9cb7d0ef7a160b028b66b204c158c1", "persons": [{"public_name": "Lauren Murphy"}]}, {"guid": "oss-d1ba5664223d09f63ab70be30306c153", "id": "oss-d1ba5664223d09f63ab70be30306c153", "title": "Let Your CI Catch Your Stack Overflows, Before They Hit Your Testing or the Field", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:20", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Static program analysis can help us to save a lot of time to catch bugs before they cause real-world issues. Inspired by the already in west integrated puncover target I want to present and discuss my advances and experiments and how this especially can help during code review and development as part as the CI pipeline in application development to correctly configure necessary stack sizes and get warned on potential stack overflows.\n \n Further ideas around how this could also benefit zephyr development are presented like checking subsystem enabled threads stack sizes across multiple boards.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d1ba5664223d09f63ab70be30306c153)", "url": "https://osselceu2026.sched.com/event/d1ba5664223d09f63ab70be30306c153", "persons": [{"public_name": "Paul Würtz"}]}, {"guid": "oss-72add531eb43b01aeb2e8a5d2e12dc84", "id": "oss-72add531eb43b01aeb2e8a5d2e12dc84", "title": "Crash Dumps Without Cables: Live Coredump Capture Over UDP/Ethernet in Zephyr RTOS", "date": "2026-10-09T16:00:00+02:00", "start": "16:00", "duration": "00:20", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "When an embedded system crashes in the field, recovering the coredump often determines whether debugging takes hours or weeks. Zephyr has long supported coredumps over UART, but in modern industrial, IoT, and edge deployments the serial port is rarely accessible. Devices may be sealed in cabinets, deployed remotely, or connected only via network. This talk introduces a new Zephyr coredump backend that streams crash data over UDP (IPv4/IPv6) at the moment of a fatal exception—no USB cable or physical access required. We will explore the design challenges of networking in the fatal path, including safely re-enabling interrupts so the NIC can transmit, and the ZCDU framing protocol used to packetize and reliably reassemble dumps from UDP datagrams. We also show how the host receiver integrates seamlessly with the existing Zephyr GDB workflow, making the switch from UART to Ethernet a simple Kconfig option. Attendees will learn how to enable fleet-scale crash capture and dramatically reduce time-to-root-cause for deployed Zephyr devices. pull request : https://github.com/zephyrproject-rtos/zephyr/pull/108410\n\n[Open in Sched](https://osselceu2026.sched.com/event/72add531eb43b01aeb2e8a5d2e12dc84)", "url": "https://osselceu2026.sched.com/event/72add531eb43b01aeb2e8a5d2e12dc84", "persons": [{"public_name": "Kedareswara Rao Appana"}]}, {"guid": "oss-cbb3398644ed9474ad1c428812cbfad2", "id": "oss-cbb3398644ed9474ad1c428812cbfad2", "title": "Scaling Zephyr Hardware CI Across Continents", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 2 A (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most Zephyr CI talks focus on Twister with a single board. This talk covers what happens when your hardware spans continents, operating systems, and team boundaries, and every PR still needs to test against all of it. Our Zephyr firmware targets proFPGA systems programmed via Windows-only scripts, Protium emulators on Linux servers with J-Links on Windows machines, MAX32xxx boards on Linux, and virtual platforms. Discrete teams — hardware, virtual platform, proFPGA, Protium, bare-metal, Debugger Scripts, and Zephyr — each own a different piece on different platforms. We built CI that unifies all of this so a developer opening a PR gets feedback from real hardware regardless of board, country, or OS. The talk covers device-specific flashing automation, reusable workflows scaling from PRs to nightly runs, observability beyond pass/fail (memory footprint tracking, runner dashboards, test analytics), and the technical interfaces between teams that make it sustainable. Every pattern is in production today, testing across 28+ boards in multiple countries and different toolchains on every pull request.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cbb3398644ed9474ad1c428812cbfad2)", "url": "https://osselceu2026.sched.com/event/cbb3398644ed9474ad1c428812cbfad2", "persons": [{"public_name": "Anıl Özrenk"}]}], "South Hall 2 B (Floor 2)": [{"guid": "oss-39348b3d541fa449cd5bba7ea3db0f90", "id": "oss-39348b3d541fa449cd5bba7ea3db0f90", "title": "From Zero Hardware To Production: High-Performance Sensors With Zephyr", "date": "2026-10-09T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "This talk shares practical lessons learned from building multi-platform sensor firmware on Zephyr RTOS for industrial alignment tools. Zephyr enabled our team to deliver a high-quality solution despite an extremely tight project schedule. Early prototyping along with Zephyr’s native simulator (native_sim) enables firmware development and testing long before first PCBs are available. A modular architecture based on message queues and the Kconfig system allows for independent, testable components. \n Finally, we dive into the hardware-facing challenges we encountered and solved: deterministic event handling under tight timing constraints and zero-CPU data acquisition using DMA-driven ADC pipelines.\n Attendees will gain insights into structuring scalable Zephyr firmware, accelerating development without hardware, and building high-performance embedded systems with confidence.\n\n[Open in Sched](https://osselceu2026.sched.com/event/39348b3d541fa449cd5bba7ea3db0f90)", "url": "https://osselceu2026.sched.com/event/39348b3d541fa449cd5bba7ea3db0f90", "persons": [{"public_name": "Jan Germer"}]}, {"guid": "oss-f6a4bd08b9b50e408af94f00d2fa30c3", "id": "oss-f6a4bd08b9b50e408af94f00d2fa30c3", "title": "Playing Audio on a SoC DAC Output With Zephyr", "date": "2026-10-09T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Some SoCs have an embedded DAC peripheral, which allow to play low or medium resolution audio with minimal electronics, no advanced I2S external codec required.\n \n In this talk, I present a list of ingredients required to make an acceptable audio output:\n - The DAC: what it is, how it is different from PWM audio output or I2S peripherals\n - DMA, your DAC’s best friend, to run continuously and without drops\n - Debug something fast and real-time thanks to tracing\n \n Then I will discuss implementation, with the codec subsystem. Example platform will be ST STM32F7 and Atmel ATSAM3X8E.\n \n Finally, if nothing crashes or burn in the meantime, I will give a demonstration.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f6a4bd08b9b50e408af94f00d2fa30c3)", "url": "https://osselceu2026.sched.com/event/f6a4bd08b9b50e408af94f00d2fa30c3", "persons": [{"public_name": "Eve Redero"}, {"public_name": "Ugo Marchand"}]}, {"guid": "oss-801d496c920db89bc20bdb53c88de074", "id": "oss-801d496c920db89bc20bdb53c88de074", "title": "Demystifying Pinctrl: Pin Multiplexing in Zephyr", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Pin multiplexing is always needed in embedded development. But when we start changing pins in a devicetree overlay, or when creating a custom board, things can quickly become confusing: build errors, wrong pin states, peripherals not starting, or hardware that simply does not behave as expected. In Zephyr, the pinctrl subsystem is what connects the physical pins of the SoC with the peripherals we want to use. It defines the pin function, the electrical configuration, and the pin states used by the drivers. In this talk, we will demystify pin multiplexing in Zephyr and explain how to use pinctrl in devicetree in simple words. We will go step by step through pin groups, pin states, common configurations, overlays, board files, and SoC-specific syntax. We will also use practical examples for common peripherals and vendor families, and show how to debug the most frequent issues when customizing pins.\n\n[Open in Sched](https://osselceu2026.sched.com/event/801d496c920db89bc20bdb53c88de074)", "url": "https://osselceu2026.sched.com/event/801d496c920db89bc20bdb53c88de074", "persons": [{"public_name": "Roy Jamil"}]}, {"guid": "oss-599befd44ef89c8a0c31a3072225a513", "id": "oss-599befd44ef89c8a0c31a3072225a513", "title": "Measuring What Matters: Introducing Hardware Performance Counters in Zephyr RTOS", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Embedded developers optimizing Zephyr applications often rely on software timers and GPIO toggles—intrusive techniques that alter the behavior they try to measure. Modern SoCs instead provide rich hardware performance counters across the system: CPU PMUs, interconnect/NoC monitors, and memory subsystem telemetry that capture cycles, cache behavior, bandwidth, and contention with near-zero overhead. Until now, Zephyr lacked a unified way to access these metrics. This talk introduces Zephyr’s new portable **pmu.h** API, a cross-architecture abstraction for hardware performance monitoring. We present the first backend: an ARMv8-A PMUv3 driver that probes counters at runtime, self-calibrates CPU frequency, and maintains per-CPU state using IRQ-locked sequences for SMP safety. Using real hardware benchmarks, we show how to measure context-switch cost, IRQ latency, cache behavior, branch prediction, and memory bandwidth. Attendees will learn how to add low-overhead profiling to their applications today and how the API will extend to RISC-V HPM, Cortex-M DWT, and SoC-level monitors without changing application code. Pull request: https://github.com/zephyrproject-rtos/zephyr/pull/107016\n\n[Open in Sched](https://osselceu2026.sched.com/event/599befd44ef89c8a0c31a3072225a513)", "url": "https://osselceu2026.sched.com/event/599befd44ef89c8a0c31a3072225a513", "persons": [{"public_name": "Kedareswara Rao Appana"}]}, {"guid": "oss-12d51bee6cd3209ef68bc6dd0daefa03", "id": "oss-12d51bee6cd3209ef68bc6dd0daefa03", "title": "Multiple Cores, One Zephyr: The Path To Cortex-M SMP in Zephyr", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Multi-core ARM Cortex-M SoCs are becoming increasingly common in today's market. Yet Zephyr RTOS only supports Asymmetric Multiprocessing (AMP) for these devices. The problem with AMP is that it limits true resource sharing, and leaves hardware parallelism underutilized. Symmetric Multiprocessing (SMP) addresses these issues by running a single Zephyr RTOS image with a unified scheduler across all cores. Zephyr RTOS currently lacks support for Symmetric Multiprocessing on ARM Cortex-M based SoCs and hence limits multi-core Cortex-M devices to AMP configurations. This talk presents a Proof-of-Concept implementation of SMP on Dual Core Cortex-M7 cores using the Infineon Traveo T2G (CYT4DN) SoC which runs a single Zephyr image with true parallel execution across cores. The key framework challenges are: lack of a secondary boot up path for the secondary cores and the complications of unified timekeeping with per-core SysTick timers. The talk details what has been achieved, the limitations that remain in timeout-driven context switching and scheduling, and outlines a path toward upstream-ready Cortex-M SMP support in Zephyr.\n\n[Open in Sched](https://osselceu2026.sched.com/event/12d51bee6cd3209ef68bc6dd0daefa03)", "url": "https://osselceu2026.sched.com/event/12d51bee6cd3209ef68bc6dd0daefa03", "persons": [{"public_name": "Sanjay Vallimanalan"}]}, {"guid": "oss-70afb911def82ccb7bc7224fae3d68ec", "id": "oss-70afb911def82ccb7bc7224fae3d68ec", "title": "Zephyr-Based VIRTIO Backend on Xen: From Tiny Driver Domains To Real Hardware Integration", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Linux-based Xen Driver Domains are powerful, but they increase the trusted computing base and add complexity to systems that need tight isolation, fast startup, and auditable software components.\n \n This talk updates the Zephyr-based VIRTIO backend for Xen, an effort to run selected VIRTIO backend functions in small, purpose-built Zephyr driver domains. The goal is to preserve Xen’s proven architecture while enabling a finer-grained model: separate lightweight domains for network, storage, or platform-specific services.\n \n Over the past half year, the project has moved toward platform integration. Upstreaming work has progressed, real-hardware demos are being developed on Renesas R-Car V4H, and integration with SoDeV, an SDV platform by Automotive Grade Linux, is underway.\n \n The session will cover the architecture, current upstream status, and obstacles to using it across platforms. Attendees will leave with a realistic view of where Zephyr-based driver domains can reduce the trusted computing base, what challenges remain, and how to contribute to lightweight open-source driver domains for edge and automotive systems.\n\n[Open in Sched](https://osselceu2026.sched.com/event/70afb911def82ccb7bc7224fae3d68ec)", "url": "https://osselceu2026.sched.com/event/70afb911def82ccb7bc7224fae3d68ec", "persons": [{"public_name": "Hiroshi Tokita"}]}, {"guid": "oss-97df8a2dbf14d584dc2854f3391b40e3", "id": "oss-97df8a2dbf14d584dc2854f3391b40e3", "title": "Zephyr on the Big Core: Real-Time on the I.MX93 Cortex-A55 With Zephyr", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The NXP i.MX93 almost always gets the same software answer: Linux on the Cortex-A55, an RTOS on the Cortex-M33. But what if you don't need Linux? Zephyr formally supports the i.MX93 A55 cores upstream (imx93_evk/mimx9352/a55 and /a55/smp), including GICv3 interrupts, PSCI power management, SMP, and the full peripheral set — Ethernet, CAN-FD, USB, MIPI-DSI, and more. Boot time drops, interrupt latency decreases, and memory footprint shrinks. And unlike other RTOS solutions, there are no per-unit royalties. This session covers two things: first, a technical deep-dive into how Zephyr runs on an arm64 application core and looking at various peripherals and proving they work. Second, a live walkthrough of authoring a Zephyr BSP for the Ezurio Nitrogen93 SMARC — an i.MX93 SOM in the SMARC 2.2 form factor — covering DTS porting, pinctrl, driver enablement, and hardware validation. Attendees leave with a clear framework for when Zephyr on Cortex-A beats Linux or a proprietary RTOS, and a practical template for porting any i.MX9x board to Zephyr.\n\n[Open in Sched](https://osselceu2026.sched.com/event/97df8a2dbf14d584dc2854f3391b40e3)", "url": "https://osselceu2026.sched.com/event/97df8a2dbf14d584dc2854f3391b40e3", "persons": [{"public_name": "Ryan Erickson"}]}, {"guid": "oss-e2dedb87eb068119b4823a0c6ccdc3db", "id": "oss-e2dedb87eb068119b4823a0c6ccdc3db", "title": "From Specification To Merge: Implementing a Standards-Compliant DALI Driver for Zephyr", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 2 B (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "DALI (Digital Addressable Lighting Interface) is the dominant standard for professional lighting control, yet firmware support for it has been absent from the Zephyr ecosystem — until now. This talk walks through the full journey of designing and upstreaming a DALI low-level driver into Zephyr mainline: from understanding the protocol's precise timing and bus requirements, to crafting an API that fits naturally within Zephyr's driver model, to surviving the community review process through multiple rounds of discussion and refactoring. Along the way we also experimented with AI-assisted code review as part of our workflow, and we'll share what that was actually like in the context of a real upstream contribution. We'll be honest about what was hard, what the community pushed back on, and what we'd do differently.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e2dedb87eb068119b4823a0c6ccdc3db)", "url": "https://osselceu2026.sched.com/event/e2dedb87eb068119b4823a0c6ccdc3db", "persons": [{"public_name": "Sven Hädrich"}]}], "South Hall 3 A (Floor 3)": [{"guid": "oss-5ff406eefb2735f741a8f7f6e1bee05c", "id": "oss-5ff406eefb2735f741a8f7f6e1bee05c", "title": "The Upstream Way: Current State of I.MX SoCs in the Linux Kernel", "date": "2026-10-09T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "NXP has historically maintained a large number of i.MX-specific patches in downstream Linux trees, increasing maintenance effort and limiting community adoption.\n \n This talk presents NXP's updated upstreaming strategy and the progress made across i.MX SoCs. We will review the current upstream status of key drivers, lessons learned from recent upstreaming efforts and the processes introduced to improve patch quality and acceptance rates.\n \n We will also cover NXP's efforts to strengthen community engagement, work on testing infrastructure and plans for the remaining internal patches.\n\n[Open in Sched](https://osselceu2026.sched.com/event/5ff406eefb2735f741a8f7f6e1bee05c)", "url": "https://osselceu2026.sched.com/event/5ff406eefb2735f741a8f7f6e1bee05c", "persons": [{"public_name": "Daniel Baluta"}]}, {"guid": "oss-9798334199e2586e166556b06812020a", "id": "oss-9798334199e2586e166556b06812020a", "title": "How We Shipped Power & Perf Optimized Snapdragon Based Product on Upstream", "date": "2026-10-09T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Booting mainline Linux on a Snapdragon SoC is a great step, but it is very different from shipping a product. In standard vendor BSPs, power and performance tuning is often hidden behind blobs and downstream hacks. When you build a commercial device entirely on upstream Linux and U-Boot, you lose those vendor shortcuts. You have to understand the hardware deeply to balance battery life and processing power.\n \n In this talk, we will share our war story of shipping a real-world consumer product based on Snapdragon SoC using mainline Linux & U-Boot. We will guide you through our optimization journey, starting from the initial dev kit. We will see how we used the Linaro DebugBoard to profile and tune power consumption across different sleep states and active workloads. We will talk about leveraging standard kernel power management frameworks instead of relying on downstream workarounds, which helps keep the system easily maintainable.\n \n We will explain how we identified power regressions and traced performance bottlenecks using upstream tools. Finally, we will look at the practical trade-offs we had to make to deliver a highly responsive, low-power device while staying close to mainline\n\n[Open in Sched](https://osselceu2026.sched.com/event/9798334199e2586e166556b06812020a)", "url": "https://osselceu2026.sched.com/event/9798334199e2586e166556b06812020a", "persons": [{"public_name": "Neil Armstrong"}, {"public_name": "Rui Silva"}]}, {"guid": "oss-e0516928cca50dbe935ce065846ece2e", "id": "oss-e0516928cca50dbe935ce065846ece2e", "title": "From Vendor Bring-up To Community Upstreaming: What We Learned From SpacemiT K3", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Upstreaming initial support for a new RISC-V SoC is becoming more common, but keeping that support useful, reviewable, and maintainable is still difficult. As more application-class SoCs land, a one-vendor model stops scaling. This talk uses SpacemiT K3, the first mass-produced RVA23-compatible SoC, as a case study. It's not about what we support, but about the upstream work we did, what tripped me up, and how we got past it. We'll walk through in-house K3 enablement work on DMA, audio I2S, bindings, and DTS. The interesting patches aren't the ones that applied cleanly; they're the ones that didn't. We'll look at where to split bindings, drivers, and DTS; how K3 hardware constraints had to be modeled in upstream terms; and how review rounds reshaped the design. The second part focuses on working with community developers outside SpacemiT: making boards available, keeping test images reproducible, pre-reviewing patches, turning regression around quickly, and keeping the internal tree close to mainline. We’ll share lessons practical for making new RISC-V platforms not only upstreamed once, but easier for vendors and community contributors to review, test, debug, and maintain.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e0516928cca50dbe935ce065846ece2e)", "url": "https://osselceu2026.sched.com/event/e0516928cca50dbe935ce065846ece2e", "persons": [{"public_name": "Troy Mitchell"}]}, {"guid": "oss-0013bdaf72c5b09a3718b8cf5faa82bb", "id": "oss-0013bdaf72c5b09a3718b8cf5faa82bb", "title": "Mainline Allwinner Support Status Update", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Support for Allwinner SoC chips in mainine projects like Linux, U-Boot and TrustedFirmware-A has been thriving for over a decade, enabling a large number of use cases and applications. This ongoing effort is lead by the linux-sunxi community and supported by various companies and individuals. This talk presents an overview of the current status of support on the boot, firmware and kernel sides, along with a comprehensive list of the supported chips with specific information for each aspect. This includes advanced topics like power management, multimedia, graphics and accelerators. The latest developments and ongoing chip support efforts is also highlighted. Context and history regarding Allwinner and the linux-sunxi community is also presented, as well as related tools and resources.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0013bdaf72c5b09a3718b8cf5faa82bb)", "url": "https://osselceu2026.sched.com/event/0013bdaf72c5b09a3718b8cf5faa82bb", "persons": [{"public_name": "Paul Kocialkowski"}]}, {"guid": "oss-cdfb975090ccf1b561cc174fc61ef334", "id": "oss-cdfb975090ccf1b561cc174fc61ef334", "title": "The Journey of Adding Hardware Support To Mainline", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Since v4.15 the kernel has support for the second version of the Raster Graphic Acceleration (RGA) IP core of Rockchip SoCs. The newer RK3588 SoC additionally ships two RGA cores with version 3 and so I was tasked to extend the driver to support them. 7 months and 7 patch series versions later the driver was merged in Linux v7.2. The talk walks through my journey to getting my first driver upstream. It shows where I had understood things the wrong way, where I've tried to do too much and where I've had to invest more work. Spiced up with some anecdotes about erroneous manuals, erratic hardware behavior and errors which only arise under load. The talk is intended for beginners who are interested in doing mainline work. Besides showing the effort required and the frustrating moments, I want to encourage putting in the effort and showcase some of the nice solutions it has produced.\n\n[Open in Sched](https://osselceu2026.sched.com/event/cdfb975090ccf1b561cc174fc61ef334)", "url": "https://osselceu2026.sched.com/event/cdfb975090ccf1b561cc174fc61ef334", "persons": [{"public_name": "Sven Püschel"}]}, {"guid": "oss-f71f6b0661fbfc48216d91e18b35889d", "id": "oss-f71f6b0661fbfc48216d91e18b35889d", "title": "Entering Linux Upstream-First: How a Newcomer MCU Vendor Builds Its Kernel Development Processes", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Most silicon vendors claim to support upstream Linux. Few show what it actually takes to sustain that when customer deadlines and upstream changes compete for limited engineering resources. Espressif Systems, the company behind the ESP32 wireless MCUs and open-source ecosystems around them, is debuting in embedded Linux, but no stranger to open source communities: ESP-IDF is widely supported, and its engineers are active contributors to Zephyr RTOS, including a member on the TSC. This is a candid look at how a newcomer builds its development process with the community in mind. We walk through the concrete processes we established: a branching strategy and sync cadence that track each stable kernel release, a pipeline for preparing and submitting patches to mainline, and immutable, reproducible release branches. We also cover the organizational model, a chip verification team that confirms silicon works quickly and a separate upstreaming team that refactors drivers to upstream standards, collaborating continuously to shrink the porting gap. The supporting infrastructure rounds this out with CI across multiple build systems, a LAVA CI board farm, and QEMU for pre-hardware testing.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f71f6b0661fbfc48216d91e18b35889d)", "url": "https://osselceu2026.sched.com/event/f71f6b0661fbfc48216d91e18b35889d", "persons": [{"public_name": "Gustavo Henrique Nihei"}]}, {"guid": "oss-d34a19a0e25927bc1480121fe6d3f19f", "id": "oss-d34a19a0e25927bc1480121fe6d3f19f", "title": "The Netdev Upstreaming Journey: Process, Pitfalls, and Best Practices", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Network interfaces are a common thing on embedded devices, so it's no surprise that getting a device supported upstream involves interacting with the netdev community on mailing lists. The netdev list is a very busy place, and like other subsystems, has its own sets of written and non-written rules. Recently, it's been busier than ever, partly due to new tooling making it more accessible to make first contributions, or finding bugs. This means the netdev community has had to adapt and put new tools, processes and rules in place to deal with this heavy influx of contributions. This talk will discuss what the upstream process for network-related patches currently looks like. We'll discuss the common pitfalls when upstreaming patches, either due to common technical mistakes or traps when following the netdev process. This may also be a chance for other subsystems to take a peek at how netdev deals with the recent surge of new contributors. We'll see how reviews are being promoted, what the recently created Netdev Foundation has been setting-up to ease the testing and CI effort, and how as a developer you can help this community and get your patches accepted in a smoother manner.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d34a19a0e25927bc1480121fe6d3f19f)", "url": "https://osselceu2026.sched.com/event/d34a19a0e25927bc1480121fe6d3f19f", "persons": [{"public_name": "Maxime Chevallier"}]}, {"guid": "oss-250cc27532730fe5234a2655f7402a2f", "id": "oss-250cc27532730fe5234a2655f7402a2f", "title": "Updates on Sbom-cve-check: An Open-source CVE Analysis Tool for Embedded Systems", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:20", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "With embedded devices now everywhere, from home appliances to industrial systems, it is vital to regularly scan them so that any known vulnerability (CVE) in software components can be identified and addressed before they become security risks.\n \n Regularly monitoring these CVEs will be mandatory in various cases to comply with the EU Cyber Resilience Act (CRA), which pushes the industry towards more accountable and proactive security in embedded systems.\n \n Released in December 2025, sbom-cve-check is an open-source automated vulnerability analysis tool. It operates directly on a Software Bill of Materials (SBOM), without requiring access to the original build environment. SBOMs can be generated from build systems such as Yocto, enabling post-build security analysis even when the build infrastructure is unavailable.\n \n This talk will present sbom-cve-check, highlight its major improvements over the past six months, and explain how it is now fully integrated into Yocto, replacing the built-in cve-check class.\n \n sbom-cve-check is provided under the GPLv2 license, and contributions are, of course, welcome :)\n\n[Open in Sched](https://osselceu2026.sched.com/event/250cc27532730fe5234a2655f7402a2f)", "url": "https://osselceu2026.sched.com/event/250cc27532730fe5234a2655f7402a2f", "persons": [{"public_name": "Benjamin Robin"}]}, {"guid": "oss-7a1b5dee2fa0cbfad81644a1788fedcf", "id": "oss-7a1b5dee2fa0cbfad81644a1788fedcf", "title": "Optimizing AI for Resource-Constrained Edge Devices", "date": "2026-10-09T16:50:00+02:00", "start": "16:50", "duration": "00:20", "room": "South Hall 3 A (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Eliminating cloud dependency and making connectivity optional is becoming essential for applications where data privacy, low latency, and reliability are critical. Running AI locally allows the system to respond immediately and keeps sensitive data on device which guarantees security. However, the cost is high. It introduces significant challenges due to computing, memory, and power constraints.\n \n This session explores optimization techniques and algorithms mandatory for deploying vision, audio, and language models on resource-constrained edge devices. We will dive into methods such as quantization, model compression, and graph optimization, and show how to balance latency, accuracy, and energy efficiency.\n \n Using widely adopted open-source frameworks like PyTorch and TensorFlow, along with intermediate ecosystems such as ONNX, we will demonstrate how to efficiently deploy from training a model to highly optimized edge inference. We will provide insight into making AI models smaller, faster, and more efficient with minimal impact on their accuracy, allowing them to run on microprocessor and microcontroller-class devices.\n\n[Open in Sched](https://osselceu2026.sched.com/event/7a1b5dee2fa0cbfad81644a1788fedcf)", "url": "https://osselceu2026.sched.com/event/7a1b5dee2fa0cbfad81644a1788fedcf", "persons": [{"public_name": "Pavel Macenauer"}]}], "South Hall 3 B (Floor 3)": [{"guid": "oss-079b2cc2877a7c5976e2b9ae01740e6a", "id": "oss-079b2cc2877a7c5976e2b9ae01740e6a", "title": "Buildroot LTS in the CRA Era: 18 Months of Keeping a 3-Year Branch Secure", "date": "2026-10-09T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Buildroot Long-Term Support (LTS) sponsorship initiative was launched in March 2025. Its goal is to help Buildroot users maintain stable and secure products over longer periods, particularly in light of upcoming security regulations such as the Cyber Resilience Act (CRA).\n \n We transitioned from a day-to-day maintenance workflow to a more systematic, weekly peer-reviewed approach. After more than a year and a half of maintaining the Buildroot LTS branch, we have encountered both successes and unforeseen challenges. We had to develop custom tooling to deal with a growing number of vulnerability reports, all while preserving stability for the releases.\n \n This talk covers:\n \n * How we tackle the maintenance task as a distributed team.\n * Maintenance challenges with the constant flow of CVEs.\n * Keeping the package metadata up-to-date and improving the vulnerability\n monitoring across branches.\n * What worked and what didn't.\n * How we plan to evolve and improve for the future.\n\n[Open in Sched](https://osselceu2026.sched.com/event/079b2cc2877a7c5976e2b9ae01740e6a)", "url": "https://osselceu2026.sched.com/event/079b2cc2877a7c5976e2b9ae01740e6a", "persons": [{"public_name": "Thomas Perale"}, {"public_name": "Titouan Christophe"}]}, {"guid": "oss-15c22346f8c6ca7f12caca55de2a192b", "id": "oss-15c22346f8c6ca7f12caca55de2a192b", "title": "Yocto BSP Layers: Breaking Free From Complexity", "date": "2026-10-09T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Many Yocto layers provided by silicon vendors prioritize vendor-specific tooling, demos, and opinionated decisions often at the expense of simplicity, flexibility and maintainability. This makes\n them challenging to integrate for custom boards or to adapt to specific customer needs.\n \n Additionally, some of those vendor-provided layers create a maintenance burden: when you need to update, you become dependent on the vendor's choices and changes, which are often hard to understand and follow.\n \n In this talk, we'll examine common issues found in vendor-provided Yocto layers and show how they introduce unnecessary complexity into embedded Linux projects. Much of what new users perceive as “Yocto complexity” actually comes from the design and maintenance practices used in vendor layers.\n \n We'll then introduce yocto-kiss as an example of a simpler and more maintainable approach to vendor support layers. The talk will cover practical best practices for layer design, common pitfalls to avoid, and strategies for building vendor layers that are clean, flexible, and pleasant to maintain.\n\n[Open in Sched](https://osselceu2026.sched.com/event/15c22346f8c6ca7f12caca55de2a192b)", "url": "https://osselceu2026.sched.com/event/15c22346f8c6ca7f12caca55de2a192b", "persons": [{"public_name": "Mathieu Dubois-Briand"}, {"public_name": "Köry Maincent"}]}, {"guid": "oss-70572c161952acb7ebc617db9fe51cdd", "id": "oss-70572c161952acb7ebc617db9fe51cdd", "title": "Is It Time To Retire Kas?", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "You are using kas, the user-friendly orchestration tool for bitbake projects, and you just got nervous? Sorry for that.\n \n With your full attention now, this talk shall bring you up to date with latest developments in kas. Among them are the diff plugin, buildtools support, build attestations, improved lock file handling, unprivileged containers, commit signature validation, easier CI builds, and more.\n \n But we would also like to hear from you what could be further improved. Are there use cases or workflows that should be added to kas or could be better handled than so far. Be prepared for an interactive part.\n \n Last but not least, we will relieve you from worries that kas might be retired by explaining our motivations and plans to drive this project also in the foreseeable future.\n\n[Open in Sched](https://osselceu2026.sched.com/event/70572c161952acb7ebc617db9fe51cdd)", "url": "https://osselceu2026.sched.com/event/70572c161952acb7ebc617db9fe51cdd", "persons": [{"public_name": "Jan Kiszka"}, {"public_name": "Felix Mößbauer"}]}, {"guid": "oss-d4a7c837df7c01c13b7ef96d4188a7a7", "id": "oss-d4a7c837df7c01c13b7ef96d4188a7a7", "title": "Bitbake-setup Has Shipped in Yocto: Producing Complete Linux Systems From One File", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The Yocto project is a toolkit for creating custom Linux distributions for the embedded use cases. Historically it has not provided tools and standards for setting up and replicating build configurations in a reproducible manner, leaving that to third party projects and custom scripts. This has changed with the latest Yocto LTS release (6.0 'wrynose'), which includes a tool called bitbake-setup. This talk will give an overview of what is available and how it can be used to write a record of how to build a complete system, and to replicate that build elsewhere with that record. I will also briefly cover possible future directions for build configuration management.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d4a7c837df7c01c13b7ef96d4188a7a7)", "url": "https://osselceu2026.sched.com/event/d4a7c837df7c01c13b7ef96d4188a7a7", "persons": [{"public_name": "Alexander Kanavin"}]}, {"guid": "oss-f9c6efe062af6ec8de28f2b67b84e112", "id": "oss-f9c6efe062af6ec8de28f2b67b84e112", "title": "Buildroot at 25: A Quarter Century of Making Embedded Linux Easy", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Buildroot started in 2001 with the goal of having a simple and easy way to build embedded Linux systems. Now, 25 years later the size and complexity of embedded Linux systems have increased dramatically and so have the required features of the build system, but the goals are still the same. This talk celebrates Buildroot's 25th anniversary by exploring the project evolution, the community that shaped it and the technical decisions that enabled it to remain relevant for modern projects before finishing up with some thoughts about what the future may bring. Attendees will gain both a historical perspective, insight into how Buildroot is developed and a view to what lies ahead.\n\n[Open in Sched](https://osselceu2026.sched.com/event/f9c6efe062af6ec8de28f2b67b84e112)", "url": "https://osselceu2026.sched.com/event/f9c6efe062af6ec8de28f2b67b84e112", "persons": [{"public_name": "Peter Korsgaard"}]}, {"guid": "oss-8fa1534c1590bc140a39da52d98933fa", "id": "oss-8fa1534c1590bc140a39da52d98933fa", "title": "Yocto: From Scarthgap To Wrynose, 2 Years of LTS Evolution", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Yocto Project has become the de-facto standard for embedded Linux build systems, and its LTS releases serve as the key milestones driving industry adoption and long-term platform decisions. Wrynose (6.0), released in May 2026, is the new LTS: teams and community members running Scarthgap in production are now facing the migration question. This talk covers what actually changed over those two years: build tooling and configuration workflow, CVE and SBOM handling in the context of the upcoming EU Cyber Resilience Act, toolchain updates, and the breaking changes that affect existing layers and distro configurations. By the end of this talk, attendees should have a clear picture of what it takes to migrate from Scarthgap to Wrynose in a real production environment.\n\n[Open in Sched](https://osselceu2026.sched.com/event/8fa1534c1590bc140a39da52d98933fa)", "url": "https://osselceu2026.sched.com/event/8fa1534c1590bc140a39da52d98933fa", "persons": [{"public_name": "Jérémie Dautheribes"}]}, {"guid": "oss-35778f6360f721e6523f19d78c14f215", "id": "oss-35778f6360f721e6523f19d78c14f215", "title": "Yocto’s Hidden Gems: Lesser-Known Tools for Daily Development", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Yocto is a complex and huge ecosystem. Getting started may feel hard, but there are various tools to make our daily development easier right out of the box—if you know about them. Unfortunately, many developers are only used to a small subset of the available tools and their capabilities, which often leads to writing additional custom tooling for already solved problems. In this presentation, we will dive into a selection of these existing tools and demonstrate how to take advantage of them in everyday workflows. For example, we’ll discuss how `bitbake-getvar` helps with debugging variables and overrides, and how to find all packages generated by a recipe with `oe-pkgdata-util`. We will also look into `yocto-check-layer`, `patchtest`, `bitbake-config-help`, and more. The session will focus on practical use cases, showing how to leverage already available tools to save time and reduce the need for custom scripts.\n\n[Open in Sched](https://osselceu2026.sched.com/event/35778f6360f721e6523f19d78c14f215)", "url": "https://osselceu2026.sched.com/event/35778f6360f721e6523f19d78c14f215", "persons": [{"public_name": "Anna-Lena Marx"}]}, {"guid": "oss-e6c85a2305e32d755ae561d36a61aa99", "id": "oss-e6c85a2305e32d755ae561d36a61aa99", "title": "BoF: The Yocto Project and OpenEmbedded", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "South Hall 3 B (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS BoF", "language": "en", "abstract": "", "description": "This BoF provides an open forum for the Embedded Linux community to ask questions and discuss issues with the Yocto Project and OpenEmbedded community. We open with a Yocto Project summary and OpenEmbedded State of the Union. All users, contributors and maintainers as well as curious minds are invited to bring their thoughts and topics.\n\n[Open in Sched](https://osselceu2026.sched.com/event/e6c85a2305e32d755ae561d36a61aa99)", "url": "https://osselceu2026.sched.com/event/e6c85a2305e32d755ae561d36a61aa99", "persons": [{"public_name": "Josef Holzmayr"}, {"public_name": "The Yocto Project"}, {"public_name": "Philip Balister"}]}], "South Hall 3 C (Floor 3)": [{"guid": "oss-eddb62e925220da1f76ac23b4d8f89a6", "id": "oss-eddb62e925220da1f76ac23b4d8f89a6", "title": "XDP & XSK Support From a Linux Driver Standpoint", "date": "2026-10-09T09:05:00+02:00", "start": "09:05", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "XDP (eXpress Data Path) is about running eBPF programs on network packets as early as possible. The goal of such an approach is performance: we minimise operating system networking stack overhead by letting the user decide which packets should reach it.\n \n XSK is an extension to XDP allowing zero-copy redirect from the Ethernet driver directly to userspace processes. This approach approximates kernel-bypass solutions while remaining well integrated into the Linux networking stack for less critical traffic.\n \n Both bring benefits but require adaptations on an Ethernet MAC driver standpoint; we'll dig into those. Quite some ground will be covered:\n - allocators, their allocation patterns and memory layout,\n - networking subsystem callbacks to be implemented,\n - scheduling logic at runtime,\n - performance numbers,\n - etc.\n \n Experience has been acquired through the upstreaming process of XDP & XSK support to the MACB/GEM controller driver, after having added Mobileye EyeQ5 support to the same driver.\n \n References:\n https://en.wikipedia.org/wiki/Express_Data_Path\n https://ebpf.io/\n https://www.kernel.org/doc/html/latest/networking/af_xdp.html\n\n[Open in Sched](https://osselceu2026.sched.com/event/eddb62e925220da1f76ac23b4d8f89a6)", "url": "https://osselceu2026.sched.com/event/eddb62e925220da1f76ac23b4d8f89a6", "persons": [{"public_name": "Théo Lebrun"}]}, {"guid": "oss-ab56fade2ba9727e930c8066b51b9e23", "id": "oss-ab56fade2ba9727e930c8066b51b9e23", "title": "Seeing Inside the NPU: Open-Source Hardware Counter Profiling for Ethos-U on Linux and Zephyr", "date": "2026-10-09T09:50:00+02:00", "start": "09:50", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Edge AI runs on dozens of NPUs — Ethos-U, Hexagon, APUs, DSPs — each with its own closed toolchain and proprietary profiling tools. Application developers have no standard way to answer the basic question: what is my NPU actually doing?\n \n This talk walks through the edge AI software stack — frameworks, delegates, drivers, hardware counters — and shows what it takes to make performance visible. Building on Tomeu Vizoso's Ethos-U PMU kernel work (upstream), we are instrumenting ONNX Runtime and TFLite operators with per-operator CPU PMU data (cycles, cache miss, bandwidth), surfaced via open trace formats, and wiring NPU hardware counter values into ExecuTorch ETDump traces on Zephyr.\n \n The goal: per-operator timing, CPU cache and bandwidth data, and NPU cycle counts in a single open trace — without a proprietary tool.\n \n Contributing to the Linux perf subsystem, this work lays the groundwork for open profiling support on other NPU targets.\n\n[Open in Sched](https://osselceu2026.sched.com/event/ab56fade2ba9727e930c8066b51b9e23)", "url": "https://osselceu2026.sched.com/event/ab56fade2ba9727e930c8066b51b9e23", "persons": [{"public_name": "Vibhore Vardhan"}]}, {"guid": "oss-6d4e469aec57fda4345da0622500670f", "id": "oss-6d4e469aec57fda4345da0622500670f", "title": "Fully Describe Your Regulators and Supplies", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "All active components require power. The device tree should properly describe these supplies so that the software can control power to the devices. On the other side of things, regulators also have their power inputs, and constraints on their power outputs. The device tree should also describe this. Nothing should be left to default.\n \n This session will present how to fully describe the regulator tree of a system, how to identify missing bits, and how to properly describe regulator constraints.\n\n[Open in Sched](https://osselceu2026.sched.com/event/6d4e469aec57fda4345da0622500670f)", "url": "https://osselceu2026.sched.com/event/6d4e469aec57fda4345da0622500670f", "persons": [{"public_name": "Chen-Yu Tsai"}]}, {"guid": "oss-898c2f9c934c1ee99d5bed23c33eec5f", "id": "oss-898c2f9c934c1ee99d5bed23c33eec5f", "title": "Edge AI on Linux", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "AI is inexorably puncturing into our daily lives in some way, shape or form. Up to now, cloud-based LLMs have been the most notable incarnations. And yet, our daily lives contain a slew of devices that remain, for now, of the \"dumb\" variant. As AI technology evolves, matures and gradually commoditizes, several underlying forces, which we'll examine, will increasingly push such functionality into edge devices. This will be especially true of Linux-grade devices that, on the surface, would seem to have the requisite capabilities to support AI-grade stacks.\n \n This talk will examine the AI software stacks available to build edge AI devices based on Linux-grade systems, especially the seemingly infinite functionality permutations made possible by generative AI. While there have been several “open weights” models with licensing constraints, the recent introduction of the Gemma 4 family (under ASL), which includes models specifically targeted at IoT, is a game changer and likely a taste of things to come. We’ll survey available models and engines, such as llama.cpp and ollama, and how to build real systems with them while accounting for in-the-field challenges.\n\n[Open in Sched](https://osselceu2026.sched.com/event/898c2f9c934c1ee99d5bed23c33eec5f)", "url": "https://osselceu2026.sched.com/event/898c2f9c934c1ee99d5bed23c33eec5f", "persons": [{"public_name": "Karim Yaghmour"}]}, {"guid": "oss-0fc95142860fb7b82344aa3946a150e7", "id": "oss-0fc95142860fb7b82344aa3946a150e7", "title": "Embedded in RISC-V: One Year of Android, Yocto, and Beyond", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The RISC-V ecosystem is maturing so rapidly that it's often hard to keep track, especially in the world of embedded systems. Now that RISC-V platforms meeting the \"general-purpose\" RVA23 specification - which mandates the vector and hypervisor extensions, among others - are available, this rate of change will only increase. We've been working hard on supporting RISC-V from the bottom up through Android, the Yocto Project, the Linux kernel, and we've even helped enable the Python ecosystem for AI at the edge. We want to share our experiences with our peers so that they can help contribute, avoid common pitfalls, and build great projects with our favorite new computer architecture. To do so, we'll cover everything we've done over the past year, what we're most excited about, and where we think the most challenging aspects of supporting RISC-V in embedded systems remain. We hope that this will be an inspiring roadmap for others looking to join the RISC-V community on its journey forward.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0fc95142860fb7b82344aa3946a150e7)", "url": "https://osselceu2026.sched.com/event/0fc95142860fb7b82344aa3946a150e7", "persons": [{"public_name": "Trevor Gamblin"}, {"public_name": "Guillaume La Roque"}]}, {"guid": "oss-65870a7ba67cea25bade40c551b7bfee", "id": "oss-65870a7ba67cea25bade40c551b7bfee", "title": "RDMA on the Edge", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Processing large volumes of sensor data (e.g. Cameras, IMUs, Radar, etc.) on embedded hardware for real-time machine learning inference requires two critical performance metrics: high throughput and minimal latency. Remote Direct Memory Access (RDMA) which originated in high-performance computing and cloud datacenters was designed for this use case . By enabling direct host-to-host memory transfers without kernel or CPU intervention, RDMA delivers throughputs exceeding 100 Gbps with microsecond-level latency. In this talk, we present a complete, open-source sensor acquisition pipeline that brings RDMA to an embedded device. We demonstrate how camera data is acquired on an AMD Kria KR260, packetized into RDMA frames entirely within the FPGA fabric, and transmitted over Ethernet to a Jetson AGX Orin platform. The goal of this talk is that attendees will leave with a practical understanding of RDMA’s benefits in the embedded sector and have access to a powerful, open-source tool for high-performance data transfer.\n\n[Open in Sched](https://osselceu2026.sched.com/event/65870a7ba67cea25bade40c551b7bfee)", "url": "https://osselceu2026.sched.com/event/65870a7ba67cea25bade40c551b7bfee", "persons": [{"public_name": "Michael Jost"}]}, {"guid": "oss-9f6f6ec89a8fd5a95f4610c7d9110d2b", "id": "oss-9f6f6ec89a8fd5a95f4610c7d9110d2b", "title": "AI-Assisted CVE Triage in Yocto-Based Supply Chains: Designing the Human–Agent Judgment Boundary", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Automotive Linux products must assess supply chain security at every release. \n Yocto-based SBOMs can serve as the foundation, but many teams have yet to answer how much CVE triage to automate and where humans should make the call. \n An OSS toolchain also enables the same foundation to be shared with suppliers, with no license barriers.\n \n Yocto-generated VEX and rule-based filtering handle many CVEs, but ambiguity remains — provenance of third-party components, applied patches, unintended dependencies. \n AI agents can handle that ambiguity, but opaque and non-deterministic outputs make it impossible to explain a missed CVE or a false positive that blocked a release. \n \n This talk presents a design for that, with a Yocto-based CVE triage pipeline as the example. \n \n The workflow begins with frozen inputs, passes through layered triage, and ends with human approval: inputs locked at CI trigger time (Input Freezing); rule-based and lightweight LLM filtering of straightforward cases (Layered Triage); a high-performance LLM presenting suggestions, with humans making the final call (Suggestion-and-Approval Loop). \n These patterns apply to embedded supply chain management beyond automotive Linux.\n\n[Open in Sched](https://osselceu2026.sched.com/event/9f6f6ec89a8fd5a95f4610c7d9110d2b)", "url": "https://osselceu2026.sched.com/event/9f6f6ec89a8fd5a95f4610c7d9110d2b", "persons": [{"public_name": "Kazuyoshi Akiyama"}, {"public_name": "Takashi Ninjouji"}]}, {"guid": "oss-2b606c4142e1cffdaa40a9b28dc713d4", "id": "oss-2b606c4142e1cffdaa40a9b28dc713d4", "title": "ELC Closing Game", "date": "2026-10-09T17:20:00+02:00", "start": "17:20", "duration": "01:00", "room": "South Hall 3 C (Floor 3)", "track": "OSS: Embedded Linux Conference", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Come join us for the Embedded Linux Conference Annual Closing Game! Walt Miner, ELC Program Co-chair, will host the event, which is a fun opportunity for attendees to win amazing prizes.\n\n[Open in Sched](https://osselceu2026.sched.com/event/2b606c4142e1cffdaa40a9b28dc713d4)", "url": "https://osselceu2026.sched.com/event/2b606c4142e1cffdaa40a9b28dc713d4", "persons": []}], "South Hall Foyer 1 (Floor 1)": [{"guid": "oss-afc9ae18781064ceba9322ae78084b6e", "id": "oss-afc9ae18781064ceba9322ae78084b6e", "title": "PX4 Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "South Hall Foyer 1 (Floor 1)", "track": "OSS: PX4 Dev Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/afc9ae18781064ceba9322ae78084b6e)", "url": "https://osselceu2026.sched.com/event/afc9ae18781064ceba9322ae78084b6e", "persons": []}], "South Hall Foyer 2 (Floor 2)": [{"guid": "oss-d0cb3b36e0e0f56f72faec3382de60b3", "id": "oss-d0cb3b36e0e0f56f72faec3382de60b3", "title": "Zephyr Community Hub", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "09:20", "room": "South Hall Foyer 2 (Floor 2)", "track": "OSS: Zephyr Developer Summit", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Find your people. Share what you're building. Get unstuck.\n\nLooking to swap ideas, troubleshoot a tricky problem, or meet others working on the same things you are?\n\nThis dedicated space is organized around this specific track interests and community. Drop in between sessions to talk shop, share what you’re working on, ask questions, or simply connect with people who get it.\n\n[Open in Sched](https://osselceu2026.sched.com/event/d0cb3b36e0e0f56f72faec3382de60b3)", "url": "https://osselceu2026.sched.com/event/d0cb3b36e0e0f56f72faec3382de60b3", "persons": []}], "Terrace 2 A (Floor 2)": [{"guid": "oss-b13bcce2d363a1138cc4379dbea5d516", "id": "oss-b13bcce2d363a1138cc4379dbea5d516", "title": "Small Language Models 101: Why Bigger Isn't Always Better", "date": "2026-10-09T11:05:00+02:00", "start": "11:05", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Large Language Models often dominate headlines, but many real world AI applications don't need billions of parameters to be effective. Tasks such as classification, information extraction, intent detection, summarization and domain specific assistants can often be served effectively by smaller open source models with lower latency, reduced infrastructure requirements and improved privacy.This session introduces Small Language Models (SLMs), explores the trade-offs between model size, accuracy, cost and performance and discusses techniques such as quantization, distillation and domain adaptation that make these models practical for deployment on laptops and edge devices.Attendees will leave with a framework for selecting the right model for a given use case, understanding why bigger is not always better and how open-source SLMs are making AI more accessible to developers and organizations with limited compute resources.\n\n[Open in Sched](https://osselceu2026.sched.com/event/b13bcce2d363a1138cc4379dbea5d516)", "url": "https://osselceu2026.sched.com/event/b13bcce2d363a1138cc4379dbea5d516", "persons": [{"public_name": "Mohit Gaur"}]}, {"guid": "oss-0f5ec8367fd397151fe897877e9f0a01", "id": "oss-0f5ec8367fd397151fe897877e9f0a01", "title": "Minimal Viable AI Platform", "date": "2026-10-09T11:55:00+02:00", "start": "11:55", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "Creating your own AI platform sounds like a job for a funded team with a matching cloud bill. Surprisingly, it isn't. I want to show how a handful of open source tools can be combined into a minimal viable AI platform that runs on one machine from a single Docker Compose file.\nFive layers are all needed for a valuable platform: agentgateway as the gateway (one API for any model, with keys and cost tracking), Open WebUI as the chat interface, n8n for automation and agents that take real actions, Ollama for private local models, and Langfuse for request tracing.\nThen we look at how to grow it (RAG, authentication, scaling) without adding a pile of disconnected tools. This setup can be advanced for every demand.\nIt is indeed not the perfect setup, but it is a valid starting point for organizations of any size.\nNo enterprise budget needed, just you, some OSS tools and a little bit of interest.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0f5ec8367fd397151fe897877e9f0a01)", "url": "https://osselceu2026.sched.com/event/0f5ec8367fd397151fe897877e9f0a01", "persons": [{"public_name": "Max Körbächer"}]}, {"guid": "oss-0957d0c3425571ab8d8d40d1dee2a40c", "id": "oss-0957d0c3425571ab8d8d40d1dee2a40c", "title": "Corporations, Communities, Foundations -- And The Government?", "date": "2026-10-09T14:00:00+02:00", "start": "14:00", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The open source sustainability conversation has revolved around three primary actors: corporations with engineering resources and product dependencies, individual volunteers and communities building and maintaining software, and foundations providing organizational homes for projects and events. It's a big and diverse landscape, but there are some gaps.\nThis talk makes the case for a fourth actor: government agencies investing in open source as public infrastructure. Not as regulators, not as occasional grant-makers, but as structural investors with a public mission, and a mandate to consider the health of open source ecosystems over a longer time horizon and beyond the strictures of a product roadmap.\nWhat makes this model distinct from philanthropy, corporate sponsorship, or community engagement? What can it do that the other three can't, and what does it depend on them for? Drawing on the work of the Sovereign Tech Agency, a German federal agency that invests in critical open source projects and the ecosystem infrastructure sustaining them, this session examines what public investment in critical open source actually looks like in practice and why it belongs in the sustainability conversation.\n\n[Open in Sched](https://osselceu2026.sched.com/event/0957d0c3425571ab8d8d40d1dee2a40c)", "url": "https://osselceu2026.sched.com/event/0957d0c3425571ab8d8d40d1dee2a40c", "persons": [{"public_name": "Powen Shiah"}]}, {"guid": "oss-24cd34506ba872e36dbc5edc076e71f8", "id": "oss-24cd34506ba872e36dbc5edc076e71f8", "title": "Landscape of the Quantum Open Source Ecosystem", "date": "2026-10-09T14:50:00+02:00", "start": "14:50", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "The discussion on quantum computers often focuses on abstract physics, but for the engineers manipulating those systems, the underlying software stack is becoming a very pressing reality. As the field matures, we are witnessing the emergence of a collaborative, open-source ecosystem. This session provides a comprehensive tour of the current quantum open source landscape, and will aim to demystify programming for quantum computers. Community-led projects are currently providing the necessary plumbing (compilers, simulators, verification tools, ...) to ensure that quantum technologies are not only scalable and useful, but also transparent and interoperable. No prior background in quantum physics or quantum computing is required. The session will actually aim to argue that most quantum software challenges are very known problems in software engineering and computer science, and that one can contribute to quantum open source projects without any knowledge of quantum physics.\n\n[Open in Sched](https://osselceu2026.sched.com/event/24cd34506ba872e36dbc5edc076e71f8)", "url": "https://osselceu2026.sched.com/event/24cd34506ba872e36dbc5edc076e71f8", "persons": [{"public_name": "Mathys Rennela"}]}, {"guid": "oss-bd995859ccf3b4110415a45622f9f964", "id": "oss-bd995859ccf3b4110415a45622f9f964", "title": "Kids Programming in Turtlegrove - Making Beautiful Things Together", "date": "2026-10-09T15:40:00+02:00", "start": "15:40", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "In 1967, Seymour Papert, Wally Feurzeig, and Cynthia Solomon built a language based on studies of Piaget whose radical premise still hasn't been fully cashed in: children should program the computer, not be programmed by it. Logo gave them a turtle an \"object to think with\" and a place to live in mathematics by walking it, drawing it, and making it their own. Half a century later, most kids meet software as something to consume, not construct. This talk argues that Papert's constructionism and the free-software ethos are the same idea one generation apart, both are about the freedom to understand and reshape your own tools and that open source is exactly how we finally deliver Logo's promise at scale. I'll show TurtleGrove: a UCBLogo compatible interpreter we created that runs in any browser, with a Rust core and a vanilla-JS frontend, fully open source and self-hostable. In the OpenSource mindset children can even show-and-share their code with other children. Working on their own canvas or creating art together. Children learn the best, when learning together. We use this also in the Living OpenSource project to introduce kids in African countries into programming.\n\n[Open in Sched](https://osselceu2026.sched.com/event/bd995859ccf3b4110415a45622f9f964)", "url": "https://osselceu2026.sched.com/event/bd995859ccf3b4110415a45622f9f964", "persons": [{"public_name": "Pascal van Dam"}]}, {"guid": "oss-06081dc2fcb5ad229452ef8c145de351", "id": "oss-06081dc2fcb5ad229452ef8c145de351", "title": "Generative AI and FOSS - Not Just the How but Also the Why", "date": "2026-10-09T16:30:00+02:00", "start": "16:30", "duration": "00:40", "room": "Terrace 2 A (Floor 2)", "track": "OSS: Open Source 101", "type": "OSS Talk", "language": "en", "abstract": "", "description": "I've given several talks & workshops on various GenAI tools in the past couple of years. Generally the goals of the presentations are to demonstrate the how - how to fine tune a model, how to prepare data for RAG systems, how to use this framework or optimize that pipeline - I find that a lot of the discussions which happen during and after the workshop are around the why. Why is structured data important? Why do we care about open source and open weights in models? Why does context size matter? Why can't I run/reproduce the same AI set up on my laptop? Why do I even have to use GenAI?? These and many more questions have popped up and quickly drowned in the rush to keep up with the next new AI tool or agent. I'd like to provide a space for everyone, especially those new to GenAI and/or open source, to pose these questions and discuss them without worring about missing out. Whether you are a skeptic or have your fully agentic workflow set up, we might share similar concerns and doubts. Bring your ideas and opinions! During the BoF, I will also share various open source resources that may be relevant and useful in answering your questions and better prepare you on the AI journey.\n\n[Open in Sched](https://osselceu2026.sched.com/event/06081dc2fcb5ad229452ef8c145de351)", "url": "https://osselceu2026.sched.com/event/06081dc2fcb5ad229452ef8c145de351", "persons": [{"public_name": "Carol Chen"}]}], "Terrace 2 B (Floor 2)": [{"guid": "oss-97ddfbea2def5bdf91797f7d64993076", "id": "oss-97ddfbea2def5bdf91797f7d64993076", "title": "Hacker Space", "date": "2026-10-09T08:00:00+02:00", "start": "08:00", "duration": "08:50", "room": "Terrace 2 B (Floor 2)", "track": "OSS: Special Events / Exhibits / Breaks", "type": "OSS Special / Exhibits / Breaks", "language": "en", "abstract": "", "description": "Discover a space, where you can collaborate, create, and explore new ideas with fellow attendees. Whether you’re here to learn or build, our space is open for everyone to enjoy throughout the conference!\n\n[Open in Sched](https://osselceu2026.sched.com/event/97ddfbea2def5bdf91797f7d64993076)", "url": "https://osselceu2026.sched.com/event/97ddfbea2def5bdf91797f7d64993076", "persons": []}]}}]}}}