In this talk I will speak about what the Future Technology Team did in the last year. Some of the bigger topics are: * Update on Full Disk Encryption with TPM and Fido2 * Adding grub2-BLS support: - YaST2 - Images (including with full disk encryption) - Making it the default * Adding FDE+TPM support to YaST2 * New features for transactional-update and rework of /etc handling * systemd-sysext on MicroOS * systemd-pull and OBS * New tools (e.g. sndiff) * And much more

As confidential computing continues to evolve, AMD SEV-SNP has gained traction in the open-source community and is now supported by cloud providers such as AWS, Google Cloud, and Azure. By encrypting memory, SEV-SNP ensures that a virtual machine’s memory remains accessible only to itself, thereby protecting sensitive data in virtualized environments. This session will provide an analysis of SEV-SNP’s security, examining its role in confidential computing, its protection mechanisms, and their limitations. Attendees will gain valuable insights into SEV-SNP’s strengths and overall security implications.

With the types of products and projects that we regularly work on many of us don't get alot of exposure to new fancy technology, this talk aims to give a quick introduction to one of these topics, web assembly. As some background, For the last year i've been helping to port Little Piggy Tracker (LGPT) a clone of the LSDJ audio software for Game Boy to various handheld devices. At the same time I saw a conference talk that was an introduction to web assembly, this prompted me to ask the ever dangerous question "how hard can it be?" It turns out the answer to that question was not that hard so this talk will go through a brief overview of webassembly followed by the process I went through to port my code along with some of the other challenges i've had porting LGPT to other devices.

Security surrounds every aspect of computing - which in turn affects our lives as computers are so pervasive in the modern world. However, we continue to see security issues in our industry. In this talk we cover a range of security issues from basic to advanced, and learn about how human factors affect every part of our work. We will also learn how to rethink our approaches so that we can make better, more secure decisions in our work - be that product management, engineering or team leadership.

Legal review is an integral part of SUSE's release process, and LegalDB is a powerful tool we can use to ease and expedite legal review. This talk will introduce LegalDB and demonstrate the workflow SUSE engineers can use to optimize the path towards successful legal review. We will demonstrate how to track review progress for specific code changes, classify license text with LegalDB's pattern recognition, and ensure correct distinction of legal text in source code comments and documentation. We will conclude with Q&A.

Libpulp has been successfully ported to the powerpc64le architecture, thereby enabling userspace livepatching on this platform. In this presentation, we will discuss the process of achieving this and discuss the differences when compared to livepatching on the x86_64 architecture.

We will kick things off with a look at the recent work happening under the current kbuild system. We will touch on improvements made to areas like mailing infrastructure, libraries/tests, and the kbuild-deploy process etc. Then, we will discuss kbuild-next, the new kernel build system that fixes old problems and aims to make things better. Looking ahead, we are actively exploring the kbuild-next-sandbox, an environment where kernel developers get direct SSH access for troubleshooting and running tests. A key area of current investigation within the sandbox is the automation of test identification based on the content of user-submitted patches. Our plan is to have a working PoC ready by then, potentially using LLM models which we will train/tune to provide us with suggestions.

Have you ever wondered how exactly your RAM is being used in Linux and how you can find out? How much memory will be freed when killing a particular process? What exactly does the “top”s RES column even mean, and why is the sum of it over all processes much larger than what “free” reports as used? Or much smaller? Why in /proc/meminfo is the value of AnonPages different from Active(anon) plus Inactive(anon)? Which of the fields there should actually sum up to MemTotal? How can I find out where the missing memory went when the proper sum is much smaller than MemTotal? What even is MemAvailable? Why is sometimes swap used even when there seems to be enough free memory? This talk will provide ways to answer questions like these, and explain why the answers are often not trivial.

Community contributions to Leap 16.0 often rely on corresponding changes in SUSE Linux Enterprise. In this session, we'll explore how community feature requests are tracked, processed, and implemented. We'll highlight the current workflows, where and how requests are submitted, and what has changed compared to Leap 15, including some areas where we’ve seen regressions.

The last year was a bit hectic due to the onslaught of CVEs from the kernel CNA. However, as a response there were some improvements, especially when it comes to our tooling. The first part of this seesion should be a presentation about tools like suse-get-maintainers (who is reponsible for what in SUSE kernel), kss-dashboard (querying CVE bug reports from commandline), get-bugzilla-metadata (an additional Bugzilla scripting), modify-bugs (bulk Bugzilla edits) and tracking-fixes service (git fixes mails). The second part should be a discussion about possible usecases, further improvement and future direction in general. If you have an overlooked usecase or an idea for a feature, let's come together and discuss this.

ink Time Optimizations have potential to create faster and smaller binaries. But they break some assumptions. Last attempt to make GCC's LTO work with the kernel required manual marking of many symbols by attributes. This is in contrast with Clang's LTOs which already work with the kernel, though with restricted optimizations. This talk covers why does GCC's LTO need this information, how much of it can be handled automatically by GCC, and in which few cases the attributes would have to remain.

In the last SUSE Labs we talked about the work done by the Future Technology team related with Full Disk Encryption based in systemd (user space). This talk will present some updates related with compatibility with grub2-bls and extra protections based on PCR15 to detect and mitigate vector attack based on tampered disks.

After my short introduction of the topic was received enthusiastically by the upstream maintainers at LPC2024[1], I started slowly working on the project. It is a rather large one. In this talk, I want to present a more detailed plan and where we stand at the moment.

The advantages of reproducible builds, its state and about what particularly we did in the Java eco-system.

Discussion about challenges related to tooling used for maintaining the kernel source.

Wololo is a parsing library written in Clojure that strives to do the following: * Provide a small domain-specific language that achieves feature-parity with standard Backus-Naur Forms (BNF). This allows existing knowledge about parsers to be reused, it's possible to simply carry existing grammars over to Wololo. * Provide an extended set of functions that allows Wololo to parse any language whose grammar can only be parsed by a Turing-Complete language. Because Wololo is written in Clojure, and Clojure is a full-fledged LISP, it's possible to "hook" into the parsing pipeline to create any Abstract Syntax Tree (AST) in any way that is desirable. This is strictly required for languages whose grammars are themselves Turing-Complete, such as C++. * Any grammar defined using Wololo can be compiled to a stand-alone program that parses a given input (using the grammar), and produces an AST as a readable XML file. * Our idea is to eventually write the best RPM spec file parser that is possibly achievable, using Wololo as its foundation. The aim of this talk is to: * Share insights about LISP, a somewhat esoteric programming language family that is often overlooked, but still incredibly valuable to present-day software engineering tasks. * Talk about Spirit (C++) and Parsec (Haskell), other libraries that follow the same approach Wololo uses. * Describe Wololo in detail, provide concrete examples, talk about its ongoing development, and where we ultimately want to arrive with this project (goals). * Talking about the existing parser for RPM spec files in general, why we think regular BNF grammars won't solve this problem perfectly, and how we aim to get there. * Invite contributors and gather feedback from the internal SUSE development community.

Goal of the project is to look more into practical usability of PSI (pressure stall information), a Linux kernel scheduler feature that provides insights into resource contention. I will explain the concept and variants of the metrics. I will show some examples of PSI values, I will consider its applicability to some user scenarios and compare it with some more traditional metrics. Ideally, I'll peek into overhead of PSI tracking.

In the last few years Kanidm has grown significantly and become a mature IDM provider - we'll cover it's latest features, it's goals, and even see a live demo of some of it's features. Finally we'll also cover the future and what's planned and in the works today. This little crab has come a long way since it was last discussed at labs!

AI in the form of Large Languages Models are good in transforming language based descriptions into actions. The idea of kowalski is to use the (openSUSE) documentation enriched with the actual state of the system to create concrete solutions for the user. https://github.com/openSUSE/kowalski

The Kernel Key Retention Service is a Linux Kernel feature that allows cryptographic keys, authentication tokens, cross-domain user mappings, and similar to be cached in the kernel for use in filesystems, kernel services, and by user-space [1]. Each key is stored in a keyring, which is a special type of key that is used to hold other keys. A key can be linked to one or more keyrings. Keyrings can have different lifetimes, and be associated with a program, thread, or session. Key types can be extended through modules, and the kernel supports a number of asymmetric, symmetric, trusted and encrypted keys. Interaction with the service is done via three syscalls: keyclt(2), add_key(2), and request_key(2). The focus of this work is on trusted keys [2] backed by a TPM trust source. I show that using only the 3 syscalls listed above, one can use the kernel as secure storage for sensitive cryptography material without using external dependencies; and can even replace external, hardware-based, solutions like smartcards and YubiKeys. As a proof-of-concept, I've implemented a SSH-agent [3][4] that stores all of it's sensitive cryptographic material in the kernel using a trusted key to bind each of it's keys to the host machine. I've also explore the problems and approaches used to persist keys, given the volatile nature of the service. A comparison is made with other operating systems, like the Keychain on macOS; and also, with other key management/interoperability protocols like PKCS #11 (commonly used in tokens/smartcards). I also present future work that can be done in the kernel to improve the usability of the service by user-space applications. [1] - https://docs.kernel.org/security/keys/core.html [2] - https://www.kernel.org/doc/html/latest/security/keys/trusted-encrypted.html [3] - https://github.com/say-fish/zssh [4] - https://github.com/say-fish/krs-agent (Will be available in a few weeks)

openSUSE Leap is a "traditional" community distribution built on binary packages from SLES. In this session, we'll dive into the recently released openSUSE Leap 16.0 Beta, exploring its new features and changes. We'll also cover the migration process from Leap 15, including any challenges or considerations to keep in mind.

This talk will present how I'm currently running BPF selftests (test suite for BPF that is part of Linux kernel source) to test upstream stable 6.12 LTS releases and SL-16.0. Additionally, I'll present a brief detail of the implementation issue I encountered, as well as the benefit of doing so. The talk will be relatively short, and the expectation is to have the rest of the session used for discussion.

I wanted to get together the people who are interested in writing their own plugins together and essentially have a crash course in development. While in the past I have had sections in the talk, It's not easy as a viewer to follow along(if you are interested). I also wanted to have a section about writing tests as this is a topic I haven't covered before and isn't suited for a talk and would benefit from the workshop structure.

Discover how the open-source /Himmelblau/ project enables Microsoft Entra ID authentication on Linux systems, including support for MFA, passwordless login, and device trust. This talk explores how Himmelblau integrates with PAM/NSS, leverages OAuth2 flows, and bridges the identity gap between Linux and Microsoft's ecosystem—making it possible to securely log in to Linux using Entra ID credentials in hybrid and cloud enterprise environments.

kABI is a kernel variant of the application binary interface. SUSE kernels provide stable kABI support, which is one value add. Maintaining such stability requires the ability to effectively compare the ABI of new kernel builds with a known-good baseline. The talk offers a brief introduction to kABI concepts and shows the relevant tooling used in SUSE kernels. It will then focus on the kABI comparison and the limitations of the current downstream implementation, primarily regarding speed and output clarity. To address these problems, the talk will introduce suse-kabi-tools, a new set of tools designed for improved analysis. The presentation will detail their design and usage, emphasizing their performance and clearer output. The talk concludes with a summary and a discussion of future plans. The session will provide a good overview of the new suse-kabi-tools, their fit into the current tooling, and how they help in understanding kABI changes.

SUSE internal only!

Performance team regularly evaluates how performance of a given kernel compares with performance of a baseline kernel. Given the complexity of contemporary hardware as well as operating system itself this is a surprisingly difficult task. In this talk we discuss various approaches to comparing performance. We start with naive methods, leading to unreliable and often misleading results, and continue to approaches with increasing level statistical soundness. On these methods we demostrate various problems one can meet when doing performance comparison as well as possible solutions. Only secondary school level of mathematics knowledge is expected, we'll build all the necessary mathematical and statistical tools using that.

About the abstract * About the GitLab in SUSE. * Who and How take care about the tool. * Shared runner and how user can build their own * Token basic - what to NOT do with it * Cool new features like GitLab registry and more. * What we are working on for the future

Since 2022, the Packaging team has been developing Packtrack, a multi-purpose tool aimed at helping package maintainers find the information they need to succeed at their tasks.Following our development schedule since the presentation during last year's Labs Conf, we have developed several new features: * IBS integration * Comparing versions across multiple codestreams * Easier upstream version checking (outdated packages) * Single sign-on (SSO) * Integration with SMELT and SMASH Through this talk, we'd like to showcase the new features, demonstrate how Packtrack can work for everyone to gather information regarding specific packages, talk about its development process and where we're headed in the future.

Last year we presented a proposal for Git based OBS projects. At the time of this writing, the workflow is live or partially live. We would like to present * the current state, and current state of tooling * efficient usage of these workflows * current developments

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 try to 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!).

Shim is a first-stage UEFI bootloader. SLE/openSUSE uses it to enable secure boot and MOK, loading/verify grub2. This talk will share some new things about SUSE shim. e.g. options.csv, SbatLevel_Variable.txt, Code Signing EKU support, NX and certwrapper... so on.

This session gives developers a practical intro to the IBM Z and LinuxONE architecture (what we in Linux ecosystem call simply s390x) — LPARs, VMs, and how it all compares to x86_64. What tools you actually need to work with an s390x machine, how to do common sysadmin/programmer tasks and what to be aware of (gotchas, tips and tricks). We’ll go hands-on with 3270 terminal, s390-tools, and other platform-specific software. Plus, we’ll cover how to reserve machines, test, and actually get stuff running on it. s390x is one of the four main 64-bit computer architectures we, at SUSE, support. If you’ve ever wondered how to work with it, this is your chance to find out.

Five years. That's how long it took to make `printk()` RT-safe in the upstream kernel. For those unfamiliar, `printk()` is a critical logging function within the Linux kernel. It started as a single RFC patchset covering the basic RT needs, but culminated in a massive rework of the `printk` subsystem, addressing several long-standing issues. Now, `printk()` has been RT-safe in the upstream kernel since version 6.12, released in November 2024. What were the challenges? What was the cost? Does this mean the work is truly finished, or is `printk()` merely mid-journey? And what unexpected twists await us in the next chapter?

Livepatching allows for the application of security or critical bug fixes to a running kernel without requiring a system reboot. Unlike traditional patches, which are applied to the kernel source code and require a rebuild and reboot, livepatches apply to the running kernel directly. The increasing number of CVEs affecting the kernel has prompted the developers to revisit and refine the SUSE livepatch creation workflow. This refinement aims to minimize their time to market and, most importantly, ease the learning curve for new volunteers and contributors. This talk gives an overview of the kernel subsystem, the tools and the workflow that the kernel livepatching developers have designed to streamline the process: from the CVE to the kernel patched at runtime.

Some kind of static, dynamic, fixed or variable partitioning of the host resources, for assigning them to the VMs, is the most effective mechanism for achieving good performance in virtualization workloads. As it is easy to guess, static partitioning and exclusive assignment (e.g., od CPU time, of RAM, ecc) is the strategy that guarantees the best results. But it is also extremely inflexible and at risk of wasting resources, so it would be nice if there are alternatives. Avoiding the meticulous and error-prone task of manually pinning all the VMs to the host pCPUs and memory would be a great improvement. Even better it would be if the VMs could be not only "placed" where it make the most sense at the time when they are created, but also dynamically moved across CPUs and/or NUMA nodes when necessary... But not too frequently! In a KVM system these tasks can be fulfilled by two component: a user-space daemon called NUMAD, and the in-kernel automatic NUMA balancing (NUMAB? :-)) and having both active at the same time can be problematic! NUMAB is considered more advanced and effective, to the point that we are in the process of kicking NUMAD out of our distros. But NUMAD can be used for computing the initial placement of the VM, while NUMAB lacks this feature. So, what? Which one shall we kill? Which one shall we keep? Can we afford losing initial placement entirely? Is there a way for mixing the two and getting the best of both worlds in a safe and sound way? During this talk we will analyze in more details the situation, propose potential solutions and show the results of an experimental evaluation of some of them.

SUSE Multi-Linux Manager 5.1 is the second release after moving product to the container world. Let us take a look at what makes this an exciting new release, what are the lessons learned and what to look forward to next.