The technique works because although silicon looks opaque at visible light, it is transparent starting at near-infrared wavelengths (roughly 1000 nm and longer). Today's commodity optics and CMOS cameras are actually capable of working with lights at this wavelength; thus, IRIS is a low-cost and effective technique for confirming the construction of chips down to block level. For example, IRIS can readily help determine if a chip has the correct amount of RAM, number of CPU cores, peripherals, bond pads, etc. This level of verification would be sufficient to deter most counterfeits or substitutions.

So it took a bit longer for the commit counts to come down this release than I tend to prefer, but a lot of that seemed to be about various selftest updates (networking in particular) rather than any actual real sign of problems. And the last two weeks have been pretty quiet, so I feel there's no real reason to delay 6.8.

Significant changes in this release include the deadline servers scheduling feature, support for memory-management auto-tuning in DAMON, the large anonymous folios feature, the kernel samepage merging advisor, the ability to prevent writes to block devices containing mounted filesystems, the listmount() and statmount() system calls, the first device driver written in Rust, the removal of the (never finished) bpfilter packet-filtering system, three new system calls for managing Linux security modules, support for data-type profiling in the perf tool, guest-first memory for KVM virtualization, the Intel Xe graphics driver, and a lot more. See the LWN merge-window summaries (part 1, part 2) for more information.

It's by no means "[devastating]" for the DNS, and the fix is much the same as the previous fix. As well as limiting the number of queries that a resolver can generate to resolve a queried name, a careful resolver will limit both the elapsed time and perhaps the amount of the resolver's processing resources that are used to resolve any single query name.

It's also not a novel discovery by the ATHENE folk. The vulnerability was described five years ago by a student at the University of Twente. I guess the issue was that the student failed to use a sufficient number of hysterical adjectives in describing this DNS vulnerability in the paper!

Serialization is the process of transforming Python objects into a sequence of bytes which can be used to recreate a copy of the object later — or on another machine. pickle is Python's native serialization module. It can store complex Python objects, making it an appealing prospect for moving data without having to write custom serialization code. For example, pickle is an integral component of several file formats used for machine learning. However, using pickle to deserialize untrusted files is a major security risk, because doing so can invoke arbitrary Python functions. Consequently, the machine-learning community is working to address the security issues caused by widespread use of pickle.

Herb Sutter, chair of the ISO C++ standards committee, writes about the current problems with writing secure C++, and his personal opinion on next steps to address this while maintaining backward compatibility.

If there were 90-98% fewer C++ type/bounds/initialization/lifetime vulnerabilities we wouldn't be having this discussion. All languages have CVEs, C++ just has more (and C still more); so far in 2024, Rust has 6 CVEs, and C and C++ combined have 61 CVEs. So zero isn't the goal; something like a 90% reduction is necessary, and a 98% reduction is sufficient, to achieve security parity with the levels of language safety provided by MSLs [memory-safe languages]… and has the strong benefit that I believe it can be achieved with perfect backward link compatibility (i.e., without changing C++'s object model, and its lifetime model which does not depend on universal tracing garbage collection and is not limited to tree-based data structures) which is essential to our being able to adopt the improvements in existing C++ projects as easily as we can adopt other new editions of C++. — After that, we can pursue additional improvements to other buckets, such as thread safety and overflow safety.

RFDS may allow a malicious actor to infer data values previously used in floating point registers, vector registers, or integer registers. RFDS does not provide the ability to choose which data is inferred

Only Atom cores are affected, but those cores can be found inside a number of processors. See this documentation commit for more information.

Kaitlyn Abdo of Fedora's AI/ML SIG opened an issue with the Fedora Engineering Steering Committee (FESCo) recently that carried a few tricky questions about packaging machine-learning (ML) models for Fedora. Specifically, the SIG is looking for guidance on whether pre-trained weights for PyTorch constitute code or content. And, if the models are released under a license approved by the Open Source Initiative (OSI), does it matter what data the models were trained on? The issue was quickly tossed over to Fedora's legal mailing list and sparked an interesting discussion about how to handle these items, and a temporary path forward.

Sasha Levin has announced the release of the 6.8.1, 6.7.10, 6.6.22, 6.1.82, 5.15.152, 5.10.213, 5.4.272, and 4.19.310 stable kernels. As always, they contain important fixes throughout the tree. Users of those kernels should upgrade.

Zach Mitchell has announced the 1.0 release of Flox, a tool that lets its users install packages from nixpkgs inside portable virtual environments, and share those virtual environments with others as an alternative to Docker-style containers. Flox is based on Nix but allows users to skip learning how to work with the Nix language:

With Flox we're providing a substantially better user experience. We provide the suite of package manager functionality with install, uninstall, etc, but we also provide an entire new suite of functionality with the ability to share environments via flox push, flox pull, and flox activate --remote.

Flox is GPLv2-licensed, and releases are available as RPMs and Debian packages for x86_64 and arm64 systems.

Cranelift is an Apache-2.0-licensed code-generation backend being developed as part of the Wasmtime runtime for WebAssembly. In October 2023, the Rust project made Cranelift available as an optional component in its nightly toolchain. Users can now use Cranelift as the code-generation backend for debug builds of projects written in Rust, making it an opportune time to look at what makes Cranelift different. Cranelift is designed to compete with existing compilers by generating code more quickly than they can, thanks to a stripped-down design that prioritizes only the most important optimizations.