With the 30th birthday of Linux coming up, TechRepublic's Jack Wallen argues that its distros "are so much better today." I remember like it was yesterday. The very first time I booted into the Linux desktop. The distribution in question was Caldera Open Linux 1.0, which installed with kernel 2.0 and the desktop was Fvwm95... It was just unsightly. The colors were decidedly too Microsoftian, and it was all so ... clinical....

The Linux desktop has morphed from an ugly, awkward, and less-than-productive state, to an almost avant-garde work of art, into an elegant, productive and professional environment. All the while, it offered more choices than most users had time to consider. Even today, I could go back to Enlightenment, or opt for the likes of Pantheon, Budgie, KDE, Openbox, Fluxbox, i3, Gala, Windowmaker or numerous other takes on the desktop...

If I were to go back in time and look over the shoulder at a younger me, I would probably see someone who loved the desktop he was using, but wished it could be a bit more productive. I would then whisper into his ear and say, "Give it time."

RoccamOccam writes: After many months of development, the memfd_secret() system call was finally merged for the upcoming 5.14 release of Linux. There have been many changes during this feature's development, but its core purpose remains the same: allow a user-space process to create a range of memory that is inaccessible to anybody else -- kernel included. That memory can be used to store cryptographic keys or any other data that must not be exposed to others. Reportedly, it is even safe from processor vulnerabilities like Spectre because secret memory is uncached mapped.

A fix that was made in early June to the GNU C Library (glibc) introduced a new and nastier problem. Steven J. Vaughan-Nichols writes via ZDNet: The first problem wasn't that bad. As Siddhesh Poyarekar, a Red Hat principal software engineer wrote, "In order to mount a minimal attack using this flaw, an attacker needs many pre-requisites to be able to even crash a program using this mq_notify bug." Still, it needed patching and so it was fixed. Alas, the fix contained an even nastier bug. While checking the patch, Nikita Popov, a member of the CloudLinux TuxCare Team, found the problem. It turns out that it is possible to cause a situation where a segmentation fault could be triggered within the library. This can lead to any application using the library crashing. This, of course, would cause a Denial-of-Service (DoS) issue. This problem, unlike the earlier one, would be much easier to trigger. Whoops.

Red Hat gives the problem in its Common Vulnerability Scoring System (CVSS) a score of 7.5, which is "high." An attack using it would be easy to build and requires no privileges to be made. In short, it's bad news. Popov himself thinks "every Linux application including interpreters of other languages (python, PHP) is linked with glibc. It's the second important thing after the kernel itself, so the impact is quite high." [...] The good news is both the vulnerability and code fix have been submitted to the glibc development team. It has already been incorporated into upstream glibc.

In addition, a new test has been submitted to glibc's automated test suite to pick up this situation and prevent it from happening in the future. The bottom line is sometimes changed in unrelated code paths can lead to behaviors changing elsewhere without the programmer realizing what's going on. This test will catch this situation. The Linux distributors are still working out the best way to deploy the fix. In the meantime, if you want to be extra careful -- and I think you should be -- you should upgrade to the newest stable version of glibc 2.34 or higher.

"One of the oldest and most renowned distributions of Linux has been released!" âwrites Slashdot reader Washuu2. Phoronix reports it took "just over two years in development." Debian 11 brings many new features as outlined this morning with the big upgrade to Linux 5.10 LTS, exFAT file-system support, control groups v2, yescrypt for password hashing, and a plethora of updated packages. GNOME 3.38, KDE Plasma 5.20, and Xfce 4.16 are among the desktop options for Debian 11.
Debian.org adds: Do you want to celebrate the release? We provide some bullseye artwork that you can share or use as base for your own creations. Follow the conversation about bullseye in social media via the #ReleasingDebianBullseye and #Debian11Bullseye hashtags...
Around the world, there were even several in-person and online release parties — with a few more upcoming!

LTTng has been called "the killer app for system-level debugging and performance tuning." And now long-time Slashdot reader compudj writes: It's the official release of LTTng 2.13 — Nordicité! LTTng is a kernel and user-space tracer for Linux. The most notable features of this release are:

- Event-rule matches condition triggers and new actions, allowing internal actions or external monitoring applications to quickly react when kernel or user-space instrumentation is hit

- Notification payload capture, allowing external monitoring applications to read elements of the instrumentation payload when instrumentation is hit.

- Instrumentation API: vtracef and vtracelog (LTTng-UST)

- User space time namespace context (LTTng-UST and LTTng-modules).

Jim Salter writes via Ars Technica: In March of last year, proprietary filesystem vendor Paragon Software unleashed a stream of anti-open source FUD about a Samsung-derived exFAT implementation headed into the Linux kernel. Several months later, Paragon seemed to have seen the error of its ways and began the arduous process of getting its own implementation of Microsoft's NTFS (the default filesystem for all Windows machines) into the kernel as well. Although Paragon is still clearly struggling to get its processes and practices aligned to open source-friendly ones, Linux kernel BDFL Linus Torvalds seems to have taken a personal interest in the process. After nearly a year of effort by Paragon, Torvalds continues to gently nudge both it and skeptical Linux devs in order to keep the project moving forward.

To those familiar with daily Linux use, the utility of Paragon's version of NTFS might not be immediately obvious. The Linux kernel already has one implementation of NTFS, and most distributions make it incredibly easy to install and use another FUSE-based implementation (ntfs-3g) beyond that. Both existing implementations have problems, however. The in-kernel implementation of NTFS is extremely old, poorly maintained, and should only be used read-only. As a result, most people who actually need to mount NTFS filesystems on Linux use the ntfs-3g driver instead. Ntfs-3g is in reasonably good shape -- it's much newer than the in-kernel ntfs implementation, and as Linux filesystem guru Ted Ts'o points out, it actually passes more automated filesystem tests than Paragon's own ntfs3 does.

Unfortunately, due to operating in userspace rather than in-kernel, ntfs-3g's performance is abysmal. In Ts'o's testing, Paragon's ntfs3 completed automated testing in 8,106 seconds -- but the FUSE-based ntfs-3g required a whopping 34,783 seconds. Bugs and performance aside, ongoing maintenance is a key aspect to Paragon's ntfs3 making it in-kernel. Torvalds opined that "Paragon should just make a pull request for [ntfs3]" -- but he did so after noting that the code should get OKs from current maintainers and that Paragon itself should maintain the code going forward. (Paragon developer Konstantin Komarov quickly replied that the company intended to continue maintaining the code, once accepted.) [...] For his own part, Torvalds seems determined to find a performant, modern, maintainable replacement for the ancient (2001-era) and seldom-used ntfs implementation in the kernel now. As long as Paragon remains willing to keep playing, it seems likely to get there eventually -- perhaps even in time for the 5.15 kernel.

According to Steam Survey numbers for July 2021, Steam on Linux hit a 1.0% marketshare, or a +0.14% increase over the month prior. Phoronix reports: This is the highest we have seen the Steam on Linux marketshare in a number of years and well off the lows prior to introducing Steam Play (Proton) since which point there has been the gradual increase in marketshare. Back when Steam on Linux first debuted there was around a 2% marketshare for Linux before gradually declining. Back when Steam first debuted for Linux, the overall Steam customer base was also much smaller than it is today.

While many believe the Steam Survey is inaccurate or biased (or just buggy towards prompting Linux users to participate in the survey), these initial numbers for July are positive in hitting the 1.0% mark after largely floating around the 0.8~0.9% mark for most of the past three years. The Steam Deck isn't shipping until the end of the year so we'll see how the number fluctuates to that point.

Along with other optimizations to benefit the Steam Deck, AMD and Valve have been jointly working on CPU frequency/power scaling improvements to enhance the Steam Play gaming experience on modern AMD platforms running Linux. Phoronix reports: It's no secret that the ACPI CPUFreq driver code has at times been less than ideal on recent AMD processors with delivering less than expected performance/behavior with being slow to ramp up to a higher performance state or otherwise coming up short of disabling the power management functionality outright. AMD hasn't traditionally worked on the Linux CPU frequency scaling code as much as Intel does to their P-State scaling driver and other areas of power management at large. AMD is ramping up efforts in these areas including around the Linux scheduler given their recent hiring spree while it now looks like thanks to the Steam Deck there is renewed interest in better optimizing the CPU frequency scaling under Linux.

AMD and Valve have been working to improve the performance/power efficiency for modern AMD platforms running on Steam Play (Proton / Wine) and have spearheaded "[The ACPI CPUFreq driver] was not very performance/power efficiency for modern AMD platforms...a new CPU performance scaling design for AMD platform which has better performance per watt scaling on such as 3D game like Horizon Zero Dawn with VKD3D-Proton on Steam." AMD will be presenting more about this effort next month at XDC. It's quite possible this new effort is focused on ACPI CPPC support with the previously proposed AMD_CPUFreq. Back when Zen 2 launched in 2019, AMD did post patches for their new CPUFreq driver that leveraged ACPI Collaborative Processor Performance Controls but the driver was never mainlined nor any further iterations of the patches posted. When inquiring about that work a few times since then, AMD has always said it's been basically due to resource constraints that it wasn't a focus at that time. Upstream kernel developers also voiced their preference to seeing AMD work to improve the generic ACPI CPPC CPUFreq driver code rather than having another vendor-specific solution. It's also possible AMD has been working on better improvements around the now-default Schedutil governor for scheduler utilization data in making CPU frequency scaling decisions.

The threat intelligence team for Microsoft's 365 Defender security suite recently focused on an example of "modern mining malware infrastructure," describing how "Anything that can gain access to machines — even so-called commodity malware — can bring in more dangerous threats."

Specifically, it offered a case study of LemonDuck. The blog post's title? "When coin miners evolve..." Today, beyond using resources for its traditional bot and mining activities, LemonDuck steals credentials, removes security controls, spreads via emails, moves laterally, and ultimately drops more tools for human-operated activity.

LemonDuck's threat to enterprises is also in the fact that it's a cross-platform threat. It's one of a few documented bot malware families that targets Linux systems as well as Windows devices. It uses a wide range of spreading mechanisms — phishing emails, exploits, USB devices, brute force, among others — and it has shown that it can quickly take advantage of news, events, or the release of new exploits to run effective campaigns... Notably, LemonDuck removes other attackers from a compromised device by getting rid of competing malware and preventing any new infections by patching the same vulnerabilities it used to gain access... LemonDuck spreads in a variety of ways, but the two main methods are (1) compromises that are either edge-initiated or facilitated by bot implants moving laterally within an organization, or (2) bot-initiated email campaigns.

LemonDuck acts as a loader for many other follow-on activities, but one if its main functions is to spread by compromising other systems. Since its first appearance, the LemonDuck operators have leveraged scans against both Windows and Linux devices for open or weakly authenticated SMB, Exchange, SQL, Hadoop, REDIS, RDP, or other edge devices that might be vulnerable to password spray or application vulnerabilities... Other common methods of infection include movement within the compromised environment, as well as through USB and connected drives. These processes are often kicked off automatically and have occurred consistently throughout the entirety of LemonDuck's operation.

Qualys has discovered a new systemd security bug that enables any unprivileged user to cause a denial of service via a kernel panic. Slashdot reader inode_buddha shares the news via ZDNet's Steven J. Vaughan-Nichols: As Bharat Jogi, Qualys's senior manager of Vulnerabilities and Signatures, wrote, "Given the breadth of the attack surface for this vulnerability, Qualys recommends users apply patches for this vulnerability immediately." You can say that again. Systemd is used in almost all modern Linux distributions. This particular security hole arrived in the systemd code in April 2015.

It works by enabling attackers to misuse the alloca() function in a way that would result in memory corruption. This, in turn, allows a hacker to crash systemd and hence the entire operating system. Practically speaking, this can be done by a local attacker mounting a filesystem on a very long path. This causes too much memory space to be used in the systemd stack, which results in a system crash. That's the bad news. The good news is that Red Hat Product Security and systemd's developers have immediately patched the hole.

An anonymous reader quotes a report from ZDNet, written by Steven J. Vaughan-Nichols: Microsoft now has its very own, honest-to-goodness general-purpose Linux distribution: Common Base Linux, (CBL)-Mariner. And, just like any Linux distro, you can download it and run it yourself. Microsoft didn't make a big fuss about releasing CBL-Mariner. It quietly released the code on GitHub and anyone can use it. Indeed, Juan Manuel Rey, a Microsoft Senior Program Manager for Azure VMware, recently published a guide on how to build an ISO CBL-Mariner image. Before this, if you were a Linux expert, with a spot of work you could run it, but now, thanks to Rey, anyone with a bit of Linux skill can do it.

CBL-Mariner is not a Linux desktop. Like Azure Sphere, Microsoft's first specialized Linux distro, which is used for securing edge computing services, it's a server-side Linux. This Microsoft-branded Linux is an internal Linux distribution. It's meant for Microsoft's cloud infrastructure and edge products and services. Its main job is to provide a consistent Linux platform for these devices and services. Just like Fedora is to Red Hat, it keeps Microsoft on Linux's cutting edge. CBL-Mariner is built around the idea that you only need a small common core set of packages to address the needs of cloud and edge services. If you need more, CBL-Mariner also makes it easy to layer on additional packages on top of its common core. Once that's done, its simple build system easily enables you to create RPM packages from SPEC and source files. Or, you can also use it to create ISOs or Virtual hard disk (VHD) images.

As you'd expect the basic CBL-Mariner is a very lightweight Linux. You can use it as a container or a container host. With its limited size also comes a minimal attack surface. This also makes it easy to deploy security patches to it via RPM. Its designers make a particular point of delivering the latest security patches and fixes to its users. For more about its security features see CBL-Mariner's GitHub security features list. Like any other Linux distro, CBL-Mariner is built on the shoulders of giants. Microsoft credits VMware's Photon OS Project, a secure Linux, The Fedora Project, Linux from Scratch -- a guide to building Linux from source, the OpenMamba distro, and, yes, even GNU and the Free Software Foundation (FSF). To try it for yourself, you'll build it on Ubuntu 18.04. Frankly, I'd be surprised if you couldn't build it on any Ubuntu Linux distro from 18.04 on up. I did it on my Ubuntu 20.04.2 desktop. You'll also need the latest version of the Go language and Docker.

"The Rust for Linux project, sponsored by Google, has advanced..." reported the Register earlier this week: A new set of patches submitted to the Linux kernel mailing list summarizes the progress of the project to enable Rust to be used alongside C for implementing the Linux kernel. The progress is significant.

- ARM and RISC-V architectures are now supported, thanks to work on rustc_codgen_gcc, which is a GCC codegen for rustc. This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation, enabling support for the architectures that GCC supports...

- Overall, "the Rust support is still to be considered experimental. However, as noted back in April, support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules," continued project leader Miguel Ojeda, a computer scientist at CERN in Geneva, Switzerland, now working full time on Rust for Linux...

There is substantial support for the project across the industry. Google said in April "we feel that Rust is now ready to join C as a practical language for implementing the kernel" and that it would reduce the number of potential bugs and security vulnerabilities. Google is sponsoring Ojeda to work full time on the project for a year, via the ISRG (Internet Security Research Group), which said last month that it is part of "efforts to move the internet's critical software infrastructure to memory safe code," under the project name Prossimo. The ISRG is also the nonprofit organisation behind Let's Encrypt free security certificates. Ojeda also mentioned that Microsoft's Linux Systems Group is contributing and hopes to submit "select Hyper-V drivers written in Rust." Arm is promising assistance with Rust for Linux on ARM-based systems. IBM has contributed Rust kernel support for its PowerPC processor.

More detail is promised at the forthcoming Linux Plumber's Conference in September. In the meantime, the project is on GitHub here.
"In addition, we would like to announce that we are organizing a new conference that focuses on Rust and the Linux kernel..." Ojeda posted. "Details will be announced soon." And for context, the Register adds: Linus Torvalds has said on several occasions that he welcomes the possibility of using Rust alongside C for kernel development, and told IT Wire in April that it is "getting to the point where maybe it might be mergeable for 5.14 or something like that."

"Linus Torvalds has just released the Linux 5.13 kernel as stable," reports Phoronix: Linux 5.13 brings initial but still early support for the Apple M1 with basic support but not yet accelerated graphics and a lot more to iron out moving ahead. There are also new Linux 5.13 security features like the Landlock security module, Clang control flow integrity support, and optionally randomizing the kernel stack offset at each system call. There is also AMD fun this cycle around FreeSync HDMI support, initial Aldebaran bring-up, and more. Intel has more work on Alder Lake, a new cooling driver, and more discrete graphics bring-up. There are also other changes for Linux 5.13 around faster IO_uring, a generic USB display driver, and other new hardware enablement.
"5.13 overall is actually fairly large," Linus Torvalds posted on the Linux Kernel Mailing List, calling it "one of the bigger 5.x releases, with over 16,000 commits (over 17k if you count merges), from over 2,000 developers. But it's a "big all over" kind of thing, not something particular that stands out as particularly unusual..."

"When Red Hat killed off CentOS Linux in a highly controversial December 2020 announcement, Gregory Kurtzer immediately announced his intention to recreate CentOS with a new distribution named after his deceased mentor," Ars Technica reported in February.

And this week, "The Rocky Enterprise Software Foundation has announced general availability (GA) of Rocky Linux 8.4," reports ZDNet. "It's an important milestone because it's the first Rocky Linux general availability release ever." Huge companies, including Disney, GoDaddy, Rackspace, Toyota and Verizon, relied on CentOS, and they were reportedly not happy about RedHat's decision... It turns out that Kurtzer's decision has been a popular one. Besides quickly building up an army of hundreds of contributors for the project, Rocky Linux 8.4 - which follows the May 18 release of Red Hat's RHEL 8.4 - was downloaded at least 10,000 times within half a day of its release... "If we extrapolate the count to include our other mirrors we are probably at least 3-4x that (if not even way more)!" boasts Kurtzer in a LinkedIn post. "Lots of reports coming in of people and organizations already replacing their CentOS systems (and even other Linux distributions) with Rocky. The media is flying off the hook and business analysts also validating to me personally that Rocky Linux might soon be the most utilized Linux operating system used in enterprise and cloud!"

Rocky Linux 8.4 took seven months for the newly formed community to release, and is available for x86_64 and ARM64 (aarch64) architecture hardware in various ISOs.
"Sufficient testing has been performed such that we have confidence in its stability for production systems," explains a blog post at RockyLinux.org, adding that free community support is available through the forums as well as live chat avaiable through IRC and Rocky Linux Mattermost. "Paid commercial support is currently available through CIQ..."

"Corporations come and go, their interests as transient as they are self-serving. But a community persists, and that's who we dedicate Rocky Linux to: you." Rocky is more than the next free and open, community enterprise operating system. It's a community. A commitment to an ideal bigger than the sum of its parts, and a promise that our principles — embedded even within our repositories and ISOs — are immutable...

This is just the beginning, and the Rocky Enterprise Software Foundation is more than just Rocky Linux — it's a home for those that believe that open source isn't just a switch that can be toggled at will, and that projects that many rely on not be subject to the whims of a few. To this point, you can easily find all of our sources, our build infrastructure, Git repositories, and everything else anyone would need to fork our work and ensure that it continues if need be...

When we announced our release candidate, we asked you to come build the next free, open, community enterprise operating system with us. Now we're asking you for more: join us as we build our community.
They also thanked 11 sponsors and partners for contributing "resources, financial backing, software, and infrastructure."

mrflash818 writes: The Internet Security Research Group (ISRG) -- parent organization of the better-known Let's Encrypt project -- has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis. Rust is a low-level programming language offering most of the flexibility and performance of C -- the language used for kernels in Unix and Unix-like operating systems since the 1970s -- in a safer way. Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts -- not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly. Using Rust for new code in the kernel -- which might mean new hardware drivers or even replacement of GNU Coreutils -- potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows -- significant sources of performance and security issues in complex C-language code.