Post Syndicated from daroc original https://lwn.net/Articles/1016484/

Security updates have been issued by AlmaLinux (firefox), Debian (atop and thunderbird), Fedora (webkitgtk), Mageia (microcode), Oracle (expat), SUSE (apparmor, assimp-devel, aws-efs-utils, expat, firefox, ghostscript, go1.23, gotosocial, govulncheck-vulndb, GraphicsMagick, headscale, libmozjs-128-0, libsaml-devel, openvpn, perl-Data-Entropy, and xz), and Ubuntu (gnupg2, kernel, linux-azure-fips, linux-iot, openvpn, ruby-saml, and xz-utils).

Post Syndicated from daroc original https://lwn.net/Articles/1015747/

José Marchesi and David Faust kicked off the BPF track at the 2025 Linux Storage,
Filesystem, Memory-Management, and BPF Summit with an extra-long session on what
they have been doing to support compiling to BPF in GCC. Overall, the project is slowly working
toward full support for BPF, with most of the self-tests now passing using
Faust’s in-progress patches. However, the progress toward that goal has turned up
a number of problems with how Clang supports BPF that needed to be discussed at
length to find a path forward for both projects.

Post Syndicated from daroc original https://lwn.net/Articles/1015718/

Security updates have been issued by Debian (mercurial and opensaml), Fedora (augeas, mingw-libxslt, and nodejs-nodemon), Mageia (chromium-browser-stable), Red Hat (grafana, kernel, kernel-rt, opentelemetry-collector, and podman), SUSE (apache-commons-vfs2, python3, and python36), and Ubuntu (ghostscript, linux, linux-aws, linux-azure, linux-gcp, linux-gke, linux-gkeop,
linux-ibm, linux-intel-iotg, linux-lowlatency, linux-lowlatency-hwe-5.15,
linux-nvidia, linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-azure, linux-gcp, linux-hwe-6.11, linux-oracle,
linux-realtime, linux, linux-aws, linux-gcp, linux-gcp-6.8, linux-gke, linux-gkeop,
linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia,
linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oracle, linux-oracle-6.8, linux-aws-5.15, linux-kvm, linux-azure, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.11, linux-oem-6.11, linux-oem-6.8, linux-realtime, smarty, and snakeyaml).

Post Syndicated from daroc original https://lwn.net/Articles/1015636/

One recurring criticism of Rust has been that the language has no official specification. This is a barrier to adoption in some safety-conscious organizations, as well as to writing alternate language implementations. Now, the Rust project has
announced
that it will be adopting the

Ferrocene Language Specification (FLS) developed by
Ferrous Systems and maintaining it as part of the core project. While this may not satisfy die-hard standardization-process enthusiasts, it’s a step toward removing another barrier to using Rust in safety-critical systems.

It’s in that light that we’re pleased to announce that we’ll be adopting the FLS into the Rust Project as part of our ongoing specification efforts. This adoption is being made possible by the gracious donation of the FLS by Ferrous Systems. We’re grateful to them for the work they’ve done in assembling the FLS, in making it fit for qualification purposes, in promoting its use and the use of Rust generally in safety-critical industries, and now, for working with us to take the next step and to bring the FLS into the Project.

Post Syndicated from daroc original https://lwn.net/Articles/1015095/

Julien Malka has

called for the NixOS project to use build-reproducibility to detect when a program has a maintainer-generated tarball that results in a different artifact than building from source. There are good reasons for projects to release maintainer-generated tarballs, but since the materials included in them are usually documentation, extra build scripts, and so on, it makes sense to check that they don’t influence the final build output. While this would not have stopped

last year’s XZ backdoor, it would have made it harder to hide.

People are often convinced that OSS is more trustworthy than closed-source software because the code can be audited by practitioners and security professionals in order to detect vulnerabilities or backdoors. In this instance, this procedure has been made difficult by the fact that part of the code activating the backdoor was not included in the sources available within the git repository but was instead present in the maintainer-provided tarball. While this was used to hide the backdoor out of sight of most investigating eyes, this is also an opportunity for us to improve our software supply chain security processes.

Post Syndicated from daroc original https://lwn.net/Articles/1014440/

Brendan Jackman has been working to try to get ahead of the next hardware CPU
vulnerability
before it gets discovered. In January, he posted the second version of

a patch set that introduces

address-space isolation (ASI) as a way of
preventing future CPU vulnerabilities from leaking important
information. The core concept is to ensure that data that is not currently
needed is not present in memory, so that speculative execution cannot leak it.
The work is nowhere near ready to be incorporated into the mainline
kernel — not least of all because it has a large performance impact in its
current form — but it is likely to once again be a topic of discussion at the
2025

Linux Filesystem, Memory Management, and BPF Summit.

Post Syndicated from daroc original https://lwn.net/Articles/1015055/

Security updates have been issued by Debian (chromium), Fedora (fluent-bit, openssh, php, and webkitgtk), Mageia (freerdp), Oracle (libreoffice and webkit2gtk3), Red Hat (kernel-rt), Slackware (libarchive), SUSE (apptainer, gitea-tea, libxml2, tomcat, webkit2gtk3, and wpa_supplicant), and Ubuntu (libxslt and pam-pkcs11).

Post Syndicated from daroc original https://lwn.net/Articles/1013640/

Modern CPUs all have multiple hardware vulnerabilities that the kernel needs to mitigate;
the 6.13 kernel has workarounds for 14 security-sensitive CPU bugs just on x86_64.
Several of those have multiple variants,
or multiple mitigations that apply on different microarchitectures. There are
different kernel command-line options for each of these mitigations, which leads
to a confusing situation for users trying to figure out how to configure their
systems. David Kaplan recently posted

a patch set that adds a single, unified command-line option for controlling
mitigations and
simplifies the logic for detecting, configuring, and
applying them as well.
If it is merged, the patch set could
make it much easier for users to navigate the complicated web of CPU
vulnerabilities and their mitigations.

Post Syndicated from daroc original https://lwn.net/Articles/1014183/

Security updates have been issued by Fedora (iniparser, thunderbird, trafficserver, and xorg-x11-server), Mageia (opensc), Oracle (.NET 8.0, .NET 9.0, gcc, kernel, and libxml2), Red Hat (firefox, grub2, and krb5), Slackware (libxslt), SUSE (amazon-ssm-agent, bsdtar, build, ffmpeg-4, forgejo-runner, kernel, python, python3, python313, rubygem-rack-1_6, and tailscale), and Ubuntu (linux-azure, linux-azure-5.15, linux-azure-fde, linux-azure-fde-5.15).

Post Syndicated from daroc original https://lwn.net/Articles/1012809/

The Zig project has

announced the release of the 0.14 version of the language,
including changes from more than 250 contributors. Zig is a low-level,
memory-unsafe programming language that aims to compete with C instead of
depending on it. Even though the language has not yet had a stable release,
there are a number of projects using it as an alternative to C with better
metaprogramming.
While the project’s release
schedule has been a bit inconsistent, with the release of version 0.14 being

delayed
several times, the release contains a number of new convenience features,
broader architecture support, and the next steps toward removing Zig’s
dependency on LLVM.

Post Syndicated from daroc original https://lwn.net/Articles/1013844/

The LLVM project’s Fortran compiler, which has for many years gone by the name “flang-new”, will now simply be “flang”, starting from LLVM’s 20.1.0 release on March 4. The

announcement, which includes details about the history of flang, comes after a long period of development and discussion. The community has considered renaming flang several times before now, but has always held off out of a feeling that the compiler was not yet ready. Now, the members of the project believe that flang has become stable and complete enough to earn its name.

We are almost 10 years from the first announcement of what would
become LLVM Flang. In the LLVM monorepo alone there have been close
to 10,000 commits from around 400 different contributors. Undoubtedly
more in Classic Flang before that.

Post Syndicated from daroc original https://lwn.net/Articles/1013581/

The Python project’s recent switch to a tail-calling interpreter may not provide as large a speed advantage as initially thought. A blog post from Nelson Elhage gives the details. In short, switching to a tail-call-based interpreter accidentally works around an unfixed regression in LLVM 19. On other compilers, the performance benefit (while still present) is more moderate.

When the tail-call interpreter was announced, I was surprised and impressed by the performance improvements, but also confused: I’m not an expert, but I’m passingly-familiar with modern CPU hardware, compilers, and interpreter design, and I couldn’t explain why this change would be so effective. I became curious – and perhaps slightly obsessed – and the reports in this post are the result of a few weeks of off-and-on compiling and benchmarking and disassembly of dozens of different Python binaries, in an attempt to understand what I was seeing.

Post Syndicated from daroc original https://lwn.net/Articles/1013561/

Security updates have been issued by Debian (openvpn and thunderbird), Fedora (buildah, chromium, podman-tui, python-spotipy, qt6-qtwebengine, and vim), Mageia (chromium-browser-stable and gpac), Oracle (krb5), Red Hat (firefox, kernel, kernel-rt, libxml2, and pcs), SUSE (buildah, chromedriver, chromium, firefox, go1.23, go1.24, grype, python, python311-GitPython, ruby3.4-rubygem-rack, thunderbird, and xen), and Ubuntu (xorg-server, xorg-server-hwe-16.04, xorg-server-hwe-18.04).

Post Syndicated from daroc original https://lwn.net/Articles/1013395/

Greg Kroah-Hartman has announced the release of four more stable kernels:
6.13.6,
6.12.18,
6.6.81, and
6.1.130.
Unlike a normal release, Kroah-Hartman did not call for all users to
update their kernels. Specifically, the 6.6.81 kernel is currently broken on
i386 systems, and users should wait for 6.6.82.

Post Syndicated from daroc original https://lwn.net/Articles/1012946/

On January 20, Thomas Weißschuh shared a new

patch set implementing an alternate method for checking the integrity of
loadable kernel modules. This mechanism, which checks module integrity based
on hashes computed at build time instead of using cryptographic signatures,
could enable reproducible kernel builds in more contexts. Several distributions
have already expressed interest in the patch set if Weißschuh can get it
into the kernel.

Post Syndicated from daroc original https://lwn.net/Articles/1013336/

Security updates have been issued by Debian (chromium), Fedora (firefox and man2html), Mageia (erlang, ffmpeg, and vim), Oracle (doxygen, firefox, python-jinja2, squid, and webkit2gtk3), Red Hat (nodejs:18), SUSE (emacs, go1.23, go1.24, and pcp), and Ubuntu (ansible, firefox, linux-azure, linux-nvidia, and python-django).

Post Syndicated from daroc original https://lwn.net/Articles/1011803/

Functional programming languages have a long association with graphs. In the
1990s, it was even thought that parallel graph-reduction
architectures could make functional programming languages much faster than their
imperative counterparts. Alas, that prediction mostly failed to materialize.
Even though graphs are still used as a theoretical formalism in order to define
and optimize functional languages (such as Haskell’s

spineless tagless graph-machine), they are still mostly compiled down to the same old
non-parallel assembly code that every other language uses. Now, two
projects —

Bend and

Vine — have sprung up attempting to change that, and prove that
parallel graph reduction can be a useful technique for real programs.

Post Syndicated from daroc original https://lwn.net/Articles/1012367/

Security updates have been issued by Debian (emacs, freerdp2, and gst-plugins-good1.0), Fedora (java-17-openjdk, python3.6, and xorg-x11-server-Xwayland), Mageia (radare2), SUSE (libX11, openvswitch3, postgresql13, procps, ruby2.5, webkit2gtk3, and xorg-x11-server), and Ubuntu (git, linux-aws, linux-aws, linux-aws-6.8, linux-aws, linux-oracle, linux-oracle-5.4, linux-ibm, linux-intel-iotg, linux-intel-iotg-5.15, and linux-oem-6.11).

Post Syndicated from daroc original https://lwn.net/Articles/1010905/

The

Faster CPython project has been working to speed up the Python interpreter
for the past several years. Now, Ken Jin, a member of the project, has merged a

new set of changes that
have been

benchmarked as improving performance by 10% for some architectures.
The only change is switching from using computed goto statements to using
tail calls as part of the implementation of Python’s bytecode interpreter — but that change allows
modern compilers to generate significantly better code.

Post Syndicated from daroc original https://lwn.net/Articles/1010404/

The Linux kernel supports attaching BPF programs to many operations.
This is generally safe because the BPF verifier ensures
that BPF programs can’t misuse kernel resources, run indefinitely, or otherwise
escape their boundaries. There is continuing tension, however, between trying
to expand the capabilities of BPF programs and ensuring that the verifier can
handle every edge case. On February 14, Juntong Deng

shared a proof-of-concept patch set that
adds some run-time checks to BPF to make it possible in the future to interrupt
a running BPF program.