- wlug - list.wlug.org.nz

Linux Foundation Announces Launch of 'High Performance Software Foundation'
by Peter Reutemann 20 May '24

20 May '24

'This week the nonprofit Linux Foundation announced the launch of the High Performance Software Foundation, which "aims to build, promote, and advance a portable core software stack for high performance computing" (or HPC) by "increasing adoption, lowering barriers to contribution, and supporting development efforts." It promises initiatives focused on "continuously built, turnkey software stacks," as well as other initiatives including architecture support and performance regression testing. Its first open source technical projects are: - Spack: the HPC package manager. - Kokkos: a performance-portable programming model for writing modern C++ applications in a hardware-agnostic way. - Viskores (formerly VTK-m): a toolkit of scientific visualization algorithms for accelerator architectures. - HPCToolkit: performance measurement and analysis tools for computers ranging from desktop systems to GPU-accelerated supercomputers. - Apptainer: Formerly known as Singularity, Apptainer is a Linux Foundation project providing a high performance, full featured HPC and computing optimized container subsystem. - E4S: a curated, hardened distribution of scientific software packages. As use of HPC becomes ubiquitous in scientific computing and digital engineering, and AI use cases multiply, more and more data centers deploy GPUs and other compute accelerators. The High Performance Software Foundation will provide a neutral space for pivotal projects in the high performance computing ecosystem, enabling industry, academia, and government entities to collaborate on the scientific software. The High Performance Software Foundation benefits from strong support across the HPC landscape, including Premier Members Amazon Web Services (AWS), Hewlett Packard Enterprise, Lawrence Livermore National Laboratory, and Sandia National Laboratories; General Members AMD, Argonne National Laboratory, Intel, Kitware, Los Alamos National Laboratory, NVIDIA, and Oak Ridge National Laboratory; and Associate Members University of Maryland, University of Oregon, and Centre for Development of Advanced Computing. In a statement, an AMD vice president said that by joining "we are using our collective hardware and software expertise to help develop a portable, open-source software stack for high-performance computing across industry, academia, and government." And an AWS executive said the high-performance computing community "has a long history of innovation being driven by open source projects. AWS is thrilled to join the High Performance Software Foundation to build on this work. In particular, AWS has been deeply involved in contributing upstream to Spack, and we're looking forward to working with the HPSF to sustain and accelerate the growth of key HPC projects so everyone can benefit." The new foundation will "set up a technical advisory committee to manage working groups tackling a variety of HPC topics," according to the announcement, following a governance model based on the Cloud Native Computing Foundation.' -- source: https://tech.slashdot.org/story/24/05/19/2234254 Cheers, Peter

1 0

Why a 'Frozen' Distribution Linux Kernel Isn't the Safest Choice for Security
by Peter Reutemann 20 May '24

20 May '24

'Jeremy Allison — Sam (Slashdot reader #8,157) is a Distinguished Engineer at Rocky Linux creator CIQ. This week he published a blog post responding to promises of Linux distros "carefully selecting only the most polished and pristine open source patches from the raw upstream open source Linux kernel in order to create the secure distribution kernel you depend on in your business." But do carefully curated software patches (applied to a known "frozen" Linux kernel) really bring greater security? "After a lot of hard work and data analysis by my CIQ kernel engineering colleagues Ronnie Sahlberg and Jonathan Maple, we finally have an answer to this question. It's no." The data shows that "frozen" vendor Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream "stable" Linux kernel created by Greg Kroah-Hartman. How can this be? If you want the full details the link to the white paper is here. But the results of the analysis couldn't be clearer. - A "frozen" vendor kernel is an insecure kernel. A vendor kernel released later in the release schedule is doubly so. - The number of known bugs in a "frozen" vendor kernel grows over time. The growth in the number of bugs even accelerates over time. - There are too many open bugs in these kernels for it to be feasible to analyze or even classify them.... [T]hinking that you're making a more secure choice by using a "frozen" vendor kernel isn't a luxury we can still afford to believe. As Greg Kroah-Hartman explicitly said in his talk "Demystifying the Linux Kernel Security Process": "If you are not using the latest stable / longterm kernel, your system is insecure." CIQ describes its report as "a count of all the known bugs from an upstream kernel that were introduced, but never fixed in RHEL 8." For the most recent RHEL 8 kernels, at the time of writing, these counts are: RHEL 8.6 : 5034 RHEL 8.7 : 4767 RHEL 8.8 : 4594 In RHEL 8.8 we have a total of 4594 known bugs with fixes that exist upstream, but for which known fixes have not been back-ported to RHEL 8.8. The situation is worse for RHEL 8.6 and RHEL 8.7 as they cut off back-porting earlier than RHEL 8.8 but of course that did not prevent new bugs from being discovered and fixed upstream.... This whitepaper is not meant as a criticism of the engineers working at any Linux vendors who are dedicated to producing high quality work in their products on behalf of their customers. This problem is extremely difficult to solve. We know this is an open secret amongst many in the industry and would like to put concrete numbers describing the problem to encourage discussion. Our hope is for Linux vendors and the community as a whole to rally behind the kernel.org stable kernels as the best long term supported solution. As engineers, we would prefer this to allow us to spend more time fixing customer specific bugs and submitting feature improvements upstream, rather than the endless grind of backporting upstream changes into vendor kernels, a practice which can introduce more bugs than it fixes. ZDNet calls it "an open secret in the Linux community." It's not enough to use a long-term support release. You must use the most up-to-date release to be as secure as possible. Unfortunately, almost no one does that. Nevertheless, as Google Linux kernel engineer Kees Cook explained, "So what is a vendor to do? The answer is simple: if painful: Continuously update to the latest kernel release, either major or stable." Why? As Kroah-Hartman explained, "Any bug has the potential of being a security issue at the kernel level...." Although [CIQ's] programmers examined RHEL 8.8 specifically, this is a general problem. They would have found the same results if they had examined SUSE, Ubuntu, or Debian Linux. Rolling-release Linux distros such as Arch, Gentoo, and OpenSUSE Tumbleweed constantly release the latest updates, but they're not used in businesses.' -- source: https://linux.slashdot.org/story/24/05/19/0030248 Cheers, Peter

1 0

Google patches its fifth zero-day vulnerability of the year in Chrome
by Peter Reutemann 13 May '24

13 May '24

'Google has updated its Chrome browser to patch a high-severity zero-day vulnerability that allows attackers to execute malicious code on end user devices. The fix marks the fifth time this year the company has updated the browser to protect users from an existing malicious exploit. The vulnerability, tracked as CVE-2024-4671, is a “use after free,” a class of bug that occurs in C-based programming languages. In these languages, developers must allocate memory space needed to run certain applications or operations. They do this by using “pointers” that store the memory addresses where the required data will reside. Because this space is finite, memory locations should be deallocated once the application or operation no longer needs it. Use-after-free bugs occur when the app or process fails to clear the pointer after freeing the memory location. In some cases, the pointer to the freed memory is used again and points to a new memory location storing malicious shellcode planted by an attacker’s exploit, a condition that will result in the execution of this code. On Thursday, Google said an anonymous source notified it of the vulnerability. The vulnerability carries a severity rating of 8.8 out of 10. In response, Google said, it would be releasing versions 124.0.6367.201/.202 for macOS and Windows and 124.0.6367.201 for Linux in subsequent days. “Google is aware that an exploit for CVE-2024-4671 exists in the wild,” the company said.' -- source: https://arstechnica.com/security/2024/05/google-patches-its-fifth-zero-day-… Cheers, Peter

1 0

AMD Core Performance Boost For Linux Getting Per-CPU Core Controls
by Peter Reutemann 13 May '24

13 May '24

'Phoronix: For the past several months AMD Linux engineers have been working on AMD Core Performance Boost support for their P-State CPU frequency scaling driver. The ninth iteration of these patches were posted on Monday and besides the global enabling/disabling support for Core Performance Boost, it's now possible to selectively toggle the feature on a per-CPU core basis... The new interface is under /sys/devices/system/cpu/cpuX/cpufreq/amd_pstate_boost_cpb for each CPU core. Thus users can tune whether particular CPU cores are boosted above the base frequency.' -- source: https://linux.slashdot.org/story/24/05/11/229219 Cheers, Peter

1 0

Linux Kernel 6.9 Officially Released
by Peter Reutemann 13 May '24

13 May '24

'"6.9 is now out," Linus Torvalds posted on the Linux kernel mailing list, "and last week has looked quite stable (and the whole release has felt pretty normal)." Phoronix writes that Linux 6.9 "has a number of exciting features and improvements for those habitually updating to the newest version." And Slashdot reader prisoninmate shared this report from 9to5Linux: Highlights of Linux kernel 6.9 include Rust support on AArch64 (ARM64) architectures, support for the Intel FRED (Flexible Return and Event Delivery) mechanism for improved low-level event delivery, support for AMD SNP (Secure Nested Paging) guests, and a new dm-vdo (virtual data optimizer) target in device mapper for inline deduplication, compression, zero-block elimination, and thin provisioning. Linux kernel 6.9 also supports the Named Address Spaces feature in GCC (GNU Compiler Collection) that allows the compiler to better optimize per-CPU data access, adds initial support for FUSE passthrough to allow the kernel to serve files from a user-space FUSE server directly, adds support for the Energy Model to be updated dynamically at run time, and introduces a new LPA2 mode for ARM 64-bit processors... Linux kernel 6.9 will be a short-lived branch supported for only a couple of months. It will be succeeded by Linux kernel 6.10, whose merge window has now been officially opened by Linus Torvalds. Linux kernel 6.10 is expected to be released in mid or late September 2024. "Rust language has been updated to version 1.76.0 in Linux 6.9," according to the article. And Linus Torvalds shared one more details on the Linux kernel mailing list. "I now have a more powerful arm64 machine (thanks to Ampere), so the last week I've been doing almost as many arm64 builds as I have x86-64, and that should obviously continue during the upcoming merge window too."' -- source: https://linux.slashdot.org/story/24/05/12/2212235 Cheers, Peter

1 0

Fedora Asahi Remix 40 is another big step forward for Linux on Apple Silicon Mac
by Peter Reutemann 10 May '24

10 May '24

'Asahi Linux, the project that aims to bring desktop Linux to Apple hardware with Apple silicon—the M series of chips—is out with Fedora Asahi Remix 40. More hardware features of Apple devices are supported, the Fedora Linux 40-based distro ships with KDE's new Plasma 6 desktop, and untold numbers of bugs are squashed, to be replaced with reams more. Fedora Asahi Remix is a "fully integrated distro," according to the Asahi team, and you can "expect a solid and high-quality experience without any unwanted surprises." It supports all the M1 and M2 devices in the MacBook, Mac Mini, Mac Studio, and iMac lines. It's OpenGL 4.6 and OpenGL ES 3.2 certified, and comes with "the best Linux laptop audio you've ever heard." So, should you install it on your Mac? Keep scrolling down Asahi's release page and check the "Device support" section. Still missing from most M-series Apple devices are support for Thunderbolt and USB4, built-in microphones, and Touch ID, as well as USB-C display support. Speakers are not supported on the iMac. And HDMI audio is in rough shape, being able to "break audio on the system completely." Still, for someone using an Apple laptop primarily as a portable device, or simply connecting to a monitor with less modern all-in-one cables, there is a desktop awaiting. Installing it is a single cURL command.' -- source: https://arstechnica.com/gadgets/2024/05/fedora-asahi-remix-40-is-another-bi… Cheers, Peter

1 0

Raspberry Pis get a built-in remote access tool: Raspberry Pi Connect
by Peter Reutemann 08 May '24

08 May '24

'One Raspberry Pi often leads to another. Soon enough, you're running out of spots in your free RealVNC account for your tiny boards and "real" computers. Even if you go the hardened route of SSH or an X connection, you have to keep track of where they all are. All of this is not the easiest thing to tackle if you're new to single-board computers or just eager to get started. Enter Raspberry Pi Connect, a new built-in way to access a Rasbperry Pi from nearly anywhere you can open a browser, whether to control yourself or provide remote assistance. On a Raspberry Pi 4, 5, or Pi 400 kit, you install Pi connect with a single terminal line, reboot the Pi, and then click a new tray icon to connect the Pi to a Raspberry Pi ID (and then enable two-factor authentication, of course). >From then on, visiting connect.raspberrypi.com gives you an encrypted connection to your desktop. It's a direct connection if possible, and if not, it runs through relay servers in London, encrypting it with DTLS and keeping only the metadata needed for the service to work. The Pi will show a notification in its tray that somebody has connected, and you can manage screen sharing from there. The Pi's docs site has a lot more on the particulars. Connect works only on 64-bit systems running the Bookworm version of Pi OS with a Wayland window server. Connect was created partly due to Pi's transition to Wayland from X, which offered its own remote desktop option. According to the Pi firm, the service runs on a peer-to-peer WebRTC connection, similar to that of Zoom, Slack, Teams, and other video-sharing services. The whole service is in beta at the moment, and the company says it's not quite sure how much traffic to expect through its relay servers.' -- source: https://arstechnica.com/gadgets/2024/05/raspberry-pis-get-a-built-in-remote… Cheers, Peter

1 0

Novel attack against virtually all VPN apps neuters their entire purpose
by Peter Reutemann 07 May '24

07 May '24

'Researchers have devised an attack against nearly all virtual private network applications that forces them to send and receive some or all traffic outside of the encrypted tunnel designed to protect it from snooping or tampering. TunnelVision, as the researchers have named their attack, largely negates the entire purpose and selling point of VPNs, which is to encapsulate incoming and outgoing Internet traffic in an encrypted tunnel and to cloak the user’s IP address. The researchers believe it affects all VPN applications when they’re connected to a hostile network and that there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android. They also said their attack technique may have been possible since 2002 and may already have been discovered and used in the wild since then. The effect of TunnelVision is “the victim's traffic is now decloaked and being routed through the attacker directly,” a video demonstration explained. “The attacker can read, drop or modify the leaked traffic and the victim maintains their connection to both the VPN and the Internet.” The attack works by manipulating the DHCP server that allocates IP addresses to devices trying to connect to the local network. A setting known as option 121 allows the DHCP server to override default routing rules that send VPN traffic through a local IP address that initiates the encrypted tunnel. By using option 121 to route VPN traffic through the DHCP server, the attack diverts the data to the DHCP server itself.' -- source: https://arstechnica.com/security/2024/05/novel-attack-against-virtually-all… Cheers, Peter

1 0

Kernel Modules Are Now Compressed
by Lawrence D'Oliveiro 06 May '24

06 May '24

Not sure if this is mentioned in any release notes anywhere, but the .ko files (loadable kernel modules) that would live in /lib/modules/«kernel version»/ are now .ko.xz files. Looks like this happened starting with the 6.6 kernel. I discovered this a few minutes ago, while trying to count how many .ko files came with my 6.7.9 Debian kernel, with find /lib/modules/$(uname -r) -name \*.ko | wc -l and was surprised to see that the answer was 0. A suitably adjusted command find /lib/modules/$(uname -r) -name \*.ko\* | wc -l returns 4165

1 0

Yet Another New systemd Feature
by Lawrence D'Oliveiro 06 May '24

06 May '24

Lennart Poettering wants to get rid of sudo now, and replace it with a new systemd feature called “run0” <https://itwire.com/business-it-news/open-source/poettering-announces-tool-i…>. It is hard to write code that runs setuid, and sudo has had quite a few security vulnerabilities over the years. So Poettering’s idea is to replace the setuid executable with another use of the existing PolicyKit system. Interesting that Poettering thinks we should get rid of the whole idea of setuid altogether. AT&T actually got a patent on the concept, back in the early days of Unix. Other OSes had the concept of privileged code, but what made setuid different is that any user can set this mode on any executable they create, and when other users run this executable (if they are allowed to), they temporarily get the permissions of the owning user. On Linux, this concept was always constrained a bit: I think it only works on compiled machine-code executables, not on interpreted scripts.

1 0