All posts by daroc

[$] The current state of Linux architecture support

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.

[$] Magic kernel functions for BPF

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.

[$] An explicit thread-safety proposal for Python

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).

[$] Mergiraf: syntax-aware merging for Git

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
.

[$] Fil-C: A memory-safe C implementation

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.

[$] BPF signing LSM hook change rejected

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.

Security updates for Friday

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).

[$] DebugFS on Rust

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
.

Security updates for Friday

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).

[$] A new API for interrupt-aware spinlocks

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

Boqun Feng spoke at

Kangrejos 2025
about adding a frequently needed API for Rust drivers
that need to handle interrupts: interrupt-aware spinlocks. Most drivers will
need to communicate information from interrupt handlers to main driver code, and
this exchange is frequently synchronized with the use of spinlocks. While his
first attempts ran into problems, Feng’s ultimate solution could help prevent bugs
in C code as well, by tracking the number of nested scopes that have disabled
interrupts. The
patch set
, which contains work from Feng and Lyude Paul, is still under review.

Security updates for Friday

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

Security updates have been issued by Debian (redis and valkey), Fedora (docker-buildkit, ibus-bamboo, pgadmin4, webkitgtk, and wordpress), Mageia (kernel-linus, kmod-virtualbox & kmod-xtables-addons, and microcode), Oracle (compat-libtiff3 and udisks2), Red Hat (rsync), Slackware (python3), SUSE (chromium, cJSON, digger-cli, glow, go1.24, go1.25, go1.25-openssl, grafana, libexslt0, libruby3_4-3_4, pgadmin4, python311-python-socketio, and squid), and Ubuntu (dpdk, libhtp, vim, and webkit2gtk).

[$] Upcoming Rust language features for kernel development

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

The

Rust for Linux
project has been good for Rust, Tyler Mandry, one of the
co-leads of Rust’s language-design team, said. He
gave a talk at

Kangrejos 2025
covering upcoming Rust language features and thanking
the Rust for Linux developers for helping drive them forward. Afterward, Benno Lossin and Xiangfei Ding
went into more detail about their work on the three most important language
features for kernel development: field projections, in-place initialization, and arbitrary self types.

[$] Progress on defeating lifetime-end pointer zapping

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

Paul McKenney gave a remote presentation at

Kangrejos 2025
following up on the
talk he gave last year about the
lifetime-end-pointer-zapping problem: certain common patterns for multithreaded code are
technically undefined behavior, and changes to the C and C++ specifications
will be needed to correct that. Those changes could also impact code that uses
unsafe Rust, such as the kernel’s Rust bindings. Progress on the problem has been slow,
but McKenney believes that a solution is near at hand.

Security updates for Friday

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

Security updates have been issued by AlmaLinux (idm:DL1), Debian (gegl and haproxy), Fedora (ffmpeg, firefox, freeipa, python-pip, rust-astral-tokio-tar, sqlite, uv, webkitgtk, and xen), Oracle (idm:DL1, ipa, kernel, perl-JSON-XS, and python3), Red Hat (git), SUSE (curl, frr, jupyter-jupyterlab, and libsuricata8_0_1), and Ubuntu (linux-aws, linux-lts-xenial, linux-aws-fips, linux-fips, linux-gcp-fips, linux-azure, linux-azure, linux-azure-6.8, linux-fips, linux-gcp-fips, and linux-intel-iot-realtime, linux-realtime).

[$] Linting Rust code in the kernel

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


Klint
is a Rust compiler extension

developed by Gary Guo
to run some
kernel-specific lint rules, which may also be useful for embedded system
development. He spoke about his
recent work on the project at

Kangrejos 2025
. The next day, Alejandra González
led a discussion about Rust’s normal linter,

Clippy
. The two tools offer complementary approaches to analyzing Rust
kernel code, although both need some additional direction and support from
kernel developers to reach their full potential.

NixOS moderation team resigns

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

The

NixOS
moderation team, which is theoretically

in charge
of ensuring that community participation on the project’s

repositories
and
discussion forum remains welcoming and useful, has released

a joint resignation statement
. This action was motivated by conflict with the project’s steering council (SC), which has repeatedly overridden the moderation team, leading the team members to decide that they could not continue acting as moderators. Arian Van Putten, speaking for the whole team, writes:

The SC has also shown, in private and public conversations, their lack of understanding of basic principles of community management and open communication. They have mistaken quiet and a lack of controversy for success and peace. They have consistently become upset when there is criticism, and gone quiet on crucial issues in between. We have some fundamental conflicts in this community, which absolutely require discussion. Meanwhile, discussion with the SC has only become less effective.

We think that the goal of moderation should not be to avoid difficult conversations – it’s to navigate those difficult conversations in ways that remain safe and constructive. We believe we’ve made considerable progress as a community on making those conversations happen, and we believe they need to happen more for the project to grow, not be suppressed. We thank everyone for the growth that we have seen, and for their efforts to avoid personal focus in discussion, especially recently.

The NixOS project has had problems with community moderation stretching back
more than a year. With the next steering council election coming up soon, it will be interesting to see whether the community selects a council that feels differently or not.

Security updates for Friday

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

Security updates have been issued by AlmaLinux (firefox, kernel, and thunderbird), Debian (ceph and thunderbird), Fedora (chromium, mingw-expat, python-deepdiff, python-orderly-set, python-pip, rust-az-cvm-vtpm, rust-az-snp-vtpm, rust-az-tdx-vtpm, and trustee-guest-components), Oracle (aide, kernel, and thunderbird), Red Hat (firefox, kernel, openssh, perl-YAML-LibYAML, and thunderbird), Slackware (expat), SUSE (jasper, libssh, openjpeg2, and python-pycares), and Ubuntu (linux-aws-6.14, linux-hwe-6.14, linux-azure, linux-hwe-6.8, linux-realtime-6.8, node-sha.js, and pcre2).

[$] Canceling asynchronous Rust

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

Asynchronous Rust code has what Rain Paharia calls a “universal cancellation
protocol
“, meaning that any asynchronous code can be interrupted in the same
way. They claim
that this is both a useful feature when used deliberately, and a source of
errors when done by accident. They presented
about this problem at

RustConf 2025
, offering a handful of techniques to avoid introducing bugs into
asynchronous Rust code.