WhtsThsWeirdMsg

Fedora Is Not a Product

2026-04-28T00:00:00-05:00

This is going to sound crazy, but I believe that the purpose of a distribution is to distribute software.

Hear me out…

TL;DR

Kernel packaging

2026-04-17T00:00:00-05:00

TL;DR

If you are interested in building alternate kernel packages or kernel module packages for Fedora, or if you’re interested in testing alternate kernels or kernel modules on Fedora, let’s chat.

Fedora’s kernel works well if you don’t need out of tree drivers

When I look through user forums, one of the problems I see described most frequently is a blank screen on boot. Sometimes this is a first-time setup and the user hasn’t followed all of the documented installation steps, or they haven’t followed the correct list of steps. (In theory, this should be a one-click operation for users that have enabled third party repos, but the last time I checked that doesn’t actually work because rpmfusion only provides AppStream data for their primary repos, not for the NVIDIA driver repo that users can enable as a third party repo.) Sometimes they’ve rebooted the system without waiting for the invisible background process of building the display driver module and the kernel initramfs to complete. Sometimes it fails and there’s simply no indication to the system’s user why. Maybe the disk ran out of space.

Whatever the cause of the problem, I think that this is one of the top reasons that Fedora is often not rated as a “beginner-friendly” distribution.

Fedora’s policies prohibit alternate kernels, and packaging kernel modules. I suspect that this is driven at least in part by requirements imposed by the agreements under which their Secure Boot signing keys are signed by the UEFI 3rd party signing CA. That’s all perfectly reasonable, but it’s also a barrier to any kind of experimentation or improvement.

I am convinced that Fedora users need pre-built kernel modules. As an SRE, I believe that reliable systems build code, test the build, and then deploy the tested build. Systems like akmods and dkms deploy the code first, then build it in place and “test in prod.” It is inevitable that such systems will fail regularly.

The Nova driver will eventually resolve this problem for most NVIDIA users, but there will continue to be users who want out of tree drivers for ZFS, VirtualBox, WiFi drivers that haven’t merged yet, etc.

Ready-to-run signing infrastructure

There’s no shortage of information about how to sign code with pesign, but they’re not always easy to use. Some guides don’t actually work on contemporary releases. Some guides are hardware specific.

The best way to promote a process is to make it as easy as possible. If a process can simply be “fork and build”, it’s much more likely to be adopted and deployed. I’ve developed a Terraform project that you can fork and build to deploy a VPC in AWS in which a forgejo-runner has an HSM with code signing certificates. Users who install the signing certificate in their MOK can use kernels and kernel modules produced on this infrastructure.

Below, you can find the Terraform project, a kernel rpm, a kernel module rpm, an Atomic desktop configuration, and an Atomic desktop container image, all of which can serve as starting points for further development:

If you’ve installed an Atomic desktop, you can try the Fedora Remix:

sudo rpm-ostree rebase ostree-unverified-image:registry:quay.io/gordonmessmer/atomic-desktop/silverblue:43.20260411.0

Various guides to signing code for Secure Boot

https://fedoraproject.org/wiki/User:Pjones/SecureBootSmartCardDeployment : Peter Jones described how to set up signing infrastructure for Feodra systems
https://forge.fedoraproject.org/infra/ansible/src/branch/main/playbooks/groups/buildhw.yml : Fedora’s infrastructure playbooks describe its signing setup
https://forge.fedoraproject.org/infra/ansible/src/branch/main/roles/bkernel/tasks/main.yml
https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/signing-a-kernel-and-modules-for-secure-boot_managing-monitoring-and-updating-the-kernel - Red Hat documents signing kernels and modules
https://wiki.almalinux.org/development/private-keys/secure-boot.html : AlmaLinux documents their setup
https://gist.github.com/chenxiaolong/520914b191f17194a0acdc0e03122e63 : Building Fedora RPMs that use pesign
https://gist.github.com/joostd/ac44db2d4e8e9bdbdde7cdab5c05c0fb : Signing EFI images with keys generated on a YubiHSM 2 device
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-User-Documentation : EDK II User Documentation includes Signing UEFI Images.pdf V1.31 This document describes how to sign UEFI images for the development and test of UEFI Secure Boot

Building a Robust Code Signing Infrastructure with AWS KMS

2026-04-10T00:00:00-05:00

Motivation

One of the reasons that I often see other systems recommended to new users is that the software required to support a large number of common devices is harder to set up and more troublesome to maintain on Fedora than it is on other systems.

That makes sense to me. I’m not a huge fan of DKMS/akmods. With an SRE background, I tend to believe that software should follow a build->test->deploy sequence, but installation from source (as in DKMS/akmods) is more of a deploy->build->test sequence. If the build process is disrupted (e.g. power loss, reboot during the silent background build, running out of free disk space, etc), or if tests fail, recovery options are limited because the software has already been deployed. That’s not a recipe for reliability.

Moreover, I advocate the use of Secure Boot. While there are systems in place to support local builds on a host that has Secure Boot enabled, they require the signing key to be located on the host, and usable by automated processes. If your package manager can build and sign kernel modules, then a rootkit can do the same thing. These systems defeat the purpose of the Secure Boot system.

I want:

a system that can build and sign code for use with Secure Boot
using an HSM so that the signing key cannot be exfiltrated
providing transparency logs so that the key cannot be quietly misused
on infrastructure that can be readily forked, deployed, discussed, and improved

The Challenge: Securing Code Signing in CI/CD

Code signing is fundamental to software security—it proves that binaries haven’t been tampered with and come from a trusted source. But some signing configurations have a critical vulnerability: the private key must exist somewhere, and wherever it exists, it can potentially be stolen.

This project tackles that problem head-on by building a code signing infrastructure where:

Keys cannot be exfiltrated
Keys cannot be used by unauthorized repositories
Every signing operation is transparent and auditable

The Solution: Hardware-Backed Signing with Public Transparency

The architecture uses AWS KMS (Key Management Service) asymmetric keys—RSA-4096 keys backed by FIPS 140-2 Level 2 validated hardware security modules (HSMs). The private key material never leaves the HSM boundary. Ever. Not in memory, not on disk, not over the network.

Core Security Properties

1. Key Exfiltration is Cryptographically Impossible

Unlike traditional signing where a private key file exists on disk (even if encrypted), AWS KMS keys exist only within HSM boundaries:

The private key is generated inside the HSM
All signing operations happen inside the HSM
The private key material is never exposed in plaintext
Even AWS administrators cannot extract the key
The key can be used only via authenticated AWS API calls

This means an attacker who fully compromises a build runner gets nothing. No key file to steal. No memory to dump. No credentials that grant signing access outside the controlled environment.

2. Cryptographic Transparency Logs

Every signing operation is automatically logged to a public S3 bucket via a Lambda function that processes CloudTrail events:

{
  "version": "1.0",
  "timestamp": "2024-01-15T12:00:00Z",
  "kms_key_id": "arn:aws:kms:us-east-1:...:key/...",
  "signing_algorithm": "RSASSA_PKCS1_V1_5_SHA_256",
  "message_digest_sha256": "abc123...",
  "signature_base64": "def456...",
  "record_hash": "789ghi..."
}

These logs provide:

Public auditability: Anyone can verify what was signed and when
Non-repudiation: The signature proves the key owner signed the digest
Tamper evidence: S3 versioning ensures logs cannot be silently modified
Cryptographic proof: Each log includes the signature that can be verified with the public key

The Lambda function sanitizes the logs to exclude:

Source IP addresses
IAM identities
Request context
Any sensitive AWS metadata

Only the cryptographically verifiable facts are published.

The Architecture: Defense in Depth

The system implements multiple security layers that work together:

Network Isolation

Runners operate in a public subnet but with security groups that block all inbound traffic. The runner pulls CI jobs and pushes artifacts.

Note: During early development of the architecture, administrative access is available via AWS Systems Manager Session Manager. The final production deployment is intended to provide no interactive access to the runner.

VPC endpoints keep AWS service traffic within the AWS network:

S3 endpoint (Gateway type): No data transfer charges, private S3 access
KMS endpoint (Interface type): KMS operations never traverse the public internet
Secrets Manager endpoint: Runner tokens retrieved privately
CloudWatch Logs endpoint: Monitoring traffic stays private

IAM Least Privilege

Each runner has a dedicated IAM role with minimal permissions:

Code Signing Runner can:

Call kms:Sign
Retrieve the public key via kms:GetPublicKey
Write to the transparency logs S3 bucket
Read the Forgejo runner token from Secrets Manager

Immutable Audit Trail

Multiple overlapping audit systems ensure complete accountability:

CloudTrail: Logs every KMS API call with AWS identity, IP, timestamp
CloudWatch Logs: Real-time streaming of signing operations
S3 Transparency Logs: Public, versioned, immutable records
S3 Access Logs: Track who reads the transparency logs
Lambda Execution Logs: Record transparency log publication

All logs are encrypted at rest, and S3 versioning means modifications are visible in the version history.

Auditability and Compliance

The transparency logs enable:

Public Accountability: Anyone can verify that signatures are legitimate by:

Fetching the transparency log entry
Downloading the signed artifact
Computing its SHA-256 hash
Verifying it matches the logged digest
Verifying the signature with the public key

Incident Response: If a compromised binary is discovered:

Find it in the transparency logs (indexed by date)
Identify the exact timestamp
Review CloudTrail for the signing operation
Determine the source (instance ID, IAM role, Forgejo workflow)
Investigate the build that produced the artifact

Compliance: The architecture supports:

SOC 2 (audit logging, encryption, access control)
ISO 27001 (security controls, monitoring, incident response)
FIPS 140-2 Level 2 (KMS hardware-backed keys)
Non-repudiation requirements (cryptographic signatures + immutable logs)

Building Trust Through Transparency

Code signing is fundamentally about trust. Users need to trust that the software they run is legitimate and hasn’t been tampered with. But traditional signing approaches require trusting that the private key is kept secure—a trust that’s regularly violated.

This infrastructure shifts the trust model. Instead of “trust that the key is secure,” it’s:

Trust the cryptographic impossibility of extracting KMS keys
Trust the mathematical proof of signatures verified by public keys
Trust the audit trail in public transparency logs
Trust the infrastructure-as-code that can be reviewed and reproduced

The security doesn’t depend on secrecy. The entire architecture is public (this repository, the transparency logs, the public keys). Security comes from cryptographic properties and defense in depth.

For anyone building CI/CD infrastructure for security-critical artifacts—whether kernel modules, container images, firmware, or applications—this architecture provides a template for signing without the risk of key compromise.

The code is here: https://codeberg.org/gordonmessmer/signed-code-build-stack

The transparency logs are here: (configured per deployment)

Technical Appendix

References

Infrastructure Repository: https://codeberg.org/gordonmessmer/signed-code-build-stack
Copr Packages: https://copr.fedorainfracloud.org/coprs/gordonmessmer/aws-kms-pkcs11/
Kernel Repository: https://codeberg.org/gordonmessmer/kernel-longterm-6.12-plus
AWS KMS Documentation: https://docs.aws.amazon.com/kms/
Forgejo Documentation: https://forgejo.org/docs/
Fedora’s build infra definition: https://forge.fedoraproject.org/infra/ansible/src/branch/main/playbooks/groups/buildhw.yml

Comments are hard

2026-03-09T00:00:00-05:00

As the joke goes, “There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.”

In truth, one of most difficult things in software development might be comments, and the more experience you have developing software, the harder it becomes.

There are some things that should be very obvious about comments at some point. Comments should explain why, not what. Well written code will tell readers what is happening, but not necessarily why. A developer may look at a block of code and unerstand that this code builds a data structure… Why does it do that? How is the data used later? How much memory does the structure cost, and how much does that improve run time? If you don’t know the answer to these “why” questions, it’s hard to tell whether things work as expected in the future. The same is true for commit messages. The diff tells a reader what is being changed, the commit message doesn’t need to describe that. Why is it being changed?

That’s the easy part.

The hard part is the question: what will the next developer to work on this know, and what do they need to be told?

You might be familiar with the the Dunning–Kruger effect. Their paper illustrates that skill exists along a spectrum, and both people at both ends have a poor understanding of people at other points along the way.

Without a clear understanding of what the typical developer understands, it is very difficult to write comments that answer “why” questions that most developers will have. An experienced developer will tend to describe too little, assuming that most developers already know what they need to know to contrubute. It can be especially difficult for experienced developers to overcome that tendency, and offer those explanations, because explaining things that seem obvious to them will, at some point, feel condescending.

My advice, or perhaps my request, to all developers is this: ask yourself why code needs to do what it is doing, and explain that as if to a student developer. Explain it more than you think you need to. Write until it is embarrassing to write. Tell yourself that the embarrasment is the cost of experience.

Memory Efficiency With Arena Allocators

2026-03-02T00:00:00-06:00

If you’ve ever heard someone ask about lightweight desktops for older hardware, you’ve probably heard GNOME referred to as a heavy weight option.

One of my hobbies is resource efficiency projects.

Last week I circled back around to a project that I’d put on my list a couple of years ago but never got around to: gnome-software. On a typical workstation, gnome-software will often use more memory than even gnome-shell itself. It will usually be the single most memory expensive component of the GNOME desktop.

gnome-software serves several purposes. In the GNOME desktop overview, it provides search results for applications that are available but not installed. It also provides a GUI for software management. And it provides notifications to the user when there are updates available to install. Notifying users that updates are available is important to maintaining a good security posture, so disabling the application entirely isn’t a great option. But its memory use tends to cause some users to seek out more resource friendly shells for their older hardware.

I’d observed that the gnome-shell process tended to increase in size as it handled search requests from the GNOME desktop overview, so I started by splitting the application search functionality out of gnome-software, and into its own application. As a separate application, it was much easier to profile the application and its memory use. Many profiling tools will hide details that are very small relative to the whole application, so getting the GTK+ code out of the process made it easier to see where memory was being allocated.

valgrind didn’t report any leaks, so the memory allocations that increased the resident size of the process were being tracked. I moved on to valgrind’s massif tool to get information about where memory was allocated. The tool confirmed that there were peaks of high memory use, but it also indicated that most dynamic allocations were being freed eventually. GNU libc has a “malloc_trim” API that can be used to release memory that had been freed, but using it released far less memory than expected, given the amount of memory that valgrind indicated was still allocated.

This suggested that I might be looking at a problem that is common and well understood, but difficult to solve: dynamic allocations that the application managed were interspersed with allocations that were made and managed within shared libraries.

The basic problem is that memory can only be returned to the OS by free() or malloc_trim() in relatively large, contiguous blocks. As long as some memory within a block has not been freed, that block cannot be released. A POSIX process typically shares an address space, a memory allocator, and a heap with all of the shared libraries that it uses.

Sometimes the easiest way to solve this problem is to use fork() to create a new process that can handle a request, and then exit that process when it’s done, which will reliably release any memory allocated by the process and its shared libraries. But that isn’t a good option if there’s expensive setup for the first request, because forking for every request would mean repeating that expensive setup each time.

What we really want is an arena allocator that can help keep contiguous the memory that the application doesn’t manage. That would allow shared libraries to allocate memory in a way that doesn’t spread untracked allocations through the application’s main heap.

As I pondered that idea, I remembered… glibc does have an arena allocator. It uses per-thread arenas to reduce lock contention during allocation in threaded applications. And I wondered, how difficult would that be to expose to applications so that they could provide a hint that they wanted allocations to use a different memory pool.

Such an API should be very simple. There should be a function to request a new arena, and there should be a function to swap the current arena for a new one. An application could then allocate a new arena for shared libraries that are known to allocate memory, and it could swap memory arenas before and after making calls into such a shared library.

The idea was simple, but I wasn’t familiar with the design and architecture of glibc. So I described the API that I wanted to add, and asked Claude to implement that API in glibc’s malloc, consistent with the coding standards used in the library.

Before diving into the implementation details, let’s visualize the problem and solution.

Understanding the Problem

To visualize why arena segregation matters, consider how memory allocations are typically distributed.

Standard glibc: Interleaved Allocations

Without an arena API, all allocations go to the main arena. Library allocations (red) are scattered throughout, interleaved with application allocations (green). Even with a relatively small number of allocations by shared libraries, most memory pages contain at least one library allocation.

After Freeing App Memory (Standard glibc)

Even though the application frees 95% of the memory, each page still contains at least one library allocation (red). Since the OS can only reclaim entire pages, none of this memory can be returned.

Using the API

The API is designed to be simple and lightweight:

The typical pattern is:

Create a dedicated arena once during initialization
Attach the arena before calling library functions
The library’s allocations go to the dedicated arena
Restore the previous arena after the call returns

With Arena API: Segregated Allocations

The arena API segregates allocations into separate arenas, so that the allocations that the application manages are contiguous. Application allocations (green) go to the main arena, while library allocations (red) go to a dedicated library arena. There is no interleaving.

After Freeing App Memory (With Arena API)

When the application frees its memory, the main arena pages contain no active allocations. Entire pages are immediately returned to the OS. Library allocations remain active in their isolated arena.

The Development Process

Design by blog

At first I simply intended to write about arena allocators. Arena allocators are often written about as a technique to reduce the risk of memory leaks and simplify allocation tracking. An arena allocator can free a collection of allocations associated with an arena all at once. Although memory reclamation issues caused by interleaved allocations is common and well understood, the utility of arena allocators in mainting contiguous allocations is not frequently mentioned, among reference and discussions that I’ve seen.

I started with the initial intent merely to discuss that function of arena allocators. I described them as follows:

An application might process a data stream and dynamically allocate memory as is processes elements in that stream. If it uses a shared library as it processes element, the shared library might also dynamically allocate memory for a private internal cache. In such a case, the heap will contain application allocations interleaved with allocations from the shared library. Even if the application reliably tracks its allocations and frees them when it finishes processing the data stream, the heap might still contain small allocations from the shared library, which prevent libc from returning memory to the operating system.

Hypothetically, a malloc implementation could allow an application to register new memory arenas. The application could then set the preferred arena for a thread to an arena dedicated to a shared library before calling that shared library’s functions, and restoring the default arena on return. By segregating the arenas used by a shared library and by the rest of the process, an application could avoid allocations that it can’t track within its own memory arena, which would improve its ability to compact its memory.

Because the shared library’s allocations will be in a dedicated arena, the application should be able to return memory from its own arenas to the OS, reducing its resident size.

For example, the application might looks something like:

#include 

static arena_hd *netio_hd = NULL;

static void
app_register_netio_hd() {
    if (netio_hd) return;
    netio_hd = malloc_new_arena ();
    if (netio_hd == NULL) {
        // check errno and handle allocation failure
    }
}

static void
app_process_element(AppElement *element) {
    arena_hd *current;

    // Switch to a dedicated arena
    current = malloc_swap_thread_arena (netio_hd);
    netio_process_element (element);
    // Restore the default arena
    malloc_swap_thread_arena (current);
}

Initial Design

In that markdown file, I had describing the API I wanted. I decided to see if Claude to help me implement it quickly to determine whether the idea was worth pursuing.

My first prompt was detailed:

In ../malloc-blog/malloc-arenas-proposed.md I described a problem, in
which an application and a shared library might allocate memory in
interleaved pages within an arena, and suggested that libc might
expose an API that allows an application to request an extra arena and
set a preferred arena before and after calling functions in a shared
library. The current directory contains glibc, and its malloc
implementation is in the malloc directory. I believe that this
implementation uses per-thread arenas. Review this malloc API and
suggest an idiomatic API extension that would allow an application to
request an arena and set a preferred arena for the current thread. The
API will need tests, and I'd also like a demo application consisting
of a main application and a simple shared library that demonstrates
the new API. It should allocate around 200MB of memory total, at 512
bytes per allocation, mostly in the application code but with some
allocations in the library.  Once the memory is allocated, the program
should print stats about its memory use including its resident
size. Then it should free the allocations from the application but not
the library and print stats again. Prioritize consistency with the
programming style in this codebase.

The first implementation looked pretty good at first glance, but failed to build. Claude was able to process the build failures, determine that the problem was that it had defined functions that should have been a public API with libc_hidden_def macros, and corrected the problem.

Once the library and the demo compiled successfully, I was able to run the demo and compare the results. Unfortunately, resident memory use in the application with a standard glibc and the version that used the new API was basically the same.

The initial memory information wasn’t very detailed, but I knew that glibc supported a malloc_stats() function that might give me more information.

This works but each verion of the demo app we've tried shows no
significant difference between the version with the new API and the
version without the new API. Can you add malloc_stats and we'll see if
that provides any hints

The new build produced information that indicated that the new API was successfully creating a new memory arena, but that no allocations were expanding its size.

I reviewed the new malloc_arena_new() function and found that it was nearly identical to _int_new_arena(), which had read about in reference material beforehand. I examined the differences closely and determined that it was initially attempting to allocate a size that was incorrect. However, that didn’t seem likely to be the cause. One thing that I was less sure how to handle was arena ownership. There was code in the initial implementation that handled reference counting and free list handling that looked like it was appropriate for normal arena handling, but which might result in an arena being released and removed in the intended use pattern. In the design I’d proposed, a thread should own multiple arenas.

I told Claude to re-sync with the changes I’d made, and to suggest appropriate handling of reference counting and free list handling:

I've made some changes to malloc_arena_new to make it more consistent
with _int_new_arena. The arena that we're creating with this API is
intended to be used in the current thread and temporarily swapped
while calling a library. So I think this API should avoid some of the
free list accounting normally associated with changing an arena. When
the arena is initially created, it should appear to be attached to one
thread even though it isn't. And when it is attached with
malloc_arena_attached, the free lists shouldn't be changed, nor should
the atttached thread count. Basically, one thread is using both arenas
concurrently.

Claude updated the API, removing the sections that I suspected did not belong, but didn’t understand well enough to adjust on my own.

I rebuilt glibc and the demo app.

Still, no dice. The demo app was still allocating memory in the main arena, while all available debugging information confirmed that the thread_arena pointer was being updated to reference the new arena.

I prompted Claude again:

OK, with the current state of malloc/ and demo/, there are no signs
that the new arena is being used. malloc_stats still shows a second
arena, but basically no utilization. system bytes = 167936 and in use
bytes = 2160. The library's call to malloc appears to be using the
main arena. Check over the malloc implementation to see how it selects
an arena. Maybe setting thread_arena is insufficient?

Claude pondered the malloc code further and found that single-threaded applications bypassed the arena selection logic. That makes sense, of course, since the per-thread arena feature is intended to reduce lock contention in threaded applications. If this feature were adopted, I’d want to enable arena selection when a new arena was created, but for initial implementation purposes, Claude simply created a temporary thread in the demo app.

With that, the demo app started working!

There were some minor inconsistencies in the output from the demo application, so I reorganized some of the reporting code, which finished the initial work on the feature.

Does This Idea Really Work?

Theory is one thing, but does arena segregation actually solve the memory fragmentation problem in practice?

The demo allocates 200MB total: 190MB for the application and 10MB in a library, using interleaved 512-byte allocations. This creates realistic fragmentation where library allocations are scattered throughout memory.

Results from running the demo:

Without arena API:

After all allocations: RSS = 206MB
After freeing app memory: RSS = 205MB (minimal reduction)
After malloc_trim(): RSS = 96MB (still high)

In the demo, malloc_trim is able to find some areas large enough to return to the OS, but a significant amount of memory remains resident.

With arena API:

After all allocations: RSS = 206MB
After freeing app memory: RSS = 15MB
After malloc_trim(): RSS = 15MB

The difference is dramatic: with arena segregation, the application can reclaim the entirety of its 190MB allocation, while the library’s 10MB remains in use. Without interleaved allocations, hidden from the application, the application is able to release memory from its main arena. In the case of the demo, the application doesn’t even need to call malloc_trim()!

Broader Implications

This kind of exploration—prototyping a new API in a complex codebase to validate an architectural idea—would have been difficult to justify without AI assistance. The learning curve for glibc’s malloc is steep: understanding arena management, thread-local storage, optimization paths, and symbol versioning all at once is a significant investment. Without assistance, the time required to explore the idea would have seemed much too high a barrier, with no means to evaluate the chance of useful results.

Using Claude Code allowed me to explore an idea that could have taken weeks or months in just a couple of days during a weekend. With Claude, I could focus on the problem I wanted to solve while getting guidance on implementation details.

The result is a working implementation that demonstrates both the problem and the solution, ready for consideration by the glibc maintainers.

Next Steps

The proof-of-concept demonstrates that arena segregation can dramatically reduce memory fragmentation when application and library allocations are interleaved. The next step is to propose this API to the glibc community and gather feedback on the design and implementation.

If accepted, this simple API could help applications like gnome-software reduce their memory footprint significantly, making GNOME more viable on resource-constrained systems. And beyond GNOME, any long-running application that loads shared libraries with different allocation patterns could benefit from this approach.

The demo code and implementation are available in my glibc fork on codeberg for anyone interested in experimenting with the API or understanding the fragmentation problem in more detail.

https://codeberg.org/gordonmessmer/glibc

Improving Memory Compaction with Dedicated Malloc Arenas

2026-03-01T00:00:00-06:00

malloc’s design can make it difficult to return memory to the OS

A POSIX process shares an address space, a memory allocator, and its heap with the shared libraries that it uses. Because the application and the shared library are allocating memory in the same heap, it can be difficult to develop compact, memory-efficient services, even if there are no memory leaks.

An application might process a data stream and dynamically allocate memory as it processes elements in that stream. For example, a stream might describe a list of applications in a package repository, and the process might allocate memory for entries detailing the release history and for application icons. If the process uses a shared library as it processes elements, the shared library might also dynamically allocate memory for a private internal cache. In such a case, the heap will contain application allocations interleaved with allocations from the shared library.

Even if the application reliably tracks its allocations and frees them when it finishes processing the data stream, the heap might still contain small allocations from the shared library, which prevent libc from returning memory to the operating system. A small number of library allocations can keep a large amount of application memory occupied and prevent it from being returned to the OS.

One Arena with Interleaved Allocations

When both application and library code allocate from the same arena, their allocations become interleaved in memory.

Freeing memory allocated by the application may not be sufficient to return memory to the operating system and reduce RSS because library allocations are scattered throughout the arena, fragmenting the heap. In this illustration, a few small library allocations prevent a large heap from being returned to the OS. This illustrates how a small amount of uncontrolled allocation can have an outsized impact on memory compaction.

Dedicated Arenas for Library Code

glibc already provides per-thread arenas, to reduce lock contention when allocating memory in a threaded process. I’d like to propose exposing an interface that allows an application to request an arena handle, and to set a preferred arena for a thread.

By segregating the arenas used by a shared library and by the rest of the process, an application could avoid allocations that it can’t track within its own memory arena, which would improve its ability to compact its memory.

Using dedicated arenas, application and library allocations can avoid interleaved allocations. When the application’s allocations are contiguous and its arena is free of untracked allocations, the application can reduce its resident size when it releases allocations.

Example Implementation

For example, the application might look something like:

#include 

static arena_hd *netio_hd = NULL;

static void
app_register_netio_hd() {
    if (netio_hd) return;
    netio_hd = malloc_new_arena();
    if (netio_hd == NULL) {
        // check errno and handle allocation failure
    }
}

static void
app_process_element(AppElement *element) {
    arena_hd *current;

    // Switch to a dedicated arena
    current = malloc_set_arena(netio_hd);
    netio_process_element(element);
    // Restore the default arena
    malloc_set_arena(current);
}

Memory Fragmentation in gnome-software Search Provider

2026-02-28T00:00:00-06:00

The Problem in One Sentence

TLS trust store allocations (~4MB) scattered through the heap prevent glibc from returning ~250MB of freed memory to the OS.

Problem Summary

When gnome-software handles search requests from gnome-shell, it allocates memory for:

Release history - Application version history and metadata
Icons - Application icon images
TLS trust stores - gnutls certificate trust lists (via libsoup HTTPS connections)

After the request completes, gnome-software frees the release history and icons, but the TLS trust store allocations remain. These small, scattered allocations prevent glibc from returning memory to the OS, causing the process to grow hundreds of MB larger than necessary.

Root Cause

Each HTTPS request to Flathub triggers a new TLS connection
Each TLS connection causes gnutls to load the system CA trust store (~150-200 certificates)
This creates thousands of small ASN.1 allocations scattered through the heap
When gnome-software frees app data, the trust store allocations remain
These prevent glibc from returning freed memory regions to the OS (heap fragmentation)

Color Coding

Throughout the diagrams:

🟢 Green = Release history allocations
🔵 Blue = Icon allocations
🔴 Red = TLS trust store allocations (gnutls)
⬜ Gray = Free memory

Visual Explanation

Phase 1: Initial State (Idle)

The process starts with minimal memory usage - only ~50 MB RSS.

Phase 2: Handling Search Request

During a search request, gnome-software allocates memory for:

Release history (green) - Application metadata and version information
Icons (blue) - Application icon images
TLS trust stores (red) - gnutls certificate trust lists for HTTPS connections to Flathub

Notice how TLS trust store allocations are interspersed with application data throughout the heap regions. The RSS grows to 280 MB.

Phase 3: After Cache Clear (30s timeout)

After the cache clear timeout, gnome-software frees the release history and icons, but the TLS trust store allocations remain.

The Problem: Each heap region still contains TLS allocations, preventing glibc from returning the entire region to the OS via madvise(MADV_DONTNEED) or sbrk().

The trust store allocations are only ~4-6 MB total, but they pin ~250 MB of heap regions in memory! The RSS only drops to 260 MB instead of returning to ~50 MB.

Call Stack

The trust list allocations occur when downloading icons:

gs_icon_download (gs-remote-icon.c:265)
  → soup_session_send (soup-session.c:3264)
    → soup_connection_connect (soup-connection.c:865)
      → new_tls_connection (soup-connection.c:626)
        → g_tls_connection_gnutls_initable_init (gtlsconnection-gnutls.c:207)
          → g_tls_connection_get_database (gtlsconnection.c:504)
            → g_tls_database_gnutls_populate_trust_list (gtlsdatabase-gnutls.c:590)
              → gnutls_x509_trust_list_add_system_trust (certs.c:384)
                → p11_index_replace_all (index.c:727)
                  → asn1_der_decoding (decoding.c:1627)
                    → _asn1_add_single_node (structure.c:55)

How to select a distribution

2026-02-07T00:00:00-06:00

People who are interested in trying Free Software are frequently bewildered at the number of available software distributions. Perhaps doubly so because there seems to be so little difference between them. And compounded further because Free Software development is a cooperative endeavor, so the distributions which represent the best that Free Software have to offer tend to avoid criticism of their peers.

I do not intend to tell you what distribution to use, but I do want to encourage you to think about who you trust, because that is the thing that will vary the most from project to project. I’ll describe some of the things that I look at when I consider distributions, and how that affects my trust in a project.

I’ve been developing software and working in operations-focused roles since the mid 1990s, so expect a lot of software development philosophy to follow.

First of all, what is a distribution?

A distribution is a project that distributes software.

One of the reasons that it might be difficult to select a distribution is that people use that term to describe something other than the project. In particular, people tend to refer to the software itself as the distribution. I think that’s confusing, because the software is largely the same from distribution to distribution. If you install GNOME on Fedora or GNOME on Ubuntu, they are largely the same software, because the software is developed by the GNOME project. It’s merely being distributed by the distributions. (To the extent that there are differences, I think that is a flaw in one or the other release. It is almost never in the best interest of users or the primary developers of a project for a distribution to make significant changes to their software.)

Mature distributions include tens of thousands of applications and libraries. Offering all of those applications and libraries as a single collection makes them easier to discover and easier to install, but I think the most important function is managing updates. Every individual project is free to discontinue a release series, and to start a new release series at any time. And any new release series may or may not be backward compatible with previous releases. Each of the tens of thousands of projects has to be monitored for updates, and each update has to be reviewed to determine how it affects everything else in the collection.

A distribution sits in between tens of thousands of Free Software projects and millions of users in order to turn tens of thousands of update streams into just one update stream.

Users who are trying to select a distribution tend to ask for a distribution that does X or one that does Y, and the question doesn’t make sense, because the functionality they are asking about is typically developed in upstream projects, not in distributions. If the software has that functionality, it’ll be available to users regardless of who delivers the software to them.

In fact, significant development happening in the distribution rather than upstream creates a lot of friction in the process. It makes it less clear to users where they should report bugs. It frustrates upstream developers who get bug reports for software they did not write and do not maintain. And similarly, especially with LTS distributions, it leads to a lot of bug reports upstream for bugs that were fixed long ago, or reports on release series that are no longer maintained.

The best thing that a distribution can do is to bring users and developers closer together, and get out of the way. That means patching as little as possible, and shipping upstream releases without filtering them or delaying them.

Contrary to what you might expect, the less a distribution does, the better it is.

What differentiates distributions from each other?

The purpose of a distribution is to deliver software, and simplify the process of updating it. But there are details that differ from project to project. I’ll run down a list, ordered from least significant to most significant.

What is included? This item tends not to vary much from distribution to distribution. We’re all building distributions from the same pool of Free Software, and we’re including as much as we can subject to the time our maintainers have available and our notions of what is useful. There is some variation, though, because some parts of the systems we build are difficult or impossible to change after the system is built. That is, if you build a system with GNU libc, you probably won’t also build and distribute uClibc, because your users can’t exchange one for the other. These differences are relatively uncommon, and typically only affect your decision if you are after a very specific and uncommon project.
How is integration managed? Source code often does not transform deterministically into usable software. Most software starts out by discovering features in the environment where it is built, and adapting itself to those features. As a result, the features present in the result of a build are influenced by what other packages were present in the build environment, and often what behaviors were specified on the command line during the build. That means that a maintainer has to make choices about what build dependencies to specify, and what configuration to specify in order to create a binary package with a feature set that’s consistent with expectations, and consistent from build to build. Maintainers need to understand the default behavior of each package, and what their users need from the package in order to make sure that everything within the distribution is integrated well.
How much are the defaults changed? Some distributions are trying to create something unique, and others prefer to deliver software to users in the configuration that its developers intended, as much as possible.
How much is the software changed? Some distributions apply a large set of patches to the software they distribute, and others adopt a policy of pushing changes to the upstream developers first in order to reduce ongoing maintenance overhead and security risks.
What is the distribution’s release cadence? Some distributions, especially those that are oriented toward infrastructure workloads, might release infrequently and support each release for a long term. Those distributions will get new features much less often. Other distributions might release relatively frequently with somewhat shorter support periods. Still others adopt a “rolling” model where there are no distinct releases, just one “current” release that continually receives new features as they’re ready. Many users conclude that they want long-term releases for systems the can set and forget, and I want to caution readers on that point. Most of the projects included in a distribution are not maintained for long-term support. Shipping software to users after support is discontinued by the developers is typically bad for both the developers and the users.
Where is the build infrastructure? Some distributions provide a build infrastructure that isn’t directly accessible to the maintainers, while others allow maintainers to build software on their own systems and upload the results. Providing an infrastructure for builds that maintainers can’t directly access helps ensure that binary packages are the result of the source code and the build scripts, with less opportunity for humans to compromise the build process.
Where is the source? Community oriented distributions offer transparency by publishing their build scripts and patches for review. Secure distributions provide shared infrastructure for source code, because that allows them to enforce policies like “protected branches,” which prevent developers from rewriting the history of source code.
How is software integrity ensured? Security-minded users want to see things like signed kernels and boot loaders (for Secure Boot), and signed packages. Some distributions sign their packages directly when they are built, while others might sign the metadata when the collection is published. In order to trust signatures, packages should be signed as early as possible after built, and both the build and signing systems should not be directly available to maintainers.
How are decisions made? In order to ensure that a distribution addresses the actual needs of its developers and users, decision making processes should be well documented and public.
Who uses it? One of the things you may want to consider when selecting a distribution is its user community. When you have questions, a larger community or a more technically experienced community may be better able to answer those questions. From that point of view, you might choose to select a distribution that’s used by mature organizations, or has a large set of known experienced users.
Is there a code of conduct, and does it align with your values? Does it encourage the kind of community that you want to be a part of?
Is the project sustainable? For many years, we’ve seen notable security events that weren’t the result of flaws in the software, but the result of changes in project membership. If you can take over a project with a large user base, you can ship software to a large user base who wouldn’t voluntarily download and run your software. Sustainability is a critical security concern. When you are selecting a software provider, you want to know not only that you can trust them, but that you can continue trusting them in the future. Large projects with diverse participants tend to be more secure against hostile takeover. Distributions that are derived from other distributions are often the work of much smaller teams who rely on larger projects to do the bulk of the work involved. Those projects might look attractive, but they might also be at greater risk of takeover due to normal turnover among participants.

Practical examples

If that list seems abstract, and you aren’t sure how to evaluate a project, I’ve described some of those characteristics with respect to Fedora, because that is a system that I understand well.

How to choose a distribution: Fedora

2026-02-07T00:00:00-06:00

In Choosing a distribution, I said that it’s not my intent to tell readers what distribution to use, and it still isn’t. But many of the characteristics I described might seem abstract, so they may not answer the question for everyone.

Many of the characteristics I described guided me toward Fedora, first as a user and later as a maintainer. I don’t have comments on all of them, but I’ll offer examples to illustrate how I evaluate those concerns in the context of Fedora.

Fedora includes promising new technology when it reaches adequate maturity, resulting in a highly technically capable system. Fedora often has new features and capabilities before any other distribution.
Fedora has a policy of staying close to upstream, and if I remember correctly, it was adopted shortly after another distro realized that one of the patches they’d been applying to openssl for years had drastically crippled key generation, resulting in a major security incident.
Fedora’s family spans the spectrum of stable release cadences. Fedora publishes a new stable release, every 6 months, with a 13 month support period. CentOS Stream publishes a stable release (based on Fedora) every 3 years, with a 5 year support period. Red Hat Enterprise Linux publishes a stable release (based on CentOS Stream) every 3 years, with a 10 year support period for each major release, and minor releases every 6 months, some of which have extended support periods of up to 4 years. No matter what your needs are, there’s probably a Fedora-derived release with an appropriate cadence.
Fedora’s build infrastructure is well managed, with distribution scripts and patches in Git, and builds managed by Koji. The build infrastructure is secured and private. Packages are not uploaded by maintainers.
Packages are directly signed, which is common for rpm-based distributions, but uncommon for other distributions which usually only sign metadata. Secure Boot is supported.
Fedora has extensive documentation for maintainers of individual packages, and for managing changes in the distribution. Changes are discussed in detail on the mailing list, and approved changes are communicated effectively to everyone who needs to coordinate work in order to make them successful and keep the distribution stable.
RHEL is common in a wide range of industries. CentOS Stream is being adopted by some of the world’s largest and most successful development organizations, including Meta. Fedora is being adopted by AWS as the basis of future releases of Amazon Linux. Fedora’s user and developer communities are a wealth of experience.
Fedora’s code of conduct encourages users to be respectful of one another, to be inclusive, and to be kind.
Fedora is maintained by thousands of contributors, with infrastructure provided by Red Hat. It is one of the most sustainable projects that I can think of.

Complex Packaging Workflow

2026-02-07T00:00:00-06:00

Often, the most difficult part of bringing an application into Fedora isn’t getting the application itself to build, it’s the large tree of dependencies the application has adopted, which haven’t been imported into Fedora yet.

Package registries are a core part of the workflow for developers in many modern languages. Rust developers have crates.io, Python developers have pypi.org, Node.js developers have npmjs.com (or pnpm.io… or jsr.io… it’s complicated). Package registries allow developers to easily get reusable libraries, generally pre-built and ready to use.

Fedora’s package repositories offer similar functionality. They provide a collection of reusable libraries that are ready to use. There are several differences from the language-specific package registries, including the requirement that packages in Fedora’s collection have to be built from source in Fedora’s build systems.

In order to support that requirement, Fedora packagers need to wrap each project’s build system in a common build system that their build infrastructure understands. Package maintainers are effectively providing an alternate registry.

One hurdle in this endeavor is that in a typical package registry, a developer can publish multiple releases in parallel. When an application needs a component from a registry, it will typically request information by the name of the package, it will receive information describing the available versions, and it will select a version according to constraints provided by the developer. However, Fedora does not function like a typical registry in this respect. In Fedora, there is only one package by any name, so in order to provide multiple versions, there must be multiple packages that include parts of the version in the name of the component.

Fortunately, we don’t have that constraint while preparing packages. We can build local source repositories that function more like a registry, and sort out the package name specifics once everything is more or less ready to review.

That brings us to the first tools that can make packaging a little easier.

Registry packager

Fedora includes tools designed to make it easier to bundle components from crates.io and from PyPI. Since we aren’t always sure what version or versions we will need when we begin building a complex application, it might be helpful to assemble a description of how to build all of them, similar to the data in the original registry.

I used Claude to construct simple wrappers for Fedora’s registry import tools. These wrappers create a local git repository in which branches represent minor release series of the component. Once the git repo is assembled, we can check out any branch and build the latest release in that minor release series. (If it’s necessary, we could also check out a previous patch and build that…)

For example:

$ ./crate_packager.py fs4
$ cd crate-repos/rust-fs4
$ git branch
* main
  release-0.11
  release-0.12
  release-0.13
  release-0.5
  release-0.6
  release-0.7
  release-0.8
  release-0.9

Build chains

Many of the packages imported in this manner will build, but some of them will reveal more dependencies that need to be added. As the set of dependencies grows, it can be difficult to track the set that’s needed for a specific application and the order in which they need to be built.

It would be helpful to have a tool to not only track this information, but to manage the build of a list of rpm packages in sequence.

Once again, I used Claude to construct a simple program that wraps mock-scm.

Mock is a tool that manages build environments in which package maintainers can build rpm packages, and its “scm” extension supports building a package directly from a source code repository, so that the package maintainer doesn’t need to manually create a source RPM to start the process.

The wrapper is “rpm-build-assist”. This program takes a YAML file that describes what release to use as the base environment for builds, what type of source code repos are used for the packages (which might be dist-git or source-git), where the resulting RPM packages will be saved, and other details of the build process.

As the packager works through the dependency set, they can simply add new dependencies to the beginning of the list. The build-assist yaml file will serve as a record of all of the packages that need to be reviewed together, what version of each package is currently needed, and the order in which they need to be built, while the script automates the process of building them in sequence during development.

base: fedora-44-x86_64
localrepo: /home/gordon/git/nodejs-electron-results

build:
  - type: dist-git
    url: /home/gordon/git
	packages:
	  - rust-walrus:release-0.24
	  - rust-wasmparser:release-0.240
	  - rust-wasmprinter:release-0.243
...
	  - nodejs-playwright:main
	  - nodejs-husky:main
	  - nodejs-electron:main

Automation

Automation through CI can improve this workflow further by moving the actual builds to dedicated compute infrastructure, and it also creates opportunities for groups of maintainers to work together on a collection of packages, coordinated in a shared source code repository.

Claude helped here, too. Claude wrote a basic container action for use in GitHub runners. It has its own workflow to prepare a container image that provides mock and rpm-build-assist, as well as the action.yml that implements the reusable action.

Now, a repo that contains the build-assist.yaml file can also contain a workflow that runs the build chain in GitHub CI.

name: source-git build and test

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: source-git build
        uses: gordonmessmer/rpm-build-assist-action@main

All of these tools are “proofs of concept”, so there are lots of opportunities to improve them. But even at an early stage, they might be useful to Fedora package maintainers who are preparing complex applications.