Linux Kernel 6.10 Released

“The latest version of the Linux kernel adds an array of improvements,” writes the blog OMG Ubuntu, ” including a new memory sealing system call, a speed boost for AES-XTS encryption on Intel and AMD CPUs, and expanding Rust language support within the kernel to RISC-V.”
Plus, like in all kernel releases, there’s a glut of groundwork to offer “initial support” for upcoming CPUs, GPUs, NPUs, Wi-Fi, and other hardware (that most of us don’t use yet, but require Linux support to be in place for when devices that use them filter out)…

Linux 6.10 adds (after much gnashing) the mseal() system call to prevent changes being made to portions of the virtual address space. For now, this will mainly benefit Google Chrome, which plans to use it to harden its sandboxing. Work is underway by kernel contributors to allow other apps to benefit, though. A similarly initially-controversial change merged is a new memory-allocation profiling subsystem. This helps developers fine-tune memory usage and more readily identify memory leaks. An explainer from LWN summarizes it well.

Elsewhere, Linux 6.10 offers encrypted interactions with trusted platform modules (TPM) in order to “make the kernel’s use of the TPM reasonably robust in the face of external snooping and packet alteration attacks”. The documentation for this feature explains: “for every in-kernel operation we use null primary salted HMAC to protect the integrity [and] we use parameter encryption to protect key sealing and parameter decryption to protect key unsealing and random number generation.” Sticking with security, the Linux kernel’s Landlock security module can now apply policies to ioctl() calls (Input/Output Control), restricting potential misuse and improving overall system security.

On the networking side there’s significant performance improvements to zero-copy send operations using io_uring, and the newly-added ability to “bundle” multiple buffers for send and receive operations also offers an uptick in performance…

A couple of months ago Canonical announced Ubuntu support for the RISC-V Milk-V Mars single-board computer. Linux 6.10 mainlines support for the Milk-V Mars, which will make that effort a lot more viable (especially with the Ubuntu 24.10 kernel likely to be v6.10 or newer). Others RISC-V improvements abound in Linux 6.10, including support for the Rust language, boot image compression in BZ2, LZ4, LZMA, LZO, and Zstandard (instead of only Gzip); and newer AMD GPUs thanks to kernel-mode FPU support in RISC-V.

Phoronix has their own rundown of Linux 6.10, plus a list of some of the highlights, which includes:

The initial DRM Panic infrastructure
The new Panthor DRM driver for newer Arm Mali graphics
Better AMD ROCm/AMDKFD support for “small” Ryzen APUs and new additions for AMD Zen 5.
AMD GPU display support on RISC-V hardware thanks to RISC-V kernel mode FPU
More Intel Xe2 graphics preparations
Better IO_uring zero-copy performance
Faster AES-XTS disk/file encryption with modern Intel and AMD CPUs
Continued online repair work for XFS
Steam Deck IMU support
TPM bus encryption and integrity protection

Read more of this story at Slashdot.

After Criticism, Signal Agrees to Secure Plain-Text Encryption Keys for Users’ Message Databases

“Signal is finally tightening its desktop client’s security,” reports BleepingComputer — by changing the way it stores plain text encryption keys for the SQLite database where users’ messages are stored:

When BleepingComputer contacted Signal about the flaw in 2018, we never received a response. Instead, a Signal Support Manager responded to a user’s concerns in the Signal forum, stating that the security of its database was never something it claimed to provide. “The database key was never intended to be a secret. At-rest encryption is not something that Signal Desktop is currently trying to provide or has ever claimed to provide,” responded the Signal employee…

[L]ast week, mobile security researchers Talal Haj Bakry and Tommy Mysk of Mysk Inc warned on X not to use Signal Desktop because of the same security weakness we reported on in 2018… In April, an independent developer, Tom Plant, created a request to merge code that uses Electron’s SafeStorage API “…to opportunistically encrypt the key with platform APIs like DPAPI on Windows and Keychain on macOS,” Plant explained in the merge request… When used, encryption keys are generated and stored using an operating system’s cryptography system and secure key stores. For example, on Macs, the encryption key would be stored in the Keychain, and on Linux, it would use the windows manager’s secret store, such as kwallet, kwallet5, kwallet6, and gnome-libsecret… While the solution would provide additional security for all Signal desktop users, the request lay dormant until last week’s X drama.

Two days ago, a Signal developer finally replied that they implemented support for Electron’s safeStorage, which would be available soon in an upcoming Beta version. While the new safeStorage implementation is tested, Signal also included a fallback mechanism that allows the program to decrypt the database using the legacy database decryption key…

Signal says that the legacy key will be removed once the new feature is tested.

“To be fair to Signal, encrypting local databases without a user-supplied password is a problem for all applications…” the article acknowledges.
“However, as a company that prides itself on its security and privacy, it was strange that the organization dismissed the issue and did not attempt to provide a solution…”

Read more of this story at Slashdot.