Welcome to the LWN.net Weekly Edition for October 20, 2022

This edition contains the following feature content:

• The disabling of hardware codecs in community distributions: just because the hardware can decode a media format doesn't mean that the software can use that capability.
• Identity management for WireGuard: a survey of options for the management of WireGuard keys.
• A first look at Rust in the 6.1 kernel: the next kernel will include Rust support — but it can't do much yet.
• The rest of the 6.1 merge window: significant changes pulled in the latter part of the kernel merge window.
• The search for the correct amount of split-lock misery: when (and by how much) is it appropriate to penalize users of working software to protect the system as a whole?

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)

The disabling of hardware codecs in community distributions

Software patents affect our systems in many ways, but perhaps most strongly in the area of codecs — code that creates or plays back audio or video that has been compressed using covered algorithms. For this reason, certain formats have simply been unplayable on many Linux distributions — especially those backed by companies that are big enough to be worth suing — without installing add-on software from third-party repositories. One might think that this problem could be worked around by purchasing hardware that implements the patented algorithms, but recent activity in the Fedora and openSUSE communities shows that life is not so simple.

In September, the Fedora project changed how it builds the Mesa graphics library, disabling support for the H.264 and H.265 codecs. These formats are heavily encrusted with software patents and have long been difficult to support on Linux systems, though the existence of OpenH264 has improved the situation for many users. In this case, though, the patented algorithms are not being executed on the CPU running Linux; instead, they are run (and accelerated) on a peripheral processor like the GPU. With the change, Fedora users (only of the upcoming Fedora 37 release for now, though that will likely change) have lost access to the acceleration provided by their hardware.

The problem was promptly brought to the Fedora development list, where a number of users expressed their unhappiness at the change. But there was also a certain amount of surprise that Red Hat would not allow code that enables hardware functionality to be shipped; Chris Adams, for example, asked: "But isn't this just providing for hardware decoding, where (presumably) the hardware vendor arranged for whatever needed licenses?". The "presumably", in this case, turns out to be wrong.

The vendors shipping this functionality, it seems, do not feel any need to arrange for the licensing to allow their customers to actually use their products in that way. Instead, the acceleration features in the hardware are viewed as a partial solution that only implements the patented algorithms when combined with software support on the CPU. And, as David Airlie pointed out: it is the provision of a solution that actually works that is seen as using the patented technology:

Think of it like a jigsaw puzzle, where the person who places the last piece in the puzzle pays the license. But then stop thinking of it like that and just assume it's a lot vaguer and way more legally involved than that.

Or, as Tom "spot" Callaway put it:

Mesa was (is) implementing the software parts of H264 and H265 encoding/decoding as part of the Video Acceleration API (VAAPI). This interface tells your GPU (usually, sometimes it is other hardware) to do the hard work of encoding/decoding, but it isn't a black box.

It is a combination of available hardware and software which does the work, and thus, the implementation as delivered potentially infringes.

So, once again, Linux users can't have good things as the result of software patents. Once Red Hat realized that Fedora was shipping code that might possibly be infringing on the codec patents, that code had to be pulled to avoid accusations of willful infringement. After the situation came to light, openSUSE quickly followed suit with a similar change. Some other distributors may not make the same change, choosing instead to continue to ship the affected codecs; Callaway had an explanation for that as well:

They might be too small to sue (remember, expensive to take to court) and/or too small to get any meaningful damages as a result. I mean, Debian is just rolling in money, right? Or the parent company is based in a legal grey zone. *cough*

Companies with sufficiently deep pockets that are not based in legally sheltered areas do not generally feel that they can take the risk, though.

All is not lost yet; Linux users have other codecs available to them. Users who are willing to take the extra step of installing OpenH264 will still have the ability to play back media in that format without infringement worries. Airlie also suggested that having OpenH264 installed might be sufficient to allow the re-enabling of other H.264 codecs on the same system — but it is not clear that any lawyers have signed off on that idea. Some of the disabled functionality may yet show up in third-parties like RPM Fusion as well. Meanwhile, though, this episode is just another reminder of the threats posed by software patents. We are free to write any software we like — but we may not be free to run it.

Comments (94 posted)

Identity management for WireGuard

Since its inclusion in the Linux kernel, the WireGuard VPN tunnel has become increasingly popular. In general, WireGuard is simpler to configure than other VPNs, but the approach that it takes to authentication can present some challenges. Each node in a WireGuard network has a cryptographic key that serves as the node's identity; nodes that do not know each other's keys cannot directly communicate. Keeping track of these keys and distributing them to the other nodes in a mesh network quickly becomes a chore as the network grows. Fortunately, there are now several open-source tools that can automate the management of these keys and make using WireGuard easier for both administrators and end users.

Key management can be particularly challenging for non-technical end users, who are used to logging into services with a username and password. Thus, the main feature that all of these tools have in common is that they allow a user to log into a WireGuard network using a username and password (and possibly a second factor, such as a one-time password). This is usually accomplished by integrating with an identity provider that implements the OpenID Connect (OIDC) standard. OIDC is built on top of the OAuth 2.0 protocol and can be used to implement the ubiquitous "Sign in with Some Big Company" functionality seen on many web sites.

Some of the software discussed in this article requires an OIDC provider; there are several open-source options for people who aren't already running their own and don't want to farm the task out to some big company. Keycloak is one of the most mature and popular choices and Authelia is an up-and-coming alternative.

Tailscale

Tailscale is a commercial service that provides managed WireGuard networks. When a network administrator creates a new network on Tailscale, they must choose an identity provider; they can choose to have their users sign in with Google, GitHub, Microsoft, or any other provider that supports OIDC. The approach of connecting key management for WireGuard to an identity provider was pioneered by Tailscale, and likely served as inspiration for the other projects covered in this article.

To connect to a Tailscale network, a user must install Tailscale's client software. The client talks to Tailscale's API and manages WireGuard interfaces on a user's device. When a user connects to a Tailscale network, the client generates a WireGuard key pair, and then submits the public key to Tailscale's API. The user is then directed to Tailscale's web site, which sends them to a login page for the identity provider chosen for the network. After a user is logged in (and after their device is approved, depending on how the administrator has configured the network), their public key is made available to be retrieved by the Tailscale clients running on the other nodes. The other clients add the new key to their WireGuard configurations, allowing them to communicate with the new node.

The Tailscale client is available for Linux, macOS, and Windows, as well as iOS and Android. The source of the command-line version of the Tailscale client (which is written in Go) is released under the 3-clause BSD license, as is the Android client. Unfortunately, the server software is proprietary. That's where Headscale comes in.

Headscale

Headscale is an independent implementation of Tailscale's server-side API; like the Tailscale client, it is written in Go. Tailscale's command-line interface (CLI) client has a --login-server flag that allows users to override the URL to the Tailscale API, which can be used to connect the client to Headscale. Despite Headscale's unofficial status, Tailscale seems to be fully supportive of its efforts; Tailscale has coordinated with Headscale's creator on API changes and hired one of Headscale's maintainers. On Android, changing the API URL was originally accomplished by recompiling the client, but a pull request that adds a hidden menu to Tailscale's official builds of the client was recently merged. Tailscale's Windows and macOS clients can also be used with Headscale, but support for changing the API URL in the iOS client is currently incomplete.

The list of Tailscale features that Headscale doesn't support is surprisingly short. Headscale does not yet support Tailscale's SSH key-management feature. Other than that, users of Headscale can enjoy most of Tailscale's features, including network-level access-control lists (ACLs), DNS for the VPN, and use Tailscale's NAT-traversal mechanism.

Headscale doesn't include a web-based administrative interface (although a third-party interface is available); it is configured using a YAML file. Headscale can be used with an OIDC provider, but it also supports using an internal database of usernames and passwords; this could be convenient for small setups or home labs that don't already have an identity provider set up. Unlike Tailscale's backend, the Headscale server doesn't support multi-tenancy; each instance of Headscale can only play host to a single network.

Though it has close ties to the Tailscale proprietary service, Headscale does enable creating a completely self-hosted WireGuard VPN using only open-source software. The project's friendly relationship with Tailscale bodes well for Headscale's continued usefulness. Unless Tailscale's management has a sudden change of heart, it is unlikely that Tailscale will make changes to its clients that make them incompatible with Headscale, at least without coordinating with the project.

NetBird

NetBird is another commercial service that provides managed WireGuard networks. The architecture of NetBird is similar to that of Tailscale. A client application (the NetBird agent) generates keys for a node and submits the public key to a management service. The user is directed to an identity provider to log in; after the user is logged in and their device is authenticated, their public key is distributed to the other clients in the network, which add the key to their WireGuard configurations. NetBird doesn't seem to have a built-in user database, and requires the use of an OIDC provider; people that don't already have one running will have to install and configure one before trying it.

Unlike Tailscale, NetBird is fully open-source; the sources to both the client and the server-side components are BSD-licensed and available on GitHub, although one needs to agree to a Contributor License Agreement (CLA) before contributing. Agreeing to the CLA grants NetBird the right to relicense contributions in any way that it might choose; it also contains some additional language about patent rights. There are also instructions for hosting your own NetBird server.

The NetBird server consists of the management API service and a signaling server to help clients find each other. A dashboard is also included; unlike Headscale, the same web interface is available to both users of the NetBird service and those who are self-hosting NetBird. Beyond that, NetBird also needs a 3rd-party STUN/TURN server to assist with NAT traversal. Instead of inventing a new protocol like Tailscale did, NetBird's NAT-traversal functionality is based on the WebRTC standard.

NetBird offers many features similar to those offered by Tailscale. Like Tailscale, NetBird supports network-level ACLs, and it also has an SSH key-management feature. NetBird doesn't currently have all of the DNS functionality that Tailscale does, and its client is currently only available for desktop platforms. Mobile clients and private DNS for the VPN are both listed as "coming soon" in the project's README, though.

It's not quite at parity with all of Tailscale's features, but NetBird largely replicates the core functionality of Tailscale's product, without any proprietary software. It has yet to achieve the same level of popularity as Tailscale or to build the kind of community that Headscale has, though; its core contributors are all NetBird employees. Compared to Tailscale, more of NetBird's software is open source, but the fate of that software is likely to be tied to that of NetBird's business endeavors.

Firezone

Firezone is a another company that aims to provide managed WireGuard networks, although its hosted offering doesn't appear to have actually launched yet; the pricing page is scant on details and the documentation features a "Join the Beta" link at the top of the page.

Firezone is written in Elixir. Its source code is available now under an Apache 2.0 license; contributions do not appear to require a CLA. Instructions for self-hosting Firezone are provided in the documentation. Like Headscale, Firezone can authenticate users using an OIDC provider or a built-in user database.

Firezone does not (yet?) provide any sort of client software. Instead, users generate WireGuard keys for themselves, and then upload them to Firezone's web interface. Users can then download a configuration for the standard WireGuard client from the web interface. Firezone allows filtering traffic between nodes but doesn't include any additional features like DNS or SSH key-management. No NAT-traversal methods are mentioned in the documentation; without assistance from NAT traversal, WireGuard nodes that are behind NAT may have trouble connecting to the VPN depending on the network configuration.

It's hard to tell if Firezone is intentionally minimal, or if it's still just early in its development; there is no public roadmap that I could find. The project's commit history starts a little over a year ago, and the vast majority of the commits are attributed to the company's founder. In its current state, it could be appealing to someone who is already comfortable managing their own WireGuard networks and is just looking for integration with an OIDC provider.

Netmaker

Netmaker is yet another provider of managed WireGuard networks. Like Tailscale, Headscale, and NetBird, Netmaker's software is written in Go. The source is available under the Server Side Public License (SSPL). Instructions for self-hosting Netmaker are available, but the license implies that the creators of Netmaker would prefer that you not attempt to make a business of it.

The SSPL is similar to the GNU Affero GPL license in that it requires source code to be made available to any user who interacts with a service over the network, but contains additional language that requires the source of any components that are used to manage the service to be released under the SSPL as well. The SSPL is designed to protect the business interests of companies that release software under it. The additional restrictions that it imposes make it legally unpalatable for other companies to offer the software as a service; according to the Open Source Initiative, it is not an open-source license. Like NetBird, Netmaker also requires contributors to agree to a CLA, which grants patent rights and allows Netmaker to relicense the contribution.

Based on the release notes for the earliest versions of Netmaker, it doesn't look like the authors set out with the intention of building a competitor to Tailscale. Instead, it was originally built for use with Kubernetes, and this use case is still supported. Netmaker uses WireGuard to enable building Kubernetes clusters that span multiple data centers and to securely connect clusters to external services and clients.

More recent versions of Netmaker have become more like Tailscale. Originally, Netmaker's client software authenticated to the API using a pre-shared key; this makes sense for automatically-deployed virtual machines and cloud instances but isn't suitable for end users. Netmaker still supports this method of authentication, but more recent versions also support logging in with a username and password, using either a built-in user database or via an OIDC provider. Netmaker also supports access-control lists; earlier versions included a DNS server, but more recent versions have switched to adding VPN hostnames to /etc/hosts instead. Like Firezone, no NAT-traversal methods are mentioned in the documentation.

Netmaker appears to have attracted more community contributions than NetBird or Firezone, but its development is still primarily employee-driven. Its origin in the world of Kubernetes is still readily apparent; prospective users can choose from multiple deployment options and the advanced server installation guide presents a vast array of ways in which an installation of Netmaker can be customized. Netmaker's client software runs on Linux, macOS, and Windows, as well as FreeBSD, but it only offers a command-line interface at the moment. Networking experts and people who are already running their own Kubernetes clusters will likely be happy and comfortable with Netmaker, but people looking for a VPN that is easy for non-technical users might want to look elsewhere.

Conclusion

For someone who wants to build a self-hosted WireGuard VPN for possibly non-technical end users, Headscale (in combination with Tailscale's client software) is the most complete solution, and the only solution if being able to connect mobile phones to the network is a requirement. If relying on Tailscale's clients is a non-starter, NetBird provides a similar experience to users, but NetBird doesn't have mobile clients yet. Firezone looks to be off to a promising start, but it still has a lot of catching up to do relative to Headscale and NetBird; its complete lack of client software still puts a lot of the work of managing WireGuard configurations on the user. Meanwhile, Netmaker's end-user experience is unpolished, but its other use cases might make it interesting to people managing Kubernetes clusters or other large deployments of virtual machines.

Despite its close association with Tailscale and dependence on its clients, Headscale is the only truly community-driven project of the bunch. All of the other solutions are open source (or, depending on how you feel about the SSPL, source available), but they are all built by venture-backed companies. Given the relative lack of community contributions, these projects may not have much of a future if the companies associated with them are unable to find their way to commercial success.

Comments (54 posted)

A first look at Rust in the 6.1 kernel

There have been a lot of significant changes merged into the mainline for the 6.1 release, but one of the changes that has received the most attention will also have the least short-term effect for users of the kernel: the introduction of support for the Rust programming language. No system with a production 6.1 kernel will be running any Rust code, but this change does give kernel developers a chance to play with the language in the kernel context and get a sense for how Rust development feels. Perhaps the most likely conclusion for most developers, though, will be that there isn't yet enough Rust in the kernel to do much of anything interesting.

Work on Rust for the Linux kernel has been going on for a few years, and it has resulted in the creation of a lot of support code and some interesting drivers to look at. There are other initiatives underway, including the writing of an Apple graphics driver in the Rust language. For the initial merge into the mainline kernel, though, Linus Torvalds made it clear that as little functionality as possible should be included. So those drivers and their support code were trimmed out and must wait for a future kernel release. What is there is the support needed to build a module that can be loaded into the kernel, along with a small sample module.

Building Rust support

The first challenge that interested developers will run into is actually building that support. The kernel configuration process looks for the prerequisites on the build system and, if they are not present, silently disables the Rust options so that they will not even show in, for example, make menuconfig. Your editor, despite having Rust installed on the system in question, ran into this and was thus forced into the ignominious process of actually reading the documentation to figure out what was missing.

Building the Rust support requires specific versions of the Rust compiler and bindgen utility — specifically, Rust 1.62.0 and bindgen 0.56.0. If the target system has newer versions, the configuration process will emit warnings but will proceed anyway. More awkwardly for anybody who is trying to do the build with the Rust toolchain provided by their distributor, the build process also needs the Rust standard library source so that it can build its own version of the core and alloc crates. Until distributors start shipping "Rust for the kernel" packages, getting that code into a place where the build process will find it will be a bit awkward.

The way to easily obtain that dependency is to throw in the towel, drop the distributor's toolchain, and install everything from the Rust repositories instead. The "getting started" page describes how to do this; inevitably, it involves one of those confidence-building "curl|bash" operations. The installer is entirely uninterested in where one might like one's Rust stuff installed (it goes into ~/.cargo) and silently modifies the user's Bash startup scripts to add the new directory into the PATH variable. The end result does work, though, and makes it easy to install the needed dependencies.

The sample module

Once that is done, the kernel configuration system will consent to set the CONFIG_RUST option; an additional option will build the sample module. That module (samples/rust/rust_minimal.rs) is minimal indeed, but it is enough to get a sense for what kernel code in Rust will look like. It starts with the Rust equivalent of a #include line:

    use kernel::prelude::*;

The pulls in the declarations found in rust/kernel/prelude.rs, making a few types, functions, and macros available.

A kernel module written in C includes a number of calls to macros like MODULE_DESCRIPTION() and MODULE_LICENSE() that stash metadata about the module in a separate ELF section. The module_init() and module_exit() macros identify the module's constructor and destructor functions, respectively. The Rust equivalent puts much of that boilerplate into a single macro call:

    module! {
        type: RustMinimal,
        name: b"rust_minimal",
        author: b"Rust for Linux Contributors",
        description: b"Rust minimal sample",
        license: b"GPL",
    }

This macro is fussy about the ordering of the various fields and will complain if the developer gets that wrong. Beyond putting all of this information into a single call, the module! macro includes a type: entry which will be the pointer to the actual module code. The developer will be expected to supply a type that does something interesting. In the sample module, that type looks like this:

    struct RustMinimal {
        numbers: Vec<i32>,
    }

It is a simple structure containing a Vec (an array, more or less) of 32-bit integer values. That's pretty boring on its own, but Rust then allows the addition of interface ("trait") implementations to a structure type. So the sample module implements the kernel::Module trait for the RustMinimal type:

    impl kernel::Module for RustMinimal {
        fn init(_module: &'static ThisModule) -> Result<Self> {
            pr_info!("Rust minimal sample (init)\n");
            pr_info!("Am I built-in? {}\n", !cfg!(MODULE));
    
            let mut numbers = Vec::new();
            numbers.try_push(72)?;
            numbers.try_push(108)?;
            numbers.try_push(200)?;

            Ok(RustMinimal { numbers })
        }
    }

The init() function is expected to do the usual module initialization work. In this case, it babbles a bit to the system log (showing off in the process the cfg!() macro that can be used to query kernel-configuration parameters at compile time). It then allocates a mutable Vec and attempts to put three numbers into it. The use of try_push() is important here: a Vec will resize itself when necessary. That involves allocating memory, which can fail in the kernel environment. Should that allocation fail, try_push() will return a failure status and that, in turn, will cause init() to return failure (that is what the "?" at the end of the line does).

Finally, if all goes well, it returns a RustMinimal structure with the allocated Vec and a success status. Since this module has not interacted with any other kernel subsystems, it won't actually do anything other than wait patiently to be removed. There isn't a function for module removal in the Kernel::Module trait; instead, a simple destructor for the RustMinimal type is used:

    impl Drop for RustMinimal {
        fn drop(&mut self) {
            pr_info!("My numbers are {:?}\n", self.numbers);
            pr_info!("Rust minimal sample (exit)\n");
        }
    }

This function prints out the numbers that were stored in the Vec at initialization time (thus confirming that the data survived in meantime) and returns; after that, the module will be removed and its memory freed. There does not appear to be a way for module removal to fail — which occasionally needs to happen in real-world modules.

Beyond "hello world"

That is, to a first approximation, the extent of what can be done with Rust kernel modules in 6.1. Torvalds asked for something that could do "hello world" and that is what we got. It is something that can be played with, but it cannot be used for any sort of real kernel programming at this point.

That situation will, hopefully, change in the near future. The next step for the Rust-for-Linux developers will be to start adding some of the infrastructure they have created to interface with other kernel subsystems. That will allow for the writing of some real kernel code and, just as importantly, show what the abstractions needed to work with other kernel subsystems will look like. This needs to happen soon; Rust in the kernel has some momentum now, but that could be lost if it remains limited to printing kernel log messages for any period of time. With luck, Rust in the 6.2 kernel will be significantly more capable.

Comments (30 posted)

The rest of the 6.1 merge window

Linus Torvalds released 6.1-rc1 and closed the 6.1 merge window on October 16; at that point, 11,537 non-merge changesets had been pulled into the mainline repository. That is considerably less than the 13,543 changesets pulled during the 6.0 merge window, but quantity is not everything: there were quite a few significant changes brought in this time around. Many of those were part of the nearly 5,800 changesets pulled since our first 6.1 merge window summary; read on for a look at some of the work done in the latter part of this merge window.

Architecture-specific

• The Loongarch architecture has gained support for perf events, kexec, kdump, and BPF just-in-time compilation.
• On EFI systems, the kernel is now able to decompress and launch itself in an architecture-independent way.

Core kernel

• There is a new io_uring mode (obtained by setting up a ring with the IORING_SETUP_DEFER_TASKRUN flag) that causes the execution of ring-related work to be deferred until the application asks for it to be done. This deferral helps to batch up work and prevent latency problems caused by the preemption of the application at inopportune times. There is a little bit of information in this commit.
• The process-ID control-group controller can now remember the highest number of PIDs used, which can be consulted when deciding what the limit should be; this value is exported in a virtual file called peak.
• It is now possible for user-space processes to request that a range of pages be "collapsed" into transparent huge pages. This makes huge pages somewhat less transparent, of course, but it also allows user space control over if and when this work is done.
• The /dev/userfaultfd patches, which provide a way for system administrators to grant access to userfaultfd() functionality with filesystem access permissions, have been merged.
• Memory-tiering is the management of banks of memory with different performance characteristics; normally one wants the most heavily used pages to be resident in the fastest memory, while less-frequently used (but still useful) pages can be in slower RAM. Two memory-tiering patch sets, both described in this article, have been merged for 6.1. "Hot page selection" improves the detection of busy pages languishing in slower RAM so that they can be promoted. Meanwhile, the "demotion-order" patches formalize the kernel's notion of what memory tiers mean and their relative performance, allowing better management of those tiers.
• The multi-generational LRU code has been merged. This work replaces the kernel's two-queue, least-recently-used mechanism with a multi-stage structure that, it is said, is better at identifying which memory pages are actually in use. Included is a "kill switch" that can be used to disable the new mechanism should it create problems on a given system. The administrative guide has some more information on how to control this feature, while the design documentation gets into how it all works.

  For those wondering how the multi-generational LRU and tiering interact: the LRU deals mostly with the management of memory within each zone (each area of physically contiguous memory of the same type on the same node), while tiering is concerned with the movement of pages between zones.

• The maple tree data structure has also been merged. It is meant to be a more efficient replacement for red-black trees and, it is hoped, will also facilitate the implementation of range locking in the future. A number of core memory-management subsystems have been converted over to maple trees; with luck the only user-visible change will be improved performance.
• Pressure-stall information can now be tracked at the control-group level. Enabling this tracking may add a significant performance cost; this commit has some more information.

Filesystems and block I/O

• Changes merged for Btrfs provide some significant performance improvement, including an "orders of magnitude speed boost for the FIEMAP ioctl().
• Btrfs now supports buffered writes with io_uring.
• The Btrfs "send" operation has gained support for files protected with fs-verity.
• The filesystems in user space (FUSE) subsystem has gained support for the creation of temporary files with O_TMPFILE.

Hardware support

• Clock: MediaTek MT6795 and MT8365 clock controllers, Qualcomm MSM8909 and SM6375 global clock controllers, Qualcomm SM6115 and SM8450 display clock controllers, Qualcomm SC8280XP graphics clock controllers, Rockchip RV1126 clock controllers, Spreadtrum UMS512 clocks, and Renesas Versaclock 7 clock controllers.
• GPIO and pin control: Cypress Cy8C95x0 pinctrl/gpio I2C expanders, Qualcomm SC8280XP and SM8450 LPASS LPI pin controllers, and MediaTek MT8188 pin controllers.
• Industrial I/O: Liteon LTRF216A light sensors, Richtek RTQ6056 current and power monitors, MEMSensing digital 3-axis accelerometers, Maxim max11205 analog-to-digital converters, and Bosch Sensortec BNO05 IMUs.
• Input: IBM operation panels, Richtek RT5120 PMIC power keys, and Pine64 PinePhone keyboards.
• Media: NXP i.MX DW100 dewarpers and MediaTek media data path interfaces.
• Miscellaneous: Synopsys DWC AHCI SATA controllers, Microchip LAN9662 OTP controllers, Microchip PolarFire SoC reset controllers, Aspeed HACE cryptographic engines, and Exar watchdog timers.
• Multi-function device: MediaTek MT6370 power-management ICs Richtek RT5120 power management ICs, and Rockchip RK817 PMIC battery chargers.
• USB: Sunplus SP7021 USB 2.0 PHYs and MediaTek MT6370 Type-C controllers.

Miscellaneous

• As usual, there is a long list of improvements to the perf tool, including improved support for AMD processors; this merge message contains a summary.

Security-related

• Support for O_NONBLOCK was (accidentally) removed from /dev/random back in 5.6. Somebody eventually noticed and complained, so that support will return in 6.1 (and, presumably, the stable updates).

Internal kernel changes

• There is continued refactoring within the various slab allocators to increase the amount of code that can be shared among them. One behavioral change that might be noticed is that SLAB will now obtain large allocations directly from the page allocator, without keeping a separate cache around.

  The long-term goal of this work is to eventually be able to remove the SLAB and SLOB allocators, but that is still a distant prospect.

• There is now an interface to show how much memory is wasted due to the rounding-up of allocation sizes by kmalloc(); this commit describes how to use it.
• The kernel build system now requires a minimal GNU Make version of 3.82.
• The x86 architecture code will now emit warnings if a kernel subsystem sets up memory that is both writable and executable. The initial plan to prohibit such mappings entirely has been deferred due to a couple of late-arriving surprises, though.
• The conversion of memory-management functionality to folios continues, with most of the effort this time focused on the swap code.
• The kernel memory sanitizer (KMSAN), briefly described in this article, has been merged. KMSAN is focused on detecting uses of uninitialized memory in the kernel; this documentation patch describes its use.
• The checkpatch.pl script will now complain about uses of the deprecated kmap() and kmap_atomic() functions; code should be using kmap_local_page() instead.
• There has been a fair amount of churn related to how kernel code obtains random numbers; this merge message contains the rules that describe how the internal API for random number is meant to be used.

Now the time has come to stabilize all of that work and turn it into the 6.1 release, which is slated to become this year's long-term-support kernel. That release can be expected on December 4 or 11; given the significance of some of the changes that have been merged, it would not be surprising if this cycle were one of those that require an extra week to become ready.

Comments (2 posted)

The search for the correct amount of split-lock misery

Unlike many other architectures, x86 systems support atomic operations that affect more than one cache line. This support comes at a cost, though, in terms of overall system performance and, even, security. Over the last few years, kernel developers have worked to discourage the use of this sort of "split-lock" operation. Now, though, one group of users is feeling a little too discouraged, leading to a discussion of how much misery can appropriately be inflicted upon users who use problematic but architecturally legal operations.

The problem with atomic operations that cross cache-line boundaries is that the system bus must take special measures to ensure that both cache lines are simultaneously protected from concurrent access. In practice, that means locking the bus for the duration of the operation, which can stall every other processor in the system. A malicious program executing a tight loop with a split-lock operation can destroy the performance of the system as a whole. For this reason, split-lock operations have long been frowned upon.

Unfortunately, software that is malicious (or just poorly written) turns out to be remarkably indifferent to even the most severe of frowns. So, starting in 2019, kernel developers sought more persuasive ways to get their point across. The initial work was done by Fenghua Yu but, in the end, this patch by Peter Zijlstra was merged in January 2020 for the 5.7 kernel release. It gives the kernel the ability to respond to traps caused by split-lock operations and provides three modes for that response, selectable by the split_lock_detect= command-line parameter:

• off causes the kernel to behave as it did before; split-lock operations are not detected and nothing is done when they occur.
• warn (the default) causes a (rate-limited) warning to go to the system log when a split-lock operation is detected.
• fatal causes the kernel to immediately kill (with SIGBUS) any process attempting split-lock operations.

The hope was that the warn mode would be sufficient to alert users to the problem, and lead to software being fixed, while not actually interfering with anybody's use of their systems. By the time the 5.19 development cycle came around earlier this year, though, it seemed that little progress toward the removal of split lock operations had been made, and the denial-of-service problem was as present as before. So it was decided to take a stronger stance against split locks.

One option, of course, would be to just switch to the fatal mode by default, but that would be a rather draconian solution. Instead, Tony Luck wrote a patch with the descriptive title of "make life miserable for split lockers". It modified the warn mode to punish processes doing split locks without actually killing them. Instead, detection of a split lock would lead to a 10ms delay, then serialization via a semaphore. When this mode is selected, a malicious program performing split locks succeeds in slowing itself down, but no longer has much effect on the system as a whole. This change was applied during the 5.19 merge window.

In mid-September, a GitHub user named "pibberflibbits" posted a bug report saying that the performance of the God of War game on Linux had become "insanely low". It took a little while, but the participants in the resulting discussion eventually figured out that the problem was the split-lock penalty. Evidently one cannot be a proper god of war using just ordinary locks, so the game does a lot of split locking. Luck's patch had achieved its intended purpose; God of War players are now suitably miserable.

Guilherme G. Piccoli, though, was not celebrating this victory over the Gods; instead, he posted a patch arguing that "it seems unacceptable to regress old/proprietary userspace programs through a default configuration that previously worked". This patch restored the old behavior of the warn mode and added a new seq mode that would slow down split-lock users like warn mode does now. The warn mode would remain the default, lifting the misery from the game-playing world.

Opinions on this change were mixed. Luck pointed out that gamers can simply disable split-lock detection by rebooting with split_lock_detect=off on the kernel command line. If the seq mode were to be added, he said, it should be the default. He also suggested filing a bug with the publishers of God of War to get its misbehavior fixed.

Others disagreed, though. Joshua Ashton argued that the problem is more widespread: "It's not just about God of War specifically. There are many old titles that will never, ever, get updated to fix this problem. These titles worked perfectly fine and were performant before." Others pointed out that many gamers are unlikely to be comfortable with adjusting kernel command-line parameters. Dave Hansen observed that the misery-inflicting mode had worked as intended and had brought the problem to light. Even so, he continued:

My gut says we should keep the warnings and kill the misery. The folks who are going to be able to fix the issues are probably also the ones looking at dmesg and don't need the extra hint from the misery. The folks running Windows games don't look at dmesg and just want to play their game without misery.

Luck, though, argued that split locking creates its own misery for processes other than the one responsible, and that the current mode "serves a very useful purpose on multi-user systems". He suggested that perhaps some sort of heuristic could be developed to confine the misery to multi-user systems.

The definitive answer, though, came from Thomas Gleixner, who pointed out that slowing down split lockers by default is the only choice that distributors could make; anything else creates an easily exploitable denial-of-service vulnerability. So the slowdown needs to remain: "Attack vector prevention has precedence over broken applications". He did suggest, though, that a sysctl knob could be added to control split-lock detection; that would allow users of broken applications to get their performance back without the need to figure out how to change command-line parameters or reboot their systems.

That is the approach that Piccoli has taken for his second attempt at addressing the problem. The new kernel.split_lock_mitigate knob, if set to zero, will disable the penalization of processes using split locking (while retaining the warning sent to the system log). The default is to retain the slowdown. This patch seems to have pleased everybody involved and looks likely to find its way into the 6.2 kernel. Affected gamers will have to set the new knob appropriately, but knowing which sysctls to tweak could be said to be part of being a true God of War.

Comments (54 posted)

Some remotely exploitable kernel WiFi vulnerabilities

It would appear that there is a set of memory-related vulnerabilities in the kernel's WiFi stack that can be exploited over the air via malicious packets; five CVE numbers have been assigned to the set. Fixes are headed toward the mainline and should show up in stable updates before too long; anybody who uses WiFi on untrusted networks should probably keep an eye out for the relevant updates.

Comments (23 posted)

GnuPG 2.3.8 released

Version 2.3.8 of the GNU Privacy Guard is out. It contains a few new features but the real purpose is to fix CVE-2022-3515, an integer overflow vulnerability that can be exploited remotely for code execution via a, for example, malicious S/MIME attachment. Note that the actual vulnerability is in the libksba library, which is normally packaged separately on Linux systems.

Full Story (comments: none)

Kernel release status

The current development kernel is 6.1-rc1, released on October 16. Linus said:

This isn't actually shaping up to be a particularly large release: we "only" have 11.5k non-merge commits during this merge window, compared to 13.5k last time around. So not exactly tiny, but smaller than the last few releases. At least in number of commits.

That said, we've got a few core things that have been brewing for a long time, most notably the multi-gen LRU VM series, and the initial Rust scaffolding (no actual real Rust code in the kernel yet, but the infrastructure is there).

Stable updates: 6.0.2, 5.19.16, 5.15.74, 5.10.148, and 5.4.218 were released on October 15, followed by 5.10.149 and 5.4.219 on October 17. These relatively small updates contain fixes for the recently disclosed WiFi vulnerabilities among other things.

The large 6.0.3 update is in the review process; it is due on October 21.

Comments (none posted)

Google launches KataOS

Google has announced the existence of yet another new operating system, called KataOS, aimed at the creation of secure embedded systems.

As the foundation for this new operating system, we chose seL4 as the microkernel because it puts security front and center; it is mathematically proven secure, with guaranteed confidentiality, integrity, and availability. Through the seL4 CAmkES framework, we're also able to provide statically-defined and analyzable system components. KataOS provides a verifiably-secure platform that protects the user's privacy because it is logically impossible for applications to breach the kernel's hardware security protections and the system components are verifiably secure. KataOS is also implemented almost entirely in Rust, which provides a strong starting point for software security, since it eliminates entire classes of bugs, such as off-by-one errors and buffer overflows.

Comments (90 posted)

Tails 5.5 released

Version 5.5 of the Tor-centered Tails distribution is out. The biggest change appears to be a significant update to the Thunderbird email client.

Thunderbird 102 is a major update with many changes to the navigation, folder icons, and address book. Thunderbird 102 also includes important usability improvements to the OpenPGP feature. When composing an email, you can now see whether it will be encrypted or not. If encryption is impossible, a key assistant helps you solve key issues.

Comments (none posted)

Distributions quote of the week

But running `cargo fetch` with a clean cache pulls down *390* crates. Of these, it looks like 199 (!) are already packaged as rust-[crate]-devel, which is *amazing*. But... that still is hundreds that I'd have to add. And mostly they are things I don't know _anything_ about.

*This is what open source winning looks like.*

— Matthew Miller

Comments (1 posted)

PostgreSQL 15 released

Version 15 of the PostgreSQL database management system is out.

PostgreSQL 15 builds on the performance improvements of recent releases with noticeable gains for managing workloads in both local and distributed deployments, including improved sorting. This release improves the developer experience with the addition of the popular MERGE command, and adds more capabilities for observing the state of the database.

There are a lot of changes in this release; click below for the details, and see the release notes for more.

Full Story (comments: 2)

Firefox 106 released

Version 106.0 of the Firefox browser has been released. There are several new features, including PDF editing, Firefox View (an overview of recently closed tabs), and a set of new color schemes.

Comments (15 posted)

CFP Deadlines: October 20, 2022 to December 19, 2022

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

Deadline	Event Dates	Event	Location
November 15	December 1 December 4	Karibu PyCon Tanzania	Zanzibar, Tanzania
November 20	February 22 February 24	PGConf India	Bengaluru, India
November 23	March 18 March 19	LibrePlanet	Boston, US
December 2	March 9 March 12	Southern California Linux Expo	Pasadena, CA, US
December 16	May 9 May 11	sambaXP	Goettingen, Germany
December 18	February 7 February 8	State of Open Con 2023	London, UK

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

Events: October 20, 2022 to December 19, 2022

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

Date(s)	Event	Location
October 16 October 21	DjangoCon US 2022	San Diego, USA
October 19 October 21	ROSCon 2022	Kyoto, Japan
October 20 October 21	Netfilter workshop	Seville, Spain
October 24 October 28	KubeCon / CloudNativeCon North America	Detroit, United States
October 24 October 28	Netdev 0x16	Lisbon, Portugal
October 25 October 28	PostgreSQL Conference Europe	Berlin, Germany
October 29	Minsk Linux User Group meeting	Minsk, Belarus
October 29	PyCon Hong Kong 2022	Hong Kong, Hong Kong
November 1 November 3	Reproducible Builds Summit 2022	Venice, Italy
November 3 November 14	Ceph Virtual 2022	Online
November 4 November 5	SeaGL 2022	Seattle, US
November 7 November 9	Ubuntu Summit 2022	Prague, Czech Republic
November 8 November 9	Open Source Experience Paris	Paris, France
November 11	Software Supply Chain Offensive Research and Ecosystem Defenses 2022	Los Angeles, USA
November 11 November 12	South Tyrol Free Software Conference	Bolzano, Italy
November 14 November 16	Open Source Monitoring Conference 2022	Nürnberg, Germany
November 26 November 27	UbuCon Asia 2022	Seoul, South Korea
December 1 December 4	Karibu PyCon Tanzania	Zanzibar, Tanzania
December 2 December 3	OLF Conference 2022	Columbus, OH, USA
December 2 December 4	GNOME Asia 2022	Kuala Lumpur, Malaysia

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

Alert summary October 13, 2022 to October 19, 2022

Dist.	ID	Release	Package	Date
Arch Linux	ASA-202210-2		kernel	2022-10-15
Arch Linux	ASA-202210-1		linux-hardened	2022-10-15
Arch Linux	ASA-202210-3		linux-lts	2022-10-15
Arch Linux	ASA-202210-4		linux-zen	2022-10-15
Debian	DLA-3155-1	LTS	bcel	2022-10-18
Debian	DSA-5256-1	stable	bcel	2022-10-18
Debian	DSA-5253-1	stable	chromium	2022-10-13
Debian	DLA-3152-1	LTS	glibc	2022-10-17
Debian	DSA-5257-1	stable	kernel	2022-10-18
Debian	DLA-3153-1	LTS	libksba	2022-10-17
Debian	DSA-5255-1	stable	libksba	2022-10-17
Debian	DSA-5252-1	stable	libreoffice	2022-10-12
Debian	DLA-3154-1	LTS	node-xmldom	2022-10-18
Debian	DSA-5254-1	stable	python-django	2022-10-15
Debian	DLA-3150-1	LTS	rexical	2022-10-12
Debian	DLA-3149-1	LTS	ruby-nokogiri	2022-10-12
Debian	DLA-3151-1	LTS	squid	2022-10-13
Debian	DSA-5258-1	stable	squid	2022-10-19
Fedora	FEDORA-2022-2ff503c5d4	F35	apptainer	2022-10-15
Fedora	FEDORA-2022-0be906c02d	F36	apptainer	2022-10-15
Fedora	FEDORA-2022-076544c8aa	F36	dbus	2022-10-14
Fedora	FEDORA-2022-f5a45757df	F36	dhcp	2022-10-14
Fedora	FEDORA-2022-9ca9a94e28	F37	dhcp	2022-10-17
Fedora	FEDORA-2022-c68d90efc3	F35	expat	2022-10-14
Fedora	FEDORA-2022-b948fc3cfb	F35	kernel	2022-10-15
Fedora	FEDORA-2022-2cfbe17910	F36	kernel	2022-10-14
Fedora	FEDORA-2022-1a5b125ac6	F37	kernel	2022-10-17
Fedora	FEDORA-2022-b8b34e62ab	F35	python3.6	2022-10-15
Fedora	FEDORA-2022-d4570fc1a6	F36	python3.6	2022-10-15
Fedora	FEDORA-2022-1454bee2fa	F35	thunderbird	2022-10-14
Fedora	FEDORA-2022-fff548cfab	F35	vim	2022-10-17
Fedora	FEDORA-2022-40161673a3	F36	vim	2022-10-14
Fedora	FEDORA-2022-ca2f721916	F36	wavpack	2022-10-12
Fedora	FEDORA-2022-b81c4781af	F36	weechat	2022-10-14
Gentoo	202210-01		assimp	2022-10-16
Gentoo	202210-07		deluge	2022-10-16
Gentoo	202210-06		libvirt	2022-10-16
Gentoo	202210-03		libxml2	2022-10-16
Gentoo	202210-02		openssl	2022-10-16
Gentoo	202210-09		rust	2022-10-16
Gentoo	202210-08		tcpreplay	2022-10-16
Gentoo	202210-05		virglrenderer	2022-10-16
Gentoo	202210-04		wireshark	2022-10-16
Mageia	MGASA-2022-0376	8	chromium-browser-stable	2022-10-19
Mageia	MGASA-2022-0374	8	dhcp	2022-10-19
Mageia	MGASA-2022-0372	8	dokuwiki	2022-10-19
Mageia	MGASA-2022-0378	8	firefox	2022-10-19
Mageia	MGASA-2022-0377	8	golang	2022-10-19
Mageia	MGASA-2022-0368	8	libofx	2022-10-13
Mageia	MGASA-2022-0369	8	lighttpd	2022-10-13
Mageia	MGASA-2022-0370	8	mediawiki	2022-10-13
Mageia	MGASA-2022-0367	8	python	2022-10-13
Mageia	MGASA-2022-0375	8	python-joblib	2022-10-19
Mageia	MGASA-2022-0373	8	sos	2022-10-19
Mageia	MGASA-2022-0371	8	unzip	2022-10-19
Oracle	ELSA-2022-6911	OL8	.NET 6.0	2022-10-13
Oracle	ELSA-2022-6913	OL9	.NET 6.0	2022-10-13
Oracle	ELSA-2022-6912	OL8	.NET Core 3.1	2022-10-13
Oracle	ELSA-2022-6963	OL9	nodejs	2022-10-18
Oracle	ELSA-2022-6964	OL8	nodejs:16	2022-10-18
Red Hat	RHSA-2022:6911-01	EL8	.NET 6.0	2022-10-17
Red Hat	RHSA-2022:6913-01	EL9	.NET 6.0	2022-10-17
Red Hat	RHSA-2022:6912-01	EL8	.NET Core 3.1	2022-10-17
Red Hat	RHSA-2022:6967-01	EL6	compat-expat1	2022-10-17
Red Hat	RHSA-2022:6921-01	EL6	expat	2022-10-12
Red Hat	RHSA-2022:6997-01	EL7	firefox	2022-10-18
Red Hat	RHSA-2022:7024-01	EL8	firefox	2022-10-18
Red Hat	RHSA-2022:7019-01	EL8.1	firefox	2022-10-18
Red Hat	RHSA-2022:7022-01	EL8.2	firefox	2022-10-18
Red Hat	RHSA-2022:7025-01	EL8.4	firefox	2022-10-18
Red Hat	RHSA-2022:7020-01	EL9	firefox	2022-10-18
Red Hat	RHSA-2022:6983-01	EL8.4	kernel	2022-10-18
Red Hat	RHSA-2022:6991-01	EL8.4	kernel-rt	2022-10-18
Red Hat	RHSA-2022:6978-01	EL8.4	kpatch-patch	2022-10-18
Red Hat	RHSA-2022:6963-01	EL9	nodejs	2022-10-18
Red Hat	RHSA-2022:6985-01	EL8.4	nodejs:14	2022-10-18
Red Hat	RHSA-2022:6964-01	EL8	nodejs:16	2022-10-17
Red Hat	RHSA-2022:6998-01	EL7	thunderbird	2022-10-18
Red Hat	RHSA-2022:7023-01	EL8	thunderbird	2022-10-18
Red Hat	RHSA-2022:7021-01	EL8.1	thunderbird	2022-10-18
Red Hat	RHSA-2022:6996-01	EL8.2	thunderbird	2022-10-18
Red Hat	RHSA-2022:6995-01	EL8.4	thunderbird	2022-10-18
Red Hat	RHSA-2022:7026-01	EL9	thunderbird	2022-10-18
Scientific Linux	SLSA-2022:6997-1	SL7	firefox	2022-10-19
Scientific Linux	SLSA-2022:6998-1	SL7	thunderbird	2022-10-19
Slackware	SSA:2022-291-01		git	2022-10-18
Slackware	SSA:2022-291-02		mozilla	2022-10-18
Slackware	SSA:2022-286-01		python3	2022-10-13
Slackware	SSA:2022-290-01		xorg	2022-10-17
Slackware	SSA:2022-288-01		zlib	2022-10-15
SUSE	SUSE-SU-2022:3654-1	SLE12	amazon-ssm-agent	2022-10-19
SUSE	SUSE-SU-2022:3637-1		caasp-release, cri-o, patchinfo, release-notes-caasp, skuba	2022-10-18
SUSE	openSUSE-SU-2022:10146-1	osB15	chromium	2022-10-13
SUSE	openSUSE-SU-2022:10151-1	osB15	chromium	2022-10-17
SUSE	openSUSE-SU-2022:10153-1	osB15	enlightenment	2022-10-19
SUSE	SUSE-SU-2022:3598-1	MP4.1 MP4.2 MP4.3 SLE15 SES6 SES7 oS15.3 oS15.4	exiv2	2022-10-17
SUSE	SUSE-SU-2022:3597-1	MP4.1 MP4.2 SLE15 SLE-m5.1 SLE-m5.2 SES6 SES7 oS15.3 osM5.2	expat	2022-10-17
SUSE	openSUSE-SU-2022:10145-1	osB15	gdcm, orthanc, orthanc-gdcm, orthanc-webviewer	2022-10-12
SUSE	openSUSE-SU-2022:10144-1	osB15	gdcm, orthanc, orthanc-gdcm, orthanc-webviewer	2022-10-12
SUSE	SUSE-SU-2022:3609-1	MP4.2 SLE15 oS15.3	kernel	2022-10-18
SUSE	SUSE-SU-2022:3585-1	MP4.3 SLE15 oS15.4	kernel	2022-10-14
SUSE	SUSE-SU-2022:3586-1	OS9 SLE12	kernel	2022-10-14
SUSE	SUSE-SU-2022:3587-1	SLE12	kernel	2022-10-14
SUSE	SUSE-SU-2022:3584-1	SLE12	kernel	2022-10-14
SUSE	SUSE-SU-2022:3599-1	SLE12	kernel	2022-10-17
SUSE	openSUSE-SU-2022:10147-1	osB15	libosip2	2022-10-13
SUSE	SUSE-SU-2022:3650-1	MP4.2 MP4.3 SLE15 oS15.3 oS15.4	libreoffice	2022-10-19
SUSE	SUSE-SU-2022:3602-1	SLE12	libreoffice	2022-10-17
SUSE	SUSE-SU-2022:3617-1		netty	2022-10-18
SUSE	SUSE-SU-2022:3616-1	MP4.2 SLE15 oS15.3 oS15.4	nodejs12	2022-10-18
SUSE	SUSE-SU-2022:3614-1	MP4.2 SLE15 oS15.3 oS15.4	nodejs14	2022-10-18
SUSE	SUSE-SU-2022:3615-1	MP4.2 SLE15 oS15.3	nodejs16	2022-10-18
SUSE	openSUSE-SU-2022:10154-1	osB15	pngcheck	2022-10-19
SUSE	SUSE-SU-2022:3613-1	MP4.2 SLE15 oS15.3	postgresql-jdbc	2022-10-18
SUSE	SUSE-SU-2022:3590-1	SLE15 SES6	python-Babel	2022-10-14
SUSE	SUSE-SU-2022:3512-2	MP4.1 SLE15 SES6 SES7	python	2022-10-17
SUSE	SUSE-SU-2022:0134-3	MP4.1 SLE15 SES6 SES7	python-numpy	2022-10-17
SUSE	SUSE-SU-2022:3635-1	OS8	python-waitress	2022-10-18
SUSE	SUSE-SU-2022:3583-1	OS9	python-waitress	2022-10-14
SUSE	SUSE-SU-2022:3593-1	MP4.1 SLE15 SLE-m5.1 SES6 SES7	python3	2022-10-14
SUSE	SUSE-SU-2022:3594-1	MP4.1 SLE15 SES7 oS15.3 oS15.4	qemu	2022-10-17
SUSE	openSUSE-SU-2022:10148-1	osB15	roundcubemail	2022-10-17
SUSE	SUSE-SU-2022:3621-1	MP4.0 MP4.1 MP4.2 MP4.3 SLE15 oS15.3 oS15.4	rubygem-activesupport-5_1	2022-10-18
SUSE	SUSE-SU-2022:3571-1	MP4.0 MP4.1 MP4.2 MP4.3 SLE15 oS15.3 oS15.4	rubygem-puma	2022-10-13
SUSE	openSUSE-SU-2022:10150-1	oS15.3	seamonkey	2022-10-17
SUSE	openSUSE-SU-2022:10149-1	oS15.4	seamonkey	2022-10-17
SUSE	SUSE-SU-2022:3596-1	MP4.1 MP4.2 SLE15 SES6 SES7 oS15.3	squid	2022-10-17
SUSE	SUSE-SU-2022:3653-1	SLE12	tcl	2022-10-19
SUSE	openSUSE-SU-2022:10152-1	oS15.4	virtualbox	2022-10-18
Ubuntu	USN-5672-1	16.04 18.04 20.04	GMP	2022-10-12
Ubuntu	USN-5685-1	22.04	frr	2022-10-18
Ubuntu	USN-5680-1	20.04	gThumb	2022-10-14
Ubuntu	USN-5686-1	18.04 20.04 22.04	git	2022-10-18
Ubuntu	USN-5675-1	14.04 16.04 18.04 20.04	heimdal	2022-10-13
Ubuntu	USN-5688-1	14.04 16.04 18.04 20.04 22.04	libksba	2022-10-18
Ubuntu	USN-5678-1	18.04	linux-aws, linux-gcp-4.15	2022-10-13
Ubuntu	USN-5682-1	18.04	linux-aws-5.4	2022-10-14
Ubuntu	USN-5679-1	16.04	linux-aws-hwe	2022-10-13
Ubuntu	USN-5684-1	14.04 16.04	linux-azure	2022-10-17
Ubuntu	USN-5687-1	18.04	linux-azure-4.15	2022-10-18
Ubuntu	USN-5677-1	18.04 20.04	linux-gcp, linux-oracle-5.4, linux-raspi, linux-raspi-5.4	2022-10-13
Ubuntu	USN-5683-1	22.04	linux-ibm	2022-10-14
Ubuntu	USN-5676-1	16.04	postgresql-9.5	2022-10-13
Ubuntu	USN-5673-1	14.04 16.04 18.04 20.04 22.04	unzip	2022-10-13
Ubuntu	USN-5674-1	16.04	xmlsec1	2022-10-13
Ubuntu	USN-5570-2	20.04 22.04	zlib	2022-10-17

Full Story (comments: none)