All posts by corbet

Kernel prepatch 6.11-rc1

Post Syndicated from corbet original https://lwn.net/Articles/983760/

Linus Torvalds has released 6.11-rc1 and closed the
merge window for this development cycle. “The merge window felt pretty
normal, and the stats all look pretty normal too. I was expecting things to
be quieter because of summer vacations, but that (still) doesn’t actually
seem to have been the case.”

Note that the extensible scheduler class
(“sched_ext”) was not merged, even though Torvalds had said he would back in June. Sched_ext, it
seems, will need another development cycle out of tree.

[$] May the FOLL_FORCE not be with you

Post Syndicated from corbet original https://lwn.net/Articles/983169/

One of the simplest hardening concepts to understand is that memory should
never be both writable and executable, otherwise an attacker can use it to
load and run arbitrary code. That rule is generally followed in Linux
systems, but there is a glaring loophole that is exploitable from user
space to inject code into a running process. Attackers have duly exploited
it. A new effort to close the hole ran into trouble early in the merge
window, but a solution may yet be found in time for the 6.11 kernel
release.

[$] What became of getrandom() in the vDSO

Post Syndicated from corbet original https://lwn.net/Articles/983186/

In the previous episode of the
vgetrandom() story, Jason Donenfeld had put together a version of
the getrandom()
system call that ran in user space, significantly improving performance for
applications that need a lot of random data while retaining all of the
guarantees provided by the system call. At that time, it seemed that a
consensus had built around the implementation and that it was headed toward
the mainline in that form. A few milliseconds after that article was
posted, though, a Linus-Torvalds-shaped obstacle appeared in its path.
That obstacle has been overcome and this work has now been merged for the
6.11 kernel, but its form has changed somewhat.

Zuckerberg: Open Source AI Is the Path Forward

Post Syndicated from corbet original https://lwn.net/Articles/982954/

Mark Zuckerberg has posted
an article announcing some new releases of the Llama large language
model and going on at length about why open-source models are important:

AI has more potential than any other modern technology to increase
human productivity, creativity, and quality of life – and to
accelerate economic growth while unlocking progress in medical and
scientific research. Open source will ensure that more people
around the world have access to the benefits and opportunities of
AI, that power isn’t concentrated in the hands of a small number of
companies, and that the technology can be deployed more evenly and
safely across society.

There is an ongoing debate about the safety of open source AI
models, and my view is that open source AI will be safer than the
alternatives. I think governments will conclude it’s in their
interest to support open source because it will make the world more
prosperous and safer.

Of course, whether Llama is truly open source is debatable at best, but it
is more open than many of the alternatives.

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/982939/

Security updates have been issued by Fedora (gtk3 and jpegxl), Red Hat (kpatch-patch and thunderbird), SUSE (apache2, git, gnome-shell, java-11-openjdk, java-21-openjdk, kernel, kernel-firmware, kernel-firmware-nvidia-gspx-G06, libgit2, mozilla-nss, nodejs20, python-Django, and python312), and Ubuntu (linux-aws, linux-aws, linux-aws-5.4, linux-iot, linux-aws-5.15, pymongo, and ruby-rack).

[$] Restricting execution of scripts — the third approach

Post Syndicated from corbet original https://lwn.net/Articles/982085/

The kernel will not consent to execute just any file that happens to be
sitting in a filesystem; there are formalities, such as the checking of
execute permission and consulting security policies, to get through first.
On some systems, security policies have been established to limit execution
to specifically approved programs. But there are files that are not
executed directly by the kernel; these include scripts fed to language
interpreters like Python, Perl, or a shell. An attacker who is able to get
an interpreter to execute a file may be able to bypass a system’s security
policies. Mickaël Salaün has been working on closing this hole for years;
the latest
attempt takes the form of a new flag to the execveat()
system call.

[$] The first half of the 6.11 merge window

Post Syndicated from corbet original https://lwn.net/Articles/982034/

The merge window for the 6.11 kernel release opened on July 14; as of
this writing, 4,072 non-merge changesets have been pulled into the mainline
repository since then. This merge window, in other words, is just now
beginning. Still, there has been enough time for a number of interesting
changes to land for the next kernel release; read on for a summary of what
has been merged so far.

Silva: How to use the new counted_by attribute in C (and Linux)

Post Syndicated from corbet original https://lwn.net/Articles/982275/

Gustavo A. R. Silva describes
the path to safer flexible arrays in the kernel, thanks to the
counted_by attribute supported by Clang 18 and GCC 15.

There are a number of requirements to properly use the
counted_by attribute. One crucial requirement is that the
counter must be initialized before the first reference to the
flexible-array member. Another requirement is that the array must
always contain at least as many elements as indicated by the
counter.

See also: this article from 2023.

Security updates for Tuesday

Post Syndicated from corbet original https://lwn.net/Articles/982169/

Security updates have been issued by Debian (kernel), Fedora (erlang-jose, mingw-python-certifi, and yt-dlp), Mageia (firefox, nss, libreoffice, sendmail, and tomcat), Red Hat (firefox, ghostscript, git-lfs, kernel, kernel-rt, ruby, and skopeo), SUSE (Botan, cockpit, kernel, nodejs18, p7zip, python3, and tomcat), and Ubuntu (ghostscript, linux, linux-azure, linux-azure-5.15, linux-gcp, linux-gke, linux-gkeop, linux-gkeop-5.15, linux-ibm, linux-intel-iotg, linux-intel-iotg-5.15, linux-kvm, linux-nvidia, linux-oracle, linux-azure-6.5, linux-gcp-6.5, and linux-gke, linux-nvidia).

[$] Development statistics for the 6.10 kernel

Post Syndicated from corbet original https://lwn.net/Articles/981559/

The 6.10 kernel was released
on July 14 after a nine-week development cycle. This time around,
13,312 non-merge changesets were pulled into the mainline repository — the
lowest changeset count since 5.17 in early 2022. Longstanding tradition
says that it is time for LWN to gather some statistics on where the new
code for 6.10 came from and how it got to the mainline; read on for the
details.

The 6.10 kernel has been released

Post Syndicated from corbet original https://lwn.net/Articles/981961/

Linus has
released
the 6.10 kernel.

So the final week was perhaps not quote as quiet as the preceding
ones, which I don’t love – but it also wasn’t noisy enough to
warrant an extra rc.

Changes in 6.10 include
the removal of support for some ancient Alpha CPUs,
shadow-stack support for the x32 sub-architecture,
Rust-language support on RISC-V systems,
support for some Windows NT synchronization
primitives (though it is marked “broken” in 6.10),
the mseal() system call,
fsverity
support in the FUSE filesystem subsystem,
ioctl() support in the Landlock security
module,
the memory-allocation profiling subsystem,
and more.

See the LWN merge-window summaries (part 1, part 2) and the KernelNewbies 6.10 page
for more details.

[$] Reports from OSPM 2024, part 1

Post Syndicated from corbet original https://lwn.net/Articles/981371/

The sixth edition of the Power Management and Scheduling
in the Linux Kernel (OSPM) Summit took place on May 30-31 2024, and was
graciously hosted by the Institut de
Recherche en Informatique de Toulouse (IRIT) in Toulouse, France. This
is the first of a series of articles describing the discussions held at
OSPM 2024; topics covered include latency hints, energy-aware scheduling,
ChromeOS, and user-space schedulers.

An empirical study of Rust for Linux

Post Syndicated from corbet original https://lwn.net/Articles/981635/

The research value of this
USENIX paper by Hongyu Li et al. is not entirely clear, but it does
show that the Rust-for-Linux project is gaining wider attention.

Despite more novice developers being attracted by Rust to the
kernel community, we have found their commits are mainly for
constructing Rust-relevant toolchains as well as Rust crates alone;
they do not, however, take part in kernel code development. By
contrast, 5 out of 6 investigated drivers (as seen in Table 5) are
mainly contributed by authors from the Linux community. This
implies a disconnection be- tween the young and the seasoned
developers, and that the bar of kernel programming is not lowered
by Rust language.

As a bonus, it includes a ChatGPT analysis of LWN and Hacker News comments.