Welcome to the LWN.net Weekly Edition for February 10, 2022

This edition contains the following feature content:

• Raw photo editing with RawTherapee: an in-depth look at another free tool for raw-image processing.
• What's coming in Go 1.18: the next Go major release has some significant new language features.
• Stray-write protection for persistent memory: a proposal to use an Intel CPU feature to prevent accidental or malicious corruption of data in persistent memory.
• A memory allocator for BPF code: why does BPF need a special-purpose memory allocator?
• PinePhone: trying out a Linux-based smartphone: what sort of experience does a phone running a "real Linux distribution" offer?

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)

Raw photo editing with RawTherapee

Digital photography opens up a whole new world of photo postprocessing opportunities, especially if the photographer uses their camera's raw format to take advantage of all of the data collected by the sensor. On the other hand, using raw images means doing without all of the processing done by the camera and taking on a range of complex tasks. Raw photo editors are designed to work with raw images as a key part of a photographer's workflow. Your editor recently reviewed the darktable editor, but there are other options available in the free-software community. RawTherapee is a GPLv3-licensed raw editor that is in some ways simpler than darktable — but that is not the same as saying that it is simple.

Superficially, RawTherapee looks a lot like darktable. The initial view is called the "file browser"; like darktable's "light table", it allows the user to import images into the application, add star ratings, and choose an image to edit. There are options to filter images in a number of ways, including by aperture and shutter speed, or by the lens that was used to take them. The right sidebar can also be turned into an inspection window for quickly looking at images using a 1:1 pixel ratio to check for focus.

As an experiment in processing photos with RawTherapee, your editor used the file browser to choose the image shown below, taken on a recent outing above town. Once again, this photo is anything but a great work of art, but it does show the kind of problems that a raw editor can address. The image contains a lot of contrast, and the mountains in the background are somewhat overexposed — an ongoing hazard when photographing scenes with snow in them — while the foreground is dark. What is shown here is the image as produced by the camera; what can be done to improve it?

The editor window will also look familiar to anybody who has seen darktable, with the image being edited taking the center part of the screen. The left column contains a "history stack" tracking image operations and allowing them to be undone, along with an overall image view and the color histogram. On the right is a set of tabs providing access to the many things that can be done to the image.

Certain aspects of interaction with RawTherapee can be annoying at times. It seems necessary to repeatedly remind the application that it would be nice to see the whole image at the largest size that fits within the window, for example. The "crop frame" tool (which, for whatever reason, lives above the editing area rather than with the rest of the cropping controls) makes it easy to draw the frame, but a naive attempt to move the frame drags the whole image within the window instead. To move the frame, the user must hold down the shift key, which is not readily discoverable without going in and reading the manuals. It's all stuff that one can get used to over time, but it slows down the process of learning how to use the tool.

One other, highly subjective impression is that RawTherapee is relatively slow to carry out its operations. Many changes are accompanied by significant delays in a way that happens less with darktable. To compound things, it is not always obvious when RawTherapee is working, so one ends up wondering if an intended change simply had no effect, or instead the application just hasn't managed to show it yet.

On the other hand, the two-pane (shown below) view helps the editing task considerably by making it easy to see the image both before and after a set of changes. A set of tweaks that may seem like a good idea on their own may look different when compared to the previous version of the image. There is also a "snapshot" capability that can be used to save the state of the work at any point.

This is as good a point as any to mention that, like darktable, RawTherapee is a non-destructive editor. The original raw image is never modified; instead, a list of changes is saved to a "sidecar" file and played back as needed. It is nice to know that there is nothing one can do in the editor to wreck the original images — other than deleting them outright in the file-browser view, of course.

Back to editing

RawTherapee does an interesting thing when an image is first pulled into the editor: it tweaks a number of settings to make the image look as similar as possible to the one produced by the camera itself. This includes obvious adjustments like setting the white balance to the value selected by the camera; just about any raw editor will do that. But RawTherapee also, according to the documentation, scans the JPEG image that the camera creates (and stashes inside the raw image) and sets its tone-mapping parameters accordingly. The documentation also says that this process may fail, though your editor did not see that happen. It does help to bring up the editor in a reasonable starting state, especially for users who are not deeply familiar with the process of processing raw images.

Darktable has its "pixelpipe" abstraction with processing modules that can be added and removed in any order. RawTherapee takes a simpler view; it provides an extensive set of processing options, but there is no visibility into (or control over) the order in which they are applied. It is not possible to apply any given process more than once. For a raw-editing neophyte like your editor, this is likely to make little difference, but it does feel like a less flexible system.

Editing a raw image follows the usual steps, starting with setting the white balance and exposure levels. The pointer can be used to set the white balance by clicking on a white (or neutral gray) pixel in the image; taking pictures with snow in them helps greatly with this process, so you editor suggests including some snow in all photographs. This mode remains active thereafter, though; it is easy to click on some other part of the image later on and throw things far out of balance. That is a bit disconcerting the first time it happens, but is also easily recovered from.

From there, most of the expected processing operations are available and can be turned on as needed. These include adjusting the tone mapping, playing with contrast and saturation, sharpening, perspective adjustment, haze removal, and much more. The tools all have lots of options that can be tweaked, naturally; it can be a bit overwhelming at times. Some changes can require going back to rethink decisions made in the earlier steps; it is not always clear when adjusting one operation will have effects on the others. Raw editors, it seems, all require a certain amount of time and dedication to learn how to use them well.

One feature that RawTherapee lacks is the ability to limit the operation of tools with masks. The flexible mask mechanism in darktable makes it possible to apply different processing options to different parts of the image. One might well argue that one should employ a more advanced image-editing tool for such tasks, leaving the raw editor to focus on the specifics of processing raw images. But there are times that this kind of flexibility is useful.

For more run-of-the-mill tasks, though, RawTherapee can get the job done relatively easily. Your editor pulled in the image above, tweaked the white balance slightly, changed the tone mapping to bring out more detail in the trees, applied a haze filter, and cropped the result to end up with the image to the right. This picture is still not a great work of art, but it does show why one might want to work with raw images rather than accepting the camera's idea of what the best picture would be. Turning a raw image into something that can be displayed on a monitor or printed involves throwing away a fair amount of information; the camera may not always make the right choices about what is important and what is not.

Community and conclusion

RawTherapee is mostly written in C++; it uses the the GTK toolkit for its user interface. The most recent release is 5.8, which came out almost exactly two years ago; the project has seen 2,264 commits since that date. This project is moving more slowly than darktable (8,357 commits and several releases in just over two years) and seems to be getting slower over time (only four small commits in 2022 as of this writing), but it is still somewhat active. Its developer base is relatively small, though; a total of 35 developers have contributed since 5.8, and one developer, Jacques Desmis, contributed 1,412 (62%) of the post-5.8 changes.

Whether things will pick up is not at all clear. This GitHub issue, opened in February 2020, reflects an ongoing desire to get a beta 5.9 release out, but it never seems to happen. There does not appear to be an active leader who can put the time into pulling a release together. Desmis, the project's primary contributor, says directly that he should not be counted on to drive the project forward: "I am old (soon 75 years old) and my health is poor". Clearly, if RawTherapee is to be an active project again, somebody is going to have to step up and bring some new energy to it.

That could well happen. RawTherapee is a solid editor that is, in many ways, more approachable than darktable. It could be a solid base on which a future developer could implement a new generation of photo-processing tools. The documentation is reasonably good — a requirement for a program of this complexity. On the surface, at least, there do not appear to be severe shortcomings that would require fixing before moving RawTherapee forward.

Without some new energy, instead, this project is at risk of falling into disrepair, which would be a shame. Many photographers feel the need to use proprietary software to do their work, but it does not have to be that way; the free-software community offers a number of alternatives. But photographers who depend on their tools will be reluctant to invest the time required to master a complex tool like RawTherapee if it appears to have an uncertain future. RawTherapee seems like too good a tool to lose; hopefully some energetic developers will materialize with an interest in keeping it going.

Comments (5 posted)

What's coming in Go 1.18

Go 1.18, the biggest release of the Go language since Go 1.0 in March 2012, is expected to be released in February. The first beta was released in December with two features which, each on their own, would have made the release a big one. It adds support for generic types and native support for fuzz testing. In the blog post announcing the beta, core developer Russ Cox emphasized that the release "represents an enormous amount of work".

Generic types

Go is a statically typed language. Functions and methods in Go may be declared to take any number of arguments and may return any number of values, though all arguments and return values must be declared to have a concrete type.

To give an example, say that we want a function to find the minimum of two arguments of type float32. The standard library's math.Min() function only allows float64 types, as there is no type promotion in Go. A user in need of a min() function for another type must therefore write it or import it from a package that is not in the standard library. So we must define a min() function for float32 values. In Go, this may be written as:

    func min(x float32, y float32) float32 {
	if x < y {
	    return x
	}
	return y
    }

If we want a function to get the minimum of two int values, we need to create yet another function.

However, starting from Go 1.18, functions in Go can accept generic types, which are described by a type parameter list specifying the permissible types for the arguments and return value:

    func min[T float32 | float64 | int](x T, y T) T {
	if x < y {
	    return x
	}
	return y
    }

This means that a function does not need to specify concrete types for its arguments or return values, but may rather specify type parameters (T in the example) for these in a type parameter list, which is in square brackets above. Each type parameter has a corresponding type constraint, which is an interface that specifies the possible type arguments for the type parameter. The permissible types comprise the type parameter's type set.

The type parameter list is surrounded by square brackets, so that it is easy to visually distinguish it from the parameter list, which is surrounded by parentheses. The valid types for a type parameter are delimited by "|" and multiple type parameters are delimited by commas.

This allows defining a generic min() that works for more than one concrete type. Above, we specified that min() takes a type parameter T which is constrained to be one of the types float32, float64, or int. The function takes two arguments, as before. These must be of the same concrete type; the return type is also the same concrete type. In other words, the program would not compile if we attempted to call min() with x being a float32 and y being a float64.

Instead of specifying the types inline, a developer can specify them as an interface:

    type ordered interface {
	float32 | float64 | int
    }
    func min[T ordered](x T, y T) T {
	if x < y {
	    return x
	}
	return y	
    }

Go has more than just these types that have an inherent ordering, such as other numeric types and string. Initially, a new package (constraints) was added to the standard library for 1.18, which defined various interfaces for types that can be ordered, but the package has since been removed due to some questions about its suitability and its name.

Generic types have been a highly requested feature in Go for many years. There have been multiple language proposals; in 2020 LWN wrote about the history of generics in Go, along with a then-recent proposal by core developers Ian Lance Taylor and Robert Griesemer. This language proposal generated much discussion and in general the reception was positive, so the proposal became a formal language change proposal in August 2021. Go 1.18 implements most of the proposal, although some things are kept out of scope for this release. In the initial proposal, the type parameter list was marked with parentheses; that was changed to square brackets before being added to the language.

Many popular, statically typed languages, such as Java, C#, and C++, have generic types or something similar. Go is a decidedly small language, in terms of language features, so it is perhaps not surprising that generic types have not been part of the language until now.

The recommended way to use a generic function is to let the compiler infer the types if possible. This means to use the function as if it were defined for the concrete types we are using. For instance:

    min(1, 3)

The other way to use a generic function is to instantiate the parameterized function by passing a type argument to the generic function. Here we define a function fmin() for float32 values:

    fmin := min[float32]

We can imagine this works by removing the type parameter list in min() and replacing all instances of T with float32. The compiler now knows that fmin() is a non-generic function: func(float32, float32) float32.

Two new predeclared identifiers have been added that are useful as constraints in type parameter lists:

• any, which is an alias for interface{}, the empty interface. It can be used as a type constraint, but means that the type can be any concrete type. A small set of operations are permitted for the any type.
• comparable, an interface that denotes the set of all types that can be compared using == or !=.

Since the compiler has been modified to support generics, the Go 1.18 compilation speed can be as much as 15% slower than Go 1.17. Improving the speed of the compiler is a goal for Go 1.19. The execution time of the compiled code is not affected.

For more information, the Go team has published a generics tutorial.

Fuzzing

Fuzz testing (fuzzing) is a type of testing that generates random inputs to a program with the goal of finding bugs. Go 1.18 adds native support for fuzz testing via a new flag, -fuzz, passed to the go test command. LWN wrote about fuzzing in Go as well. The fuzzing that is added to Go in 1.18 stems from a 2020 design draft by Go core developer Katie Hockman, which became a formal Go proposal in February 2021. A fuzz test must be in a *_test.go file as a function of the form FuzzXxx(), where Xxx is a capitalized (by convention) name for what is being fuzzed, that has a single *testing.F pointer argument and has no return value. The following program fragment for fuzzing min() will look somewhat similar to other kinds of tests in Go that use its testing framework:

    func FuzzMin(f *testing.F) {
	f.Fuzz(func(t *testing.T, a float64, b float64) {
	    actual := min(a, b)
	    expected := math.Min(a, b)
	    if actual != expected {
		t.Fatalf("min(%f, %f) was %f instead of %f", a, b, actual, expected)
	    }
	})
    }

Fuzz tests can be invoked in fuzzing mode, go test -fuzz=target, where target is a regular expression specifying which fuzz tests to run. The arguments to mutate are those in the function passed to the fuzzing engine's Fuzz() method. That passed function runs the function under test and checks for incorrect results, reporting those via the usual testing framework mechanisms. Fuzz() repeatedly calls the function with mutated arguments.

Go fuzzing uses "coverage-guided fuzzing" to generate new inputs in a way that increases the test coverage. Coverage-guided fuzzing has been used to great effect on many open-source projects. American fuzzy lop (AFL) is the most well-known fuzzer of this type; its website lists more than one 150 projects that it has found a bug in, including Bash, FFmpeg, and the OpenBSD kernel.

Fuzzing starts by picking an input from a seed corpus, which can be populated in code in the fuzz test or with files representing previously failed inputs. Fuzzing mutates the seed input, executes the target with the new input, and collects code coverage for it. If the new input caused a new path to be executed, the input is added to the seed corpus. If the fuzz target fails for a given input, the fuzzing engine writes the inputs that caused the failure to a file in the directory testdata/fuzz/<Name> within the package directory. As mentioned above, this file will also serve as a seed input.

Running fuzz tests may not only find bugs, they can also double as regression tests. Fuzz tests are run much like a unit test by default, using all of the stored test data as input. Each seed corpus entry will be tested against the fuzz target, reporting any failures before exiting. A fuzz test runs until it encounters a failing input or it times out. A fuzz timeout can be set with the -fuzztime flag to go test. The test process can also be interrupted by a signal, of course.

There are some limitations to native Go fuzzing. The arguments to fuzz are limited to the following types in 1.18:

• strings: string, []byte
• signed integers: int, int8, int16, int32/rune, int64
• unsigned integers: uint, uint8/byte, uint16, uint32, uint64
• floats: float32, float64
• booleans: bool

Furthermore, the compiler only supports coverage instrumentation on x86-64 and Arm64 platforms as of 1.18.

As with generics, the Go team has published a fuzzing tutorial, in addition to a new documentation page for fuzzing..

Other changes

Due to Go's compatibility promise, there are no breaking changes to the language in Go 1.18. The compatibility promise is a stated intention that programs written in Go will compile and run for all future versions of Go. However, each Go version typically adds new packages and functions. Two packages are being added in Go 1.18: debug/buildinfo, which provides access to module versions, version-control information, and build flags embedded in the executable built by the go command, and net/netip, which defines a new comparable IP address type, Addr.

There are a number of new functions added to the standard library; one of these seems particularly interesting. strings.Cut() slices a string around a separator. It can replace many common uses of Index() and other similar functions. In the issue proposing it, Cox claimed that out of 285 calls to string.Index() in the Go standard library, "77% of [these] calls are more clearly written using Cut".

The built-in vet linting tool has been updated to detect errors in code using generic functions and types. In most cases, it reports an error in generic code whenever it would report an error in the equivalent non-generic code after substituting for type parameters with a type from their type set. gofmt, which automatically formats Go source code, now reads and formats input files concurrently. This means that gofmt is now significantly faster.

To get the complete picture of everything in Go 1.18, readers are encouraged to seek out the full release notes. Go 1.18 is currently in Beta 2, with a release expected this month. The maintainers will certainly be appreciative of anyone who tries it out and reports any bugs that they find.

Comments (6 posted)

Stray-write protection for persistent memory

Persistent memory has a number of advantages; it is fast, CPU-addressable, available in large quantities and, of course, persistent. But it also, arguably, poses a higher risk of suffering corruption as a result of bugs in the kernel. Protecting against this possibility is the objective of this patch set from Ira Weiny, which makes use of Intel's "protection keys supervisor" (PKS) feature to make it harder for the kernel to inadvertently write to persistent memory.

The stray-write problem

Data stored on rotating or solid-state drives can, normally, only be overwritten with an explicit request issued by the CPU, a complex operation that takes several steps to carry out. Kernel bugs are certainly capable of causing the wrong data to be written to a drive — or the right data to end up in the wrong place — so kernel developers go out of their way to prevent that from happening. On the other hand, the kernel is highly unlikely to accidentally trigger an erroneous write to a storage device when the real objective was, say, to move a process into a new control group or allocate a block of memory. Things can always go wrong, but an error that just happens to go through all of the steps of launching an I/O operation is nearly impossible.

Persistent memory changes that situation. A system can be equipped with terabytes of this memory, all of which may contain important data, and all of which is directly addressable by the CPU. Now all that is required to corrupt that memory is a single write to an incorrect pointer, which is a much more probable sort of bug. The corrupted data could lurk undetected for years before, for example, some poor user discovers that their cryptocurrency wallet has become inaccessible. This kind of corruption seems likely enough that it is worth making an effort to prevent, regardless of how one feels about cryptocurrencies.

An obvious way to protect against this sort of bug would be to set the protections on persistent memory to prevent kernel writes. Those protections would only be changed when the kernel actually needs to write to persistent memory, and only for the duration of the operation. The normal permissions stored in the page tables could accomplish this task, but at a huge performance cost. Changing page-table permissions is expensive; doing so for every persistent-memory write would take away much of the performance gain that justified the use of persistent memory in the first place.

There is another way, though, at least on Intel CPUs. The "memory protection keys" feature allows a four-bit key value to be associated with each page-table entry; there is a per-thread mask that sets the read and write permissions that currently apply to each key. So, for example, that mask might say that all pages marked with key 3 are readable but not writable by the current thread. Changing the mask is not a privileged operation, so protection keys are not a strict security feature, but they can raise the bar for malicious access and prevent accidents. Meanwhile, changing the access mask is a fast operation that can change the accessibility of large number of pages, so it is a far more efficient way to provide this protection than tweaking page permissions.

Protecting persistent memory with PKS

Memory protection keys can be used with any type of memory; one use case, for example, is protecting cryptographic keys in ordinary memory. Linux has supported memory protection keys for user space since the 4.9 release in 2016. But memory protection keys can also be used for the kernel, with a kernel-specific key value associated with each page; memory protection keys for the kernel is also known as PKS. Linux is not currently making use of this capability, though. Thus, the first objective of Weiny's 44-part patch set is to add support for PKS to the kernel, a task that involves a number of little details.

For example, the access-control map for PKS is stored in a model-specific register (MSR), which makes changes relatively fast. That MSR is not automatically saved by the CPU, though, when a thread is preempted, so the kernel has to take care of that detail itself. That involved some detailed changes to the pt_regs structure so that it could hold the extra information without breaking code that might not be expecting it. The new "auxiliary pt_regs" infrastructure can hold the PKS permission mask, along with other information that will surely need to be stored in the future.

There also needs to be a way to allocate the 16 available key values within the kernel. Of those, key 0, which is the default key applied to all pages, must retain the "all access allowed" permissions, so 15 keys remain for other uses. In the current implementation, these keys are allocated statically in the code. That approach will have to change if the kernel runs out of keys, but it is not clear that there will ever be enough users to get to that point. Until that happens, there is little value in adding a more sophisticated key-allocation mechanism, so the static approach prevails. In this patch set, key 1 is reserved for kernel self tests, and key 2 is for stray-write protection.

With that infrastructure in place, it's a relatively straightforward matter to set up persistent-memory pages with the new key, and to set the access permissions to deny writes. That will prevent any stray writes from corrupting the memory, which is good, but will also block legitimate writes, which is not quite as good. So the final step is to change the permissions whenever the kernel needs to write to a persistent-memory page. This is easily enough done in the drivers that deal directly with persistent memory; the appropriate calls can just be inserted before and after the writes are performed. Once again, the change to the permissions mask only applies to the current thread, so no other part of the kernel can write to persistent memory while this operation is underway.

There is a remaining problem, though, in the form of the higher layers of the kernel, which may also need to write to persistent memory. One example is the DAX code within filesystems that allows for the reading and writing of data directly to persistent memory without the need to go through the page cache. Attempts to add the necessary calls around every location that might write to persistent memory seem doomed to failure, so another approach is required.

As it happens, kernel code is already required to make special calls before accessing arbitrary pages of memory. These calls, in the form of kmap() and friends, currently do nothing on most 64-bit systems, but they are needed on 32-bit systems where it is not possible to directly map all of physical memory into the kernel's address space. Weiny's patch set causes the short-term calls (such as kmap_atomic() and kmap_local_page()) to check whether the memory in question is protected by the persistent-memory key. If so, the permissions are changed to allow persistent-memory writes for the duration of the mapping. Long-term mappings (with plain kmap()) of protected persistent memory are not allowed, so the window of opportunity to write to persistent memory is kept small and is limited to the thread that needs it.

This patch set is in its eighth revision and has changed considerably since version 2 was covered here in mid 2020. A number of core developers have had a close look and made comments, resulting in a redesign of much of the functionality. Whether this version will pass muster remains to be seen, but it should be getting closer. The objective seems good; the CPU provides a mechanism that can efficiently detect and prevent accidents, the kernel should make use of it.

Comments (7 posted)

A memory allocator for BPF code

Loading a BPF program into the kernel involves a lot of steps, including verification, permissions checking, linking to in-kernel helper functions, and compilation to the native instruction format. Underneath all of that, though, lies one other simple task: allocating some memory to store the compiled BPF program in the kernel's address space. It turns out that this allocation can be somewhat wasteful of memory in current kernels, especially on systems where large numbers of BPF programs are loaded. This patch set from Song Liu seeks to remedy this problem by introducing yet another specialized memory allocator into the kernel.

The kernel allows BPF programs to be reasonably large, but most of them are, in practice, quite small. BPF can do quite a bit with a few hundred bytes of code space. But the kernel allocates space for BPF programs in units of full base (usually 4KB) pages, with all of the space past the end of each program being wasted for as long as that program remains loaded. For a small program, most of the page allocated to hold the code is unused; if there are many programs loaded, the amount of wasted memory can start to add up.

Liu's patch set adds a new "bpf_prog_pack" allocator to address this problem. It would be, on the surface, one of the simplest memory allocators in the system. It maintains a list of huge pages to hold BPF programs, allocating new ones as needed. Whenever space is needed for a new BPF program, a simple, first-fit algorithm allocates the amount needed. A bitmap associated with each huge page (or "pack") tracks the free space (in 64B chunks), thus automatically coalescing chunks returned to the allocator when programs are unloaded. It is not written for speed, but it does not need to be; even on a system that makes heavy use of BPF, allocation and free operations will be relatively rare.

The advantages of this simple allocator are reasonably clear. Because multiple programs can be packed into a single page, the memory that is wasted due to internal fragmentation will be greatly reduced. Performance will be helped by putting BPF programs into huge pages, which reduces translation lookaside buffer (TLB) pressure. But it is worth asking why yet another allocator is needed when the kernel already has memory-management code that has been extensively developed and tuned over the years. The answer is that BPF brings some special needs that cannot be met with existing allocators.

The problem with using the kernel's page allocator without a subdividing layer has already been described: too much space is wasted. But the kernel's slab allocators have been designed for exactly this task: they take large chunks from the page allocator and pass them out to the rest of the kernel in smaller pieces. So it might be natural to think about using the slab allocator here; Liu does not explain why that was not done, but there are a couple of plausible reasons for this choice.

One reason is that the slab allocators are optimized for the allocation of equal-sized chunks. But there is no one size that fits all for BPF programs, so the simple expedient of using a dedicated slab and kmem_cache_alloc() will not work here. It would be possible to use multiple slabs, of course, either directly within the BPF code or simply by allocating space with kmalloc(), but there would be internal fragmentation issues there (albeit smaller) either way. The power-of-two approach used by kmalloc() would still waste a fair amount of space at the end of each program.

There is a more fundamental problem with using the slab allocator, though. BPF programs are executable code, which must be handled specially. Code requires execute permissions at the page level, meaning that it cannot be intermixed with data (as kmalloc() would do). After all, developers have gone out of their way for years to ensure that data cannot be made executable within the kernel. So the slab allocators, which are meant to manage space for data, are not really suitable for this application.

A certain amount of trickery is required to make the program-packing scheme work, even with the special-purpose allocator. Updating code in a running system is fraught with perils; if a CPU in the system tries to run code while it is being changed, the results tend to be bad. The kernel relies fairly heavily on self-modifying code, so the mechanisms to do this modification safely are there, but the task must still be handled carefully. The inability to write to executable memory in straightforward ways, along with the fact that executable memory in the kernel must be read-only, presents challenges for the JIT compiler.

So when the new allocator is invoked to find a spot for a new program, it actually allocates two buffers. The first is the read-only, executable space where the program is destined to live; the second is ordinary memory obtained with kvmalloc(). The JIT compiler will compile into the second buffer, which can be written to, but any addresses it generates must be relative to the first buffer instead. Once the compilation process is complete, the kernel's "text poke" machinery, enhanced with a new copy function, can be used to move the compiled program into the read-only space and the temporary buffer freed.

This patch set has been through eight revisions as of this writing, with a fair amount of review activity creating a stream of new items to fix. At this point, though, there may not be a whole lot more to change. So it would not be entirely surprising to see this code find its way into 5.18; heavy BPF users should benefit with reduced memory usage and a small performance improvement.

Comments (33 posted)

PinePhone: trying out a Linux-based smartphone

The PinePhone is a Linux-based smartphone made by PINE64 that runs free and open-source software (FOSS); it is designed to use a close-to-mainline Linux kernel. While many smartphones already use the Linux kernel as part of Android, few run distributions that are actually similar to those used on desktops and laptops. The PinePhone is different, however; it provides an experience that is much closer to normal desktop Linux, though it probably cannot completely replace a full-featured smartphone—at least yet.

Goals

For several years, the only major options in the smartphone market have been Android and iOS. Android is an open-source operating system, but virtually all Android devices come with significant amounts of proprietary code; iOS is almost completely proprietary. Many Android phones and all iPhones have locked bootloaders, preventing the user from replacing the operating system.

Many phones are also carrier-locked, preventing the user from switching cell carriers without the approval of the one through which they purchased the phone. Few devices give the user root access without making modifications to the software and possibly voiding the warranty in the process. Overall, while the purchaser may legally own the device, in many ways it remains in the control of the manufacturer and often the carrier. Previous attempts at developing open-source smartphones have either failed or produced expensive devices.

PINE64 has been making various FOSS-friendly electronic devices for several years. The company originally made single-board computers (SBCs), and later developed devices such as laptops and tablets. One of its most popular devices, however, is the PinePhone, which is designed to promote mobile Linux distributions as an alternative to Android and iOS. The phone allows the user to install any compatible operating system, and it is not locked to a particular carrier. Instead, it is designed to give the user as much control as possible.

Distributions

Many distributions are available for the PinePhone, including DanctNIX (an unofficial spin of Arch Linux Arm for PINE64 phones and tablets), Manjaro Arm Mobile, Mobian (Debian for phones), postmarketOS (based on Alpine Linux), and Ubuntu Touch. Some of these, such as postmarketOS and Ubuntu Touch, were originally designed to be installed as custom ROMs on Android smartphones; others were developed specifically for the PinePhone and other Linux phones. All of these distributions, with the exception of Ubuntu Touch, are basically desktop Linux distributions with custom "desktop" environments designed for phones. (Ubuntu Touch is different in several ways, including a read-only root filesystem.)

There are also several mobile-friendly desktop environments available. The most popular are Phosh (similar to and partially based on GNOME, note that the Wikipedia article has more information than the project's sparse home page), KDE Plasma Mobile, and Sxmo (a minimalist environment based on a tiling window manager). Phosh and Plasma Mobile use Wayland, while Sxmo uses either X11 or Wayland. It is also possible to use regular desktop environments such as GNOME and Xfce, although they may not be usable with the phone's touchscreen.

So far, I have tested DanctNIX with Phosh. I still use my Android phone because of the PinePhone's limited app support and slow processor, but the user interface is usable and most of the basic phone features are present. Functions such as calling and texting work fine. MMS is supported, but most if not all distributions require the installation of extra FOSS components to use it. Once I installed the extra software and made some carrier-specific settings, MMS worked well, so group chats and sending pictures from the default Chatty app are possible.

Basic apps such as weather, calendar, and clock are also available, though alarms do not work if the phone is sleeping. I have not found an email client that works well, but webmail interfaces typically work fine in Firefox on the phone. YouTube worked well at 360p with occasional pauses on both WiFi and LTE in Firefox.

Pure Maps is an OpenStreetMap-based map app for Linux. I tried it briefly, and did not try to navigate with it, but the GPS worked. The interface seemed user-friendly, although it is written using Qt, so its interface did not match Phosh's GTK-based interface. Pure Maps is not available in the Arch Linux Arm repositories, so I had to use a Flatpak to install it.

Because Linux smartphones have a smaller ecosystem, there are far fewer apps available for Linux phones than for Android and iOS. Since iOS is a closed platform, it is not possible to run iOS apps on the PinePhone; however, Android's core is open source, making it feasible to run many Android apps on the PinePhone.

So far, three projects support this: GloDroid, Anbox, and Waydroid. GloDroid is an Android distribution that supports the PinePhone. Development seems to have stalled, however, and I did not test it. Anbox and Waydroid are compatibility layers for running Android apps on normal Linux distributions. They both work by running the Android user space in a container. Waydroid is the more popular choice, mainly because it has better performance than Anbox. Many apps, including some lightweight games, work well in Waydroid.

The only major issue I have noticed is that Waydroid does not support changing the screen size. If the phone is rotated, only part of the Android UI is visible until the phone is rotated back to the previous position. It is also important to make sure the on-screen keyboard is not visible when launching Waydroid; if it is, Waydroid will leave the space occupied by the keyboard empty.

Specifications and performance

The PinePhone has a 151mm (5.95in.) diagonal, 1440x720 capacitive touchscreen. The Allwinner A64 system-on-chip running the phone contains a quad-core, 64-bit Arm CPU. The phone comes in two models; the one I purchased has 3GB RAM and 64GB eMMC; the other model has 2GB RAM and 32GB eMMC. The 3GB model costs $200, while the 2GB one costs $150. Both models can use (and boot from) a microSD card of up to 2TB in size.

The phone boots from the microSD card if a bootable card is found. This is helpful when making changes to important parts of the operating system, because it makes the phone almost unbrickable. It is possible to brick the cell modem, but accidentally doing so is highly unlikely unless you try to reflash the proprietary modem firmware.

The PinePhone, like most smartphones until fairly recently, has two cameras: one front "selfie" camera and one rear camera. The front camera has a 2 megapixel (MP) sensor, while the rear camera has a 5MP sensor. Currently, the front camera takes poor-quality pictures that usually have a green tint and are often severely out of focus, while the rear camera seems comparable to that of an inexpensive Android smartphone. However, improvements to the postprocessing software are likely to significantly improve image quality in the future. Both cameras on my PinePhone have several dead pixels, but they are not noticeable in most pictures. The rear camera has an LED flash which also functions as a flashlight.

For me, using DanctNIX with Phosh with intermittent light use, the PinePhone's battery lasts for almost a whole day. Of course, this will vary with different distributions and workloads. I usually charge it occasionally throughout the day, but I could probably use it for a full day without charging if I reduced the screen brightness and/or used the phone less often.

The hardware supports WiFi, Bluetooth, and cellular (2G GSM, 3G UMTS, and 4G LTE). WiFi works as expected; it can connect to networks just like any other phone or computer, though only 2.4 GHz is supported. For me, 4G LTE voice, SMS, MMS, and data work fine. I use it with a T-Mobile-compatible Tracfone SIM card. Unfortunately, some carriers are not compatible with the PinePhone. It is best to check the carrier support page on the PINE64 wiki. Bluetooth audio output works well for playing music (both from MP3s stored on the phone and streaming over the Internet). I have not tested it for calls, nor have I tested audio input.

Security and privacy

The PinePhone's security is comparable to that of a Linux laptop with Secure Boot disabled. Apps are not containerized or isolated by default, but normal Linux security mechanisms apply. There have been some reports of PinePhone-specific malware, but avoiding software from unknown sources is a good way to protect against that kind of problem, as with desktop Linux. Most distributions optionally support full-disk encryption, as well, to protect phone data when the phone is turned off.

Privacy with a PinePhone is also basically the same as with a Linux desktop or laptop. Carriers can obtain approximate location information from cell tower triangulation, but this is inherent in the design of cellular networks and cannot be prevented by the phone other than by disconnecting from the cell network.

The phone does have several hardware privacy switches, found behind the battery cover. They can be used to disable the cellular modem and GPS receiver, WiFi/Bluetooth chip, microphone, and cameras. With the cellular/GPS and WiFi/Bluetooth switches turned off, it should be nearly impossible for the phone to be tracked by normal means. But, of course, virtually all electronic devices, even those with no communication hardware, produce radio-frequency emissions that could conceivably be tracked; other methods of tracking may also be possible.

Regular desktop web browsers are used, so any web trackers would work on a PinePhone just like they would on a desktop or laptop. However, because desktop browsers are used, extensions such as uBlock Origin and Privacy Badger work well.

Convergence

One of the features that I found most useful is convergence: the ability to use the phone as a desktop computer. The 3GB edition comes with a USB-C docking bar, which provides two USB-A ports, one HDMI output port, and one Ethernet port. It also includes a USB-C port for charging the phone. The dock can be purchased separately, presumably for use with the 2GB model. Alternatively, any USB-C hub that supports USB-C DisplayPort alt mode and has HDMI output should be compatible, although one without the ability to charge the phone from the hub would not be recommended due to the increased power usage while docked.

Any programs that are open on the phone screen can be easily moved to the monitor and vice versa. The video occasionally briefly disconnects and then comes back, but overall it works reasonably well; that problem may be due to the inexpensive TV I used as a monitor. Because all features of the phone still work, it is possible to send and receive text messages. Calling should also work, but because several cables are connected to the phone, using speakerphone or an external headset is probably necessary.

Development

Developing for the PinePhone is not much different from developing for any other 64-bit Arm device running Linux, such as a Raspberry Pi. Of course, applications must be designed to support small screens and touch input. Many desktop programs work fine with only scaling adjustments; others need more substantial changes.

GTK applications can use libhandy (for GTK 3) of libadwaita (for GTK 4) for improved mobile device compatibility. Qt apps can use Kirigami. A list of mobile Linux applications, LINMOBapps, is useful for both users and developers; for users, it is a way to find applications that run on the PinePhone; for developers, it is a way to find mobile Linux projects to contribute to.

Accessories and other devices

PINE64 has also created a new phone, the PinePhone Pro, which features a faster processor and increased RAM and eMMC compared to the original PinePhone. The PinePhone Pro costs $399; it is currently even more experimental than the PinePhone, so it is still mostly a developer device.

Several add-on devices for the PinePhone are available. These replace the phone's back cover, adding features such as wireless charging, fingerprint sensing, or an external hardware keyboard. The keyboard basically converts the phone into a small laptop and adds battery capacity to the device. It is important to note that the keyboard interferes with using the phone as a handset and with the convergence feature, so users who need those may be better off without it. More common accessories, such as cases and a screen protector, are also available, as well as development-focused devices such as a serial console adapter.

The PINE64 smartphones are not the only Linux phones available. Some models of Android phones can run regular Linux distributions in the form of custom ROMs, as mentioned earlier. There have also been previous attempts at creating FOSS-oriented smartphones, such as Openmoko. Purism has developed the Librem 5 Linux-based smartphone, but there have been long shipping delays with it. Also, the price tag ($1,199 for the base model, or $1,999 for the made-in-USA model) may discourage many potential customers from ordering the Librem 5.

Pine Store Ltd., which is the company that makes and sells PINE64 products, only makes hardware; the software is developed by the PINE64 community. The community is also involved in the design of the hardware, however. The PINE64 Philosophy page describes it this way:

A simplistic point of view, often offered up and referenced online, is that 'PINE64 does hardware while the community does the software'. While this depiction is not inaccurate, it is also a gross oversimplification. The fact that PINE64 is community driven doesn't simply entail a one-way reliance on the community or partner projects for software support; it means that the community gets to actively shape the devices, as well as the social platform, of PINE64 from the ground up.

Beyond just SBCs, phones, tablets, and laptops, Pine Store also makes devices such as an IP camera (PineCube) and a smartwatch (PineTime). All of these devices run almost exclusively FOSS by default as well.

In conclusion

The PinePhone is definitely different from most smartphones. It is closer in many ways to a regular Linux computer than to an Android smartphone or an iPhone. Having experience with Linux and a willingness to ignore some rough edges will both help in getting the most out of it, but it may be a good idea to keep another phone around for times when the PinePhone does not live up to the full smartphone experience that people have come to expect. For Linux users willing to ignore or work around these problems, the PinePhone is a device with a lot of potential.

Comments (120 posted)

Huang: The Plausibly Deniable DataBase

Andrew 'bunnie' Huang introduces PDDB, a database meant to allow users to (plausibly) deny the existence of specific data within it.

Precursor is a device we designed to keep secrets, such as passwords, wallets, authentication tokens, contacts and text messages. We also want it to offer plausible deniability in the face of an attacker that has unlimited access to a physical device, including its root keys, and a set of “broadly known to exist” passwords, such as the screen unlock password and the update signing password. We further assume that an attacker can take a full, low-level snapshot of the entire contents of the FLASH memory, including memory marked as reserved or erased. Finally, we assume that a device, in the worst case, may be subject to repeated, intrusive inspections of this nature.

We created the PDDB (Plausibly Deniable DataBase) to address this threat scenario.

Comments (17 posted)

Security quote of the week

Adding knobs to disable features for unactionable security concerns gives a feel good in terms of security theatre, but it causes system unpredictability in that any given application now has to check if a feature is usable before it uses it and figure out what to do if it isn't available. The more we do it, the bigger the combinatoric explosion of possible missing features and every distro ends up having a different default combination.

The bottom line is it's much better to find and fix actual security bugs than create a runtime configuration nightmare.

— James Bottomley

Comments (none posted)

Kernel release status

The current development kernel is 5.17-rc3, released on February 6. Linus said: "Things look fairly normal so far, with a pretty average number of commits for an rc3 release".

Stable updates have, once again, been readily available this week. 4.4.302, the final 4.4.x release, started the flood on February 3. Thereafter, we saw 5.16.6, 5.15.20, 5.10.97, and 5.4.177 on February 5, but a problem was reported almost immediately after those releases, leading to the reversion of a broken patch and the subsequent releases of 5.16.7, 5.15.21, and 5.10.98. The 5.16.8, 5.15.22, 5.10.99, 5.4.178, 4.19.228, 4.14.265, and 4.9.300 releases then came out on February 8.

The (tiny) 5.16.9, 5.15.23, 5.10.100, 5.4.179, 4.19.229, 4.14.266, and 4.9.301 updates are in the review process; they are due on February 11.

Comments (none posted)

Slackware 15 released

Version 15 of the venerable Slackware distribution has been released.

The challenge this time around was to adopt as much of the good stuff out there as we could without changing the character of the operating system. Keep it familiar, but make it modern. And boy did we have our work cut out for us. We adopted PAM (finally) as projects we needed dropped support for pure shadow passwords. We switched from ConsoleKit2 to elogind, making it much easier to support software that targets that Other Init System and bringing us up-to-date with the XDG standards. We added support for PipeWire as an alternate to PulseAudio, and for Wayland sessions in addition to X11.

A bit more information can be found in the release notes. Many of us got our start with Slackware; it is good to see that it's still out there and true to form.

Comments (38 posted)

Qubes OS 4.1.0 released

Version 4.1.0 of the secure-desktop-oriented Qubes OS distribution has been released. "The culmination of years of development, this release brings a host of new features, major improvements, and numerous bug fixes". New features an experimental GUI domain separate from dom0, the "Qrexec" policy system, progress toward a reproducible build, and more. See below and this article for more information.

Full Story (comments: none)

Distributions quote of the week

If the [Debian] project continues to believe that it is of primary importance for us to be the copyright notice and license catalog review system for the entire free software ecosystem (which is honestly what it feels like we've currently decided to volunteer to do on top of our goal of building a distribution), then I will do my part with the packages that I upload so that I don't put unnecessary load on the folks doing NEW review. But when we've collectively been doing something for so long, we can lose track of the fact that it's a choice, and other choices are possible. It's worth revisiting those choices consciously from time to time.

— Russ Allbery

Comments (none posted)

GNU Binutils 2.38 released

Version 2.38 of the GNU Binutils tool set has been released. Changes include new hardware support (including for the LoongArch architecture), various Unicode-handling improvements, a new --thin option to ar for the creation of thin archives, and more.

Full Story (comments: 1)

GNU C Library 2.35 released

Version 2.35 of the GNU C Library has been released. New features include Unicode 14.0.0 support, support for the C.UTF-8 locale, a bunch of new math functions, support for restartable sequences, and much more; see the announcement for details.

Comments (6 posted)

GStreamer 1.20.0 released

Version 1.20.0 of the GStreamer multimedia system is out. Changes include a new high-level playback library replacing GstPlayer, decoding support for WebM Alpha, updated Rust bindings, and more; see the announcement for lots of details.

Comments (none posted)

Plasma 5.24 released

Version 5.24 of the KDE-based Plasma desktop is out; this is a long-term-support release. Changes include various task-manager improvements, a new overview mode, fingerprint-reader support, improved Wayland support, and more.

Comments (10 posted)

Ryabitsev: Cross-fork object sharing in git (is not a bug)

This is a few days old, but evidently there is still need for this message: Konstantin Ryabitsev explains how it is easy to cause a commit to appear falsely to be part of a GitHub repository:

With all the benefits of object sharing comes one important downside — namely, you can access any shared object through any of the forks. So, if you fork linux.git and push your own commit into it, any of the 41.1k forks will have access to the objects referenced by your commit. If you know the hash of that object, and if the web ui allows to access arbitrary repository objects by their hash, you can even view and link to it from any of the forks, making it look as if that object is actually part of that particular repository (which is how we get the links at the start of this article).

A failure to understand this point is how the net fills up with articles like this one.

Comments (55 posted)

CFP Deadlines: February 10, 2022 to April 11, 2022

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

Deadline	Event Dates	Event	Location
February 13	April 20 April 22	foss-north Online 2022	Online
February 15	July 11 July 17	SciPy 2022	Austin, TX, USA
February 16	March 4 March 6	Binary T00ls Summit	Online
February 22	May 13	PostgreSQL Conference Germany	Leipzig, Germany
March 1	May 2 May 4	Linux Storage, Filesystem, and Memory-Management Summit	Palm Springs CA, USA
March 1	June 21 June 25	The Perl and Raku Conference 2022	Houston, Texas, USA
March 14	June 21 June 24	Open Source Summit North America	Austin, TX, USA
March 18	April 29 May 1	Linux Application Summit 2022	Rovereto, Italy
March 30	June 23 June 24	Linux Security Summit North America	Austin, TX, USA
March 31	May 31 June 2	sambaXP	Göttingen, Germany
March 31	July 19 July 20	stackconf 2022	Berlin, Germany
March 31	July 20 July 25	GUADEC 2022	Guadalajara, Mexico

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

Events: February 10, 2022 to April 11, 2022

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

Date(s)	Event	Location
February 19 February 20	Online Guix Days 2022	online
March 4 March 6	Binary T00ls Summit	Online
March 7 March 11	Mozilla Festival 2022	Online
March 19 March 20	LibrePlanet 2022	Online
March 22	Nordic PGDay 2022	Helsinki, Finland
March 24	pgDay Paris	Paris, France
March 29	Open Source 101	Online
April 1 April 3	Fedora and openSUSE Mentors Summit 2022	Online
April 5 April 7	Cephalocon 2022	Portland, OR, US
April 7 April 9	FOSSASIA Summit	Online

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

Alert summary February 3, 2022 to February 9, 2022

Dist.	ID	Release	Package	Date
CentOS	CESA-2022:0473	C7	aide	2022-02-08
CentOS	CESA-2022:0442	C7	log4j	2022-02-07
Debian	DLA-2911-1	LTS	apng2gif	2022-02-04
Debian	DSA-5068-1	stable	chromium	2022-02-07
Debian	DLA-2915-1	LTS	connman	2022-02-09
Debian	DLA-2910-1	LTS	ldns	2022-02-04
Debian	DLA-2912-1	LTS	libphp-adodb	2022-02-06
Debian	DLA-2908-1	LTS	librecad	2022-02-03
Debian	DSA-5066-1	stable	ruby2.5	2022-02-03
Debian	DSA-5067-1	stable	ruby2.7	2022-02-03
Debian	DLA-2909-1	LTS	strongswan	2022-02-04
Debian	DLA-2913-1	LTS	xterm	2022-02-07
Debian	DLA-2914-1	LTS	zabbix	2022-02-07
Fedora	FEDORA-2022-5aee32fbab	F35	389-ds-base	2022-02-04
Fedora	FEDORA-2022-8c64cb0992	F34	flatpak	2022-02-03
Fedora	FEDORA-2022-8c64cb0992	F34	flatpak-builder	2022-02-03
Fedora	FEDORA-2022-918e18c52c	F34	glibc	2022-02-03
Fedora	FEDORA-2022-560d2bc333	F35	glibc	2022-02-04
Fedora	FEDORA-2022-612dd9ae5e	F34	java-latest-openjdk	2022-02-04
Fedora	FEDORA-2022-74707ed2dd	F35	kate	2022-02-08
Fedora	FEDORA-2022-667a5c6e26	F34	kernel	2022-02-06
Fedora	FEDORA-2022-57fd391bf8	F35	kernel	2022-02-05
Fedora	FEDORA-2022-667a5c6e26	F34	kernel-headers	2022-02-06
Fedora	FEDORA-2022-57fd391bf8	F35	kernel-headers	2022-02-05
Fedora	FEDORA-2022-667a5c6e26	F34	kernel-tools	2022-02-06
Fedora	FEDORA-2022-57fd391bf8	F35	kernel-tools	2022-02-05
Fedora	FEDORA-2022-dbb274913a	F34	keylime	2022-02-04
Fedora	FEDORA-2022-5770dad5f8	F35	keylime	2022-02-04
Fedora	FEDORA-2022-e6b2bd5b50	F35	lua	2022-02-08
Fedora	FEDORA-2022-286134c3c1	F34	mingw-binutils	2022-02-06
Fedora	FEDORA-2022-eca9d3b7fa	F34	mingw-openexr	2022-02-06
Fedora	FEDORA-2022-e4087f9366	F34	mingw-python-pillow	2022-02-04
Fedora	FEDORA-2022-a1bc7decc9	F35	mingw-python-pillow	2022-02-04
Fedora	FEDORA-2022-7018d21c6b	F34	mingw-python3	2022-02-06
Fedora	FEDORA-2022-56f583fd79	F34	mingw-qt5-qtsvg	2022-02-06
Fedora	FEDORA-2022-1e29b8997a	F35	mingw-qt5-qtsvg	2022-02-07
Fedora	FEDORA-2022-f4b7f896e3	F35	perl-App-cpanminus	2022-02-09
Fedora	FEDORA-2022-f3ab9c77bc	F34	perl-Image-ExifTool	2022-02-04
Fedora	FEDORA-2022-c0c11c4776	F35	perl-Image-ExifTool	2022-02-04
Fedora	FEDORA-2021-6bd024d2a7	F34	podman	2022-02-08
Fedora	FEDORA-2022-e4087f9366	F34	python-pillow	2022-02-04
Fedora	FEDORA-2022-a1bc7decc9	F35	python-pillow	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-afterburn	2022-02-04
Fedora	FEDORA-2022-1b76e3a192	F35	rust-afterburn	2022-02-09
Fedora	FEDORA-2022-7ec8bda833	F34	rust-askalono-cli	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-below	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-cargo-c	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-cargo-insta	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-fd-find	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-lsd	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-oxipng	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-python-launcher	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-ripgrep	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-skim	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-thread_local	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	rust-tokei	2022-02-04
Fedora	FEDORA-2022-0ee49c7f19	F34	scap-security-guide	2022-02-06
Fedora	FEDORA-2022-8936f7d630	F35	scap-security-guide	2022-02-06
Fedora	FEDORA-2022-448c3fe785	F34	stratisd	2022-02-07
Fedora	FEDORA-2022-51067372d7	F35	stratisd	2022-02-07
Fedora	FEDORA-2022-b670788a8d	F35	strongswan	2022-02-04
Fedora	FEDORA-2022-9d02441b24	F35	util-linux	2022-02-05
Fedora	FEDORA-2022-7e9e1ae1fb	F34	vim	2022-02-04
Fedora	FEDORA-2022-f7366e60cb	F34	webkit2gtk3	2022-02-06
Fedora	FEDORA-2022-420bf9fc1e	F35	xen	2022-02-04
Fedora	FEDORA-2022-7ec8bda833	F34	zola	2022-02-04
Mageia	MGASA-2022-0043	8	chromium-browser-stable	2022-02-02
Mageia	MGASA-2022-0045	8	connman	2022-02-02
Mageia	MGASA-2022-0047	8	cryptsetup	2022-02-03
Mageia	MGASA-2022-0048	8	expat	2022-02-03
Mageia	MGASA-2022-0052	8	glibc	2022-02-08
Mageia	MGASA-2022-0046	8	libtiff	2022-02-02
Mageia	MGASA-2022-0049	8	lrzsz	2022-02-05
Mageia	MGASA-2022-0050	8	qtwebengine5	2022-02-05
Mageia	MGASA-2022-0044	8	rust	2022-02-02
Mageia	MGASA-2022-0051	8	xterm	2022-02-05
openSUSE	openSUSE-SU-2022:0030-1	15.3 SLE15	chromium	2022-02-07
openSUSE	openSUSE-SU-2022:0334-1	15.3	containerd, docker	2022-02-04
openSUSE	openSUSE-SU-2022:0330-1	15.3 15.4	glibc	2022-02-04
openSUSE	openSUSE-SU-2022:0024-1	15.3 SLE15	lighttpd	2022-02-02
openSUSE	openSUSE-SU-2022:0333-1	15.3	xen	2022-02-04
Oracle	ELSA-2022-0441	OL8	aide	2022-02-07
Oracle	ELSA-2022-0370	OL8	cryptsetup	2022-02-02
Oracle	ELSA-2022-0124	OL7	firefox	2022-02-03
Oracle	ELSA-2022-0442	OL7	log4j	2022-02-07
Oracle	ELSA-2022-0350	OL8	nodejs:14	2022-02-02
Oracle	ELSA-2022-0368	OL8	rpm	2022-02-02
Oracle	ELSA-2022-0127	OL7	thunderbird	2022-02-03
Oracle	ELSA-2022-0418	OL8	varnish:6	2022-02-03
Oracle	ELSA-2022-0366	OL8	vim	2022-02-03
Red Hat	RHSA-2022:0495-01	EL8	.NET 5.0	2022-02-09
Red Hat	RHSA-2022:0496-01	EL8	.NET 6.0	2022-02-09
Red Hat	RHSA-2022:0472-01	EL6	aide	2022-02-08
Red Hat	RHSA-2022:0473-01	EL7	aide	2022-02-08
Red Hat	RHSA-2022:0441-01	EL8	aide	2022-02-07
Red Hat	RHSA-2022:0464-01	EL8.1	aide	2022-02-08
Red Hat	RHSA-2022:0456-01	EL8.2	aide	2022-02-08
Red Hat	RHSA-2022:0440-01	EL8.4	aide	2022-02-07
Red Hat	RHSA-2022:0442-01	EL6 EL7 EL7.3 EL7.4 EL7.6 EL7.7	log4j	2022-02-08
Red Hat	RHSA-2022:0475-01	RHV	ovirt-engine	2022-02-09
Red Hat	RHSA-2022:0439-01	RHSC7	rh-maven36-log4j12	2022-02-03
Red Hat	RHSA-2022:0457-01	EL7	samba	2022-02-08
Red Hat	RHSA-2022:0458-01	EL8	samba	2022-02-08
Red Hat	RHSA-2022:0418-01	EL8	varnish:6	2022-02-03
Red Hat	RHSA-2022:0420-01	EL8.1	varnish:6	2022-02-03
Red Hat	RHSA-2022:0421-01	EL8.2	varnish:6	2022-02-03
Red Hat	RHSA-2022:0422-01	EL8.4	varnish:6	2022-02-03
SUSE	SUSE-SU-2022:0334-1	MP4.2 SLE15	containerd, docker	2022-02-04
SUSE	SUSE-SU-2022:0355-1	OS8	elasticsearch, elasticsearch-kit, kafka, kafka-kit, logstash, openstack-monasca-agent, openstack-monasca-log-metrics, openstack-monasca-log-persister, openstack-monasca-log-transformer, openstack-monasca-persister-java, openstack-monasca-persister-java-kit, openstack-monasca-thresh, openstack-monasca-thresh-kit, spark, spark-kit, venv-openstack-monasca, zookeeper, zookeeper-kit	2022-02-09
SUSE	SUSE-SU-2022:0354-1	OS9	elasticsearch, elasticsearch-kit, kafka, kafka-kit, logstash, openstack-monasca-agent, openstack-monasca-persister-java, openstack-monasca-persister-java-kit, openstack-monasca-thresh, openstack-monasca-thresh-kit, spark, spark-kit, storm, storm-kit, venv-openstack-monasca, zookeeper, zookeeper-kit	2022-02-09
SUSE	SUSE-SU-2022:0330-1	MP4.2 SLE15	glibc	2022-02-04
SUSE	SUSE-SU-2022:0288-1	SLE15	kernel	2022-02-02
SUSE	SUSE-SU-2022:0323-1	SLE12	samba	2022-02-03
SUSE	SUSE-SU-2022:0301-1	SLE15	unbound	2022-02-02
SUSE	SUSE-SU-2022:0333-1	MP4.2 SLE15	xen	2022-02-04
SUSE	SUSE-SU-2022:0331-1	OS9 SLE12	xen	2022-02-04
SUSE	SUSE-SU-2022:0342-1	SLE12	xen	2022-02-07
SUSE	SUSE-SU-2022:0332-1	SLE15	xen	2022-02-04
Ubuntu	USN-5275-1	16.04 18.04 20.04 21.10	bluez	2022-02-08
Ubuntu	USN-5262-1	16.04	gdisk	2022-02-03
Ubuntu	USN-5264-1	16.04	graphviz	2022-02-03
Ubuntu	USN-5030-2	16.04	libdbi-perl	2022-02-03
Ubuntu	USN-5265-1	20.04 21.10	linux, linux-aws, linux-aws-5.11, linux-aws-5.13, linux-gcp, linux-gcp-5.11, linux-hwe-5.13, linux-kvm, linux-oem-5.13, linux-oracle, linux-oracle-5.11, linux-raspi	2022-02-02
Ubuntu	USN-5267-1	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-bluefield, linux-gcp, linux-gcp-5.4, linux-gkeop, linux-gkeop-5.4, linux-hwe-5.4, linux-ibm, linux-kvm, linux-oracle, linux-oracle-5.4	2022-02-02
Ubuntu	USN-5267-2	18.04 20.04	linux, linux-aws, linux-aws-5.4, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm, linux-kvm, linux-oracle, linux-oracle-5.4	2022-02-08
Ubuntu	USN-5268-1	14.04 16.04 18.04	linux, linux-aws, linux-aws-hwe, linux-azure, linux-dell300x, linux-gcp-4.15, linux-hwe, linux-kvm, linux-oracle, linux-raspi2, linux-snapdragon	2022-02-02
Ubuntu	USN-5266-1	18.04 20.04	linux-gke, linux-gke-5.4	2022-02-02
Ubuntu	USN-5270-1	18.04 20.04 21.10	mysql-5.7, mysql-8.0	2022-02-03
Ubuntu	USN-5270-2	16.04	mysql-5.7	2022-02-03
Ubuntu	USN-5276-1	18.04 20.04 21.10	nvidia-graphics-drivers-450-server, nvidia-graphics-drivers-470, nvidia-graphics-drivers-470-server, nvidia-graphics-drivers-510	2022-02-08
Ubuntu	USN-5269-2	14.04 16.04	python-django	2022-02-07
Ubuntu	USN-5269-1	18.04 20.04 21.10	python-django	2022-02-03
Ubuntu	USN-4754-5	14.04	python2.7	2022-02-08
Ubuntu	USN-5260-3	14.04 16.04	samba	2022-02-03
Ubuntu	USN-5279-1	20.04 21.10	util-linux	2022-02-09

Full Story (comments: none)