openSUSE uses RPM for its own packaging needs, with macros on their own on top. However, the distributions using RPMs are just a couple compared to the vast Linux ecosystem. How are other distributions handling packaging? Are they using bash scripts, functions, or even declarative languages? This talk will give a rundown of the different approaches that have been more successful in building a distribution on top, such as Gentoo ebuilds, Void Linux packages, and even some more niche packaging spec files.

SECCOMP, short for SECure COMPuting, is a part of Linux kernel that allows restricting, logging or otherwise reacting to systemcalls or systemcall arguments a userspace process can invoke. The talk offers a brief introduction to SECCOMP API and its history. Further I will focus on how SECCOMP is currently used (sandboxing) and some of its current limitations. As a bonus, I will briefly talk about debugging SECCOMP enabled process with Valgrind.

MIDI is a communication standard for music instruments, and probably one of the oldest interfaces that is still actively used. After 40 years of MIDI 1.0 era, the new modernized MIDI 2.0 was introduced in 2019/2020. I was involved with the support of MIDI 2.0 for Linux since recently, and its result was finally merged to 6.5 Linux kernel, along with the new MIDI 2.0 UMP spec updates. The development was a new adventure for me; it was with a cooperation of other OS vendors like Apple, Microsoft and Google in a working group of MIDI Association. This talk will cover the new features of MIDI 2.0, how the Linux support was developed without hardware, and how the things are managed among different groups in the upstream.

We will start with a retrospective for how we handled the kernel release for SLE15 SP6 and ALP then, after a short break, we will attempt to plan for SLE15 SP7, SLE16, and Micro 6.1 and 6.2 There are couple of points we need to discuss and clarify going forward: * Are we going to upgrade kernel base version for SLE15 SP7, SLE16, Micro 6.1 and Micro 6.2?; * Which base kernel version are we going to pick; * Are we going to switch to yearly base kernel upgrades after SLE15 SP7; * How do we setup branch naming for new kernels (formely ALP); * etc.

Josef Čejka and Bogdano Arendartchuk present the facilities from the L3 team that are available for Labs to assist with analyzing and reproducing bugs and tracking PTFs delivered to customers: l3mule, fastzilla, l3vm, ptfdb, debuginfod, ptfutils, etc. We then open for discussion, mostly focused on: a) what Labs needs from L3 regarding infra and b) what can be improved in l3mule.

Last hackweek, With my somewhat limited understanding of electronics, I set out to Circuit Bend an 80's video editor. This process was made significantly easier when the second result on google was an old service manual with a complete set of schematics. With my limited experience I wasn't able to make it work the way I wanted it to but it does do something unique and fun. This talk will cover several aspects: * My approach to Circuit bending this device and or similar devices; * A look at how much more open and repairable hardware was in the past; * A look at other modern open designs for video processing and effects; * A live demo of my hackweek project.

Running SAP HANA inside a KVM virtual machine and meeting SAP's performance requirements is a rather challenging piece of research and work. Yet for a few years, thanks to a joint effort between SAP and our own Virtualization experts (and, recently, even with the help of external partners, such as Fujistu and Intel) we've managed to put together a detailed best practice guide that explains how to meet all the expectations, for the different versions of SUSE Linux Enterprise Server. In this session, we will give an overview of what are the various scenarios that we have addressed so far and are currently targeting (single or multiple VMs, storage solution, OS versions, hardware generations, etc) and of what's required for making SLES a validated KVM hypervisor platform for SAP HANA. We will also explain the technical details of how both the host and the guest need to be configured and tuned. And last but not least, we will discuss which ones have been (and are being!) the toughest challenges and indulge on some pain points we have faced (and are facing!).

Unlock the secrets behind connecting Linux seamlessly with Entra ID (formerly Azure AD). Learn about the intricacies of device joins, OAuth2 authentication, and TGT retrieval. Explore hands-on experiences using Rust. Join me in bridging the gap between Linux and Entra ID, unlocking a world of possibilities for enhanced integration.

The installation process of whole compute clusters tends to be error prone and struggling work. Warewulf[1] aims to make this work more reliable and fast. This achieved by using containers to install the compute nodes.

Latency is a metric indispensable for assessing performance. There are various approaches suitable for measuring latency that compute latency values in the kernel: BPF (bcc-tools, bpftrace), systemtap or custom debugging modules. At times, it may be necessary to use only ftrace because none of the other tools are available (e.g. on production servers with strict policies). Histogram triggers and synthetic events can be leveraged to compute latency in the kernel in situations when capturing a full trace is not workable. The approaches to measuring the time spent in functions and measuring scheduling latency will be discussed. Synthetic events open new ways of utilizing the snapshot trigger, which is a means to capture a full trace after an event of interest has occurred. This is an introductory talk.

With ALP we switch from AppArmor to SELinux. Last year Filippo introduced SELinux at the conference: http://events.suse.cz/labs2023/slides/selinux_SUSE_Labs_23.pdf This talk will discuss the current state of SELinux on ALP: * what works well; * what are the challenges we've seen; * what to expect in the future. This talk requires a basic understanding of SELinux (e.g. last years talk) https://www.youtube.com/watch?v=GVYcfk_i9no&list=PL4ibkKyj5eYR-lCsKAazQRQkGfAPYF78f&index=9&pp=iAQB

Orthos 2 is SUSE Labs management tool of choice for sharing bare-metal machines with colleagues. The talk will showcase what I was able to achieve in my role as Hardware Operations Infrastructure Developer the last year. The talk should end with an overview of the features to be rolled out/worked on in the next year.

This presentation will focus on CXL (Compute Express Link) as an advanced interconnect between machines and peripherals. CXL allows to leverage the PCIe physical interconnect to link together different device types (CPU, memory, I/O, cache, switches etc) into a combined hierarchy. This allows IHVs to create tailored solutions for eg large-scale AI systems or dynamic resource pooling between machines. As it's also possible to connect or pool memory resources it means the we can end up with some really interesting NUMA topologies. Plus we need to look at memory placement, as CXL memory is inherently hotpluggable, and as such not really suitable for some data structures like DMA areas etc. In this talk I will give an overview over CXL and the implications for NUMA topologies, and I'll be giving a short demo with an emulated CXL instance under qemu.

Secure boot on x86_64 is mostly taken for granted, as it is a mature feature in UEFI. When it comes to aarch64, the Secure Boot implementation can differ on each platform. In this session, we will learn how to safeguard SUSE ALP on NXP platforms with QorIQ Trust Architecture and High Assurance Boot (HABv4).

We maintain our kernel configs inside the kernel-source git branches which unfortunately has a few disadvantages. Namely it's hard to track the reason for changes and we also had a few cases of accidental changes for config options we carefuly set. Since rather small set of config options has far reaching consequencies I've prototyped a config checker which is a database of important config values and a script to check if these are set as expected. In this session I would like to discuss the prototype checker implementation and possible use.

Currently we use OBS as the source and binary repository of all packages, images and various other things. There is a current effort to break this dependency on a single internal tool and move the sources away from OBS into Git. Here we would like to give a quick overview of the current state and future developments, including:   * package repository setup;   * project repository setup;   * build setup.

We build, boot and test kernels every day using well-know routines. It sounds like there is nothing to discuss but from my experience each person in SUSE Labs equals own approach. It start with how you edit the sources, how and where you build them, how you get and track built artifacts, how you accompany them with functional userspace and how you run it and eventually how you make this all efficient. I am going to present the workflow that I have converged to and I invite you to share yours. The expected outcome is to be mutually inspired to see how to improve your own workflow and learn about each other's specifics (or to ascertain yourself that your workflow is already perfect). This is meant to be an open format, I encourage you show up with your own slide or two for better delivery.

* Kbuild - today; * Improvements planned by the kbuild team. (kbuild_todo-_list); * Showcase some of our improvements and our investigations; * Open to discussion: Reproducible build infrastructure as containers and suggestions/improvements to kbuild.

make install has been used for 30 years or more; it has always been the standard way of installing simple C programs and a lot of stuff that didn't have a build system capable of doing so on Linux. However, getting a Makefile right is hard and painful. Should I use `PREFIX=` or `PREFIX?=`, should I hardcode BINDIR? Installing a program should be simpler and more deterministic. Hence, rinstall has been developed, to provide a way to install programs without studying the entire GNU Standard Directory reference. How does it work? More importantly, how do we use it in openSUSE? This talk will give a rundown of the issues that rinstall fixes and the integration in a distribution.

An overview of how memory-tiering is currently implemented in the Linux Kernel

Data compression has long provided an efficient way to preserve storage resources at the expense of extra CPU cycles for compression and decompression. While traditionally used for transport over a network and cold storage media, compression is now prolific across many layers within OS and application stacks. These independent layers often lack knowledge about compression use in other components, leading to cases where data may be decompressed and recompressed unnecessarily. This presentation will explore some options for reducing decompress / recompress inefficiencies, and demonstrate proof-of-concept changes to unpack compressed rpms directly to the root filesystem using Btrfs zstd encoded I/O support.

Explore Packtrack - a project by the Packaging team aiming to make the lives of SUSE package maintainers easier. It should aggregate data from various sources and present all the relevant information and summaries you need to know about your packages, bugs, or OBS requests. No need to monitor plenty of services or rely on your email notifications anymore. With Packtrack, you'll find everything in one place. While we're still in the early stages of development, Packtrack aims to improve the way we approach packaging. Whether you're a seasoned packager or just maintain a few packages, join us to learn about our plans and discover how Packtrack can simplify your workload.

Status update on the current efforts of integrating systemd-boot support into factory, including btrfs snapshot support.

Cockpit has been part of SLE micro and in the future ALP. Lets learn about what cockpit is, how it works and look into the internals of cockpit. We'll also be looking into writing "applications" for cockpit and showcase some applications we've written to integrate with cockpit. As well as some unusual applications we've come around cockpit.

What would happen if we could get the expressiveness of Python, the efficiency of compiled programming languages and mix it with concepts from Ada, Modula, C/C++ and other memory safe programming languages? And what would happen if we make all these features optional? And what would happen if we want to target any architecture? Nim is a programming language that tries to answer all these questions and provide innovative solutions where possible that's already mature to be used in production applications. Features: * Native, dependency-free executables; * Support for all major platforms: Windows, Linux, BSD and MacOS; * Deterministic memory management: destructors, move semantics and different memory models, depending on the target arch/app; * Modern concepts: zero-overhead constructs, compile-time evaluation, automatic by-value/by reference data; * C, C++ and Javascript backends: go from low-level systems programming to frontend web development. Target anything!; * Seamless FFI: consume any C/C++ library and easily. Export ABI compatible C/C++ functions/types; * Powerful standard library; * Extremely expressive macro/template system, with access to the AST at compile time!; * Modern type system: type inference, generics, types, concepts, sum types...

Showing how we can improve the security in the boot process of our image, building a static initrd or/and a UKI. I will explain the process to build these two entities, and show what we have done, learn, and built, in our OBS. I will also compare the effectiveness of different tools to use in our build service. As a result, I will show an image based on Aeon that includes the UKI as the boot option. For now, it misses the integration of snapshots with UKI to finalize the entire project.

In other talks we presented the plan that we have with relation FDE in openSUSE, with special focus in MicroOS and Tumbleweed. The proposed architecture is using systemd to enroll security devices (like a TPM2 or a FIDO2 key) in user space, and configuring the system such that is initrd the one that unlocks the device. This architecture is different from the current ALP model, which uses GRUB2 to unlock the device from the boot loader, before the kernel is even loaded. For this talk we will present the current implementation announced in December 2024 that uses signed policies to a TPM2 installation, and the ongoing adaptation on using TPM2 policies stored in a NVRAM slot, using the new systemd-pcrlock tool.

Peter Zijlstra (et al) have reworked the guts of the default scheduling class, that has landed in v6.6. What used to be completely fair scheduler (CFS) is now earliest eligible deadline first (EEVDF) and will be SUSE when base kernel version is bumped. If you are interested how EEVDF and its implementation work, this is a talk for you. I have read the EEVDF paper so that you don't have to.

Current Linux allows for three models of kernel preemption: ""none"" (run kernel task to completion), ""voluntary"" (run to next scheduling point) and ""full"" (preempt kernel task anywhere). Work is currently underway by Ankur Arora (Oracle) and Thomas Gleixner (Linutronix) to unify these models and remove explicit preemption points that characterize the ""voluntary"" flavor. It is widely believed that explicit preemption points are the mitigation to an imperfect design; this unification work approaches the problem in a more systematic way, allowing the scheduler to express a finer reschedulingsemantics. This presentation will summarize the ongoing work and discussion, and provide some concrete example applications.

rpmlint is a stable tool with a slow development, not too many active developers working on it. This talk is about how we're trying to modernize the code using the resources provided by google with the Summer of Code project.

This talk is to introduce bcachefs, the newly upstream merged file system created by Kent Overstreet: * What does bcachefs intend to be; * How to setup and use bcachefs; * Core data structures design from bcachefs; * Basic and limited benchmark performance numbers. Considering the code is just freshly merged within months, only above topics are mentioned at this moment.

In response to SLE16's shift away from Wicked, we needed a solution for customers to migrate their network configuration. This talk explores our options, chosen approach, and the project's current status.

A fundamental problem in source-based live patching is the task of extracting the changes from the original codestream and its dependencies in a modular way. Manual extraction is notably laborious, involving meticulous tracing of functions, variables, and headers within the original project to construct either a kernel module or a shared object file. This process must also account for compiler transformations and symbol externalization, further complicating the task. To address these complexities, we introduce `clang-extract`, a tool relying on libclang to mimic the compilation process and automatically extract pertinent content.

Kernel test are special in numerous aspects because they interact with OS and some even with hardware. I would like to sumarize the particularities I've tripped over during my years as a kernel automation engineer as well as to sketch solutions for these problems our kernel QE colleagues are working on.

A goal of virtual machine performance is to approach bare-metal, in our research and testing, correctly binding vNUMA topology against bare-metal is helpful to achieve the goal. The presentation will introduce how to correctly setup vNUMA topology including vcpupin for Skylake and CascadeLake CPU with different server models, comparing benchmarks performance results with different vNUMA topology, user case and my experience about vcpupin tuning for HANA on KVM performance.

Velociraptor is an open-source endpoint monitoring, digital forensic and security incident response platform. This talk will outline why Velociraptor was chosen and provide an overview of how it works and how we are deploying it. We will also cover the work SUSE has done to extend Velociraptor to meet the requirements of the SUSE Cybersecurity team.

Confidential Computing for virtual machines provides hardware protection for data as it is being processed on an untrusted host, giving strong assurance that the guest memory and context is protected from observation and manipulation by the host. In order to ensure integrity of the workload deployed into a confidential VM, CPU vendors include the ability to remotely attest the startup state of the guest. This provides verifiable cryptographic evidence that the guest is running inside a patched, up-to-date CC environment and confirms exactly what firmware the guest is running. In order to retain integrity from the verified firmware, unlock an encrypted disk and boot the operating system, a traditional secure boot process can be used. However, a TPM or equivalent is required to implement secure boot. COCONUT-SVSM provides a secure environment to implement a virtual TPM where keys and state are protected both from the host and the guest firmware. Manufacturing a vTPM requires access to persistent root seeds that must remain secure and available even when the guest is migrated to a different host. This talk introduces the process and capabilities of remote attestation with AMD SEV-SNP and discusses how this can be used during the the initialisation of COCONUT-SVSM to securely obtain vTPM seeds from a key broker service.

When talking about data compression, the common sense is to assume the compression of data 'at rest', e.g. files and directories, stored in a hard drive or some other type of storage. This presentation will talk about compression on transmitting (a.k.a. over-the-wire) data. This isn't novel, though; HTTP compression has been supported and used for decades now.  For the non-average computer users, rsync has also supported over-the-wire data compression for about just as long. And even though MS-SMB2 specification has also indicated support for compression for a few years, only the most recent versions of Windows and Windows Server have implemented it.  On the Linux side, a few proprietary solutions exist, but they're actually built on top of their own protocols, that will then do the compres-send-receive-decompress cycle on their own way, with whatever advantages/restrictions that might exist. Here, an implementation for the Linux SMB client module (cifs.ko) is introduced. We'll talk about the compression algorithms supported by MS-SMB2, the strengths and weakness of each, the assessment made to decide which to implement or prioritize its use over the others, etc. Being a new feature, and a feature that deals with user data, a major goal of this talk is to discuss the details of this implementation, so feedback can be parsed, modeled, and used for further refinement and prevention of data corruption.

Heisenbugs are pretty difficult to find, especially when you're looking; for quite some time, in Quality Engineering, we've been using openQA primarily to validate builds, maintenance updates, but it can do much more. In this talk, I would like to introduce a few parts of our workflows and tools that allow us to iterate fast, especially when hunting for sporadic bugs like [bsc#1219073 - system crashed during raid remove/attach operations](https://bugzilla.suse.com/show_bug.cgi?id=1219073), how to access them and use them for fun, profit, and bug squashing.