6.2 Merge window, part 1

By Jonathan Corbet
December 15, 2022

Once upon a time, Linus Torvalds would try to set a pace of about 1,000 changesets pulled into the mainline each day during the early part of the merge window. For 6.2, though, the situation is different; no less than 9,278 non-merge changesets were pulled during the first two days. Needless to say, these commits affect the kernel in numerous ways, even though there are fewer fundamental changes than were seen in 6.1.

The most significant changes merged for 6.2 so far include:

Architecture-specific

The arm64 architecture can now enable or disable software-implemented shadow stacks at boot time; this is done by patching in the relevant instructions where necessary. This change allows a single kernel to work efficiently on systems both with pointer authentication (where shadow stacks don't really add much) and without.
The Intel "asynchronous exit notification" mechanism is now supported; this allows code in SGX enclaves to detect single-step attacks.
There is a new set of operations allowing a hypervisor to support requests from Intel TDX guests; this documentation commit has some more information.
There is a new sysctl knob to control how x86 systems respond to processes executing split locks; see this commit for an overview and this article for the background.

BPF

BPF programs have increased access to control-group local storage; see this documentation commit for details.
BPF programs can now define types, allocate objects, and create their own data structures; this merge message gives an overview.
It is now possible for BPF code to access and store task_struct objects; see this commit for an overview.

Core kernel

It is now possible to move a process into a new time namespace when it calls exec(). Among other things, this allows a process to execute the vfork()+exec() sequence after unsharing its time namespace, which does not work in current kernels.
More Rust infrastructure code has been merged; see this article for details.

Filesystems and block I/O

Squashfs filesystems can now be mounted with the threads= option to control how parallel decompression is done; see this commit for details.
Squashfs can also now handle ID-mapped mounts.
The kernel's handling of POSIX access-control lists has been massively reworked. There should be no user-visible changes. This merge commit contains a detailed overview of what was done.
The fscrypt mechanism can now make use of the SM4 encryption algorithm though, as detailed in this merge message, the fscrypt maintainer recommends against its use.
The reliability of the much-maligned Btrfs RAID5 and RAID6 implementation has been improved; this merge message describes the changes that were made. There have also been more performance improvements merged for Btrfs.
The kernel can now be built without NFSv2 support; this is the next step toward removing that support entirely.
Permissions checks for access to NVMe devices have changed; operations that read or write a given device will now succeed if the writing process has the appropriate access in the permission bits on the device special file. Previously, CAP_SYS_ADMIN was required for such operations.
The packet CD/DVD driver, deprecated in 2016, has finally been removed.

Hardware support

Clock: MStar CPUPLL clocks, Ingenic JZ4755 CGU clocks, MediaTek FHCTL hardware controller clocks, Qualcomm SC8280XP and SM6375 display clock controllers, and Qualcomm SM8550 global clock controllers.
GPIO and pin control: Qualcomm SDM670 pin controllers, Loongson-2 SoC pin controllers, and Intel Moorefield pin controllers.
Graphics: Open Firmware display controllers, Renesas RZ/G2L MIPI DSI encoders, Jadard JD9365DA-H3 WXGA DSI panels, and NewVision NV3051D DSI panels.
Hardware monitoring: Ampere Altra SMpro hardware monitors and OneXPlayer EC fan controllers.
Input: Hynitron cst3xx touchscreens, Cypress TrueTouch Gen5 touchscreens, and Himax hx83112b touchscreens.
Media: OmniVision OV08X40 and OV4689 sensors, STmicroelectronics VGXY61 sensors, Toshiba TC358746 parallel-CSI2 bridges, Allwinner A31 image signal processors, Microchip image sensor controllers, Renesas RZ/G2L MIPI CSI-2 receivers, and Renesas RZ/G2L camera data receiving units.
Miscellaneous: ARM CoreSight performance monitoring units, Amlogic DDR bandwidth performance monitors, Loongson-2 SoC global utilities register blocks, Dell WMI-based platform sensors, ChromeOS human-presence sensors, Apple CPU-frequency controllers, ARM SCMI powercap controllers, Richtek RT6190 4-Switch BuckBoost controllers, MediaTek MT6357 power-management ICs, and Sunplus SP7021 MMC controllers.
Networking: Realtek 8852BE PCI wireless network adapters, Motorcomm yt8521 gigabit Ethernet PHYs, Renesas R-Car S4-8 Ethernet switches, MediaTek MT7996 wireless interfaces, NVIDIA Tegra multi-gigabit Ethernet controllers, Realtek 8821CU, 8822BU, 8822CU and 8723DU USB wireless network adapters, and Broadcom BCM4377/4378/4387 Bluetooth interfaces.
Sound: Realtek RT1318 codecs.
SPI: Microchip pci1xxxx PCIe switches, Socionext F_OSPI SPI flash controllers, and Nuvoton WPCM450 flash interface units.
Also: the kernel has a new framework for the management of compute-acceleration devices. There are no actual devices using that framework in 6.2; that may change for 6.3. Meanwhile, this documentation commit gives an overview of the new subsystem.

Miscellaneous

The new rv tool can be used to control the operation of the runtime verification subsystem. See this documentation commit for details.
The HTML version of the kernel documentation is now built with the Sphinx "alabaster" theme by default.

Networking

The IPv6 stack has gained support for "protective load balancing", described as:

PLB (Protective Load Balancing) is a host based mechanism for load balancing across switch links. It leverages congestion signals(e.g. ECN) from transport layer to randomly change the path of the connection experiencing congestion.

This paper has more details.

Security-related

The RANDOM_TRUST_BOOTLOADER and RANDOM_TRUST_CPU configuration options have been removed; the only way to set those parameters now is with a command-line option. See this commit for more information.
The Landlock security module can now control file truncation operations. This documentation commit has some more information.

Internal kernel changes

The read-copy-update (RCU) subsystem has a new "lazy" mode (controlled by the RCU_LAZY configuration option). When this mode is active, the handling of RCU callbacks will be delayed so that those callbacks can be run in larger batches. On lightly loaded systems, the result can be a 5-10% power savings. For callbacks that can't wait, there is a new call_rcu_hurry() function. This commit has the details.
As described in this article, the char type will now default to unsigned on all architectures.
The SLOB slab allocator, which was designed for small-memory systems, has been deprecated and will likely be removed in a future release. Any remaining users are encouraged to move to SLUB, as the other allocator (SLAB) will eventually be targeted as well. To help on smaller systems, there is a new SLUB_TINY configuration option that reduces the SLUB allocator's memory requirements.
Support for message-signaled interrupts (MSIs) has been massively reworked to deal with years of technical debt and upcoming technologies. This merge commit describes the situation in great detail.
There have been changes to the timer subsystem as well. del_timer() and del_timer_sync() have been renamed to timer_delete() and timer_delete_sync() respectively. There are new functions, timer_shutdown() and timer_shutdown_sync(), which are meant to ease the task of cleaning up timers that might be rearmed during that process; once they are called, any attempts to rearm the timer will be ignored.

If the usual two-week schedule is followed, the 6.2 merge window can be expected to end on December 25. Given the significance of that date and a number of warnings from Torvalds, though, it would not be at all surprising if this merge window ended up being shorter than usual. Whatever happens, LWN will follow up with a summary of the changes that were pulled once 6.2-rc1 has been released.

Index entries for this article
Kernel	Releases/6.2

6.2 Merge window, part 1

Posted Dec 15, 2022 16:09 UTC (Thu) by smurf (subscriber, #17840) [Link] (3 responses)

> The kernel can now be built without NFSv2 support

Well, it always could be built without NFSv2. Just turn off NFS entirely. :-P

6.2 Merge window, part 1

Posted Dec 15, 2022 16:35 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

I suspect the motivation behind the new config flag were the screwy situations such as EL7 dropping support for v2 mounts but still supporting v2 exports.

6.2 Merge window, part 1

Posted Dec 15, 2022 20:39 UTC (Thu) by jlayton (subscriber, #31672) [Link] (1 responses)

That should probably read:

"The kernel can now be built without NFSv2 server support."

Prior to this, support for NFSv2 and v3 were was always built in. With this change, v3 is always supported, but v2 support is now optional. v4 support has always been optional.

6.2 Merge window, part 1

Posted Dec 17, 2022 21:28 UTC (Sat) by trondmy (subscriber, #28934) [Link]

> That should probably read:
>
> "The kernel can now be built without NFSv2 server support."

Sure, but the NFS client code has been able to do this since 2012, so both statements are correct. :-)

6.2 Merge window, part 1

Posted Dec 15, 2022 19:19 UTC (Thu) by wsy (subscriber, #121706) [Link] (13 responses)

SM2/SM3/SM4 cipher suites are highly likely backdoored. People with choices should never use them.

6.2 Merge window, part 1

Posted Dec 15, 2022 23:53 UTC (Thu) by willy (subscriber, #9762) [Link] (6 responses)

I see no evidence that SM4 is weaker than AES. "it's from China" plays well on Fox News, but I like to think we have a higher standard of proof than that.

It's been a published algorithm since 2012. The best known attack is based on a 22-round version instead of the specified 32. Arguably, Rijndael is closer to being broken than SM4.

6.2 Merge window, part 1

Posted Dec 16, 2022 4:37 UTC (Fri) by wsy (subscriber, #121706) [Link] (5 responses)

I say this because as a Chinese I know how our gov works. They are control freaks.

The PKI standards built upon these cipher suites are called 双证书体系 or Dual-Certificate System. A user has to use saparate key pairs for encryption and signature. The encryption cert private key is issued by the key authority. The signature cert private key is generated by yourself and signed by the CA like a normal certificate.

So the gov can easily decrypt your communication while you have no plausible deniability. This is crazy. I doubt any sane person will trust those ciphers seeing this dual-cert system.

6.2 Merge window, part 1

Posted Dec 16, 2022 6:33 UTC (Fri) by uudiin (guest, #131856) [Link]

Dual-certificate design, or TLCP can sniff traffic content, but this can only be done on the premise of having a key, which does not mean that the SM2/3/4 algorithm itself is flawed, and there is currently no evidence that the algorithm itself it is not safe. of course, a dual-certificate system like TLCP will never be introduced into community software.

6.2 Merge window, part 1

Posted Dec 18, 2022 2:10 UTC (Sun) by anselm (subscriber, #2796) [Link] (2 responses)

So the gov can easily decrypt your communication while you have no plausible deniability. This is crazy. I doubt any sane person will trust those ciphers seeing this dual-cert system.

Yes, but that approach would work with any asymmetric cryptosystem (such as RSA). It doesn't indicate a weakness in the actual ciphers used in China. On the contrary, if the ciphers themselves were in fact backdoored, the Chinese government wouldn't even need to go through this elaborate “dual-certificate” song-and-dance routine in the first place.

6.2 Merge window, part 1

Posted Dec 19, 2022 11:48 UTC (Mon) by k3ninho (subscriber, #50375) [Link] (1 responses)

I have no way to assess the likelihood of the following, but there is an avenue where both flaws exist and the song-and-dance over certificates and public keys is a distraction from an exploitable flaw in the algorithm used.

K3n.

6.2 Merge window, part 1

Posted Dec 23, 2022 7:25 UTC (Fri) by anton (subscriber, #25547) [Link]

That is certainly a possibility. The British planted stories of spies to cover up the existence of Ultra (their successful cryptanalysis).

OTOH, the PRC government may just want their own cypher for fear of an NSA backdoor in cyphers coming from elsewhere.

6.2 Merge window, part 1

Posted Dec 22, 2022 18:05 UTC (Thu) by flussence (guest, #85566) [Link]

That sounds familiar. I don't remember where I saw it (LibreSSL dev blog?) but there was a version of AES that took four keys and did... *something* with them.

Don't overestimate people's sanity. After all, OpenSSL is still in use a decade later for some reason.

6.2 Merge window, part 1

Posted Dec 16, 2022 0:21 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

It's highly unlikely. If China knows a way to backdoor a cipher like SM4, then it's likely that AES is also vulnerable.

6.2 Merge window, part 1

Posted Dec 18, 2022 4:04 UTC (Sun) by Paf (subscriber, #91811) [Link] (3 responses)

There is an enormous difference between backdoor ing a particular cipher design when you’re designing it and cracking a related one. Choice of constants, etc, etc.

6.2 Merge window, part 1

Posted Dec 18, 2022 6:48 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

There are no constants in SM4 that are not derived from first principles. Just like AES, SM4 uses S-boxes for the round function. They are calculated using different polynomials, but otherwise they are very similar.

So it's extremely unlikely that SM4 is backdoored. And if it is, then AES is also pretty much guaranteed to be just as vulnerable.

It doesn't mean that everyone should switch to SM4, it's simply not a good modern cipher from a purely practical standpoint.

6.2 Merge window, part 1

Posted Dec 20, 2022 1:24 UTC (Tue) by Paf (subscriber, #91811) [Link] (1 responses)

“ The eight S-boxes of DES were the subject of intense study for many years out of a concern that a backdoor (a vulnerability known only to its designers) might have been planted in the cipher. The S-box design criteria were eventually published (in Coppersmith 1994) after the public rediscovery of differential cryptanalysis, showing that they had been carefully tuned to increase resistance against this specific attack. Biham and Shamir found that even small modifications to an S-box could significantly weaken DES.[4]”
From Wikipedia. From your description, you know more of the details of S-box creation than I do, but this sure sounds like an S-box could be weak in a way that might not be apparent to others.

6.2 Merge window, part 1

Posted Dec 23, 2022 3:45 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

S-Boxes in DES were basically chosen experimentally, they are not a result of any "nothing up my sleeves" process.

In contrast, both AES and SM4 use algorithmically generated S-Boxes. The algorithms are very similar, so it's highly unlikely that only one of them is vulnerable.

6.2 Merge window, part 1

Posted Dec 16, 2022 9:02 UTC (Fri) by InfoHunter (guest, #162753) [Link]

Don't mix up the security of cryptography primitives and secure network protocols. A specific protocol being not secure doesn't mean the cryptography primitives it uses are also vulnerable. The SM algorithms you mentioned have already all been standardized by ISO during the last few years.

6.2 Merge window, part 1

Posted Dec 15, 2022 22:37 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

> On lightly loaded systems, the result can be a 5-10% power savings. For callbacks that can't wait, there is a new call_rcu_hurry() function.

I was following this discussion at length, but didn't see the final patches. Is there a specific reason why `call_rcu_hurry` is not just `call_rcu_expedited`? Do we really need two *separate* flavors of "go faster", for a total of three variants?

6.2 Merge window, part 1

Posted Dec 20, 2022 6:38 UTC (Tue) by calumapplepie (guest, #143655) [Link]

I don't think call_rcu_expedited exists; a grep through the Linux source tree didn't find any examples. It seemed to have been proposed as an alternate name for call_rcu_hurry.

6.2 Merge window, part 1

Posted Dec 22, 2022 18:20 UTC (Thu) by flussence (guest, #85566) [Link]

I like the new kernel-doc theme (https://www.kernel.org/doc/html/next/ if anyone's curious). The old one's DHTML sidebar never seemed to mesh well with the way kernel documentation is structured.