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

The BPF verifier works, on a theoretical level, by considering every possible
path that a BPF program could take. As a practical matter, however, it needs to
do that in a reasonable amount of time. At the

2025 Linux Plumbers Conference, Mahé Tardy and Paul Chaignon
gave a detailed explanation
(slides;
video) of
the main mechanism that it uses to accomplish that: state pruning. They focused
on two optimizations that help reduce the number of paths the verifier needs to
check, and discussed some of the complications the optimizations introduced to the verifier’s
code.

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

The BPF verifier is complicated. It needs to
check every possible path that a
BPF program’s execution could take. The fact that its determination of whether a
BPF program is safe is based on the whole lifetime of the program, instead of
simple local factors, means that the cause of a verification
failure is not always obvious. Ihor Solodrai and Jordan Rome gave a presentation
(slides)
at the

2025 Linux Plumbers Conference in Tokyo about
the
BPF verifier visualizer that they have been building
to make diagnosing verification failures easier.

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

The

Internet Engineering Task Force (IETF) is the standards body responsible
for the TLS encryption standard — which your browser is using right now
to allow you to read LWN.net. As part of its work to keep TLS secure, the IETF
has been entertaining

proposals to adopt “post-quantum” cryptography (that is,
cryptography that is not known to be easily broken by a quantum computer) for TLS
version 1.3. Discussion of the proposal has exposed a large disagreement between
participants who worried about weakened security and others who worried about
weakened marketability.

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

Emma Smith and Kirill Podoprigora, two of Python’s core developers, have
opened a
discussion about including Rust code in CPython, the reference implementation of
the Python programming language. Initially, Rust would only be used for optional
extension modules, but they would like to see Rust become a required dependency
over time. The initial plan was to make Rust required by 2028, but Smith and
Podoprigora indefinitely postponed that goal in response to concerns raised in the discussion.

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

Loris Cro has published

a detailed YouTube video talking about the terminology used to discuss asynchronicity, concurrency, and parallelism in our recent article about Zig’s new Io interface. Our article is not completely clear because it uses the term “asynchronous I/O” to refer to what should really be called “non-blocking I/O“, and sometimes confuses asynchronicity for concurrency, among other errors of terminology, he says. Readers interested in precise details about Zig’s approach and some of the motivation behind the design may find Cro’s video interesting.

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

The designers of the

Zig programming language have been working to find a
suitable design for asynchronous code for some time.
Zig is a carefully minimalist language, and its

initial design for
asynchronous I/O did not fit well with its other
features. Now, the project has

announced (in a Zig SHOWTIME video) a new approach to asynchronous I/O that
promises to solve the

function coloring problem, and allows writing code that will execute
correctly using either synchronous or asynchronous I/O.

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

Security updates have been issued by AlmaLinux (bind, binutils, delve and golang, expat, firefox, haproxy, kernel, libsoup3, libssh, libtiff, openssh, openssl, pam, podman, python-kdcproxy, shadow-utils, squid, thunderbird, vim, xorg-x11-server-Xwayland, and zziplib), Debian (cups-filters, libsdl2, linux-6.1, net-snmp, pdfminer, rails, and tryton-sao), Fedora (chromium, docker-buildkit, docker-buildx, and sudo-rs), Gentoo (librnp), Mageia (webkit2), SUSE (amazon-ssm-agent, buildah, curl, dpdk, fontforge-20251009, kernel, libIex-3_4-33, librnp0, python311, rclone, and sssd), and Ubuntu (linux, linux-aws, linux-aws-6.8, linux-ibm, linux-lowlatency, linux-lowlatency-hwe-6.8, linux-nvidia, linux-nvidia-6.8, linux-nvidia-lowlatency, linux-oracle, linux-aws-6.14, linux-oracle-6.14, linux-aws-fips, linux-fips, linux-gcp-fips, linux-realtime, linux-realtime-6.8, mupdf, openjdk-17, openjdk-8, and openjdk-lts).

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

Security updates have been issued by AlmaLinux (buildah, firefox, go-rpm-macros, kernel, kernel-rt, podman, and thunderbird), Debian (erlang, python-gevent, and r-cran-gh), Fedora (buildah, chromium, k9s, kubernetes1.33, kubernetes1.34, podman, python-mkdocs-include-markdown-plugin, and webkitgtk), Gentoo (Chromium, Google Chrome, Microsoft Edge. Opera, qtsvg, redict, redis, UDisks, and WebKitGTK+), Mageia (cups-filters and ruby-rack), Oracle (kernel and libssh), Red Hat (.NET 8.0, tigervnc, xorg-x11-server, and xorg-x11-server-Xwayland), SUSE (act, bind, cups-filters, govulncheck-vulndb, grub2, libebml, python39, and tcpreplay), and Ubuntu (linux-raspi, linux-raspi-realtime, openjdk-21, openjdk-25, python3.12, python3.11, python3.10, python3.9, python3.8, python3.7, python3.6, python3.5, python3.4, and runc-app, runc-stable).

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

Greg Kroah-Hartman has announced the release of the
6.17.9,
6.12.59, and
6.6.117 stable kernels. As usual, he advises
users of stable kernels to upgrade.

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

Security updates have been issued by Fedora (calibre, chromium, cri-o1.32, cri-o1.33, cri-o1.34, dotnet10.0, dovecot, gnutls, gopass, gopass-hibp, gopass-jsonapi, kubernetes1.31, kubernetes1.32, kubernetes1.33, kubernetes1.34, and linux-firmware), Mageia (ffmpeg, kernel, kmod-xtables-addons & kmod-virtualbox, kernel-linus, konsole, and redis), Red Hat (bind and bind-dyndb-ldap and kernel), SUSE (act, alloy, amazon-ssm-agent, ansible-12, ansible-core, blender, chromium, cups-filters, curl, elfutils, expat, firefox, glib2, grub2, helm, kernel, libipa_hbac-devel, libxslt, nvidia-container-toolkit, ongres-scram, openexr, podman, poppler, runc, samba, sssd, thunderbird, and tomcat), and Ubuntu (cups-filters, linux, linux-aws, linux-gcp, linux-hwe-6.14, linux-oracle, linux-realtime, linux-oem-6.14, and linux-realtime-6.14).

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

The Linux kernel
supports a large number of architectures.
Not all of those are supported by Linux distributions, but Debian does support
many of them, officially or unofficially. On October 26, Bastian Blank

opened a discussion about the minimum version of these architectures
that Debian should support: in particular, raising the de-facto minimum
versions in the next Debian release (“forky”). Thread participants were generally in favor of
keeping support for older architecture variants, but didn’t reach a firm
conclusion.

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

There have been several recent announcements about Linux distributions changing
the list of architectures they support, or adjusting how they build binaries for
some versions of those architectures.
Ubuntu introduced architecture variants, Fedora
considered dropping support for i686 but
reversed course after some pushback, and Debian developers

have discussed raising its architecture baseline for the upcoming

Debian 14
(“forky”).
Linux supports a large number of architectures, and it’s not always
clear where or by whom they are used.
With increasing concerns about diminishing support for legacy
architectures, it’s a good time to look at the overall state of architecture
support on Linux.

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

When programs written in BPF (the kernel’s hot-loadable virtual-machine
bytecode) call kernel functions (kfuncs), it may be useful
for those functions to have additional information about the context in which
those BPF programs are executing. Rather than requiring it to supply
that information, it would be convenient to let the BPF verifier pass that
information to the called function automatically. That is already possible, but

a recent patch set from Ihor Solodrai would make it more ergonomic.
It allows kernel
developers to specify that a kfunc should be passed additional
parameters inferred by the verifier, invisibly to the BPF program. The
discussion included concerns that Solodrai’s implementation was unnecessarily
complex, however.

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

Python already has several ways to run programs concurrently —
including asynchronous functions, threads, subinterpreters, and multiprocessing
— but all of those options have drawbacks of one kind or another.

PEP 703 (“Making the Global Interpreter Lock Optional in CPython”)
removed a major barrier to running Python
threads in parallel, but also exposed Python programmers to the same tricky
synchronization problems found in other languages supporting multithreaded
programs. A new draft proposal
by Mark Shannon,

PEP 805 (“Safe Parallel Python”), suggests a way for the CPython runtime
to cut down on concurrency bugs, making it more practical for Python programmers
to use versions of the language without the global interpreter lock (GIL).

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

The idea of automatic syntax-aware merging in version-control systems goes back to

2005 or earlier, but initial implementations were
often language-specific and slow.

Mergiraf is a merge-conflict resolver that uses a generic algorithm plus a
small amount of language-specific knowledge
to solve conflicts that Git’s default strategy cannot.
The project’s contributors have been working on the
tool for just under a year, but it already

supports 33 languages, including C,
Python, Rust, and even

SystemVerilog.

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

Fil-C is a memory-safe implementation of C and C++ that aims to let C code —
complete with pointer arithmetic, unions, and other features that are often
cited as a problem for memory-safe languages — run safely, unmodified.
Its dedication to being “fanatically
compatible” makes it an attractive choice for retrofitting memory-safety
into existing applications. Despite the project’s relative youth and single
active contributor, Fil-C is capable of compiling an
entire memory-safe Linux user space (based on

Linux From Scratch),
albeit with some modifications to the more complex programs. It also features
memory-safe signal handling and a concurrent garbage collector.

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

BPF lets users load programs into a running kernel.
Even though BPF programs are checked by the verifier to
ensure that they stay inside certain limits, some users would still like to ensure
that only approved BPF programs are loaded. KP Singh’s

patches adding that capability to the kernel were accepted
in version 6.18, but not everyone is
satisfied with his implementation. Blaise Boscaccy, who has been working to get
a version of BPF code signing with better auditability
into the kernel for some time, posted

a patch set on top of Singh’s changes that alters the loading process to
not invoke security module hooks
until the entire loading process is complete.
The discussion on the patch
set is the continuation of a

long-running disagreement over
the interface for signed BPF programs.

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

Security updates have been issued by AlmaLinux (webkit2gtk3), Debian (bind9, chromium, python-internetarchive, and tryton-sao), Fedora (dokuwiki and php-php81_bc-strftime), Mageia (firefox, nss & rootcerts and thunderbird), Slackware (openssl), SUSE (bleachbit, chromium, kernel, mozilla-nss, and python311-uv), and Ubuntu (fetchmail, golang-go.crypto, and linux-oracle-5.4).

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

DebugFS is the kernel’s anything-goes, no-rules interface: whenever a kernel
developer needs quick access to internal details of the kernel to debug a
problem, or to implement an experimental control interface,
they can expose them via DebugFS. This is possible because DebugFS is not subject
to the normal rules for user-space-interface stability, nor to the rules about
exposing sensitive kernel information. Supporting DebugFS in Rust drivers is an
important step toward being able to debug real drivers on real hardware. Matthew
Maurer spoke at

Kangrejos 2025 about his recently merged

DebugFS bindings for Rust.

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

Security updates have been issued by AlmaLinux (kernel and libssh), Debian (firefox-esr and pgpool2), Mageia (varnish & lighttpd), Red Hat (python3, python3.11, python3.12, python3.9, and python39:3.9), SUSE (expat, gstreamer-plugins-rs, kernel, openssl1, pgadmin4, python311-ldap, and squid), and Ubuntu (dotnet8, dotnet9, dotnet10 and mupdf).