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

Security updates have been issued by Debian (chromium, nodejs, openjdk-17, and thunderbird), Fedora (firefox, golang-github-nvidia-container-toolkit, and thunderbird), Mageia (kernel), Oracle (ghostscript, glibc, kernel, libxslt, php:8.1, and thunderbird), SUSE (cmctl, firefox-esr, govulncheck-vulndb, java-21-openjdk, libxml2, poppler, python-h11, and redis), and Ubuntu (docker.io, ghostscript, linux-xilinx-zynqmp, and micropython).

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

Modern compilers perform a lot of optimizations, which can complicate debugging.
Song Liu and Thierry Treyer spoke about a potential improvement to

BPF Type Format (BTF) debugging information that could partially combat that
problem at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit.
They want to add information on selectively inlined functions to BTF in order to
better support tracing tools.
Treyer participated remotely.

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

Martin Lau gave a talk in the BPF track of the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit about a performance problem
plaguing the networking subsystem, and some potential ways to fix it. He works on
BPF programs that need to store socket-local data; amid other improvements to
the networking and BPF subsystems, retrieving that data has become a noticeable
bottleneck for his use case. His proposed fix prompted a good deal of discussion
about how the data should be laid out.

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

The Linux kernel can be configured so that
kernel modules must be signed or

otherwise authenticated to be loaded
into the kernel. Some BPF developers want that to be an option for BPF programs
as well — after all, if those are going to run as part of the kernel,
they should be subject to the same code-signing requirements. Blaise Boscaccy
and Cong Wang presented two different visions for how BPF code signing could
work at the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit.

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

Anton Protopopov kicked off the BPF track on
the second day of the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit with a discussion about permitting
indirect calls in BPF. He also spoke about his continuing work on

static keys, a topic which is related because the implementation of indirect
jumps and static keys in the verifier use some of the same mechanisms for
tracking indirect control-flow.
Although some design work remains to be done, it may soon be
possible to make indirect calls in BPF without any extra work compared to normal
C.

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

The Python Steering Council

accepted PEP 750
(“Template Strings“) on April 10. LWN
covered the discussion around the proposal, including the
substantial revisions to the idea that were needed for it
to be accepted. Template strings (t-strings) are a new kind of string that produces
structured data instead of a raw string, allowing library authors to build their own custom
template-handling logic.
Since the approval happened before the cutoff for new features (May 6),
support for template strings will be included in Python 3.14, scheduled for October 2025.

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

Security updates have been issued by Debian (graphicsmagick and libapache2-mod-auth-openidc), Fedora (giflib, mod_auth_openidc, mysql8.0, perl, perl-Devel-Cover, perl-PAR-Packer, perl-String-Compare-ConstantTime, rust-openssl, rust-openssl-sys, trunk, and workrave), Mageia (chromium-browser-stable and rust), Oracle (java-1.8.0-openjdk, java-17-openjdk, java-21-openjdk, kernel, libreoffice, and webkit2gtk3), Red Hat (gvisor-tap-vsock), SUSE (containerd, docker, docker-stable, forgejo, GraphicsMagick, libmozjs-115-0, perl-32bit, poppler, subfinder, and thunderbird), and Ubuntu (erlang and ruby2.3, ruby2.5).

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

The BPF verifier is not magic; it cannot solve the

halting problem. Therefore,
it has to err on the side of assuming that a program will run too long if it
cannot prove that the program will not.
The ultimate check on the size of a BPF program is the
one-million-instruction limit — the verifier will refuse to process more than
one-million instructions, no matter what a BPF program does. Alexei Starovoitov gave
a talk at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit about that limit,
why correctly written BPF programs shouldn’t hit it, and how to make the user
experience of large BPF programs better in the future.

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

BPF is, famously, not part of the kernel’s promises of user-space stability. New
kernels can and do break existing BPF programs; the BPF developers try to
fix unintentional regressions as they happen, but the whole thing can be something of a bumpy
ride for users trying to deploy BPF programs across multiple kernel versions.
Shung-Hsi Yu and Daniel Xu had two different approaches to fixing the problem
that they presented at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit.

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

Eduard Zingerman presented a daring proposal that “makes sense if you think
about it a bit” at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF Summit. He wants to inline
performance-sensitive kernel functions
into the BPF programs that call them. His
prototype does not yet address all of the design problems inherent in that idea,
but it did spark a lengthy discussion about the feasibility of his proposal.

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

Security updates have been issued by AlmaLinux (delve and golang and go-toolset:rhel8), Debian (webkit2gtk), Fedora (openvpn, thunderbird, uboot-tools, and zabbix), SUSE (expat, fontforge, govulncheck-vulndb, and kernel), and Ubuntu (haproxy and libsoup2.4, libsoup3).

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

The 6.15 merge window saw the inclusion of a new type of lock for BPF programs:
a resilient queued spinlock that Kumar Kartikeya Dwivedi has been working on
for some time. Eventually, he hopes to convert all of the spinlocks currently
used in the BPF subsystem to his new lock.
He gave a remote presentation about the design of the lock at the
2025 Linux Storage, Filesystem,
Memory-Management, and BPF summit.

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

Pahole (originally “Poke-a-hole”) is a Swiss Army knife for exploring and
editing debug information. Pahole is also currently involved
in the kernel’s build process to rearrange the information
produced by various compilers into a form useful to the BPF verifier, although
there are plans to render it unnecessary.
Pahole maintainer Arnaldo Carvalho de Melo shared some status
updates about the project at the 2025 Linux Storage, Filesystem,
Memory-Management, and BPF summit. Interested readers can find his slides
here.

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

Yonghong Song brought a story about tracking down the cause of a strange verifier error
message to the 2025 Linux Storage, Filesystem, Memory-Management, and BPF
Summit. He then presented some possible ways to improve Clang’s user experience for
anyone running into the same class of error in the future. Toward the end of his
allotted time, he also discussed the problems with optimizations that change the
signature of functions — a problem that José Marchesi had also brought up in
the previous session.

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.