All posts by corbet

[$] Progress toward a GCC-based Rust compiler

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

The gccrs project is an ambitious
effort started in 2014 to implement a Rust compiler within The GNU Compiler
Collection (GCC). Even though the task is far from complete, progress has
been made since LWN’s previous coverage,
according to reports from the project. Meanwhile, another hybrid and more
mature approach to GCC Rust code generation is available in rust_codegen_gcc.

[$] Ext4 data corruption hits the stable kernels

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

The kernel’s stable-update process is intended to produce kernels that are,
well, stable; when that promise is lived up to, users can update to newer
stable updates without fear. By any account, a bug that corrupts data on
ext4 filesystems constitutes a failure to hold to that promise. As is so
often the case, this problem is the result of a chain of failures in a
system that works well most of the time.

Rust for Linux — in space

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

The Rust for Linux (RFL) project may not have (yet) resulted in user-visible
changes to the Linux kernel, but it seems the wider world has taken notice.
Hongyu Li has announced
that the Rust for Linux code is now part of a satellite just launched
out of China. The satellite is running a system called RROS, which follows the old
RTLinux pattern of running a realtime kernel alongside Linux. The realtime
core is written in Rust, using the RFL groundwork.

Despite its imperfections, we still want to share RROS with the
community, showcasing our serious commitment to using RFL for
substantial projects and contributing to the community’s
growth. Our development journey with RROS has been greatly enriched
by the support and knowledge from the RFL community. We also have
received invaluable assistance from enthusiastic forks here,
especially when addressing issues related to safety abstraction

(Thanks to Dirk Behme).

OpenPGP for application developers

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

A new book called OpenPGP for application
developers
has been released under the Creative Commons BY-SA license.

This document is not intended for end-users or implementers of
OpenPGP libraries (or other software that directly handles internal
OpenPGP data structures).

Instead, this document is focused on the second group, application
developers, who use OpenPGP functionality in their software
projects. It describes the properties of the OpenPGP system and its
uses. It presupposes solid knowledge of software development
concepts and of general cryptographic concepts. Thus, this text
describes OpenPGP at the “library-level,” teaching concepts that
will help software developers get started as a user of any
implementation (e.g., OpenPGP.js, Sequoia-PGP).

Security updates for Wednesday

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

Security updates have been issued by Debian (debian-security-support and xorg-server), Fedora (java-17-openjdk, libcmis, and libreoffice), Mageia (fish), Red Hat (buildah, containernetworking-plugins, curl, fence-agents, kernel, kpatch-patch, libxml2, pixman, podman, runc, skopeo, and tracker-miners), SUSE (kernel, SUSE Manager 4.3.10 Release Notes, and SUSE Manager Client Tools), and Ubuntu (gnome-control-center, linux-gcp, linux-kvm, linux-gkeop, linux-gkeop-5.15, linux-hwe-6.2, linux-lowlatency-hwe-6.2, linux-nvidia-6.2, linux-lowlatency, linux-lowlatency-hwe-5.15, linux-oracle, linux-oracle-5.4, linux-raspi, linux-raspi-5.4, netatalk, and pydantic).

The end of vger.kernel.org

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

Konstantin Ryabitsev has announced
that the movement of kernel mailing lists away from the venerable
vger.kernel.org system is nearly complete:

Over the past few months we’ve migrated all of the vger.kernel.org
mailing lists, with the exception of the Big One (linux-kernel, aka
LKML). This list alone is responsible for about 80% of all vger
mailing list traffic, so we left it for the last.

This Thursday, December 14, at 11AM Pacific (19:00 UTC), we will
switch the MX record for vger to point to the new location
(subspace.kernel.org), which will complete the mailing list
migration from the legacy vger server to the new infrastructure.

Graber: LXD now re-licensed and under a CLA

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

The story of Canonical’s takeover of the LXD container manager, and the
subsequent creation of the Incus fork, has been
simmering for a while. Now Incus developer Stéphane Graber reports
that Canonical has changed the license and contribution terms for LXD:

Per the commit message performing the re-licensing, all further
contributions will be under the AGPLv3 license and all
contributions from Canonical employees have been re-licensed to
AGPLv3.

However, Canonical does not own the copyright on any contribution
from non-employees, such as the many changes they have imported
from Incus over the past few months. Those therefore remain under
the Apache2 license that they were contributed under.

As a result, Canonical cannot release LXD under the AGPLv3 license
and likely never will be able to. LXD is now under a weird mix of
Apache2 and AGPLv3 with no clear metadata indicating what file or
what part of each file is under one license or the other.

He also notes that this change will put an end to the flow of patches — in
either direction — between the two projects.

Security updates for Tuesday

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

Security updates have been issued by Debian (libreoffice and webkit2gtk), Fedora (java-1.8.0-openjdk and seamonkey), Oracle (apr, edk2, kernel, and squid:4), Red Hat (postgresql:12, tracker-miners, and webkit2gtk3), SUSE (curl, go1.20, go1.21, hplip, openvswitch, opera, squid, and xerces-c), and Ubuntu (binutils, ghostscript, libreoffice, linux, linux-aws, linux-aws-5.15, linux-azure, linux-azure-5.15,
linux-azure-fde, linux-azure-fde-5.15, linux-gcp, linux-gke,
linux-hwe-5.15, linux-ibm, linux-ibm-5.15, linux-kvm, linux-nvidia,
linux-oracle, linux-oracle-5.15, linux-raspi, linux, linux-aws, linux-aws-5.4, linux-azure, linux-azure-5.4,
linux-bluefield, linux-gcp, linux-gcp-5.4, linux-hwe-5.4, linux-ibm,
linux-ibm-5.4, linux-kvm, linux-xilinx-zynqmp, postfixadmin, python3.11, and webkit2gtk).

Bottomley: Solving the Looming Developer Liability Problem

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

James Bottomley writes
that open-source developers are increasingly likely to be held liable for
flaws in their code and suggests a solution:

Indemnification means one party, in particular circumstances,
agreeing to be on the hook for the legal responsibilities of
another party. This is actually a well known way not of avoiding
liability but transferring it to where it belongs. As such, it’s
easily sellable in the court of public opinion: we’re not looking
to avoid liability, merely trying to make sure it lands on those
who are making all the money from the code.

[$] Some recent and notable changes to Rust

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

The Rust project makes incremental releases every six
weeks, a fact that makes it easy to overlook some of the
interesting changes coming to the language, such as new
ABIs, better debugger support, asynchronous traits, and
support for C strings.
The end of the year provides an opportunity to look back
over the past several months of updates, and to look
forward to what to expect in 2024.

Kernel prepatch 6.7-rc5

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

The 6.7-rc5 kernel prepatch is out for
testing.

Nothing looks particularly scary, which is good, because if it had
been, I wouldn’t have had the capacity to deal with it last week.

Let’s hope it stays that way even as I am getting better. Because the
holidays are almost upon us, and I’m woefully underprepared.

[$] Modern C for Fedora (and the world)

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

It can be instructive to pull down the dog-eared copy of the first edition
of The C Programming Language that many of us still have on our
bookshelves; the language has changed considerably since that book was
published. Many “features” of early C have been left behind, usually for
good reasons, but there is still a lot of code in the wild that is still
using those features. A concerted effort is being made in both the Fedora
and GCC communities to fix that old code and enable some new errors in the
GCC 14 release (which is in
stage 3
of its development cycle and likely to be released by
mid-2024), but a fair amount of work remains to be done.

[$] Controlling shadow-stack allocation in clone3()

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

User-space shadow stacks are a relatively new feature in Linux; support was
only added for 6.6, and is limited to the x86
architecture
. As support for other architectures (including arm64 and RISC-V) approaches readiness,
though, more thought is going into the API for this feature. As a recent
discussion on the integration of shadow stacks with the clone3() system call shows, there are
still some details to be worked out.

Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack (ars technica)

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

This
ars technica article
describes how secure-boot firmware on a huge range
of systems can be subverted with a malicious image file:

As its name suggests, LogoFAIL involves logos, specifically those
of the hardware seller that are displayed on the device screen
early in the boot process, while the UEFI is still running. Image
parsers in UEFIs from all three major IBVs [independent BIOS
vendors] are riddled with roughly a dozen critical vulnerabilities
that have gone unnoticed until now. By replacing the legitimate
logo images with identical-looking ones that have been specially
crafted to exploit these bugs, LogoFAIL makes it possible to
execute malicious code at the most sensitive stage of the boot
process.

SLAM: a new Spectre technique

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

Many processor vendors provide a mechanism to allow some bits of a pointer
value to be used to store unrelated data; these include Intel’s linear address masking (LAM), AMD’s upper address ignore, and Arm’s top-byte
ignore
. A set of researchers has now come up with a way (that
they call “SLAM”) to use those features to bypass many checks on pointer
validity, opening up a new set of Spectre attacks.

In response to SLAM, Intel made plans to provide software guidance
prior to the future release of Intel processors which support LAM
(e.g., deploying LAM jointly with LASS). Linux engineers developed
patches to disable LAM by default until further guidance is
available. ARM published an advisory to provide guidance on future
TBI-enabled CPUs. AMD did not implement guidance updates and
pointed to existing Spectre v2 mitigations to address the SLAM
exploit described in the paper.

See the full
paper
for the details.

Security updates for Wednesday

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

Security updates have been issued by Fedora (chromium, clevis-pin-tpm2, firefox, keyring-ima-signer, libkrun, perl, perl-PAR-Packer, polymake, poppler, rust-bodhi-cli, rust-coreos-installer, rust-fedora-update-feedback, rust-gst-plugin-reqwest, rust-pore, rust-rpm-sequoia, rust-sequoia-octopus-librnp, rust-sequoia-policy-config, rust-sequoia-sq, rust-sequoia-wot, rust-sevctl, rust-snphost, and rust-tealdeer), Mageia (samba), Red Hat (postgresql:12), SUSE (haproxy and kernel-firmware), and Ubuntu (haproxy, linux, linux-aws, linux-aws-6.2, linux-azure, linux-azure-6.2,
linux-azure-fde-6.2, linux-lowlatency, linux-oracle, linux-raspi,
linux-starfive, linux, linux-aws, linux-kvm, linux-lts-xenial, linux-oem-6.1, and redis).