Welcome to the LWN.net Weekly Edition for February 6, 2025

This edition contains the following feature content:

• Exposing concurrency bugs with a custom scheduler: putting sched_ext to use to create a novel new debugging tool.
• Resistance to Rust abstractions for DMA mapping: the Rust-for-Linux project runs into a roadblock in the DMA-mapping subsystem.
• The rest of the 6.14 merge window: more changes for the next kernel release.
• An update on sealed system mappings: the controversial idea of preventing changes to system-created memory mappings.
• A look at the openSUSE board election: the openSUSE project struggles to get candidates for its board election.
• New horizons for Julia: interesting changes to the Julia language over the last year.
• LWN site tour 2025: an update on new features added to the LWN site.

This week's edition also includes these inner pages:

• Brief items: Brief news items from throughout the community.
• Announcements: Newsletters, conferences, security updates, patches, and more.

Please enjoy this week's edition, and, as always, thank you for supporting LWN.net.

Comments (none posted)

Exposing concurrency bugs with a custom scheduler

Jake Hillion gave a presentation at FOSDEM about using sched_ext, the BPF scheduling framework that was introduced in kernel version 6.12, to help find elusive concurrency problems. In collaboration with Johannes Bechberger, he has built a scheduler that can reveal theoretically possible but unobserved concurrency bugs in test code in a few minutes. Since their scheduler only relies on mainline kernel features, it can theoretically be applied to any application that runs on Linux — although there are a number of caveats since the project is still in its early days.

Bechberger, who unfortunately could not be present for the talk, is an OpenJDK developer. Since Java has its own concurrency model that OpenJDK is responsible for upholding, Bechberger often has to spend time debugging nasty concurrency problems. After wrestling with one such bug, wasting a lot of time trying to reproduce it, he came up with the idea of making a scheduler that deliberately scheduled a process "badly" in order to try and make misbehavior more likely, and therefore easier to debug.

Hillion works at Meta, mainly on custom Linux schedulers. Meta uses a sched_ext scheduler in production, which is well-engineered, tuned to their specific applications, and reliable, he said. The scheduler that Hillion and Bechberger have built, concurrency-fuzz-scheduler, is the exact opposite of that.

A bad scheduler

To illustrate how a scheduler could expose bugs in an application, Hillion gave an extremely simplified example of the kind of workload that some applications have: a producing thread produces items of work, and a consuming thread consumes them. The items are passed between the threads using a queue. But, each item has an expiration time, after which trying to process it causes an error.

This model may seem oversimplified, but it describes applications Hillion has worked on. He specifically mentioned the case of a large C++ application where someone had copied a pointer to some shared data, instead of copying the data, and not correctly validated that the data would remain alive long enough. In that application, as long as the thread that was using the copied pointer was scheduled often enough, it would run before the data was deleted, and things would appear to work. When the system came under heavy load, the processing thread couldn't keep up, and it started accessing freed memory.

Hillion and Bechberger's scheduler does this deliberately: when a thread is ready to run, instead of assigning it to a CPU right away, their scheduler will put it to sleep for a random amount of time based on some configurable parameters. This gives threads that would ordinarily not have any problem keeping up with each other a chance to let one thread race ahead and overwhelm the other. It also ensures that threads run in a random order, which can help expose bugs as well. In a way, it is the fact that Linux's default scheduler is so good that makes these problems hard to reproduce, Hillion explained. EEVDF is too fair, and only actually lets one thread overwhelm the other when the machine is already overloaded, and even then rarely.

The idea of running threads in a random order is not new. There are plenty of specialized concurrency testing tools that do something similar. But concurrency-fuzz-scheduler is not nearly as fine-grained as such tools usually are. It won't help deterministically find violations of a particular memory model, for example. It will find the kinds of gross logic errors that are common in real-life applications, however.

Hillion showed a recording of a Java application that implements his example running while being managed by the scheduler. In a little less than a minute, the application crashed — an eventuality that they could not get to reoccur on that machine without the scheduler, despite leaving it running for several days.

Early days

Eventually, Hillion would like concurrency-fuzz-scheduler to be able to run on a production machine, increasing the probability of finding bugs without otherwise impacting a workload's performance too much. For now, however, tasks run with the scheduler end up running many times more slowly than they otherwise would, because of the added delays. So currently the scheduler is more suited to use on an individual developer's workstation while trying to reproduce intermittent bugs.

Hillion expects to be able to fix this drawback with a bit more work, however. His job at Meta has taught him that writing a performant scheduler for large machines with sched_ext is a bit tricky. The simplest possible scheduler (which he showed the code for in his talk) is actually quite easy to implement: newly runnable tasks are added to a global queue. When a CPU is about to go idle, it pulls a task from the global queue.

This kind of simple sched_ext demo is nearly obligatory when anyone gives a talk on the topic; the simple C and Rust examples in the scx repository have been presented dozens of times. Hillion's example code, however, was written in Java — as is concurrency-fuzz-scheduler. One of Bechberger's other projects has been working to make it possible to compile Java to BPF bytecode for use in the kernel. Unfortunately, Hillion has not done as much work on that part of things, and didn't dedicate much time to talking about it.

In any case, the simple sched_ext example that has been used to demonstrate the project, while safe and functional for small systems, does not scale to larger systems. The use of a single global queue imposes synchronization costs between different CPUs whenever they need to switch tasks. For systems with dozens of CPUs, especially on separate sockets, these synchronization costs can sometimes get so bad that the system actually gets slow enough to trigger the kernel's softlockup detector and force a reboot, Hillion said.

He explained that sched_ext has a watchdog that is supposed to kick out misbehaving schedulers and switch back to EEVDF. But if a large enough machine has a scheduler that relies on rapidly updating global state, the hardware cost of synchronizing memory between different cores can actually delay things enough that the system won't recover before the softlockup detector trips. In practice, this is not much of an issue. Things only bog down enough to cause problems when all the cores of a large machine are constantly contending for the same global queue; giving each core a local queue and transferring tasks in batches or putting cores to sleep when there aren't enough tasks completely avoids the problem.

concurrency-fuzz-scheduler, however, ends up deliberately introducing serious delays into the tasks it schedules, often running only a single thread at a time and leaving many CPUs idle. Then, when it does run another thread, it may well do so on another CPU to try to expose synchronization problems. No well-behaving scheduler would normally leave so many CPUs idle, or, if it did, it would at least let them go to sleep instead of having them constantly contend for the scheduler's global data structures. Together, the deliberate delays and cross-CPU communication can make concurrency-fuzz-scheduler time out and trigger the softlockup detector on larger systems. So while the scheduler is entirely suitable for use on a programmer's computer, it's not yet in a state where it makes sense to deploy to production (or even to sufficiently large test systems).

Hillion said that the next steps for the project are making it more reliable — scaling it to larger machines, trying to come up with ways to still cause as many problems with less performance overhead, and adding a seed for deterministic randomness.

Questions

After the talk, one audience member asked about whether the scheduler did anything intelligent, such as looking at an application's memory to decide which threads to schedule. Hillion said that it currently does not, but wants to look into the possibility of enabling more communication between an application and the scheduler. Meta's production scheduler lets applications give the scheduler hints about how they should be run, and potentially concurrency-fuzz-scheduler could do the same thing. It should be possible to do things like preempt a task specifically when it's in the middle of a critical section, or holding a lock — that just hasn't been implemented yet.

Another person asked about other sources of erratic behavior. For example, simulating additional memory latency. Hillion agreed that would be useful for catching additional bugs, but said that interfering with processes like that is much harder than just writing a scheduler. There are some things you can do, such as switching a task to another CPU core to force it out of cache, he said, but that's about it. The scheduler would need a lot of additional work to be able to actually interfere with tasks as they run, instead of only when their time slice expires.

After taking several related questions, Hillion said that he was excited to see so many people having interesting scheduling-related ideas. He works on schedulers professionally, and Bechberger was interested in schedulers as well. But part of the promise of sched_ext was that it would open up scheduler development to more people, and he's excited to see whether that means people who aren't as deeply involved in the space can actually try out some of these ideas.

Hillon and Bechberger's concurrency-fuzz-scheduler is a promising example of a sched_ext scheduler that does something more than act as a testbed for scheduling ideas. It is a practical tool for shaking more bugs out of applications — something that is always helpful, in a world where software only grows more complex.

[Unfortunately, LWN couldn't send anyone in person to FOSDEM this year. But thanks to the great video of the talk, we are able to report on it.]

Comments (12 posted)

Resistance to Rust abstractions for DMA mapping

While the path toward the ability to write device drivers in Rust has been anything but smooth, steady progress has been made and that goal is close to being achieved — for some types of drivers at least. Device drivers need to be able to set up memory areas for direct memory access (DMA) transfers, though; that means Rust drivers will need a set of abstractions to interface with the kernel's DMA-mapping subsystem. Those abstractions have run into resistance that has the potential to block progress on the Rust-for-Linux project as a whole.

DMA transfers move data directly between RAM and the device of interest, without involving the CPU. It is difficult to get any sort of reasonable I/O performance without DMA, so almost all devices support it. Making DMA work, though, is not just a matter of handing a memory address to a peripheral device; there are many concerns that must be dealt with. These include maintaining cache coherency, ensuring that pages are resident in RAM, handling device-specific addressing limitations, programming I/O memory-management units, and more. Plus, of course, every architecture does things differently. The DMA-mapping layer exists to hide most of these problems from device drivers behind an architecture-independent interface.

Drivers written in Rust will need to do DMA, so they will need access to the mapping layer. There have been patches to provide some of that access in circulation for some time; Abdiel Janulgue posted a version of this work in early January. This series adds a small Rust module with sufficient support to set up coherent mappings (long-term mappings in cache-coherent memory) for drivers. This work only covers part of the DMA API, but it is sufficient for simpler devices. Upcoming drivers will require that these abstractions are in place.

But Christoph Hellwig, who does a lot of work with the DMA-mapping layer, turned this submission away with a message reading, in its entirety: "No rust code in kernel/dma, please" (despite the fact that the patch did not put any code in that directory). When pressed, he added that developers should keep these abstractions in their own code and said that he had no interest in maintaining multi-language code. Rust developers should keep their wrapping code to themselves, he concluded.

Danilo Krummrich pointed out that the proposed abstractions were doing exactly that — keeping the Rust code separate from the rest: "We wrote a single piece of Rust code that abstracts the C API for all Rust drivers, which we offer to maintain ourselves". The conversation then went quiet for several days, after which Krummrich said: "Since there hasn't been a reply so far, I assume that we're good with maintaining the DMA Rust abstractions separately".

Hellwig, though, made it clear that he is not on board with that plan. He does not want the Rust code anywhere near the DMA layer, and that fact that somebody else would be maintaining it does not change his view. Adding another language (he was clear that he was talking about any language, not Rust in particular) would, he said, make Linux as a whole "impossible to maintain". That has, for now, brought the conversation to a halt.

Without DMA support, there can be no interesting drivers written in Rust. So one option that the Rust-for-Linux developers have at this point is to give up on the whole thing and find a less frustrating project to work on. As appealing as this option might be, it still is probably not their first choice, though.

An alternative would be to do what Hellwig is suggesting and put the abstractions into each driver that needs them. That, however, is not a path toward a more maintainable kernel. When the DMA API changes, as it inevitably will, numerous drivers will have to be fixed, one by one, rather than fixing a single set of abstractions that are used by all. So this, too, might not appear at the top of the list of options as seen by the developers involved.

Yet another approach might be to stash the DMA abstractions somewhere out of Hellwig's immediate sight — not in the kernel/dma directory, in other words. At that point it becomes just another user of the DMA API that, in theory, is not subject to more scrutiny than any other driver. The only problem with this idea is that Janulgue's patch already does that, and it was not sufficient.

Someday, there will need to be a more decisive answer to this question. Krummrich has tried to bring this about with a note asking for Linus Torvalds or Greg Kroah-Hartman to make a decision regarding these abstractions. Other Rust developers have reiterated that they would take responsibility for the maintenance of this code, and that it would not affect the DMA subsystem. Jason Gunthorpe questioned that last claim, noting that a 6.14 pull request was delayed due to a Rust build problem, but Kroah-Hartman answered that it was "a tooling issue that people missed due to the holidays" rather than an example of Rust code holding up development. Neither he nor Torvalds has made any decrees on whether the code in question will be merged, though.

By allowing the entry of Rust, the kernel community has decided — on a provisional basis, at least — that it is indeed willing to maintain a multi-language code base. Perhaps, for now, the desire to banish Rust code to the periphery of the kernel makes some sense, while Rust is still seen as an ongoing experiment. If it is eventually decided that the Rust experiment has failed, backing the existing Rust code out will be easier if it's confined to the edges.

But it seems increasingly unlikely that the Rust experiment will be judged that way. Rust clearly can be used to write kernel code, and there would appear to be some significant advantages to doing that. If the experiment has indeed succeeded then, at some point, the language will need to be treated as a first-class citizen within the kernel. Over time, "I don't want to deal with more than one language" will be an increasingly weak argument against a contribution written in Rust.

That day may be a while in coming yet. Already overworked kernel maintainers will have to find time to learn Rust well enough to manage it within their subsystems. Incoming Rust developers can shoulder some of that burden, but they too will need time to acquire anywhere near the level of experience that the current maintainers have — experience that the kernel community depends on heavily. A change of this magnitude to a body of code as large as the kernel was never going to be a quick or easy affair; it has gone as well as could have been expected so far, but there will be more, perhaps harder, obstacles to overcome in the future.

Comments (305 posted)

The rest of the 6.14 merge window

By the time that Linus Torvalds released 6.14-rc1 and closed the merge window for this development cycle, some 9,307 non-merge changesets had been pulled into the mainline repository — the lowest level of merge-window activity seen in years. There were, nonetheless, a number of interesting changes in the 5,000 commits pulled since the first-half merge-window summary was written.

First, though, to get an idea of how atypical this cycle is, here are the merge-window commit counts for recent development cycles:

Release	Commits
6.13	12,142
6.12	12,115
6.11	12,954
6.10	12,402
6.9	13,342
6.8	13,052

In other words, the norm for a long time is to have at least 30% more commits show up during the merge window than we saw this time. To find a slower merge window than this one, it is necessary to go back to the 3.6 release in 2012 (with 9,140 commits during the merge window) — though, the 4.0 release in 2015, with 9,591 merge-window commits, was close. The slowdown this time, which was broadly felt across kernel subsystems, may well be a result of the timing of the development cycle relative to the holiday season this year and not indicative of a longer-term trend; time will tell.

It is also worth keeping some perspective in mind; as Torvalds said in the announcement: "Of course, 'tiny' for us still means that there's half a million lines changed, and more than 10k commits in there".

The most interesting changes pulled in the latter part of the 6.14 merge window include:

Architecture-specific

• The OpenRISC architecture has gained support for restartable sequences.

Core kernel

• There are two new BPF kfuncs — bpf_local_irq_save() and bpf_local_irq_restore() — that will disable interrupts on the local CPU and restore them again. They are intended to help with the implementation of interrupt-safe data structures in BPF programs. This commit includes a self-test program that demonstrates their use.
• The MADV_DONTNEED and MADV_FREE operations in madvise() will now free the associated page tables (when possible) along with the indicated address range. For some workloads, empty page tables can waste a lot of memory; see this commit for a description of the problem that was solved.
• The ntsync subsystem, which provides a set of Windows NT synchronization primitives, was merged in 6.10 but marked "broken". All of the broken pieces are now fixed, and this subsystem is now fully enabled. The interface implemented by ntsync is documented in Documentation/userspace-api/ntsync.rst.

Filesystems and block I/O

• The XFS realtime device is a special mode intended to provide consistent and predictable latency for filesystem operations. In 6.14 the realtime device has gained support for reverse mapping (mapping a device block to the file the contains it) and reflink (sharing blocks between files) operations.
• The fsnotify subsystem has a new event type called FS_PRE_ACCESS. If a listener has requested this access, it will be notified before content in a file is read, and that access will be held up until the listener responds. The intended purpose, it seems, is to help with the implementation of hierarchical storage systems, enabling the listener to fill in data from slow storage if need be. This operation requires the CAP_SYS_ADMIN capability; as the merge message notes: "it is an administrator responsibility to make sure the userspace event handler doesn't do stupid stuff that can DoS the system".
• The uncached buffered I/O patches have been merged. This block I/O option is meant to provide most of the performance benefits of direct I/O using the normal POSIX I/O API and without some of the pitfalls of direct I/O.
• The NFS server now supports NFS4.2+ attribute delegation, matching the client support merged for 6.11. From the merge message: "An attribute delegation permits an NFS client to manage a file's mtime, rather than flushing dirty data to the NFS server so that the file's mtime reflects the last write, which is considerably slower."
• The NFS "localio" functionality has been enhanced so that clients can perform direct I/O in cases where the client and server are on the same host.
• Work has been underway for some time to allow the filesystems in user space (FUSE) subsystem to use io_uring. That capability has landed for 6.14. There is some beginning documentation in Documentation/filesystems/fuse-io-uring.rst.

Hardware support

• GPIO and pin control: Qualcomm 8917 pin controllers and Mediatek MT7988 pin controllers.
• Industrial I/O: Texas Instruments OPT4060 RGBW color sensors and ROHM Semiconductor BD79703 digital-to-analog converters.
• Input: Intel touch host controllers.
• Media: ST Microelectronics STM32 camera serial interface controllers.
• Miscellaneous: Microchip inter-processor communication interfaces, Samsung Exynos mailboxes, Nuvoton MA35 SoC NAND controllers, ST Microelectronics STC3117 fuel gauges, Thunderbolt 3 interfaces in alternate mode, Qualcomm SM8750 interconnects, and AMD AE4DMA controllers.
• Sound: TI TAS2781 SPI HD-audio side codecs and Awinic Technology aw88083 amplifiers.

Miscellaneous

• The perf tool has, as usual, received a number of enhancements; see this merge message for the list.

Security-related

• Once upon a time, there was a patch series implementing the O_MAYEXEC option to open(), which would cause the open to succeed only if system policy (permission bits, security modules, etc.) would allow the target file to be executed. Its purpose was to enable language interpreters (for Python, for example) to decide whether executing a given file of text is consistent with local security policies. This idea was later reimplemented as the trusted_for() system call, but that one was rejected during the 5.18 merge window.

  In 2024, the idea returned in a form that has now (after yet more changes) been merged for 6.14. There is a new option (AT_EXECVE_CHECK) to execveat() that causes the call to check whether the indicated file would be allowed to execute (without actually executing it). There are two new securebits (accessible via prctl()) that tell interpreters how they should handle input. The bit now named EXEC_RESTRICT_FILE instructs interpreters to use AT_EXECVE_CHECK on a file to decide whether to execute its contents, while EXEC_DENY_INTERACTIVE tells the interpreter to refuse to read interactive commands. Interpreters must be updated separately to implement that functionality.

  See Documentation/userspace-api/check_exec.rst for some more information.

Internal kernel changes

• There has been a significant reorganization of the code for the CRC32 and CRC-T10DIF algorithms; they can now be invoked directly from the library interfaces and no longer need involve the kernel's crypto layer. The result is simpler and more efficient code.
• Kernel modules will be signed using the SHA512 algorithm rather than SHA1 by default.
• The kernel is now able to allocate and free "frozen" pages that have no meaningful reference count. This change will make the slab allocator a bit more efficient, but it also helps in the longer-term goal of shrinking the page structure.
• The new zpdesc memory descriptor also serves that latter goal by acting as a replacement for struct page for zswap pages.
• More Rust bindings have been merged for dealing with PCI buses, platform drivers, Open Firmware, and more. According to Greg Kroah-Hartman: "We are almost at the 'write a real driver in rust' stage now, depending on what you want to do". Included in the merge are a sample PCI driver and a platform driver in Rust.
• There is a new implementation of the build-time code that generates symbol versions for loadable modules. It uses information from the DWARF debugging records rather than parsing the source directly; the main driver for this work is to enable symbol versioning for modules written in Rust. For the time being, at least, both the old and new implementations remain in the kernel, with a configuration option to choose between them.

The 6.14 release is most likely to happen on March 23, though the possibility of a one-week delay is always there. As this release stabilizes, eyes will be on linux-next to see whether 6.15 reverts to the mean with regard to commit activity.

(LWN subscribers can follow the upcoming 6.14 release, perhaps comparing it with 3.6 and 4.0, in the LWN Kernel Source Database).

Comments (none posted)

An update on sealed system mappings

Jeff Xu has been working on a patch set that makes certain mappings in a process's address space impossible to change, sealing them against tampering. This has some potential security benefits — mainly, making sure that someone cannot relocate the vsyscall and vDSO mappings — but some kernel developers haven't been impressed with the patches. While the core functionality (sealing the mappings) is sound, some of the supporting code for enabling and disabling the new feature caused concern by going against the normal design for such things. Reviewers also questioned how this feature would interact with checkpointing and with sandboxing.

Unlike the mseal() system call, which can be used to seal any memory mapping, Xu's patch set is focused specifically on sealing mappings that the kernel uses, before any user-space code starts executing. The patch set seals the memory mappings for five things: the vDSO (code to implement some system calls in user space), vvar (data for vDSO calls), sigpage (code for implementing signal handling on Arm), uprobes (user-space tracing), and vsyscall (an older and obsolete system-call mechanism). Each of these facilities involves having the kernel map some additional pages into a user-space process; all of them except the uprobe pages are created on process startup, and should by and large remain unmodified until the process dies. Uprobes are inserted dynamically, and the kernel maps the pages at that time, but that mapping also lives until the process is terminated.

Each of these mappings is relied on to perform functions that would otherwise be performed by the kernel. Therefore, it's important for security that user-space code doesn't change these pages. If a process had some vulnerability that did allow changing the pages (or the mappings), it could potentially spoof the results of certain system calls, which would be highly exploitable. While not the most common kind of exploit, it is a known kind of attack. Removing the possibility entirely would be another component of defense-in-depth against malware.

These mappings are generally set to be read-only or execute-only, depending on what the architecture supports, but Xu's patch would go a step further by sealing the mappings themselves, preventing them from being made writable or unmapped. This change should provide additional security without impacting the behavior of well-behaved user-space programs, because they were generally not supposed to be touching any of these mappings in the first place.

Checkpointing

There is one major exception, however: Checkpoint/Restore in Userspace (CRIU), which can freeze an application or container and "checkpoint" its state to disk and then restore it. It needs to move these mappings during the process of restoring a stored application, to return them to where they were located in the checkpointed process. The fourth (and most recent, as of this writing) version of Xu's patch set only works for kernels that are built without checkpoint support, and only on 64-bit x86 and Arm architectures. That limitation was not appreciated by some reviewers. Andrei Vagin, one of the CRIU developers, said:

I like the idea of this patchset, but I don't like the idea of forcing users to choose between this security feature and checkpoint/restore functionality. We need to explore ways to make this feature work with checkpoint/restore. Relying on CAP_CHECKPOINT_RESTORE is the obvious approach.

CAP_CHECKPOINT_RESTORE capability controls a process's ability to perform some of the privileged operations that CRIU uses to implement checkpointing and restoration, including reading memory map files in /proc for other processes. Since only trusted programs are supposed to be given the capability, allowing such processes to selectively disable the sealing of system mappings should not expose the system to much more risk.

Vagin also pointed out that CRIU only needs to move mappings during the restore process, not change their properties or contents. Xu thought that was an important detail to consider. He agreed "that forcing users to choose isn't ideal". He questioned whether it made sense to have a prctl() option to control whether mappings are sealed or not on systems with both features enabled, but still thought that the code should unconditionally seal the mappings on systems which did not have checkpointing support enabled.

Xu's patch set seals the created mappings while the kernel is processing a call to execve(); the proposed prctl() option would not be able to disable the sealing for an existing process, but could be used to turn it off for newly created processes. Vagin agreed that such an option would work for CRIU, which controls the way that restored processes are created. He did mention that other programs, such as gVisor, might not be able to make use of the option, however.

Command-line parameters

The larger source of complaints, however, was how Xu's patch set handled the kernel command-line parameter that it adds (exec.seal_system_mappings). The patch set has both a kernel configuration setting and a kernel command-line parameter. This isn't unusual — many features have a configuration setting to build the feature into the kernel, and then a command-line parameter to enable or disable it at run time. Xu's patch set was set up the opposite way around: the feature was always built into the kernel, the configuration setting controlled whether it defaulted to on or off, and the setting could be overridden by the command line. Lorenzo Stoakes objected that the kernel command-line flag just seems like "a debug flag to experiment on arbitrary kernels".

Xu indicated that the design was deliberate, to allow users to enable the security feature even if a distribution chose not to enable it in its kernel builds. Stoakes was not convinced. Xu reiterated that users should know what they're doing, and if a user wants to enable the feature on a kernel that also supports CRIU, and this breaks things, then that's their prerogative. When Xu proved not to be receptive to changes in this area, Stoakes blocked the patch set from being merged, saying: "This series is unacceptable in its current form as it allows untested architectures and known broken configurations to enable this feature."

Even once Stoakes had blocked the most recent version of the patch set, discussion continued, however. Kees Cook summarized the discussion up to that point, saying that if Xu could clarify some details about which mappings and platforms were included, clean up the command-line parameters, and add a prctl() option, he would have everything needed for the next version of the patch set. Liam Howlett thought that there was more research needed, however:

So we have at least two userspace uses that this will break: checkpoint restore and now gVisor, but who knows what else? How many config options before we decide this can't be just on by default?

[...]

And we really don't understand what it will impact fully - considering v4 is still resulting in new things that will be broken.

Stoakes expressed the same sentiment, saying that they should "tread carefully" with this feature, and calling for extensive testing and additional justification of the security benefits. Cook thought that, while additional testing was wise, it was unreasonable to ask for testing of every combination of architecture and relevant flags. He advocated for starting with the minimum number of supported platforms, and narrowly testing those.

Xu raised the possibility of removing the kernel command-line argument altogether, and relying only on the kernel configuration setting to enable or disable sealing. This would be sufficient for Android and ChromeOS, and sidestep some of the problems reviewers were pointing out. He later suggested that, since CRIU is not the only thing that breaks when his changes are enabled, the build-time conflict between his changes and CRIU provides a false sense of safety and could be removed. Stoakes strongly objected to that idea, saying that any patch must not make it possible for a user to accidentally break their kernel. He does want to see this patch set merged, but only once it doesn't include a boot parameter that will silently break things if used incorrectly. Matthew Wilcox was harsher, implying that Xu was trying to get the bare minimum needed by Google upstream.

Pedro Falcato floated the idea of leaving it up to user space to seal these mappings, pointing out that the GNU C library (glibc) is already working toward sealing some parts of the address space (an effort that might soon be finished). Sealing the vDSO from glibc is more complicated than it might seem, Xu explained. The dynamic linker doesn't know how large the vDSO is, especially since it varies between architectures and kernel versions. Also, uprobe mappings (which are created later) couldn't be sealed by the dynamic linker.

The fifth version of this patch set is now in the works. By removing the command-line parameter that reviewers objected to, and fixing some of the other technical problems with the patches, hopefully Xu will be able to get the next version accepted. That will take time, however, and require another round of review that may provoke an equally detailed set of comments. Still, the kernel is one step closer to locking down another potential security problem before it becomes relevant — without handing users another way to shoot themselves in the foot.

Comments (9 posted)

A look at the openSUSE board election

The election to replace outgoing openSUSE board members is underway, with four candidates vying for three seats. The election was initially scheduled to be completed in December, but the timeline was extended due to too few candidates standing for the seats. Voting closes on February 2 and the results are expected to be announced on February 3.

The openSUSE board is tasked with leading the overall project, acting as a central point of contact, helping to resolve conflicts, facilitating communication and decision-making processes, and initiating discussions about new project-wide initiatives. The board has six members, five are elected by the members of the project, and the board chairperson is appointed by SUSE. The outgoing members are Douglas DeMaio, Neal Gompa, and Patrick Fitzgerald. Board members are limited to two consecutive roughly two-year terms and then they must sit out an election period before running again. Gompa is term-limited this time around; DeMaio and Fitzgerald are not running for second terms.

Only members of the openSUSE project are allowed to run for the board. The criteria for membership is "contribution in a measurable way" to the project, and approval by the openSUSE membership team, which is appointed by the board.

Anybody?

The first call for nominations was announced on November 15, but openSUSE election committee member Ariez Vachha said, on December 2, that the committee was extending the timeline because no one had stepped forward to run. Board chair Gerald Pfeifer said that he expected this coming year to be important for the future of openSUSE as a project, and encouraged members who care about openSUSE to step up and run for a seat.

It is, perhaps, not surprising that openSUSE members were not initially clamoring to run for a seat. The board has been subject to turmoil in the past, and this year promises to have its own challenges. For example, there is the lingering question of a name-change request from primary openSUSE sponsor, SUSE, as well as calls to improve project governance and clarify the relationship between the project and the Geeko Foundation. The foundation is a UK not-for-profit entity that takes in and handles money for openSUSE activities, but it is separate from the project and not directly answerable to the board or larger openSUSE membership.

The project has faced a scarcity of candidates before (LWN covered one such instance in 2019), but this seems to be the first time the clock has run out entirely with no candidates.

Candidates and discussion

Ultimately, Vachha announced that four willing members were found to run for the seats by the end of the second nomination phase on January 18. The candidates, with links to each one's platform page, are Jeff Mahoney, Chuck Payne, Rachel Schrader, and Ish Sookun. Mahoney, VP of engineering for Linux systems, is the only SUSE employee running this time around.

The discussion phase has been relatively quiet, but not entirely silent. Christian Boltz asked the candidates what their opinion was about the renaming question. Mahoney said that he obviously couldn't get into SUSE-internal discussions about the topic, but shared his opinion that he was never particularly happy with the project being named openSUSE in the first place. However, after nearly 20 years, it would take time and effort for a new name to reach the same level of recognition that openSUSE has now. The community, he said, should not seriously consider a rename without support to provide the "acceleration" needed to regain public awareness. If that were present, a rebranding could be beneficial:

I think it could be an opportunity for rejuvenation. This board election is a pretty good example of flagging community involvement. We heard people at [the openSUSE Conference] this past summer talk about how difficult it is to join the community in a non-technical role. I know some people love the near-anarchy "do-ocracy" model of openSUSE but it also often turns into "whoever yells the loudest wins." A rebrand could also bring an opportunity to revamp governance to be more inviting to newcomers.

Payne said that the thought of changing the name filled him with a sense of sadness and that he could not support a name change. However, he would support "the direction that the majority [of the community] and SUSE ultimately choose." He said that his primary concern was continued growth and success of the distribution and community.

Sookun first replied to the question with his thoughts on whether a new legal entity, such as a foundation, should carry the openSUSE name. He preferred the openSUSE name, but said success of the project mattered most. He followed up with a note saying that he would prefer the name of the project remain unchanged. Schrader has not respond to the question.

Another openSUSE member, Thorsten Bro, had several questions. Bro wanted to know about the candidates' "pet projects" within openSUSE, their thoughts on the future of a legal setup for openSUSE and the status of the Geeko Foundation, as well as how they would react to "an escalation" on the mailing list. The example given was a long thread started in 2023 by Günter Dachs complaining that a post asking Reddit moderators to switch back to a regular openSUSE logo following the end of Pride Month had been deleted.

Payne said that his project was advocacy, and that he would like to see the openSUSE Ambassador program make a return. As far as handling the contentious thread, he said that he sided with the code of conduct that the board had developed and that the project needed "to move past this and accept everyone as humans regardless". He had little to say about the concept of a foundation, but was in favor of "whatever it takes" for the project to be great.

Sookun said that his project was openSUSE mirrors, and that he had set up the first Linux mirror in Mauritius. "Imagine using Linux for 20 years and always longing for faster updates — then finally experiencing lightning-fast updates." Like Payne, he said that he stood by the code of conduct, and did not feel that display of the pride flag should be restricted to Pride Month. "Inclusivity cannot be limited to certain dates."

He admitted that he did not have a full understanding of what had been accomplished and what was left to do with regard to a foundation for openSUSE. His vision, however, was for an independent openSUSE that could operate on its own.

Schrader responded that she was still looking for the best place to fit into openSUSE, but wanted to focus on making the things welcoming and easy to use for those with accessibility needs. She had not interacted in the pride thread Bro pointed to, but she felt that many Linux communities had not done much to show "that it's a space for all types of people". She wanted openSUSE to be the community that welcomes minorities, and to make that a big part of the project's marketing.

She also wanted to get past talking and move to the actionable stage of rebranding and making the project more independent "and not be seen as just an arm of the corporation". She felt that having a clear path for the project was important as "many onlookers are unsure about the future and may choose another distro because of that."

Finally, Mahoney said his pet project "historically" was maintaining the kernel of openSUSE's rolling-release distribution, Tumbleweed. These days, like his career in general, his focus is more big-picture. "I'm interested in governance and the health and growth of the community and project overall." His take on the escalation story was that it sounded "exactly like every other Reddit moderator story" he'd ever heard. But, the situation could have been avoided with a policy about how long alternate celebratory logos were in use.

Mahoney said that Bro would have to ask the board of the Geeko Foundation for its status, since it is supportive of but independent of the openSUSE project. It would require a lot of moving parts for that to change, though he said that there was a "big intersection" between an independent foundation and his interests in governance and growth of the community. The renaming would also play a role there.

What's next

As Pfeifer indicated, this coming year may be one of the most important for openSUSE in a long time. The board, and larger community, is likely to grapple with a rebranding and trying to chart a more independent path from the SUSE mothership. It is not a great sign that the membership had to be prodded to produce candidates to run for the board. If openSUSE, by any name, is going to increase its relevance and user base it will have to generate substantially more enthusiasm.

It is not solely up to the board to do this, but it could potentially act as a catalyst and cheerleader for a renaissance. In addition to a looming rebrand, the project also has a major release—openSUSE Leap 16—on the docket for 2025. Handled properly, it might be the thing to draw in new users and contributors.

Comments (1 posted)

New horizons for Julia

Julia, a free, general-purpose programming language aimed at science, engineering, and related arenas of technical computing, has steadily improved and widened its scope of application since its initial public release in 2012. As part of its 1.11 release from late 2024, Julia made several inroads into areas outside of its traditional focus, provided its users with advances in tooling, and has seen several improvements in performance and programmer convenience. These recent developments in and around Julia go a long way to answer several longstanding complaints from both new and experienced users. We last looked in on the language one year ago, for its previous major release, Julia 1.10.

Static binaries

It's simple to share Julia projects in environments where Julia is already installed: provide the text files containing the program and one additional text file, called Project.toml, which lists the direct dependencies of the code. This latter file is generated automatically by Julia. The recipient need merely execute the single command instantiate to have Julia install any needed packages to exactly reproduce the environment.

This works well with colleagues who happen to be Julia users; it is great for collaborative development and for reproducibility in scientific research. However, it's a dead end for colleagues who do not have Julia installed. Distributing the program in the form of an "app" would solve the problem, but a normal installation of Julia provides no obvious way to do this.

As Julia is a compiled language, one might wonder what the problem is. After all, you can compile your Fortran or C program into a compact, self-contained (perhaps, depending on shared libraries) binary, and even target a variety of architectures with cross-compilation. Anyone can run these binaries, without a compiler installed.

It has also been possible to compile a Julia program into a static binary for some time, using the PackageCompiler package. Experienced Julia hands use this package to create "system images" (or "sysimages") that contain the Julia runtime along with frozen versions of packages used in their projects. These sysimages load instantly and save time when one is not currently using the Julia read-eval-print loop (REPL).

The major improvements in precompilation and package-loading times that came with 1.10 largely obsoleted the use of PackageCompiler to save startup time. PackageCompiler might still be a solution to the problem of binary distribution except for one serious issue: the binaries that it generates are huge.

The sysimages created by PackageCompiler contain the Julia runtime, the entire standard library, parts of the LLVM compiler, and more. The result is that a "hello, world" program is burdened with about 150MB of stuff that it does not use. (The compiled "hello, world" program will, for example, contain the BLAS linear algebra routines, because, in its current state of development, PackageCompiler does not figure out that they are not needed.) This is a vast improvement over earlier incarnations of PackageCompiler, which turned "hello world" into a gargantuan 900MB, but does not compare well with, for example, the Fortran equivalent. I just used the gfortran compiler to process a Fortran 90 "hello world" program and found that it resulted in a tiny 17KB binary.

Efforts toward reducing the size of binaries have also involved another package for static compilation. This package is only useful for relatively small Julia programs, however, and is confined to a severely limited set of language features. Within these limitations, StaticCompiler can produce truly small binaries, similar in size to those produced by C and Fortran. Because of the limitations, however, interest remained focused on the evolution of PackageCompiler.

Why can't PackageCompiler just strip out the unneeded stuff and create binaries of a reasonable size? That's the obvious question, but finding a way to eliminate the unneeded baggage turned out to be a difficult problem. Julia's dynamic design and its focus on REPL-driven development mean that its runtime and "just-ahead-of-time" compiler were envisioned to be always available behind the scenes. They are used to compile new methods for newly-encountered mixtures of argument types and to keep the whole array of language features at the ready, including various types of introspection. This is the essential reason that binaries created by PackageCompiler are so large, and why so much work was required to allow the programmer nearly full use of all language features while not dragging the entire runtime along with each compilation target.

The goal of creating small binaries has occupied a handful of talented developers over the past few years, and they have recently achieved a new level of success. Development builds of Julia now include an experimental method of invoking the compiler called juliac. This compiler invocation script comes with a --trim flag that "trims" away whatever is not needed to run the program, while still allowing the use of nearly all normal Julia features. The idea is that the user will be able to type juliac at the terminal, instead of julia, to compile a binary rather than run a program or start the REPL. The result is an impressive 90% reduction in final binary size compared with the current version of PackageCompiler. The exact size of "hello world" is fluctuating some in the development builds as of this writing, but it is around 900KB.

The next major Julia release, 1.12, is likely to appear in mid-2025. It will finally include the ability to generate static binaries of a reasonable size, appropriate for distribution. This will be a refinement of the juliac mechanism that is already merged into the development branch.

Static compilation will be the definitive answer to the complaints and wishes of many Julia programmers who have wanted their favorite language to be able to do what the traditional workhorses for scientific computing have done for decades.

juliaup

Julia has always been easy to install and upgrade on operating systems such as Linux and BSD: simply download and expand the tarball and place a link to the julia binary in your path. Julia's package system also makes it easy to keep any number of Julia versions installed on the same machine, with dependencies correctly resolved for projects using different versions of the language. However, it's clear from questions on forums that there are many users of Julia who are less comfortable using command-line tools to navigate their filesystems. Installing, upgrading, or switching among versions often leads to confusion.

Now there is a utility called "juliaup" to make their lives simpler. As juliaup has become the recommended way to install and upgrade Julia, it's now widely used even by Linux adopters (although I am set in my ways and don't bother with it). juliaup does provide some useful abstractions. These are built around its concept of "channels". Some examples of juliaup channels are release, referring to the latest stable version of Julia; lts, referring to the "long term support" release; beta, pointing to the most recent beta; and nightly, pointing to, perhaps unsurprisingly, the nightly build. Thanks to this channel abstraction, one need never refer to Julia's version numbers.

To get the latest nightly, a user simply types:

    $ juliaup update nightly

juliaup also provides a new, flexible julia command for starting the language. To run the nightly build, the command is:

    $ julia +nightly

After executing the command:

    $ juliaup default release

the plain julia command will now use the stable release.

These are just a few examples of how juliaup works. It comes with a collection of other commands to do such things as list available channels, update all channels at once, or refer to specific Julia versions, as well.

Julia in web browsers

These days, fairly complex simulations written in Julia can run completely within the web browser. Alexander Barth has created a fun and addictive simulation of fluid flow that runs in the browser. The visitor can draw boundaries with the mouse and watch the pressure field adapt. The same author has also created a browser-based simulation of surface waves. Those with an interest in chaos theory can find an in-browser solution of the famous Lorenz system of ordinary differential equations. It's remarkably fast, and the demonstration comes with a tutorial explaining how it was done.

These three examples were written not in JavaScript, but in Julia, and run in the browser thanks to WebAssembly. Launched in 2015, WebAssembly (often abbreviated "Wasm") is a binary instruction format that has become widely deployed in modern web browsers. It potentially allows any language to run in a browser, provided someone has written a WebAssembly compiler for it.

The growing list of source languages with WebAssembly compilers in various stages of development is encouraging. We can already use Python, C, Go, Lua, Rust, and many others as replacements for JavaScript. However, despite the impressive examples above, Julia for WebAssembly is still in the early stages of development. Only a restricted subset of the language is supported (for example, no multidimensional arrays). However, the problems encountered in creating small binaries have some overlap with the problems of targeting WebAssembly, so recent progress in the former is likely to help speed along the latter.

Readers interested in getting their Julia programs running in the browser should start with the WebAssemblyCompiler package. The author warns that the code is experimental, but it comes with guided examples.

Features of 1.11

The latest release of Julia is 1.11.3, unveiled on January 21, 2025. The release notes for the 1.11 major version, which appeared on October 8, provide detailed information on the improvements to the language in that release. Here I'll summarize some of the most important and interesting language developments since 1.10.

MemoryRef datatype: many array operations had been implemented in C up to now, which created some overhead. These have now been moved to Julia code thanks to a new datatype called MemoryRef. The performance improvements coming from this change include a doubling in speed of the push!() function that inserts items onto the end of an array. The maintainer of the WebAssembly package remarked that the MemoryRef datatype will finally allow multidimensional arrays to be used in Julia programs destined for WebAssembly.

public keyword: as pointed out in our article about Julia's package system, names in a module can be explicitly exported, which allows their use without namespacing. For example, Base is a library that is automatically imported into every Julia environment. It provides hundreds of functions, from basic mathematical workhorses such as sin() to string manipulation routines such as split(). Julia programmers can use these functions by invoking their unadorned names because they are exported by the modules in which they are defined.

However, Base also contains functions useful in more unusual contexts that are not exported. One example is Base.OneTo(n), which returns something like the interval 1:n, but slightly different in the way that it's treated by the type system. Those who know that they need this function must namespace it by prefixing Base. Although not exported, Base.OneTo() is "safe" to use; it's intended for public consumption and will not break future code. This is not the case for every unexported function defined in every module. Up to now, there was no standard way to tell the difference between a safe unexported function and one that should be considered "private", in the sense that it may not be future-proof. Now Julia's public keyword fills this gap by marking names that are safe to use even if they are not exported. Of course Julia will not stop programmers from using names not so blessed, but now it will warn them.

stdlib excision: Julia 1.11 continues the process that has been underway for a couple of years to remove modules from the standard library and turn them into normal packages. This allows them to be developed independently from releases of the language, which generally allows a faster pace of improvements. It also allows Julia to be distributed with a smaller sysimage, purged of unnecessary libraries, that can start faster and consume less memory. In the latest release, modules from stdlib will all have their own version numbers, formalizing their independent existence.

@main: Julia 1.11 added a @main macro that marks which function in a Julia program file will be the entry point when the program is run (rather than imported). This lets programmers use the same file as a resource imported into other programs and as a file to be executed. For example, a module that consists of a list of function definitions can be imported into another program without any side effects. But if one of those functions is decorated with @main, then, if the same file is executed (for instance by typing "julia file.jl"), in addition to the functions being defined, the one so marked will be run. This is semantically identical to inserting a line at the bottom of the file invoking the name of the main function; thanks to @main, one version of the file can now be used both ways.

Conclusion

Due to the accumulation of improvements in the last several versions of Julia, startup times have become fast enough that I have begun to use the language for utility scripting, something that would have been impractical a few years ago. This trend continues in the most recent version, and the greater ease of compiling programs promised in the next version should make Julia even more suited for building system utilities. It's already become a serious contender to replace Bash and Python for my purposes. If WebAssembly targeting continues to make progress, which the improvements to compilation will also contribute to, then Julia will become a welcome replacement for (or addition to) JavaScript as well, further extending its scope of application.

A solution to the problem of small binaries, to be released as part of 1.12, should allay the misgivings of those for whom the difficulty of sharing compiled programs has kept them away from the language. For Julia's core original audience, who were accustomed to amortizing large compilation times over simulation times measured in days or weeks, the new language's awkwardness in some interactive contexts was an acceptable tradeoff to finally have a modern, expressive medium that did not entail compromises in performance. By successfully meeting the objections of Julia's critics in several key areas, its developers have ensured that their language is poised to widen its scope far beyond that original core user base.

Comments (22 posted)

LWN site tour 2025

Over the past year or so, LWN has added a number of useful new features for our subscribers to enhance the experience of reading and commenting on our content. Those features are of little use, however, to readers who do not know about them. It has been more than a decade since we last provided a tour of the site—it seems that another is in order. Walk this way for a look at the LWN kernel source database (KSDB), enhanced commenting features, EPUB downloads, and more.

Search

The LWN site search engine has been reworked and improved using the PostgreSQL full text search functionality. Searches can be limited on content type and category, making it easy to find a specific article of interest. If you have habitually used that big search engine to look for things on LWN, consider giving the internal search feature another try.

LWN has long hosted searchable mailing-list archives for a number of important open-source projects and Linux distributions. This functionality is provided with the public-inbox project's software. Last year, we added a universal search for all of our hosted mailing lists.

For example, readers can search all mailing lists by date to find emails that match the word "vulnerability" in the subject by visiting the universal search page and using "s:vulnerability" as the search term. Similar search prefixes are available for matching text in the message body (b:), from header (f:), diff file names (dfn:), and a number of others. This feature is available to all LWN readers.

LWN kernel source database

LWN's merge-window summaries and development statistics articles have been a staple of LWN's coverage since we published "Who wrote 2.6.20" in 2007. Our index of kernel release articles has a full list of our development statistics articles. Those are useful, but readers may want to dive deeper into the kernel's development history and look at details that span multiple kernel releases.

To assist with that, we quietly launched LWN's KSDB last May. This is a subscriber‑only feature that provides detailed release data for every major kernel release in the Git era: that is the Linux 2.6.12 release from June 2005 all the way to the most recent release as of this writing, Linux 6.14-rc1. The KSDB shows the release date, number of commits, merges, and provides a breakdown of most active employers for each release.

Subscribers can search the database by developer to see each developer's work in the kernel across releases, and get a list of first‑time contributors for each kernel version. The database includes a full list of -by tags for kernel releases (Reviewed-by, Tested-by, and Reported-by), and a full list of developers that contributed to each release.

The KSDB makes it possible to drill down into all commits by a developer in a given release, with links to each commit. For example, Linus Torvalds's developer page lists his contribution history by release and contribution type. Clicking the link in the Signoff column for the 5.10 kernel will show all of the commits that have a Signed-off-by tag from Torvalds, with links to each. The same is true for Reported-by, Tested-by, and so forth.

All LWN subscribers have access to the KSDB; we welcome feedback in the comments or to lwn@lwn.net on its feature set and ideas how to improve its usefulness in the future.

EPUB downloads

Over the years we have received a number of requests to provide LWN's content in a format suitable for ebooks. We have recently added this feature for subscribers at the professional hacker level (and above). For articles, simply add epub to the URL. For example, visiting https://lwn.net/Articles/1006001/epub will provide an EPUB-formatted version of this article. To access an EPUB version of the weekly edition, just click the "Download EPUB" link in the navigation bar on the left-hand side of the screen.

There is an RSS feed for the weekly edition as an EPUB as well.

Most readers can make use of the EPUB format, but there is always Calibre to convert EPUB into other formats if needed. We have tested LWN EPUBs with services such as Send to Kindle to ensure that they work with popular readers. Of course, there are many different types of readers on the market, so we appreciate any reports of incompatibilities with specific e-readers or ebook software. We are considering additional ebook features and content for subscribers, so watch this space for more information.

Commenting features and account customization

LWN has several ways to view comments. Each article and news item has its own comment thread, of course, and even its own RSS feed for comments. That feed is available by replacing Articles in the URL with headlines. As an example, the comment feed for this article is found at https://lwn.net/headlines/1006001/. Readers can also visit the recently posted comments page for a view of comments on all stories on LWN. That page and its feed are available to all readers. Subscribers have access to the unread comments page, which has a view of all unread comments since the last visit to the unread comments page. Many readers like to see the parent comment when seeing new comments. This is off by default, but can be enabled with the "Display old parent in unread comments" option under "Display preferences" in account settings.

LWN subscribers have access to a number of comment-filtering controls in their account customization page. Readers can choose to view all comments, view only the first-level comments, and even hide comments completely. All readers can choose to receive replies to their comments by email. Subscribers at the project leader (and higher) subscription level may choose to receive all comment responses to an article as well. Of course, we offer the option of HTML or plain-text emails.

Subscribers at the professional hacker level (and above) also have the option to filter users. When the "filter users" feature is enabled, a "Mute user" button will appear next to each comment. If another user is muted, their comments will not be displayed by default, though users will still see a comment indicator with the content hidden and a button that says "Unmute user". This makes it easy to ignore comments if one chooses, but simplifies unmuting a fellow reader if desired. It is also possible to filter all guest accounts so that one only sees comments from LWN subscribers. Visit the comment filtering page to see which users (if any) are being filtered and to unfilter users if desired.

It's worth a reminder, too, that readers can customize LWN's look and feel. Under account preferences, look for the "Display preferences" controls. Users can change the color scheme of the site, pick different fonts, and more. LWN now has the ever-popular dark mode available in the "Bulk options" preferences. It is easy to reset the site colors to the default should theme experimentation go awry.

Get LWN in your inbox

Many LWN readers prefer to receive updates from LWN in their inbox, so we offer a number of mailing list options (what people today call "newsletters") to best fit their needs. Currently we have five lists available; a weekly edition notification list, a daily list that includes all items published on the front page, a more terse daily list with just headlines, and a "just freed" list that notifies readers when articles are freed to all readers. Finally there is a features mailing list for subscribers at the "project leader" (or above) level that includes a full copy of feature articles as soon as they are published. By default, this is sent in multipart plain‑text/html format, but subscribers can adjust this to plain‑text only.

Readers can visit the mailing list subscriptions account preferences page to subscribe or unsubscribe from lists. Set the "Email preferences" option in the account preferences page to receive mail in HTML or plain-text only.

Groups subscriptions and gift certificates

Though this is not a new feature, many readers do not realize that we offer group subscriptions as well as individual subscriptions. Group subscriptions start at ten seats with a discount over individual subscriptions. This is a great way to provide LWN access to a group of developers or other IT staff, and to support the work that we do through LWN.

Need to convince your boss? We have a one-page PDF to help make the case. We are, ultimately, not marketeers nor salespeople and rely on word-of-mouth to help bring in new groups that would benefit from an LWN subscription.

What to give to friends and family that have everything? We recommend LWN gift certificates. Our gift certificates are also useful for small organizations that wish to provide LWN subscriptions to fewer than ten employees. Have questions? We're happy to help—just email us at subs@lwn.net.

What we haven't added

It seems important to note what readers will not find on LWN. Specifically, readers will not encounter obnoxious banners about site cookies, content-blocking features that try to force readers to turn off ad-blocking technologies, or pop-up windows demanding that visitors subscribe to LWN.

Whenever we consider a new feature, we ask ourselves "can this be implemented without JavaScript?" For the most part, that answer has been "yes", though it is sometimes more challenging. All major LWN site features work fine without JavaScript. Like many other sites, we are facing a continual barrage of nonsense requests from content-gobbling site scrapers trying to feed AI models. While we look for ways to block them to preserve site performance, we are avoiding adding any counter-measures that inconvenience our human readers.

While LWN runs a small number of ads, our primary support comes from our individual and group subscribers. We wish to keep it that way. We remain committed to respecting our readers' privacy and providing a pleasant reading experience that works well in all browsers. See LWN's privacy statement to learn about the information we do, and do not, collect. In general, we collect the barest minimum of information needed to run LWN.

More to come

That concludes the tour for today, we do hope that it has been informative. LWN will continue to find new ways to improve the site experience for our readers and add new functionality for our subscribers. We appreciate feedback, suggestions, and news tips, though we cannot promise to implement every idea and write every story. As always, our sincere thanks to the subscribers who have helped us keep LWN afloat all this time. We look forward to continuing to inform, and occasionally entertain, our readers for many years to come.

Comments (23 posted)

Security quote of the week

While the impact of this problem is potentially huge, we struggled with setting a severity combined with the knowledge that a user vulnerable to this is using an over twenty years old and vulnerable zlib and has practically "given up" all security. If there actually exist users vulnerable to this flaw in the world, they most likely already have worse problems than this to deal with.

— Daniel Stenberg in a CVE report.

Comments (4 posted)

Kernel release status

The current development kernel is 6.14-rc1, released on February 2. Linus remarked:

This is actually a _tiny_ merge window, and that's ok. The holidays clearly meant that people did less development than during a normal cycle, and that then shows up as a much smaller-than-average release. I really felt like this year we got the whole holiday season release timing right, and this is just another sign of that.

Stable updates: 6.13.1, 6.12.12, 6.6.75, 6.1.128, 5.15.178, 5.10.234, and 5.4.290 were released on February 1.

The 6.13.2, 6.12.13, and 6.6.76 stable updates are in the review process; they are due on February 7.

Comments (none posted)

Quotes of the week

The thing that makes Linux kernel development so unpleasant is that so many developers/maintainers are focused on arguing their opinion/position rather than trying to understand the problem and work collaboratively towards a solution.

— Josef Bacik

General muse: if a reviewer asks questions regarding a patch then we should treat those questions as bug reports against the changelogs and code comments: required information is missing. So please let's go through reviewer questions as we prepare the next revision of a patchset and make sure that all those questions are fully answered.

— Andrew Morton

Comments (none posted)

Distributions quote of the week

I am concerned that if we are not careful the quality of models we are able to offer our users will lag significantly behind the rest of the world. If we are much more strict than other free-software projects, we will limit the models our users can use. Significant sources of training data will be available to others but not our users. I suspect that models that only need to release data information rather than training data will be higher quality because they can have access to things like published books, works that can be freely used, but not freely distributed and the like.

— Sam Hartman

Comments (3 posted)

GNU Binutils 2.44 Released

Version 2.44 of the GNU Binutils package has been released. Perhaps the most significant change is the absence of the "gold" linker, which is deprecated and about to disappear entirely. Gold appeared in 2008 with some fanfare as a faster linker, but it has suffered from a lack of maintenance in recent years. This release also includes some architecture-specific assembler improvements, and some (non-gold) linker enhancements.

Full Story (comments: 36)

Firefox 135.0 released

Version 135.0 of the Firefox web browser has been released. Changes include more languages for the translations feature, increasing roll-out of the credit-card autofill and AI chatbot features, and (perhaps most welcome):

Firefox now includes safeguards to prevent sites from abusing the history API by generating excessive history entries, which can make navigating with the back and forward buttons difficult by cluttering the history. This intervention ensures that such entries, unless interacted with by the user, are skipped when using the back and forward buttons.

Comments (21 posted)

Freedesktop looking for new home for its GitLab instance

Visitors to the freedesktop.org GitLab instance are currently being greeted with a message noting that the company who has been hosting it for free for nearly five years, Equinix, has asked that it be moved (or start being paid for) by the end of April. The issue ticket opened by Benjamin Tissoires in order to track the planning of a move is clear that the project is grateful for the gift: "First, I'd like to thank Equinix Metal for the years of support they gave us. They were very kind and generous with us and even if it's a shame we have to move out on a short notice, all things come to an end."

The current cost for the services, much of which is for 50TB of bandwidth data transfer per month and a half-dozen beefy servers for running continuous-integration (CI) jobs, comes to around $24,000 per month. Tissoires believes that the project should start paying for service somewhere, in order to avoid upheaval of this sort, sometimes on short or no notice. "I personally think we better have fd.o pay for its own servers, and then have sponsors chip in. This way, when a sponsor goes away, it's technically much simpler to just replace the money than change datacenter." Various options are being discussed there, but any move is likely to disrupt normal services for a week or more.

Comments (39 posted)

GNU C Library 2.41 released

Version 2.41 of the GNU C Library has been released. Changes include a number of test-suite improvements, strict-error support in the DNS stub resolver, wrappers for the the sched_setattr() and sched_getattr() system calls, Unicode 16.0.0 support, improved C23 support, support for extensible restartable sequences, Guarded Control Stack support on 64-bit Arm systems, and more.

Comments (none posted)

What’s new in GTK, winter 2025 edition

Matthias Clasen has written a short update on a GTK hackfest that took place at FOSDEM and what's coming in GTK 4.18. This includes fixes for pointer sizes in Wayland when fractional scaling is enabled, removal of the old GL renderer in favor of the GL renderer introduced in GTK 4.13.6, and deprecation of X11 and Broadway backends with intent to remove them in GTK 5.

The deprecated backends will remain available until then, and no action is required by developers at this time, Clasen wrote: "There is no need to act on deprecations until you are actively porting your app to the next major version of GTK, which is not on the horizon yet".

Comments (95 posted)

Servo in 2024: stats, features and donations

The Servo Rust-based rendering engine project has published an article summarizing its progress in 2024, and plans for the future:

Servo main dependencies (SpiderMonkey, Stylo and WebRender) have been upgraded, the new layout engine has kept evolving adding support for floats, tables, flexbox, fonts, etc. By the end of 2024 Servo passes 1,515,229 WPT subtests (79%). Many other new features have been under active development: WebGPU, Shadow DOM, ReadableStream, WebXR, ... Servo now supports two new platforms: Android and OpenHarmony. And we have got the first experiments of applications using Servo as a web engine (like Tauri, Blitz, QtWebView, Cuervo, Verso and Moto).

Comments (2 posted)

Thunderbird moving to monthly updates in March

The Thunderbird project has announced that it is making its Release channel the default download beginning with the 135.0 release in March. This will move users to major monthly releases instead of the annual major Extended Support Release (ESR) that is the current default.

One of our goals for 2025 is to increase active installations on the release channel to at least 20% of the total installations. At last check, we had 29,543 active installations on the release channel, compared to 20,918 on beta, and 5,941 on daily. The release channel installations currently account for 0.27% of the 10,784,551 total active installations tracked on stats.thunderbird.net.

Comments (none posted)

The Linux Foundation on global regulations and sanctions

The Linux Foundation has published its long-awaited article on international sanctions and open-source development. This is the reasoning that went into the removal of a group of Russian kernel maintainers in October.

It is disappointing that the open source community cannot operate independently of international sanctions programs, but these sanctions are the law of each country and are not optional. Many developers work on open source projects in their spare time, or for fun. Dealing with U.S. and international sanctions was unlikely on the list of things that most (or very likely any) open source developers thought they were signing up for. We hope that in time relevant authorities will clarify that open source and standards activities may continue unabated. Until that time, however, with the direct and indirect sponsorship of developers by companies, the intersection of sanctions on corporate entities leaves us in a place where we cannot ignore the potential risks.

Comments (60 posted)

CFP Deadlines: February 6, 2025 to April 7, 2025

The following listing of CFP deadlines is taken from the LWN.net CFP Calendar.

Deadline	Event Dates	Event	Location
February 13	May 14 May 16	Linaro Connect Lisbon 2025	Lisbon, Portugal
February 17	June 23 June 25	Open Source Summit North America	Denver, CO, US
February 22	May 22	NLUUG Spring Conference 2025	Utrecht, The Netherlands
February 23	June 15 June 17	Berlin Buzzwords	Berlin, Germany
February 23	June 5 June 8	Flock to Fedora 2025	Prague, Czech Republic
February 28	March 24 March 28	TechWeekStorage 25	Geneva, Switzerland
March 1	April 26	Central Pennsylvania Open Source Conference	Lancaster, PA, US
March 1	April 26	21st Linux Infotag Augsburg	Augsburg, Germany
March 2	June 12 June 14	DevConf.CZ	Brno, Czech Republic
March 10	June 26 June 27	Linux Security Summit North America	Denver, CO, US
March 16	July 24 July 29	GUADEC 2025	Brescia, Italy
March 16	May 24 May 25	Journées du Logiciel Libre	Lyon, France
March 28	October 12 October 14	All Things Open	Raleigh, NC, US
March 30	July 1 July 3	Pass the SALT Conference	Lille, France
March 31	June 26 June 28	Linux Audio Conference	Lyon, France
March 31	August 9 August 10	COSCUP 2025	Taipei City, Taiwan

If the CFP deadline for your event does not appear here, please tell us about it.

Events: February 6, 2025 to April 7, 2025

The following event listing is taken from the LWN.net Calendar.

Date(s)	Event	Location
March 6 March 9	SCALE 22x	Pasadena, CA, US
March 10 March 11	FOSS Backstage	Berlin, Germany
March 10 March 14	Netdev 0x19	Zagreb, Croatia
March 13 March 15	FOSSASIA Summit	Bangkok, Thailand
March 18 March 20	Linux Foundation Member Summit	Napa, CA, US
March 18	Nordic PGDay 2025	Copenhagen, Denmark
March 20	pgDay Paris	Paris, France
March 22 March 23	Chemnitz Linux Days 2025	Chemnitz, Germany
March 24 March 26	Linux Storage, Filesystem, Memory-Management and BPF Summit	Montreal, Canada
March 24 March 28	TechWeekStorage 25	Geneva, Switzerland
March 29	Open Source Operating System Annual Technical Conference	Beijing, China
April 1 April 2	FediForum Unconference	online

If your event does not appear here, please tell us about it.

Alert summary January 30, 2025 to February 5, 2025

Dist.	ID	Release	Package	Date
AlmaLinux	ALSA-2025:0845	8	git-lfs	2025-01-31
AlmaLinux	ALSA-2025:0838	8	libsoup	2025-01-31
AlmaLinux	ALSA-2025:0791	9	libsoup	2025-01-30
AlmaLinux	ALSA-2025:0692	9	redis:7	2025-01-29
AlmaLinux	ALSA-2025:0837	8	unbound	2025-01-31
Debian	DSA-5854-1	stable	bind9	2025-01-29
Debian	DSA-5855-1	stable	chromium	2025-01-30
Debian	DLA-4038-1	LTS	dcmtk	2025-01-31
Debian	DLA-4036-1	LTS	debian-security-support	2025-01-30
Debian	DLA-4039-1	LTS	ffmpeg	2025-02-01
Debian	DSA-5858-1	stable	firefox-esr	2025-02-05
Debian	DLA-4035-1	LTS	flightgear	2025-01-29
Debian	DLA-4037-1	LTS	openjdk-11	2025-01-31
Debian	DSA-5857-1	stable	openjdk-17	2025-02-03
Debian	DLA-4040-1	LTS	pam-u2f	2025-02-03
Debian	DSA-5853-1	stable	pam-u2f	2025-01-29
Debian	DLA-4041-1	LTS	python-aiohttp	2025-02-03
Debian	DSA-5856-1	stable	redis	2025-01-30
Debian	DLA-4034-1	LTS	simgear	2025-01-29
Fedora	FEDORA-2025-df3432c3ee	F40	buku	2025-02-03
Fedora	FEDORA-2025-e035838041	F41	buku	2025-02-03
Fedora	FEDORA-2025-82ba6b8dc5	F40	chromium	2025-02-02
Fedora	FEDORA-2025-2525ddc3f2	F41	chromium	2025-02-04
Fedora	FEDORA-2024-2462a2fc4c	F40	expat	2025-01-31
Fedora	FEDORA-2025-29fc4fefd5	F40	fastd	2025-02-05
Fedora	FEDORA-2025-b895b18cfe	F41	fastd	2025-02-04
Fedora	FEDORA-2025-9f92cbc27f	F41	java-21-openjdk	2025-01-31
Fedora	FEDORA-2025-6e4727185c	F41	jpegxl	2025-02-02
Fedora	FEDORA-2025-07901b1995	F40	lemonldap-ng	2025-01-31
Fedora	FEDORA-2025-3aa9a75a72	F41	lemonldap-ng	2025-01-31
Fedora	FEDORA-2025-cc8f9d8943	F40	nodejs18	2025-02-02
Fedora	FEDORA-2025-e330d34ecc	F41	nodejs18	2025-02-01
Fedora	FEDORA-2025-54958ff9e2	F40	nodejs20	2025-02-02
Fedora	FEDORA-2025-76fc32d433	F41	nodejs20	2025-02-01
Fedora	FEDORA-2025-721a8bada2	F40	ovn	2025-02-05
Fedora	FEDORA-2025-46e6440101	F41	ovn	2025-02-04
Fedora	FEDORA-2025-c17ef0f176	F40	phpMyAdmin	2025-01-31
Fedora	FEDORA-2025-4b8ab3834c	F41	phpMyAdmin	2025-01-31
Fedora	FEDORA-2025-bbabead4d7	F41	rust-routinator	2025-02-01
Fedora	FEDORA-2025-93d6242840	F40	yq	2025-02-05
Fedora	FEDORA-2025-cd51e0177b	F41	yq	2025-02-04
Mageia	MGASA-2025-0029	9	chromium-browser-stable	2025-01-30
Mageia	MGASA-2025-0031	9	clamav	2025-01-31
Mageia	MGASA-2025-0028	9	git-lfs	2025-01-30
Mageia	MGASA-2025-0030	9	kernel, kmod-virtualbox, kmod-xtables-addons & dwarves	2025-01-31
Mageia	MGASA-2025-0032	9	kernel-linus	2025-01-31
Mageia	MGASA-2025-0035	9	libreoffice	2025-02-04
Mageia	MGASA-2025-0034	9	libxml2	2025-02-04
Mageia	MGASA-2025-0033	9	redis	2025-02-03
Oracle	ELSA-2025-0733	OL8	bzip2	2025-01-31
Oracle	ELSA-2025-0845	OL8	git-lfs	2025-01-31
Oracle	ELSA-2024-11344	OL7	gstreamer1-plugins-base, gstreamer1-plugins-good	2025-02-03
Oracle	ELSA-2025-0838	OL8	libsoup	2025-01-31
Oracle	ELSA-2025-0791	OL9	libsoup	2025-01-31
Oracle	ELSA-2025-0737	OL8	mariadb:10.11	2025-01-31
Oracle	ELSA-2025-0739	OL8	mariadb:10.5	2025-01-31
Oracle	ELSA-2025-0711	OL8	python-jinja2	2025-01-31
Oracle	ELSA-2025-0693	OL9	redis	2025-01-31
Oracle	ELSA-2025-0837	OL8	unbound	2025-01-31
Red Hat	RHSA-2025:0923-01	EL9	buildah	2025-02-04
Red Hat	RHSA-2025:0733-01	EL8	bzip2	2025-02-04
Red Hat	RHSA-2025:0925-01	EL9	bzip2	2025-02-04
Red Hat	RHSA-2025:0345-01	EL9.0	fence-agents	2025-01-30
Red Hat	RHSA-2025:0335-01	EL9.2	fence-agents	2025-01-30
Red Hat	RHSA-2025:0338-01	EL9.4	fence-agents	2025-01-30
Red Hat	RHSA-2025:0914-01	EL9	galera, mariadb	2025-02-04
Red Hat	RHSA-2025:0845-01	EL8	git-lfs	2025-01-30
Red Hat	RHSA-2025:0825-01	EL8.4	git-lfs	2025-01-30
Red Hat	RHSA-2025:0765-01	EL8.6	git-lfs	2025-01-30
Red Hat	RHSA-2025:0762-01	EL8.8	git-lfs	2025-01-30
Red Hat	RHSA-2025:0673-01	EL9	git-lfs	2025-01-30
Red Hat	RHSA-2025:0758-01	EL9.0	git-lfs	2025-01-30
Red Hat	RHSA-2025:0757-01	EL9.2	git-lfs	2025-01-30
Red Hat	RHSA-2025:0759-01	EL9.4	git-lfs	2025-01-30
Red Hat	RHSA-2025:0662-01	EL9.4	grafana	2025-02-04
Red Hat	RHSA-2025:0743-01	EL8	keepalived	2025-02-04
Red Hat	RHSA-2025:0917-01	EL9	keepalived	2025-02-04
Red Hat	RHSA-2025:0838-01	EL8	libsoup	2025-01-30
Red Hat	RHSA-2025:0903-01	EL8.2	libsoup	2025-02-04
Red Hat	RHSA-2025:0889-01	EL8.4	libsoup	2025-02-04
Red Hat	RHSA-2025:0949-01	EL8.6	libsoup	2025-02-04
Red Hat	RHSA-2025:0882-01	EL9.0	libsoup	2025-02-04
Red Hat	RHSA-2025:0847-01	EL9.2	libsoup	2025-01-30
Red Hat	RHSA-2025:0848-01	EL9.4	libsoup	2025-01-30
Red Hat	RHSA-2025:0737-01	EL8	mariadb:10.11	2025-02-04
Red Hat	RHSA-2025:0912-01	EL9	mariadb:10.11	2025-02-04
Red Hat	RHSA-2025:0739-01	EL8	mariadb:10.5	2025-02-04
Red Hat	RHSA-2025:0936-01	EL9	mingw-glib2	2025-02-04
Red Hat	RHSA-2025:0922-01	EL9	podman	2025-02-04
Red Hat	RHSA-2025:0711-01	EL8	python-jinja2	2025-01-31
Red Hat	RHSA-2025:0950-01	EL8.6	python-jinja2	2025-02-04
Red Hat	RHSA-2025:0883-01	EL8.8	python-jinja2	2025-02-04
Red Hat	RHSA-2025:0667-01	EL9	python-jinja2	2025-01-31
Red Hat	RHSA-2025:0951-01	EL9.0	python-jinja2	2025-02-04
Red Hat	RHSA-2025:0850-01	EL9.4	python-jinja2	2025-01-31
Red Hat	RHSA-2024:5689-01	EL9.0	python3.9	2025-01-29
Red Hat	RHSA-2024:5535-01	EL9.2	python3.9	2025-01-29
Red Hat	RHSA-2025:0849-01	EL6	rsync	2025-01-30
Red Hat	RHSA-2025:0714-01	EL7	rsync	2025-01-30
Red Hat	RHSA-2025:0884-01	EL8.2	rsync	2025-02-03
Red Hat	RHSA-2025:0885-01	EL8.4	rsync	2025-02-03
Red Hat	RHSA-2025:0790-01	EL8.6	rsync	2025-01-30
Red Hat	RHSA-2025:0787-01	EL8.8	rsync	2025-01-30
Red Hat	RHSA-2025:0688-01	EL9.0	rsync	2025-01-30
Red Hat	RHSA-2025:0774-01	EL9.2	rsync	2025-01-30
Red Hat	RHSA-2025:0637-01	EL9.4	rsync	2025-01-30
Red Hat	RHSA-2025:0823-01	EL8.8	traceroute	2025-01-29
Red Hat	RHSA-2025:0837-01	EL8	unbound	2025-01-30
Slackware	SSA:2025-029-01		bind	2025-01-29
Slackware	SSA:2025-035-01		mozilla	2025-02-04
SUSE	openSUSE-SU-2025:0037-1	osB15	SDL2_sound	2025-01-30
SUSE	openSUSE-SU-2025:14703-1	TW	apache2-mod_security2	2025-01-29
SUSE	SUSE-SU-2025:0313-1	SLE15 oS15.6	apptainer	2025-01-31
SUSE	openSUSE-SU-2025:14714-1	TW	apptainer	2025-01-31
SUSE	SUSE-SU-2025:0337-1	SLE-m5.0 SLE-m5.1 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5	bind	2025-02-03
SUSE	openSUSE-SU-2025:14719-1	TW	bind	2025-02-01
SUSE	SUSE-SU-2025:0320-1	SLE15 SES7.1 oS15.3	buildah	2025-02-03
SUSE	SUSE-SU-2025:0319-1	SLE15 oS15.4	buildah	2025-02-03
SUSE	SUSE-SU-2025:0301-1	SLE15 oS15.5 oS15.6	buildah	2025-01-30
SUSE	openSUSE-SU-2025:14720-1	TW	chromedriver	2025-02-01
SUSE	openSUSE-SU-2025:0036-1	osB15	chromium	2025-01-30
SUSE	SUSE-SU-2025:0325-1	MP4.3 SLE15 SLE-m5.5 SES7.1	clamav	2025-02-03
SUSE	SUSE-SU-2025:0328-1	SLE12	clamav	2025-02-03
SUSE	SUSE-SU-2025:0327-1	SLE15 oS15.6	clamav	2025-02-03
SUSE	openSUSE-SU-2025:14706-1	TW	corepack22	2025-01-29
SUSE	openSUSE-SU-2025:14715-1	TW	dovecot24	2025-01-31
SUSE	SUSE-SU-2025:0285-1	SLE15 SES7.1 oS15.6	go1.24	2025-01-29
SUSE	SUSE-SU-2025:0302-1	MP4.2 MP4.3 SLE15 SLE-m5.5 oS15.6	google-osconfig-agent	2025-01-30
SUSE	openSUSE-SU-2025:14723-1	TW	google-osconfig-agent	2025-02-04
SUSE	SUSE-SU-2025:0297-1	SLE15 oS15.6	govulncheck-vulndb	2025-01-30
SUSE	openSUSE-SU-2025:14724-1	TW	grafana	2025-02-04
SUSE	openSUSE-SU-2025:14711-1	TW	hauler	2025-01-30
SUSE	openSUSE-SU-2025:14725-1	TW	helm	2025-02-04
SUSE	SUSE-SU-2025:0290-1	SLE12	hplip	2025-01-29
SUSE	SUSE-SU-2025:0346-1	SLE-m5.1	ignition	2025-02-04
SUSE	SUSE-SU-2025:0306-1	SLE-m5.2	ignition	2025-01-31
SUSE	SUSE-SU-2025:0342-1	SLE-m5.3	ignition	2025-02-03
SUSE	SUSE-SU-2025:0318-1	SLE-m5.4	ignition	2025-02-03
SUSE	SUSE-SU-2025:0295-1	SLE-m5.5	ignition	2025-01-30
SUSE	SUSE-SU-2025:0299-1	SLE15 oS15.4 oS15.6	ignition	2025-01-30
SUSE	SUSE-SU-2025:0291-1	SLE15 SES7.1 oS15.6	iperf	2025-01-29
SUSE	SUSE-SU-2025:0338-1	MP4.3 SLE15 SES7.1 oS15.6	java-11-openjdk	2025-02-03
SUSE	SUSE-SU-2025:0339-1	MP4.3 SLE15 oS15.4 oS15.6	java-17-openjdk	2025-02-03
SUSE	SUSE-SU-2025:0289-1	SLE15	kernel	2025-01-29
SUSE	openSUSE-SU-2025:14705-1	TW	kernel-devel-longterm	2025-01-29
SUSE	SUSE-SU-2025:0343-1	SLE-m5.3 SLE-m5.4 oS15.4	krb5	2025-02-03
SUSE	SUSE-SU-2025:0304-1	SLE-m5.5 oS15.5	krb5	2025-01-30
SUSE	openSUSE-SU-2025:14721-1	TW	kubelogin	2025-02-01
SUSE	openSUSE-SU-2025:14716-1	TW	libQt5Bluetooth5-32bit	2025-01-31
SUSE	openSUSE-SU-2025:0041-1	osB15	libjxl	2025-02-01
SUSE	SUSE-SU-2025:0341-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 oS15.4	libxml2	2025-02-03
SUSE	SUSE-SU-2025:0300-1	SLE12	libxml2	2025-01-30
SUSE	SUSE-SU-2025:0303-1	SLE15 SLE-m5.1 SLE-m5.2 SES7.1 oS15.6	libxml2	2025-01-30
SUSE	SUSE-SU-2025:0348-1	SLE15 SLE-m5.5 oS15.5 oS15.6	libxml2	2025-02-04
SUSE	SUSE-SU-2025:0283-1	SLE15 oS15.6	nginx	2025-01-29
SUSE	SUSE-SU-2025:0284-1	SLE15 oS15.6	nodejs22	2025-01-29
SUSE	SUSE-SU-2025:0345-1	SLE15 SLE-m5.5 oS15.5	openssl-1_1	2025-02-04
SUSE	openSUSE-SU-2025:14707-1	TW	openvpn	2025-01-29
SUSE	SUSE-SU-2025:0344-1	MP4.3 SLE15 SLE-m5.2 SLE-m5.3 SLE-m5.4 SLE-m5.5 SES7.1 oS15.6	orc	2025-02-03
SUSE	SUSE-SU-2025:0314-1	SLE12	orc	2025-01-31
SUSE	openSUSE-SU-2025:14708-1	TW	owasp-modsecurity-crs	2025-01-29
SUSE	openSUSE-SU-2025:14717-1	TW	owasp-modsecurity-crs	2025-01-31
SUSE	openSUSE-SU-2025:0052-1	osB15	python-asteval	2025-02-04
SUSE	SUSE-SU-2025:0310-1	MP4.3 SLE15 oS15.4 oS15.6	python-pydantic	2025-01-31
SUSE	openSUSE-SU-2025:14718-1	TW	python311-ipython	2025-01-31
SUSE	openSUSE-SU-2025:14712-1	TW	python311-pydantic	2025-01-30
SUSE	openSUSE-SU-2025:14722-1	TW	rime-schema-all	2025-02-04
SUSE	SUSE-SU-2025:0340-1	MP4.3 SLE15 SLE-m5.3 SLE-m5.4 SLE-m5.5 oS15.4	rsync	2025-02-03
SUSE	SUSE-SU-2025:0292-1	SLE15 SES7.1	shadow	2025-01-30
SUSE	openSUSE-SU-2025:0039-1	osB15	stb	2025-01-31
SUSE	openSUSE-SU-2025:14713-1	TW	trivy	2025-01-30
SUSE	SUSE-SU-2025:0335-1	SLE12	xrdp	2025-02-03
SUSE	SUSE-SU-2025:0336-1	SLE15 oS15.6	xrdp	2025-02-03
Ubuntu	USN-7241-1	20.04 22.04 24.04 24.10	bind9	2025-01-29
Ubuntu	USN-7251-1	20.04 22.04	harfbuzz	2025-02-03
Ubuntu	USN-7244-1	18.04 20.04 22.04 24.04 24.10	jinja2	2025-01-30
Ubuntu	USN-7246-1	20.04	jquery	2025-01-30
Ubuntu	USN-7248-1	16.04 18.04	libndp	2025-02-04
Ubuntu	USN-7249-1	14.04 16.04 18.04	libvpx	2025-02-04
Ubuntu	USN-7240-1	20.04 22.04 24.04	libxml2	2025-01-29
Ubuntu	USN-7233-2	14.04 18.04	linux-azure, linux-azure-4.15	2025-01-30
Ubuntu	USN-7234-3	18.04 20.04	linux-azure, linux-azure-5.4	2025-02-04
Ubuntu	USN-7233-3	16.04	linux-azure	2025-02-03
Ubuntu	USN-7235-2	20.04	linux-azure-5.15	2025-01-30
Ubuntu	USN-7234-2	18.04	linux-hwe-5.4	2025-01-30
Ubuntu	USN-7238-3	24.10	linux-lowlatency	2025-02-04
Ubuntu	USN-7236-2	22.04	linux-lowlatency-hwe-6.8	2025-01-29
Ubuntu	USN-7238-2	24.10	linux-oracle	2025-01-30
Ubuntu	USN-7245-1	20.04 22.04 24.04 24.10	mysql-8.0	2025-01-30
Ubuntu	USN-7250-1	18.04 20.04 22.04 24.10	netdata	2025-02-03
Ubuntu	USN-7247-1	18.04 22.04	opencv	2025-02-04
Ubuntu	USN-7253-1	18.04 20.04 22.04 24.04 24.10	openjdk-17	2025-02-05
Ubuntu	USN-7254-1	20.04 22.04 24.04 24.10	openjdk-21	2025-02-05
Ubuntu	USN-7255-1	24.10	openjdk-23	2025-02-05
Ubuntu	USN-7096-2	16.04 18.04 20.04 22.04 24.04 24.10	openjdk-8	2025-02-05
Ubuntu	USN-7252-1	18.04 20.04 22.04 24.04 24.10	openjdk-lts	2025-02-05
Ubuntu	USN-7157-3	16.04	php7.0	2025-01-29
Ubuntu	USN-7242-1	14.04	tomcat6	2025-01-30
Ubuntu	USN-7243-1	16.04 18.04 20.04 22.04 24.04	vlc	2025-01-30

Full Story (comments: none)