All posts by daroc

[$] Forking Vim to avoid LLM-generated code

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

Many people dislike the proliferation of Large Language Models (LLMs) in recent
years, and so make an understandable attempt to avoid them.
That may not be possible in general, but there are two new forks of
Vim that seek to provide an editing
environment with no LLM-generated code. EVi focuses on being a modern Vim
without LLM-assisted contributions, while Vim Classic focuses on providing a long-term maintenance
version of Vim 8. While both are still in their early phases,
the projects look to be on track to provide stable alternatives — as long as
enough people are interested.

[$] A flood of useful security reports

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

The idea of using large language models (LLMs) to discover security problems is
not new. Google’s Project Zero
investigated
the feasibility of using LLMs for security research in 2024. At the time, they
found that models could identify real problems, but required a good deal of
structure and hand-holding to do so on small benchmark problems. In February
2026, Anthropic
published a report
claiming that the company’s most recent LLM at that point in time, Claude Opus 4.6, had discovered
real-world vulnerabilities in critical open-source software, including the Linux
kernel, with far less scaffolding. On April 7, Anthropic announced a new experimental model that is

supposedly even better
; which they have

partnered with the Linux Foundation

to supply to some open-source developers with access to the tool for security reviews.
LLMs seem to have progressed significantly in the last few months, a change
which is being noticed in the open-source community.

[$] An API for handling arithmetic overflow

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

On March 31, Kees Cook shared

a patch set
that represents the culmination of more than a year of work
toward eliminating the possibility of silent, unintentional integer overflow in
the kernel. Linus Torvalds was

not pleased
with the approach, leading to a detailed discussion about the
meaning of “safe” integer operations and the design of APIs for handling integer
overflows. Eventually, the developers involved reached a consensus for a
different API that should make handling overflow errors in the kernel much less
of a hassle.

[$] Sharing stories on Scuttlebutt

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

Not many people live on sailboats. Things may be better these days, but
back in 2014 sailboat dwellers had
to contend with lag-prone,
intermittent, low-bandwidth internet connections. Dominic Tarr

decided

to fix the problem of keeping up with his friends by developing a delay-tolerant,
fully distributed social-media protocol called

Scuttlebutt
. Nearly twelve
years later, the protocol has gained a number of users who have their own,
non-sailboat-related reasons to prefer a censorship-resistant,
offline-first social-media system.

Exelbierd: What’s actually in a Sashiko review?

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

Brian “bex” Exelbierd has published
a blog
post
exploring follow-up questions raised by
the recent debate about the use of the LLM-based review
tool Sashiko
in the memory-management subsystem. His main finding is that Sashiko reviews are
bi-modal with regards to whether they contain reports about code not directly
changed by the patch set — most do not, but the ones that do often have several
such comments.

Hypothesis 1: Reviewers are getting told about bugs they didn’t create.
Sashiko’s review protocol explicitly instructs the LLM to read surrounding code,
not just the diff. That’s good review practice — but it means the tool might
flag pre-existing bugs in code the patch author merely touched, putting those
problems in their inbox.

Hypothesis 2: The same pre-existing bugs surface repeatedly. If a known
issue in a subsystem doesn’t get fixed between review runs, every patch touching
nearby code could trigger the same finding. That would create a steady drip of
duplicate noise across the mailing list.

I pulled data from Sashiko’s public API and tested both.

[$] The role of LLMs in patch review

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

Discussion of

a memory-management patch set
intended to clean up a helper function for
handling huge pages spiraled into something else entirely after it was posted on March 19.
Memory-management maintainer Andrew Morton

proposed
making changes to the subsystem’s review process, to require
patch authors to respond to feedback from Sashiko,
the

recently released LLM-based kernel patch review system
. Other
sub-maintainers, particularly Lorenzo Stoakes, objected. The
resulting discussion about how and when to adopt Sashiko is potentially relevant
to many other parts of the kernel.

[$] Rust’s next-generation trait solver

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

Rust’s compiler team has been working on a long-term project to

rewrite the trait solver
— the part of the compiler that determines which
concrete function should be called when a programmer uses a trait method that is
implemented for multiple types. The rewrite is intended to simplify
future changes to the trait system, fix a handful of tricky soundness bugs, and
provide faster compile times. It’s also nearly finished, with a relatively
small number of remaining blocking bugs.

[$] Tracking when BPF programs may sleep

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

BPF programs can run in both sleepable and non-sleepable (atomic) contexts.
Currently, sleepable BPF programs are not allowed to enter an atomic context.
Puranjay Mohan has a

new patch set
that changes that. The patch set would let BPF programs called
in sleepable contexts temporarily acquire locks that cause the programs to
transition to an atomic context. BPF maintainer Alexei
Starovoitov objected to parts of the implementation, however, so acceptance of
the patch depends on whether Mohan is willing and able to straighten it out.

[$] BPF comes to io_uring at last

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

The kernel’s asynchronous

io_uring interface
maintains two shared ring buffers:
a submission queue for sending requests to the kernel, and a completion queue
containing the results of those requests. Even with shared memory removing much
of the overhead of communicating with user space, there is still some overhead
whenever the kernel must switch to user space to give it the opportunity to
process completion requests and
queue up any subsequent work items. A

patch set
from Pavel Begunkov minimizes this overhead by letting
programmers extend the io_uring event loop with a BPF program that can enqueue
additional work in response to completion events. The patch set has
been in development for a long time, but has
finally been accepted.

[$] More timing side-channels for the page cache

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

In 2019, researchers published a way to
identify which file-backed pages
were being accessed on a system using timing information from the page cache,
leading to a handful of unpleasant consequences and a change to the design of
the

mincore()
system call. Discussion at the time
led to a number of ad-hoc patches to address the
problem. The lack of new page-cache attacks suggested that attempts to fix
things in a piecemeal fashion had succeeded. Now, however, Sudheendra Raghav Neela,
Jonas Juffinger, Lukas Maar, and Daniel Gruss have
found a new set of
holes
in the Linux kernel’s page-cache-timing protections that allow
the same general class of attack.

[$] HTTPS certificates in the age of quantum computing

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

There has been ongoing discussion in the

Internet Engineering Task Force
(IETF)
about how to protect internet traffic against future quantum computers. So far,
that work has focused on key exchange as the most urgent problem; now,

a new IETF working group
is looking at adopting post-quantum cryptography
for authentication and certificate transparency as well. The main challenge to
doing so is the increased size of
certificates — around 40 times larger. The techniques that the working group is investigating
to reduce that overhead could have efficiency benefits for traditional
certificates as well.

[$] Inspecting and modifying Python types during type checking

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

Python has a

unique approach to static typing
. Python programs can contain type
annotations, and even access those annotations at run time, but the annotations
aren’t evaluated by default. Instead, it is up to external programs to ascribe
meaning to those annotations. The annotations themselves can be arbitrary Python
expressions, but in practice usually involve using helpers from the built-in

typing
module, the meanings of which external type-checkers mostly
agree upon. Yet the type system implicitly defined by the typing module
and common type-checkers is insufficiently powerful to model all of the kinds of
dynamic metaprogramming found in real-world Python programs.
PEP 827 (“Type Manipulation”)
aims to add additional
capabilities to Python’s type system to fix this, but
discussion
of the PEP has been of mixed sentiment.

[$] Magit and Majutsu: discoverable version-control

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


Jujutsu
is an increasingly popular Git-compatible version-control system. It has
a focus on simplifying Git’s conceptual model to produce a smoother, clearer command-line
experience. Some people already have a preferred replacement for Git’s usual
command-line interface, though:

Magit
, an Emacs package for working with Git
repositories that also tries to make the interface more
discoverable.
Now, a handful of people are working to implement a Magit-style interface for Jujutsu:

Majutsu
.

[$] No hardware memory isolation for BPF programs

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

On February 12, Yeoreum Yun posted a
suggestion
for an improvement to the security of the kernel’s BPF implementation: use

memory protection keys
to prevent unauthorized access to memory by BPF
programs.
Yun wanted to put the topic on the list for discussion at the Linux
Storage, Filesystem, Memory Management, and BPF Summit in May, but the
lack of engagement makes that unlikely. They also have a patch set implementing
some of the proposed changes, but has not yet shared that with the mailing list.
Yun’s proposal does not seem likely to be accepted in its
current form, but the kernel has

added hardware-based hardening options
in the
past, sometimes after substantial discussion.

[$] The second half of the 7.0 merge window

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

The 7.0 merge window

closed
on February 22 with 11,588 non-merge commits total,
3,893 of which came in after
the article covering the first half of the merge
window
. The changes in the second half were weighted toward bug fixes over
new features, which is usual. There were still a handful of surprises, however, including
89 separate tiny code-cleanup changes from different people for the rtl8723bs
driver, a number that
surprised
Greg Kroah-Hartman. It’s unusual for a WiFi-chip driver to receive that much
attention, especially a staging driver that is not yet ready for general use.

[$] Open-source Discord alternatives

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

The closed-source chat platform Discord

announced
on February 9 that it would soon require some users to verify their
ages in order to access some content — although the company quickly

added
that
the “vast majority” of users would not have to. That reassurance has to
contend with the fact that the UK and other countries are implementing
increasingly strict age requirements for social media. Discord’s age
verification would be done with an AI age-judging
model or with a government photo ID. A surprising number of open-source
projects use Discord for support or project communications, and some of those
projects are now looking for open-source alternatives. Mastodon, for example,

has moved discussion to Zulip
. There are some alternatives out there, all
with their own pros and cons, that communities may want to consider if they want
to switch away from Discord.

[$] The first half of the 7.0 merge window

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

The merge window for Linux 7.0 has opened, and with it
comes a number of interesting improvements and enhancements. At the time of
writing, there have been 7,695 non-merge commits accepted. The 7.0 release is
not special,

according to the kernel’s versioning scheme
— just the release
that comes after 6.19. Humans love symbolism and round numbers, though, so it
may feel like something of a milestone.

[$] Poisoning scraperbots with iocaine

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

Web sites are being increasingly beset by AI scraperbots — a problem that we have
written about before, and which has slowly
ramped up to an occasional de-facto DDoS attack. This has not gone
uncontested, however: web site operators from around the world have been working on
inventive countermeasures. These solutions target the problem posed by scraperbots in different ways;

iocaine
, a MIT-licensed nonsense generator, is designed
to make scraped text less useful by poisoning it with fake data. The hope is to
make running scraperbots not economically viable, and thereby address the
problem at its root instead of playing an eternal game of Whac-A-Mole.

[$] Kernel control-flow-integrity support comes to GCC

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

Control-flow integrity (CFI) is a set of techniques that make it more difficult for
attackers to hijack indirect jumps to exploit a system. The Linux kernel has
supported forward-edge CFI (which protects indirect function calls)
since 2020, with the most recent implementation
of the feature introduced in 2022. That
version avoids the overhead introduced by the earlier approach by using a
compiler flag (-fsanitize=kcfi) that is present in Clang but not in
GCC. Now, Kees Cook has

a patch set
adding that support to GCC that looks likely to land in GCC
17.

[$] The future for Tyr

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

The

team
behind

Tyr
started 2025 with little to show in our quest to
produce a Rust GPU driver for Arm Mali hardware, and by the end of the
year, we were able to play SuperTuxKart (a 3D open-source racing
game) at the Linux Plumbers Conference (LPC). Our prototype was a joint
effort between Arm, Collabora, and Google; it ran well for the duration
of the event, and the performance was more than adequate for players.
Thankfully, we picked up steam at precisely the right moment: Dave
Airlie just

announced
in the Maintainers Summit that the DRM subsystem
is only “about a year away” from disallowing new drivers written in C
and requiring the use of Rust. Now it is time to lay out a
possible roadmap for 2026 in order to upstream all of this work.