Brief items
Security
Just about every Windows and Linux device vulnerable to new LogoFAIL firmware attack (Ars Technica)
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.
Security quote of the week
But it's worse than that. When a tech company designs a device for remote, irreversible, nonconsensual downgrades, they invite both external and internal parties to demand those downgrades. Like Pavel Chekov says, a phaser on the bridge in Act I is going to go off by Act III. Selling a product that can be remotely, irreversibly, nonconsensually downgraded inevitably results in the worst person at the product-planning meeting proposing to do so. The fact that there are no penalties for doing so makes it impossible for the better people in that meeting to win the ensuing argument, leading to the moral injury of seeing a product you care about reduced to a pile of shit: https://pluralistic.net/2023/11/25/moral-injury/#enshittification— Cory DoctorowBut even if everyone at that table is a swell egg who wouldn't dream of enshittifying the product, the existence of a remote, irreversible, nonconsensual downgrade feature makes the product vulnerable to external actors who will demand that it be used. Back in 2022, Adobe informed its customers that it had lost its deal to include Pantone colors in Photoshop, Illustrator and other "software as a service" packages. As a result, users would now have to start paying a monthly fee to see their own, completed images. Fail to pay the fee and all the Pantone-coded pixels in your artwork would just show up as black: https://pluralistic.net/2022/10/28/fade-to-black/#trust-the-process
Kernel development
Kernel release status
The current development kernel is 6.7-rc5, released on December 10. Linus said:
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.
Stable updates: 6.6.5, 6.1.66, 5.15.142, 5.10.203, 5.4.263, 4.19.301, and 4.14.332 were released on December 8, followed by 6.6.6 and 6.1.67 on December 11, and 6.6.7, 6.1.68, 5.15.143, 5.10.204, 5.4.264, 4.19.302, and 4.14.333 on December 13. Anybody who installed 6.1.64 or 6.1.65 will likely want to update to get the fix for the ext4 data-corruption regression.
Ext4 data corruption in stable kernels
There is a problem in multiple stable kernel releases that is causing data corruption in ext4 filesystems. It is caused by a problematic commit that is in multiple stable kernels:The commit got merged in 6.5-rc1 so all stable kernels that have 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") before 6.5 are corrupting data - I've noticed at least 6.1 is still carrying the problematic commit.
More information can be found in a Debian bug report. It has also delayed the release of Debian 12.3 images. "Please do not upgrade any systems at this time, we urge caution for users
with UnattendeUpgrades configured.
"
(Thanks to Alex Ridevski for giving us a heads up on this.)
The end of vger.kernel.org
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.
Rust for Linux — in space
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).
Quote of the week
hp2:/usr/src/mm> git log | grep Singed-off-by | wc -l— Andrew Morton
59(sounds painful)
Development
Graber: LXD now re-licensed and under a CLA
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.
OpenPGP for application developers
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).
Miscellaneous
Bottomley: Solving the Looming Developer Liability Problem
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.
Page editor: Jake Edge
Next page:
Announcements>>