Welcome to the LWN.net Weekly Edition for September 23, 2021

This edition contains the following feature content:

• Weaponizing middleboxes: filtering devices can be turned into attack amplifiers.
• A discussion on folios: Linux Plumbers Conference attendees ponder the next step for the folio patches.
• Coverage from the Kangrejos Rust-for-Linux workshop, including:
  • The Rust for Linux project: an introduction to the effort to bring Rust into the Linux kernel.
  • Key Rust concepts for the kernel: what Rust provides for kernel development.
  • More Rust concepts for the kernel: how kernel abstractions translate into Rust.

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)

Weaponizing middleboxes

Middleboxes are, unfortunately in many ways, a big part of today's internet. While middleboxes inhabit the same physical niche as routers, they are not aimed at packet forwarding; instead they are meant to monitor and manipulate the packets that they see. The effects of those devices on users of the networks they reign over may be unfortunate as well, but the rest of the internet is only affected when trying to communicate with those users—or so it was thought. Based on some recently reported research, it turns out that middleboxes can be abused to inflict denial-of-service (DoS) attacks elsewhere on the net.

Though it lacks the catchy nickname and logo that have come to dominate security research reporting over the last few years, the "Weaponizing Middleboxes for TCP Reflected Amplification" web site describes a potent threat. The researchers, Kevin Bock, Abdulrahman Alaraj, Yair Fax, Kyle Hurley, Eric Wustrow, and Dave Levin, found flaws in the TCP/IP implementation of various middleboxes that allow DoS attacks via amplification. The middleboxes they studied are those deployed by government organizations for the purposes of censorship, but "even benign deployments of firewalls and intrusion prevention systems in non-censoring nation-states can be weaponized using the techniques we discovered".

It is important to note that the problems found are in the TCP/IP implementations of these middleboxes and not in the protocol itself. Those problems could be fixed, perhaps, but the researchers are skeptical that will happen:

Completely fixing this problem will require countries to invest money in changes that could weaken their censorship infrastructure, something we believe is unlikely to occur.

Background

Amplification is a technique used in denial-of-service attacks that allows an attacker to send a relatively small amount of data which causes a larger amount of data to reach the victim. Typically, this is done by spoofing the IP address of the victim while making a request to a service that will respond with a larger reply. The ratio between the sizes of the response and request is known as the "amplification factor"; historically, those have ranged from low single digits to as much as 50,000x for the memcached amplification flaw that was fixed in 2018.

In the past, DoS amplifications have used UDP because TCP requires a three-way handshake to establish a connection. Spoofing a victim's IP address and trying to establish a TCP connection does not work because the information in the SYN-ACK response from the destination (i.e. step 2 of the handshake) gets sent to the victim. That means that the attacker does not receive what is needed to complete the handshake, thus the connection never gets established. But the researchers found that the censorship middleboxes ignore the fact that there is no TCP connection established and respond (to the victim IP) with an HTML page indicating that the content is censored (i.e. a "block page").

Middleboxes are often not TCP-compliant by design: many middleboxes attempt [to] handle asymmetric routing, where the middlebox can only see one direction of packets in a connection (e.g., client to server). But this feature opens them to attack: if middleboxes inject content based only on one side of the connection, an attacker can spoof one side of a TCP 3-way handshake, and convince the middlebox there is a valid connection.

Methodology

In order to find packet sequences that would elicit the misbehavior, the researchers developed Geneva, which is a program that employs a genetic algorithm to "automatically discover new ways to evade censorship". The genetic algorithm is used to refine the results, "but at its core, Geneva is a packet-level network fuzzer". They gathered a list of 184 censorship middleboxes from around the world using data gathered by the Quack tool from Censored Planet. Then they turned Geneva loose with a goal of finding amplifications: "We modified Geneva’s fitness function to reward it for making the elicited response as large as possible, and then trained Geneva against all 184 middleboxes."

That fuzzing resulted in finding five packet sequences that would elicit amplified responses, as well as five ways to increase the amplification for a small subset of the middleboxes, which could be used in targeted attacks. The packet sequences abuse the TCP protocol in various ways, which should result in the packets being ignored, but the middleboxes tested would instead respond with a block page.

As might be guessed, these censoring middleboxes need to find something "objectionable" in the packet before they will respond with a block page. Using the data gathered by Quack, the researchers put together a list of the five most-blocked domains. As it turned out, those domains covered five different subject areas that governments like to censor (e.g. pornography, file sharing, social media). Those domains were used in well-formed HTTP GET requests in a packet (or packets) that caused the censor boxes to send the block page.

In a fairly eye-opening experiment—one that would, of course, be impossible for IPv6—the researchers scanned the entire IPv4 address space 35 separate times. They used the five domains of "interest", plus no domain and example.com as controls, with each of the five packet sequences and recorded the amplification found for each. Below is a graph from the web site that shows the amplification factors found:

Amplification

Generally, the amount of amplification from a country's censorship middlebox is fairly low, though there are exceptions. "Most of these nation-states are weak amplifiers (the Great Firewall of China only offers about 1.5x amplification, for example), but some of them offer more damaging amplifications, such as Saudi Arabia (~20x amplification)." Certain types of attacks can actually lead to effectively infinite amplification, however, either because of a routing loop where the time-to-live (TTL) value is not decremented correctly or one where the victim system's default response sustains the attack:

We found amplifiers that, once triggered by a single packet sequence from the attacker, will send an endless stream of packets to the victim. In our testing, some of these packet streams lasted for days, often at the full bandwidth the amplifier’s link could supply.

A factor that makes these attacks even more pernicious is that when the censorship middleboxes block a connection to a host, they spoof the IP address of that host as the source address in their response. That way, it appears that the response is coming from the host and not from the middlebox. Normally, an amplified response has the source IP address of the amplifier, which might make it easier to filter when a DoS attack is underway. That is not the case here:

The real challenge of nation-states is that their censorship infrastructure usually processes all traffic entering or exiting the country. This means that unlike other amplification attacks, where the source IP address of the traffic received by the victim is the amplifier itself, every IP address behind a middlebox can appear as the source of traffic. Said another way: every IP address within an amplifying nation-state can be an amplifier.

The full damage that attacker could do using this technique is not known. The amplification factor is only one part of the equation, as it also depends on the bandwidth available to the amplifier, which the researchers were unwilling to try to measure:

Unfortunately, this is the hardest to study ethically. To measure the maximum capacity of a given amplifier, we would have to completely saturate the link for each network, which could have real negative consequences on the users of that network. For now, the true capacity available to attackers from this attack is unknown.

This mechanism has not been seen in the wild, at least yet, but the researchers are working with companies that monitor and mitigate distributed DoS (DDoS) attacks in order to keep an eye out for it—and assist in mitigation. In September 2020, the flaws were reported to "several country-level CERTs [computer emergency response teams], DDoS mitigation services, and firewall manufacturers" in an effort at responsible disclosure. But, as noted, the changes needed to actually fix the problems would potentially threaten the reasons for deploying the middleboxes (i.e. censorship), so are rather unlikely to ever occur.

There is a lot more information available, including the full paper, which was presented at the 30th USENIX Security Symposium in August; it received a Distinguished Paper award from the conference. A YouTube video of the presentation is also available. Beyond that, there are GitHub repositories for the code used in the research and for Geneva.

[Thanks to Paul Wise for giving us a heads-up on this topic.]

Comments (19 posted)

A discussion on folios

A few weeks ago, Matthew Wilcox might have guessed that his session at the 2021 Linux Plumbers Conference would be focused rather differently. But, as we reported earlier in September, his folio patch set ran into some, perhaps unexpected, opposition and, ultimately, did not land in the mainline for 5.15. Instead of discussing how to use folios as part of the File Systems microconference, he led a discussion that was, at least in part, on the path forward for them.

Wilcox began by noting that the folio patches had not been merged and that he did not have clear direction from Linus Torvalds about what "needs to be changed in order to make it acceptable to him". That is a rather different outcome than Wilcox had been hoping for, so the session was not going to be about "what you need to do in order to enable your filesystems to go faster" using folios. "That's not where we are."

Instead, though, it would be useful to talk about what filesystems need to do in order to use larger pages in the page cache. That will make filesystem I/O more efficient, he said. The best thing that developers can do is to convert the filesystems that still use buffer heads to use iomap for I/O, at least for block-based filesystems. Network filesystems should use David Howells's netfs_lib. In both cases, those APIs will isolate the filesystems from most of the work that Wilcox is doing, he said with a chuckle.

Both of those APIs insulate filesystems from the page cache; for example, they use bytes for sizes, rather than pages. Any filesystems that are working with the page cache directly should look at using iomap or netfs_lib instead. There are artificial filesystems in the kernel, such as procfs, that do not deal with the page cache at all; they fall outside of the discussion, since the focus is on improving the page cache.

There are features that the buffer-head interface has, which iomap currently lacks. He has been talking with filesystem developers about what needs to be added so that block-based filesystems can be converted to use it. There are features that iomap needs to in order to support both fscrypt and fs-verity. There are also some things that buffer heads can do in the I/O completion path, which are lacking in iomap, but there are "no fundamental limitations", he said. As always, though, there are limitations in terms of developer time

Howells briefly described the work he is doing on making fscrypt work with network filesystems and, in particular, to use folios in that work. The idea is to put fscrypt and the page-cache handling code into a separate library for network filesystems to use. Currently, AFS and Ceph are using it. When a network filesystem receives encrypted data from the server, it should not be storing it in the page cache unencrypted, but the code to keep the data encrypted should not be replicated in the six different network filesystems. His work hit something of a wall when Torvalds did not merge the folio patches, however.

Help wanted?

Josef Bacik asked how the filesystem developers could help Wilcox; he knows that moving to iomap is part of that and that is ongoing work for Btrfs. But he wondered if there were concrete steps the filesystem developers could take to support Wilcox's efforts; "sometimes it is patch review, other times it is design review, [...] what do you wish that we would do to help you with all of this?"

Wilcox said that he did not think there was a lot to do on the filesystem side. He has "imposed on the XFS developers extensively" and they helped work out some of his misconceptions. They also helped ferret out problems in his iomap changes; iomap was originally cut from the bottom of XFS and turned into common code, he noted. If there were going to be an effort to make buffer-head-using filesystems handle larger pages, he would need similar help from the developers of one of those filesystems, he said. But the consensus seems to be that the right path is to minimize the use of buffer heads, so that probably won't be needed. On the flipside, though, Wilcox feels that he and the XFS developers owe the developers of other filesystems some assistance in converting to iomap. But he has already seen some of that going on in the current efforts to convert direct I/O for Btrfs to use iomap; it is all proceeding collaboratively.

Bacik said that he wasn't necessarily asking as a Btrfs developer, rather as a kernel developer. These kinds of changes often come down to a single person pushing them forward even though lots of others want the changes in the kernel; that one person can sometimes have a rough time of it, he said.

Ted Ts'o asked whether help with benchmarking would be useful. Wilcox said that he does not do much in the way of benchmark testing; he runs xfstests many times a day, but is "not set up to do performance testing". Both Ts'o and Bacik said they were set up to do that kind of testing, so if Wilcox could point them at a Git tree, testing with and without folios could be done regularly.

In something of a tangent, Ts'o noted that fscrypt and fs-verity were written as libraries of a sort, so that they could be adopted more easily by other filesystems. But the combination of the two was not really made as accessible. He has considered providing a sort of generic pipeline for operations (e.g. decryption, verification, decompression) on filesystem data coming from block devices or over the network that could be combined in arbitrary ways.

He suggested to Howells that the next version of the work he is doing on fscrypt support for network filesystems provide some kind of ability to stack operations of this sort. Howells described what he has been doing to make fscrypt work with some of the network filesystems using larger pages. That kind of work will be needed for ext4, Ts'o said, so that it can move to using iomap as well. They agreed to pick up that discussion elsewhere when more of the appropriate people were present.

Folio future

Wilcox said that over the previous few days he and Kent Overstreet had been talking about getting folios merged. Overstreet said that he thought progress had been made in the discussion on the linux-kernel mailing list over the last week or so. He said that the objections to folios turned out to not really apply to the actual code that was proposed for 5.15 in many cases. In particular, the patches did not really touch anonymous pages, which was an area of contention, he said.

Overstreet suggested that Wilcox consult with Andrew Morton to see where things stand because Overstreet felt that the objections were largely on where folios were headed rather than what was actually posted. Beyond that, later in the day, Overstreet posted a request to Torvalds to reconsider the original folios patch set for inclusion. But it turns out that the situation is more complicated than Overstreet perceived. In particular, Johannes Weiner, who disagrees strongly with the direction of folios, at least on the memory-management side, had objections to the existing patch set and not just the direction they are headed in.

Ts'o said that someone had remarked to him that the memory-management developers may not have actually looked closely at folios until the pull request came in. That may be due to a "cultural expectations that stuff in MM takes forever and a day". He wondered if there was a way to work with those developers to determine what the review procedure is for patches of this nature. There may be a process question as to how the subsystem as a whole makes decisions. That would help everyone understand the ground rules on how to get consensus; he does not believe there is a consensus within the memory-management community on folios, at least yet.

There is no one who is really working on fixing "the struct page mess" at this point, Overstreet said, which is perhaps part of the problem; Wilcox's work is the closest the community has come to that. But the reason that this discussion has been so contentious is that the state from different subsystems is all jumbled together in struct page, Overstreet said. There is no real overarching design for unwinding that.

He said that everyone sees the mess, but that each person sees a different aspect of that mess; folios are cleaning up one part, but some are unhappy that their part of it is not being cleaned up right away. An overall plan that could show the end goal and where each part gets cleaned up would go a long way toward resolving these problems, he said. That ended the session, but clearly the overall discussion will continue.

Interested readers can watch the video of the session over at YouTube.

Comments (4 posted)

The Rust for Linux project

The first ever Rust for Linux conference, known as Kangrejos, got underway on September 13. Organizer Miguel Ojeda used the opening session to give an overview of why there is interest in using Rust in the kernel, where the challenges are, and what the current status is. The talk and following discussion provided a good overview of what is driving this initiative and where some of the sticking points might be.

Why Rust?

This year marks the 30th anniversary of the Linux kernel, he began, but it is also the 30th anniversary of the first ISO standard for the C programming language. C has a lot of history and a lot of baggage, but it is still relevant and interesting. Ojeda said that he is working with the C committee to improve the language, but that process will take a long time — if it ever reaches fruition.

C is good for kernel development for a number of reasons. It is fast, facilitates low-level programming, is simple, and fits the problem domain well. But there is one little problem, known generally as "undefined behavior". The advantage of Rust is that it eliminates undefined behavior, at least in "safe" code. Indeed, the lack of undefined behavior is what Rust developers mean when they say "safe"; it has no relation to similar terms like "safety-critical". An abort() call in C is safe by this definition, even if the end result kills somebody. Ojeda has proposed a "[[safe]]" attribute for C to mark functions that are written to avoid all undefined behavior (and have the compiler enforce that), but that proposal has not made much progress.

So what is not "safe" by Rust standards? The list of not-safe behaviors include using pointers after they are freed, dereferencing NULL pointers, freeing memory twice, using the contents of uninitialized memory, out-of-bounds memory accesses, data races, and more. None of these things will happen, he asserted, in safe sections of Rust code; that is why he wants to see Rust code in the kernel. About 70% of published C vulnerabilities result from undefined behavior, he said, and the rate for vulnerabilities in the Android media and Bluetooth components is closer to 90%. Rust can help make those problems go away. Rust offers a number of other advantages as well, including stricter types, modules, pattern-matching primitives, lifetimes, an extensive set of development tools, and much more.

What is the downside of using Rust in the kernel? It is not possible to model everything, he said, so it is still necessary to use some unsafe code. The Rust language is much more complex than C, and its extra run-time checks can hurt performance. And, of course, it is another language for kernel developers and maintainers to learn, which is also a significant cost. It's a one-time cost that, he said, pays off, but it's still a cost. The Rust for Linux developers are happy to help developers get past this initial learning obstacle.

So how does Rust compare to C as a systems-programming language? Like C, it is fast. It's somewhat low-level like C but, depending on the code, it might be less easy for developers to predict what the resulting assembly code will look like. Rust is definitely not simple like C is. He believes that it fits the domain as well as C does, but others may differ.

Rust support in the kernel

There are five supported architectures for Rust so far: armv6, arm64, powerpc, riscv, and x86-64. Work to this point has not been aimed at supporting every possible architecture; that is a lot of low-level work that doesn't necessarily demonstrate anything new. Instead, the intent is to show that supporting a variety of architectures is possible. There are currently three projects working on compiling Rust code for the kernel. Two of them use the "official" rustc front-end, then using LLVM or GCC for code generation. The rustc/LLVM combination is the leading compiler at this point; Ojeda did not say much about the rustc/GCC pairing. There is also a project working on a native Rust compiler for GCC (gccrs); that is expected to be ready in a year or two.

The Rust for Linux work is split between the Rust and kernel trees. The Rust side has two crates called core (low-level functionality) and alloc (data structures and such). The alloc crate is part of the submission for the kernel side as well; that might eventually not be necessary. These crates are considered to be more a part of the standard Rust library than the kernel.

On the kernel side there are the kernel and builtins crates. The kernel crate abstracts the interface to the rest of the kernel. The bindgen tool is used to generate the bindings that allow calling kernel functions from Rust; there is currently no provision for calling back into Rust from C. One problem that still needs a complete solution, he said, is keeping the C and Rust sides synchronized. The intent is for Rust to be a first-class citizen in the kernel; if a developer makes a change that breaks Rust code, they should fix it, just as they would with the kernel's C code. Just how that will work is not yet fully clear, though.

Where things get interesting is the driver author's point of view. It would be possible to create Rust bindings for all of the kernel functions that one normally calls from a driver and have it work, but that is not what the Rust-on-Linux developers are trying to do. Instead, they are populating the kernel crate with a set of subsystem abstractions and interfaces that will, it is hoped, make it possible to write drivers with no unsafe code at all, he said.

Discussion

There were some concerns raised at this point about the need for maintainers to learn Rust. Ojeda acknowledged that this will be necessary; in the end, maintainers need to be able to take responsibility for their subsystems, even if the Rust developers help them initially. Laurent Pinchart said that help could be needed for a long time; he does not have the time to stop everything and learn Rust anytime soon, so he will be hard put to take responsibility for any Rust code in his subsystem.

Ojeda answered that the Rust developers are aware of this; they have been trying to pick subsystems to start that have maintainers with the time and interest to take up this challenge. Hopefully that will result in the creation of enough examples and experience to help bring in other subsystems later. He reiterated, though, that maintainers need to be on board; if Rust isn't a first-class citizen in the kernel, this experiment is not going to work. Half in jest (perhaps), he added that maintainers who jump on the Rust train sooner are likely to get more help from the Rust developers than those who come later.

Ojeda said that, while subsystem maintainers may have some difficult work to do, life will be easier for driver writers, who only need to work with the (safe) interfaces provided to them. Pinchart objected that driver writers often find that they need to make core-subsystem changes to support their devices properly, so life isn't quite that simple. If the bar for driver authors is raised to include being fluent in Rust, that will be a real impediment for some, he said.

Paolo Bonzini worried that Rust code could inhibit changes to internal kernel APIs. A developer may find that Rust code is the only remaining user of a given API, but may lack the desire (or the ability) to fix that code, so the old API will remain. He asked: how many wrappers for core-kernel APIs do the Rust developers plan to add? If, for example, only some file_operations members are used by Rust code, will there still be bindings for all of them? Adding more bindings than necessary may make it harder to change those operations in the future. Ojeda replied that, for something as core as file_operations, they might just add them all, since they will be used eventually. In other cases, only the interfaces actually used by Rust code will be implemented.

The conversation wandered into the toolchain; Ojeda said that the Rust for Linux developers are currently only supporting one version of the Rust compiler with any given kernel version. Others may work, but there is no guarantee. Eventually it will be possible to build the kernel using only stable Rust features, at which point it will be possible to support more compiler versions. He added that concerns about the stability of the Rust language in general have been raised, but he does not think that is a problem. The language is stable now, he said, and becoming more stable quickly. Kernel code written now, even code using unstable features, will "mostly" work going forward.

Philip Herron, who is working on gccrs, asked: what areas in particular would the Rust for Linux developers like to see written in Rust? Ojeda suggested filesystems and other subsystems that contain a lot of state would be good candidates. Herron then asked about whether there were any plans to pick a specific subset of the Rust language to use in the kernel. He asked specifically about const generics which, he said, would be a good feature to use in the kernel context. But will there come a time when the use of language features must be limited to reduce the burden on maintainers? Ojeda said that some of the more esoteric features might be useful in the core code, but he would rather see drivers using a smaller subset of the language and avoid things like "crazy metaprogramming" and such.

At this point, the session ran out of time and the participants headed off for a much-needed coffee break; further discussion was deferred to the following two days. More than 30 developers attended the session, indicating that there is a fair amount of interest in the idea of writing kernel code in Rust, even if that capability remains out of the mainline kernel for now. Rust in the kernel is not an easy sell, but if it fails, it will not be due to a lack of trying.

Comments (42 posted)

Key Rust concepts for the kernel

The first day of the online Kangrejos conference was focused on introducing the effort to bring the Rust programming language into the Linux kernel. On the second day, conference organizer Miguel Ojeda shifted to presenting the Rust language itself with an emphasis on what Rust can provide for kernel development. The result was a useful resource for anybody who is curious about this project, but who has not yet had the time to become familiar with Rust.

Ojeda began by stressing that the talk was not meant to be a tutorial; to actually learn the language, one should get a good book and work from that. There is no way to cover everything needed in an hour of talk (a fact that became abundantly clear as time went on), but he hoped to be able to show some of the key ideas behind Rust. In the end, though, the only way to really understand the language is to sit down and write some code.

Reading material

There are a number of resources available for developers wanting to learn Rust, including several books. The definitive book appears to be The Rust Programming Language, which is available online for free. The book is a good introduction, he said, and is also an example of the documentation style that pervades the Rust project. Developers who are specifically interested in kernel development need not read the whole thing; much of the discussion on concurrency, for example, is not applicable to the kernel environment.

Programming Rust is also quite nice, he said. It is aimed at experienced programmers, and thus may be useful for kernel developers. This book is the only resource on his list that is not freely available, though. For readers who want to jump right in, Rust by Example presents a series of exercises, each of which introduces a new language feature.

Then, there is The Rustonomicon. This book, which is not complete, focuses on the challenges of writing unsafe Rust in particular. If the Rust-for-Linux project's goals are met, driver writers will not need to write unsafe Rust and, thus, may not need this book. There is a lot of gritty, low-level material in this book, but it also demonstrates a key point: most Rust developers should never have to deal with the language at this level.

Finally, The Rust Reference, which is also incomplete, is a good book for "people who like to read language standards". Most Rust developers will not need it. Ojeda summarized this section by suggesting either of the The Rust Programming Language or Programming Rust for most developers.

The Rust project offers a lot of other documentation too, of course. For the C language, Ojeda said, the standard is the documentation, but Rust is different. Documentation is everywhere, full of explanations and examples, and often generated directly from the code. A similar approach is being taken to the documentation generated by the kernel effort; it is being written using rustdoc rather than the kernel's Sphinx-based system. How to integrate those two bodies of documentation remains an open question.

Tools

Ojeda moved on to a couple of tools that are useful for looking at Rust code and the machine code that it is compiled to. One of those is the Rust playground, which can build code, run linters, examine assembly code, and more.

That said, he prefers Compiler Explorer; it offers a lot of the same features but is not limited to Rust. It can be used to compare assembly output produced by different languages, for example, and features a nice basic-block display for that purpose. Compiler Explorer can also run the code in question and display the results.

The language

While some people describe Rust as "a safer C", Ojeda doesn't like that term. It's more like a version of C with a safer type system, which is not the same as being safety-critical. Rust can also be described as a "cleaned-up C", he said. As an example, he presented a snippet of similar code in three languages:

    map(v, [](const auto & x) { return x.get(); });   // C++
    map(v, lambda x: x.get())    # Python
    map(v, |x| x.get());  // Rust

The Rust version is just cleaner and easier, he said. C++ may contain a lot of useful features, but developers often fear to use them; Rust makes it all easier.

He spent some time on the concept of "safety" in Rust, a discussion that repeated a fair amount from the first day. Rust is "safe" in that it has no undefined behavior; there are no situations where "the compiler has the freedom to do crazy things". Many undesirable behaviors, including kernel panics, memory leaks, and integer overflows, are well defined and, thus, Rust-safe (the compiler can be made to check for overflows though). And, of course, logic errors are "safe"; the language cannot guarantee that a program does what the developer intended.

But many other types of problems can be eliminated by coding in safe Rust. As an example of undefined behavior, Ojeda showed a simple C function:

    int f(int a, int b) {
        return a/b;
    }

There are two ways that this function can wander into undefined behavior. The obvious one is if the caller passes zero for b; if that happens, the compiler is allowed to produce any result it likes. The other undefined situation comes about if a is INT_MIN and b is -1. There is no positive equivalent of the largest negative integer in the two's complement representation, so the result of the division cannot be represented. Once again, the compiler is allowed to improvise when that happens.

One can write a similar function in Rust:

    pub fn f(a: i32, b: i32) -> i32 {
        a/b
    }

Using Compiler Explorer, Ojeda showed that this function, when compiled, contains tests for both of the above undefined-behavior cases. If either is encountered, the program will abort. That may not be what the programmer wanted, but neither is continuing to run in an undefined state.

There was some brief discussion of the performance cost for all of these checks. It certainly is not zero, but nobody seems to have measured what the impact really is in a performance-critical situation. Ojeda pointed out that, in the worst case, code can be put into an unsafe block, which will remove all of those checks. "Unsafe" was often described as an "escape hatch" during this conference — a way to remove many of the constraints placed by the language when they become too heavy.

There are also various tricks that can be applied to show the compiler that certain situations are impossible, at which point it will omit the checks automatically. If one defines a bounded-integer type, for example, the compiler knows that its value will be within its bounds and may not need to perform overflow checks. This technique often involves putting the necessary checks into a constructor, where they only need to be done once.

Ojeda provided one other example, being C code in a function that looks like this:

    int x;  /* not initialized */

    while (f())
        x = 42;
    return x;

Looking at the assembly output for this function, he pointed out that the compiled code just returns a constant 42. The loop body that assigns to x may never have executed, but to reference x in that case puts the program into undefined behavior. The compiler is allowed to assume that this will never happen; in that worldview, x must be assigned the value 42. Rust, instead, will throw a compile-time error in this case and force an explicit initialization of the variable.

Laurent Pinchart noted that developers must train their brains to avoid undefined behavior when working in either language. The difference is that the Rust compiler will catch mistakes, while a C compiler will often remain silent. After training your brain with a language like Rust, he said, the result will often be writing better C code as well.

The time for the session had long since run out by this point, but Ojeda pressed through a series of additional slides describing other Rust language features that are relevant to kernel developers. These include union types that don't allow access to the wrong member, implicit freeing of dynamically allocated objects, handling signed integer overflow, mechanisms for avoiding data races, and more. There is, in short, a lot in Rust for systems developers — much more than can be covered in a brief conference session.

Comments (37 posted)

More Rust concepts for the kernel

The first day of the Kangrejos (Rust for Linux) conference introduced the project and what it was trying to accomplish; day 2 covered a number of core Rust concepts and their relevance to the kernel. On the third and final day of the conference, Wedson Almeida Filho delved deeper into how Rust can be made to work in the Linux kernel, covered some of the lessons that have been learned so far, and discussed next steps with a number of kernel developers.

Almeida started by noting that he is not a Rust developer and does not feel that the language is perfect; he does believe, though, that it can solve some problems in the kernel. He works as an Android platform security-team engineer and has been looking for ways to improve that platform — specifically, to reduce its attack surface. Rust can do that, he said; it also helps with correctness and provides an expressive type system with features that C cannot match.

Ownership

An important Rust concept, he continued, is data ownership; every value in a Rust program has exactly one owner. That ownership will move around as the program executes, but will never be shared. When the owner of an object goes out of scope, that object will be freed. Ownership is exclusive, but there are still ways to move data around, of course; in Rust that is done with references. A mutable reference allows the holder to modify the data; mutable references are exclusive, in that no other references to the object in question may exist. Shared references, instead, are non-exclusive, and are read-only.

There are, it seems, a couple of exceptions to the above rules. Almeida mentioned briefly the idea of interior mutability but did not get into the details of it. Rust also supports raw pointers, but only in unsafe code.

One result of Rust's ownership rules is that there are no data races in code written in safe Rust. To have a data race, you must have at least two CPUs accessing shared data in an unsynchronized manner, with at least one writer. Since mutable references are exclusive, this situation simply cannot come about.

These rules also give the compiler the ability to optimize around code that it cannot directly see. For example, in code that looks like:

    *x = 32
    some_function()
    return *x

The compiler can safely just return 32. There cannot be aliases for the variable x, so there is no way that some_function() can have modified its value.

So how do the ownership rules apply to kernel code? Almeida brought up the example of the private_data field found in many kernel structures; it allows subsystems to attach their own data to a structure managed by higher levels of the system. That field is typically a void * pointer that is cast to the appropriate type when it is used; this is not safe usage by Rust standards. As an example, consider struct file, which is used in the kernel to represent an open file.

In Rust code, a developer would write an open() method that creates some sort of internal state — the sort of data that would normally be attached via private_data. That state will be returned to the caller, and ownership of that state object is returned as well. If, for example, user space calls ioctl() on that open file, the handler will get a shared reference to the state object; this must be shared, since these calls can be made concurrently. When, instead, the file is closed, the release() method will get ownership of the state, which it will then drop. All of this can be done using Rust's type discipline to provide type and concurrency safety.

Device IDs, locks, and more

Another example is the device-ID tables found throughout the driver subsystem. These tables contain an array of IDs and an untyped, optional argument; they must be null-terminated. Almeida has written a PL061 (GPIO) driver in Rust to mirror the C driver found in the kernel and created a new device-ID-table abstraction to go with it. Developers must decide what the type of the optional data will be, and all data specified must match that type. There is no need to null-terminate the list, eliminating a common error made by driver authors. As a result, the whole mechanism is type-safe and easier to use.

Locking is the cause of a lot of complexity and confusion in the kernel. In C code, locks are typically declared as structure fields, and it is often not clear exactly what data any given lock is protecting. In Rust, instead, data is associated directly with the lock that protects it, with the result that there is no way to write code that accesses that data without first acquiring the lock — at least, not if the developer wants the compiler to accept it. All of the checking can be done at compile time.

Almeida briefly mentioned the vulnerability known as CVE-2021-26708, which was an exploitable race condition in the mainline kernel caused by accessing data prior to acquiring the lock that protects it. Rust, he said, would have prevented this vulnerability from happening. The definition of the lock would have ensured that the relevant data could not be touched without first acquiring that lock. But what happens if a developer doesn't realize that a lock is needed in the first place? In this case Rust's ownership rules would save the situation, since attempts to modify the unprotected data would fail with the wrong type of reference.

Laurent Pinchart jumped in to say that he likes the idea of bundling data with the lock that protects it. But he wondered about the cases where the developer knows that the lock is not needed; initialization code is one such case. Seemingly, if the compiler knows that there can only be one reference to the object in question, the lock is not necessary; this can happen when the object has just been created, for example. If all else fails, Almeida said, developers can always use the "unsafe escape hatch".

Another abstraction to look at is file descriptors; these are created by first acquiring a reference to the underlying file structure, then allocating the descriptor number itself. If that allocation fails, code must remember to drop the file reference. Rust's lifecycle management makes that error-handling happen automatically, with a lot less boilerplate code. The sort of "goto out;" pattern often seen in kernel code is just not necessary in Rust.

CVE-2019-15971, Almeida said, came about as the result of a failure to increment a file's reference count; that led to a use-after-free vulnerability. In Rust it is not possible to make this kind of mistake without getting a friendly diagnostic from the compiler.

Returning to error paths, Almeida repeated that most of the complex and error-prone error handling seen in kernel code just vanishes when using Rust. For the most part, objects are simply cleaned up when they go out of scope, with no explicit handling needed at all. For cases where the developer needs more control, a scopeguard object can be used. This object is initialized with the appropriate error-handling information; if all goes well and the error-handling code is not needed, its dismiss() method can be called. Otherwise, if that object goes out of scope, it will perform the needed error handling.

A few other kernel abstractions were covered, including task structures, red-black trees, and access to memory-mapped I/O areas. The point that Almeida was trying to make should be clear by now, though. The Rust language is capable of handling kernel-level programming in a way that is inherently safer than doing the same tasks in C. Were there, he concluded, any questions or objections?

Discussion

Julia Lawall started by asking about things that don't work well in Rust — where are the sticking points? Almeida answered that, in Rust, all objects are movable in memory, which can be problematic for self-referential data structures. The solution is pinning, but that requires writing unsafe code. A lot of unsafe code in existing Rust drivers has its origin in this problem, he said. Another issue is the way that Rust requires all data to be initialized, which can be a problem with mutexes in particular. Fixing that is mostly a matter of finding the right abstractions.

Pinchart questioned the incremental approach being taken by the Rust developers — an issue that came up a number of times in the discussion. He said that the right approach is to lock the kernel subsystem maintainers in a room, require them to learn Rust, and to provide a great deal of help to those maintainers during the transition. If a maintainer is blocked by a Rust-related problem, they should be able to count on immediate help to fix it. Otherwise, he said, the Rust developers are going to encounter a huge amount of pushback.

Ojeda questioned whether pushback was really going to be a problem; nobody is taking away the ability to write a driver in C, he said. Pinchart replied that, at some point, maintainers may not accept those drivers. Ojeda said that could maybe happen in five or ten years, not before. It is necessary to say that kernel developers will be expected to learn some Rust, he said; the safe subset is not that hard. He did allow that unsafe Rust is rather harder; worries about undefined behavior return, and the documentation is not as good.

In another frequently heard concern, Pinchart pointed out that kernel developers have to be able to work all over the source tree; it's a rare developer who never looks outside of one subsystem. That will make it hard to minimize the impact of Rust in the kernel early on; a surprising number of developers are likely to encounter it. Ojeda said that the plan is only to introduce Rust in subsystems where the maintainer knows the language, but Pinchart answered that expecting that other developers will not have to care about that Rust code is wrong. Developers are almost certainly going to have to work with unsafe Rust as well. Mark Brown added that there will probably have to be some sort of flag day tied to the introduction of Rust, after which maintainers will simply have to know the language to some degree.

Almeida asked how many Rust-knowing kernel developers would need to exist before this transition might begin; Jonathan Cameron answered: "a lot". I jumped in with some experience from the introduction of the ReStructured Text language for documentation; that process took longer than might have been expected, ran into some fierce (and ongoing) resistance, and is still not complete. It would not have succeeded to the degree it has without acceptance by a significant part of the development community. The introduction of Rust, which is a vastly more complex task, will not have an easier time of it; working to build wide acceptance is not optional. Pinchart said that most developers seem to appreciate the value of Rust now, but many of them worry about the cost of bringing it into the kernel.

Ojeda said that the Rust for Linux developers need to either convince enough developers of the value of Rust so that Linus Torvalds will bless the change, or else simply end the discussion. He looked forward to the upcoming discussions at the Linux Plumbers Conference and Kernel Summit as a way to bring more developers into the process. I expressed some worries about relying too heavily on a blessing from Torvalds; that is a necessary condition but far from sufficient.

Greg Kroah-Hartman said that he likes the idea of introducing Rust into kernel development, but said that this work has a long way to go yet. Device drivers (which is what the Rust developers are initially targeting) have to interact with many parts of the kernel, including the driver model, sysfs, and various other subsystems; the Rust to enable that interaction has not yet been written. There are going to be social, political, and technical issues around the introduction of Rust, and not even the technical issues have been taken care of yet. That said, he commended the Rust developers for the progress they have made so far.

As the session ran out of time, Kroah-Hartman said that it would not be possible to require developers to write in Rust for at least five years. Pinchart asked whether anybody has thought about how many developers the community is willing to lose in this transition; the actual number will almost certainly not be zero. Ojeda concluded things by saying that the process for getting Rust into the kernel is the most important aspect, and that the next step for that will be the discussions at the Linux Plumbers Conference.

Comments (21 posted)

An update on Memory Safety in Chrome

The Google security blog provides an overview of what is being done to address memory-safety problems in the Chrome browser.

In parallel, we’ll be exploring whether we can use a memory safe language for parts of Chrome in the future. The leading contender is Rust, invented by our friends at Mozilla. This is (largely) compile-time safe; that is, the Rust compiler spots mistakes with pointers before the code even gets to your device, and thus there’s no performance penalty. Yet there are open questions about whether we can make C++ and Rust work well enough together. Even if we started writing new large components in Rust tomorrow, we’d be unlikely to eliminate a significant proportion of security vulnerabilities for many years.

Comments (22 posted)

Travis CI flaw exposed secrets of thousands of open source projects (Ars Technica)

This Ars Technica article describes a problem with the Travis continuous-integration service:

A security flaw in Travis CI potentially exposed the secrets of thousands of open source projects that rely on the hosted continuous integration service. Travis CI is a software-testing solution used by over 900,000 open source projects and 600,000 users. A vulnerability in the tool made it possible for secure environment variables—signing keys, access credentials, and API tokens of all public open source projects—to be exfiltrated.

Any project storing secrets in this service would be well advised to replace them.

Comments (13 posted)

Kernel release status

The current development kernel is 5.15-rc2, released on September 19. Linus said:

So I've spent a fair amount of this week trying to sort out all the odd warnings, and I want to particularly thank Guenter Roeck for his work on tracking where the build failures due to -Werror come from.

Is it done? No. But on the whole I'm feeling fairly good about this all, even if it has meant that I've been looking at some really odd and grotty code. Who knew I'd still worry about some odd EISA driver on alpha, after all these years? A slight change of pace ;)

Stable updates have not been in short supply this week. 5.14.5, 5.13.18, 5.10.66, and 5.4.147 came out on September 16, followed by 5.14.6, 5.13.19, and 5.10.67 on September 18 and 5.14.7, 5.10.68, 5.4.148, 4.19.207, 4.14.247, 4.9.283, and 4.4.284 on September 22. Note that the 5.13.x line ends with 5.13.19.

Comments (none posted)

Conill: The long-term consequences of maintainers’ actions

Ariadne Conill looks at the difficulties caused by the OpenSSL 3 transition in the context of Alpine Linux.

For distributions, however, the story is different: cryptography moved to using Rust, because they wanted to leverage all of the static analysis capabilities built into the language. This, too, is a reasonable decision, from a development perspective. From the ecosystem perspective, however, it is problematic, as the Rust ecosystem is still rapidly evolving, and so we cannot support a single branch of the Rust compiler for an entire 2 year lifecycle, which means it exists in community. Our solution, historically, has been to hold cryptography at the latest version that did not require Rust to build. However, that version is not compatible with OpenSSL 3, and so it will eventually need to be upgraded to a new version which is. And so, since cryptography has to move to community, so does paramiko and Ansible.

Comments (34 posted)

Schaller: Cool happenings in Fedora Workstation land

Here's a post from Christian Schaller describing a number of the desktop-oriented improvements that can be expected in the Fedora 35 release.

And I know some people will wonder why we spent so much time working with NVidia around their binary driver, but the reality is that NVidia is the market leader, especially in the professional Linux workstation space, and there are lot of people who either would end up not using Linux or using Linux with X without it, including a lot of Red Hat customers and Fedora users. And that is what I and my team are here for at the end of the day, to make sure Red Hat customers are able to get their job done using their Linux systems.

Comments (69 posted)

Courtès: What's in a package

Over at the Guix-HPC blog, Ludovic Courtès writes about trying to package the PyTorch machine-learning library for the Guix distribution. Building from source in a user-verifiable manner is part of the philosophy behind Guix, but there were a number of problems that were encountered:

The first surprise when starting packaging PyTorch is that, despite being on PyPI, PyTorch is first and foremost a large C++ code base. It does have a setup.py as commonly found in pure Python packages, but that file delegates the bulk of the work to CMake.

The second surprise is that PyTorch bundles (or "vendors", as some would say) source code for no less than 41 dependencies, ranging from small Python and C++ helper libraries to large C++ neural network tools. Like other distributions such as Debian, Guix avoids bundling: we would rather have one Guix package for each of these dependencies. The rationale is manifold, but it boils down to keeping things auditable, reducing resource usage, and making security updates practical.

Comments (17 posted)

Distribution quote of the week

Imagine that you are the product manager for Debian `which`. According to the hatemail in my inbox, this is the most important utility in the history of time, such that even printing a warning to stderr causes global devastation, block hints, and calls for impeachment.

— Clint Adams

Comments (none posted)

GNOME 41 released

The GNOME project has announced the release of GNOME 41.

The most notable changes this in release include an improved Software app, new multitasking settings, and enhanced power management features. With these changes, GNOME is smarter, more flexible, and offers a richer and more engaging experience than ever before.

The new release also comes with significant improvements for developers, including a new developer documentation website, a major new version of the Human Interface Guidelines, new features in the Builder IDE, GTK 4 enhancements, and much more.

Comments (22 posted)

Rosenzweig: Panfrost achieves OpenGL ES 3.1 conformance on Mali-G52

Alyssa Rosenzweig reports that the open-source Panfrost driver for Mali GPUs has achieved official conformance on Mali-G52 for OpenGL ES 3.1.

This important milestone is a step forward for the open source driver, as it now certifies Panfrost for use in commercial products containing Mali G52 and paves the way for further conformance submissions on other Mali GPUs.

Comments (1 posted)

Postgres 14: It's The Little Things (Kerstiens)

Craig Kerstiens highlights some of the "little things" featured in the upcoming PostgreSQL 14 release.

And now in PostgreSQL 14 there is this seemingly small update, pipeline mode, which, according to the docs, allows applications to send a query without having to read the result of the previously sent query. Taking advantage of the pipeline mode, a client will wait less for the server, since multiple queries/results can be sent/received in a single network transaction.

Comments (9 posted)

Hoyt: Structural pattern matching in Python 3.10

Ben Hoyt has published a critical overview of the Python 3.10 pattern-matching feature.

As shown above, there are cases where match really shines. But they are few and far between, mostly when handling syntax trees and writing parsers. A lot of code does have if ... elif chains, but these are often either plain switch-on-value, where elif works almost as well, or the conditions they’re testing are a more complex combination of tests that don’t fit into case patterns (unless you use awkward case _ if cond clauses, but that’s strictly worse than elif).

(Pattern matching has been covered here as well).

Comments (9 posted)

Development quote of the week

Now, for the "Xorg is dead" claims - it's very likely that the current release will be the last Xorg release. There is little interest in an X server that runs on hardware, or rather: there's little interest in the effort required to push out releases.

— Peter Hutterer

Comments (26 posted)

CFP Deadlines: September 23, 2021 to November 22, 2021

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

Deadline	Event Dates	Event	Location
September 30	November 27 November 28	EmacsConf	Online
October 1	December 3 December 4	OLF Conference	Columbus, OH, USA
October 4	November 17	SQLite & Tcl virtual conference	Online
October 19	November 30 December 2	Yocto Project Summit 2021-11	virtual
October 24	December 1 December 4	FlaskCon	Online
November 1	July 28 July 31	Southern California Linux Expo	Los Angeles, CA, USA

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

Events: September 23, 2021 to November 22, 2021

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

Date(s)	Event	Location
September 20 September 24	Linux Plumbers Conference	Online
September 20 September 24	GNU Radio Conference 2021	Charlotte, NC, USA
September 22 September 23	Open Mainframe Summit	Online, UTC-4
September 22 September 24	CyberCon	Brno, Czech Republic
September 25 September 26	Ubucon Asia 2021	Online
September 27 September 29	OSPOCon	Seattle, WA, and online
September 27 September 30	Open Source Summit + Embedded Linux Conference	Seattle, WA, and online
September 28 September 30	Qt Developer Conference [POSTPONED]	Berlin, Germany
September 29 October 1	Linux Security Summit	Seattle, WA, and online
September 30 October 1	Collabora COOL Days 2021	Online
October 2 October 3	MiniDebConf	Regensburg, Germany
October 3 October 9	Fedora Week of Diversity	Online
October 4	LinuxConf [ZA]	Online, South Africa
October 4 October 5	Open Source Strategy Forum London	London, UK
October 5	PostgresConf South Africa	Online, South Africa
October 6	OSPOCon Europe	London, UK
October 7 October 8	PyCon ZA 2021	Online
October 11 October 12	Open Networking & Edge Summit + Kubernetes on Edge Day	Virtual
October 17 October 19	All Things Open	Raleigh, NC, and virtual
November 3	Qt World Summit 2021	Online
November 5 November 6	Seattle GNU/Linux conference	Online
November 9 November 10	Open Source Strategy Forum New York	New York, NY, USA
November 9 November 10	PackagingCon 2021	Online
November 10 November 12	Meeting C++ 2021	Online
November 17	SQLite & Tcl virtual conference	Online

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

Alert summary September 16, 2021 to September 22, 2021

Dist.	ID	Release	Package	Date
CentOS	CESA-2021:3498	C7	firefox	2021-09-16
CentOS	CESA-2021:3494	C7	thunderbird	2021-09-16
Debian	DLA-2759-1	LTS	gnutls28	2021-09-17
Debian	DLA-2762-1	LTS	grilo	2021-09-21
Debian	DLA-2760-1	LTS	nettle	2021-09-18
Debian	DSA-4974-1	stable	nextcloud-desktop	2021-09-19
Debian	DLA-2761-1	LTS	openssl1.0	2021-09-18
Debian	DLA-2758-1	LTS	sssd	2021-09-15
Debian	DSA-4975-1	stable	webkit2gtk	2021-09-21
Debian	DSA-4976-1	stable	wpewebkit	2021-09-21
Debian	DSA-4977-1	stable	xen	2021-09-20
Fedora	FEDORA-2021-c5584b92d4	F34	curl	2021-09-21
Fedora	FEDORA-2021-e5f64ca6ce	F34	dovecot-fts-xapian	2021-09-20
Fedora	FEDORA-2021-8093e197f4	F34	drupal7	2021-09-19
Fedora	FEDORA-2021-450c33d2a6	F33	firefox	2021-09-21
Fedora	FEDORA-2021-256c80b4eb	F34	ghostscript	2021-09-20
Fedora	FEDORA-2021-cd5ee418f6	F33	haproxy	2021-09-17
Fedora	FEDORA-2021-3493f9f6ab	F34	haproxy	2021-09-16
Fedora	FEDORA-2021-db6fb33b05	F33	libtpms	2021-09-19
Fedora	FEDORA-2021-bd49accf09	F34	libtpms	2021-09-15
Fedora	FEDORA-2021-232161e4d5	F33	lynx	2021-09-20
Fedora	FEDORA-2021-9f020cf155	F33	mingw-python-pillow	2021-09-21
Fedora	FEDORA-2021-cbfaefb390	F34	mingw-python-pillow	2021-09-21
Fedora	FEDORA-2021-9f020cf155	F33	python-pillow	2021-09-21
Fedora	FEDORA-2021-cbfaefb390	F34	python-pillow	2021-09-21
Fedora	FEDORA-2021-9f020cf155	F33	python2-pillow	2021-09-21
Fedora	FEDORA-2021-4a43cbe0b4	F33	vim	2021-09-15
Fedora	FEDORA-2021-c00e45b6c0	F34	webkit2gtk3	2021-09-21
Fedora	FEDORA-2021-f53d1bbf50	F33	wordpress	2021-09-17
Fedora	FEDORA-2021-9d5bbdae5b	F34	wordpress	2021-09-16
Fedora	FEDORA-2021-fed53cbc7d	F33	xen	2021-09-17
Fedora	FEDORA-2021-11577e5229	F34	xen	2021-09-16
openSUSE	openSUSE-SU-2021:1277-1	15.2	apache2-mod_auth_openidc	2021-09-16
openSUSE	openSUSE-SU-2021:1300-1	SLE15.3	chromium	2021-09-22
openSUSE	openSUSE-SU-2021:1274-1	15.2	fail2ban	2021-09-16
openSUSE	openSUSE-SU-2021:1273-1	15.2	ghostscript	2021-09-16
openSUSE	openSUSE-SU-2021:3175-1	15.3	grafana-piechart-panel	2021-09-21
openSUSE	openSUSE-SU-2021:1279-1	15.2	haserl	2021-09-16
openSUSE	openSUSE-SU-2021:1271-1	15.2	kernel	2021-09-15
openSUSE	openSUSE-SU-2021:3179-1	15.3	kernel	2021-09-21
openSUSE	openSUSE-SU-2021:1294-1	15.2	libcroco	2021-09-21
openSUSE	openSUSE-SU-2021:3123-1	15.3	libcroco	2021-09-17
openSUSE	openSUSE-SU-2021:1275-1	oSB SLE15	nextcloud	2021-09-16
openSUSE	openSUSE-SU-2021:1289-1	15.2	php-composer	2021-09-21
openSUSE	openSUSE-SU-2021:1267-1	15.2	php7-pear	2021-09-15
openSUSE	openSUSE-SU-2021:1276-1	15.2	wireshark	2021-09-16
openSUSE	openSUSE-SU-2021:1301-1	15.2	xen	2021-09-22
openSUSE	openSUSE-SU-2021:3140-1	15.3	xen	2021-09-18
Oracle	ELSA-2021-3582	OL8	curl	2021-09-21
Oracle	ELSA-2021-9452	OL7	kernel	2021-09-21
Oracle	ELSA-2021-9452	OL7	kernel	2021-09-21
Oracle	ELSA-2021-9450	OL7	kernel	2021-09-16
Oracle	ELSA-2021-3548	OL8	kernel	2021-09-15
Oracle	ELSA-2021-9450	OL8	kernel	2021-09-16
Oracle	ELSA-2021-9450	OL8	kernel	2021-09-16
Oracle	ELSA-2021-9451	OL7	kernel-container	2021-09-16
Oracle	ELSA-2021-9451	OL8	kernel-container	2021-09-16
Oracle	ELSA-2021-3572	OL8	nss and nspr	2021-09-21
Red Hat	RHSA-2021:3582-01	EL8	curl	2021-09-21
Red Hat	RHSA-2021:3585-01	EL8	go-toolset:rhel8	2021-09-21
Red Hat	RHSA-2021:3576-01	EL8	krb5	2021-09-21
Red Hat	RHSA-2021:3590-01	EL8	mysql:8.0	2021-09-21
Red Hat	RHSA-2021:3623-01	EL8	nodejs:12	2021-09-21
Red Hat	RHSA-2021:3639-01	EL8.1	nodejs:12	2021-09-22
Red Hat	RHSA-2021:3638-01	EL8.2	nodejs:12	2021-09-22
Red Hat	RHSA-2021:3572-01	EL8	nss and nspr	2021-09-21
Red Hat	RHSA-2021:3559-01	SCL	rh-ruby27-ruby	2021-09-20
Slackware	SSA:2021-264-01		alpine	2021-09-21
Slackware	SSA:2021-258-01		curl	2021-09-15
Slackware	SSA:2021-259-01		httpd	2021-09-16
SUSE	SUSE-SU-2021:3117-1	SLE12	Mesa	2021-09-16
SUSE	SUSE-SU-2021:3121-1	SLE12	crmsh	2021-09-17
SUSE	SUSE-SU-2021:3180-1	OS8 OS9 SLE12	ghostscript	2021-09-21
SUSE	SUSE-SU-2021:3174-1	SES6	grafana-piechart-panel	2021-09-21
SUSE	SUSE-SU-2021:3125-1	OS8 OS9 SLE12	gtk-vnc	2021-09-17
SUSE	SUSE-SU-2021:3179-1	SLE15	kernel	2021-09-21
SUSE	SUSE-SU-2021:3177-1	SLE15	kernel	2021-09-21
SUSE	SUSE-SU-2021:3178-1	SLE15	kernel	2021-09-21
SUSE	SUSE-SU-2021:14800-1	SLE11	libcroco	2021-09-17
SUSE	SUSE-SU-2021:3123-1	SLE15	libcroco	2021-09-17
SUSE	SUSE-SU-2021:3144-1	OS8 SLE12	openssl	2021-09-20
SUSE	SUSE-SU-2021:14802-1	SLE11	openssl	2021-09-18
SUSE	SUSE-SU-2021:14801-1	SLE11	openssl1	2021-09-18
SUSE	SUSE-SU-2021:3119-1	SLE12	postgresql12	2021-09-17
SUSE	SUSE-SU-2021:3120-1	SLE12	postgresql13	2021-09-17
SUSE	SUSE-SU-2021:3124-1	OS8 OS9 SLE12	transfig	2021-09-17
SUSE	SUSE-SU-2021:3181-1	SLE12	xen	2021-09-21
SUSE	SUSE-SU-2021:3140-1	SLE15	xen	2021-09-18
SUSE	SUSE-SU-2021:3141-1	SLE15	xen	2021-09-18
Ubuntu	USN-5079-4	14.04 16.04	curl	2021-09-21
Ubuntu	USN-5079-3	18.04	curl	2021-09-21
Ubuntu	USN-5080-2	16.04	libgcrypt20	2021-09-16
Ubuntu	USN-5080-1	18.04 20.04 21.04	libgcrypt20	2021-09-16
Ubuntu	USN-5086-1	16.04 18.04 20.04 21.04	linux, linux-hwe, linux-hwe-5.11, linux-hwe-5.4	2021-09-22
Ubuntu	USN-5073-2	16.04 18.04	linux-gcp, linux-gcp-4.15	2021-09-16
Ubuntu	USN-5071-2	18.04	linux-hwe-5.4	2021-09-16
Ubuntu	USN-5082-1	20.04	linux-oem-5.13	2021-09-16
Ubuntu	USN-5071-3	18.04 20.04	linux-raspi, linux-raspi-5.4	2021-09-21
Ubuntu	USN-5073-3	18.04	linux-raspi2	2021-09-21
Ubuntu	USN-5083-1	14.04 16.04	python3.4, python3.5	2021-09-16
Ubuntu	USN-5081-1	18.04	qtbase-opensource-src	2021-09-16
Ubuntu	USN-5078-2	16.04	squashfs-tools	2021-09-15
Ubuntu	USN-5084-1	20.04	tiff	2021-09-21

Full Story (comments: none)