Brief items

Huang: IRIS (Infra-Red, in situ) Project Updates

Andrew 'bunnie' Huang provides an update on his IRIS infrared chip-scanning project as the starting point for a detailed summary on how chip customers can detect forgeries and modifications in general.

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.

Comments (24 posted)

Huston: KeyTrap!

Geoff Huston digs into the details of the KeyTrap DNS vulnerability, which was disclosed in February.

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!

Comments (6 posted)

Today's hardware vulnerability: register file data sampling

The mainline kernel has just received a set of commits addressing the "register file data sampling" hardware vulnerability.

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.

Comments (11 posted)

Kernel release status

The 6.8 kernel was released on March 10; Linus said:

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.

Stable updates: none have been released in the last week.

Comments (none posted)

Quote of the week

I would argue that use of normal C-language loads and stores should be accompanied by comments saying why the compiler cannot mess things up. But maintainer's choice. Those maintainers who keep a close personal relationship with the ever-growing list of optimizations should have no problem working out which use cases are safe for normal C-language loads and stores. Me, I would really rather play it safe, especially in the innards of something like RCU.

— Paul McKenney

Comments (none posted)

Herb Sutter on increasing safety in C++

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.

Comments (171 posted)