Fedora prepares for the end of AF_ALG

The Linux kernel's user-space interface (AF_ALG) to the Crypto API has been linked to a number of recent high-profile security problems, including Copy Fail and successor vulnerabilities. It was deprecated earlier this year. Eric Biggers, and other kernel developers, have been working to remove it from the kernel. With that in mind, the Fedora Project is planning to restrict use of AF_ALG in the next Fedora release in the hopes of nudging remaining users of the API to prepare for its eventual removal.

Goodbye AF_ALG

Allowing user space programs to request crypto operations from the kernel was both popular and controversial when AF_ALG was added by crypto subsystem maintainer Herbert Xu in 2010. Xu designed AF_ALG to allow user-space programs access to hardware cryptographic accelerators in order to provide performance gains.

Some, however, were unconvinced that this was a good idea. Christoph Hellwig, for example, said that it was computationally intensive code that had "no business in kernel space unless absolutely required (e.g. for kernel consumers)". He added that CPUs were gaining "proper instructions" for cryptography, which made providing a user-space API even less useful.

In hindsight, it turns out that adding AF_ALG was a bad idea—but not, necessarily, for the reasons that its critics expressed at the time. The reason that kernel developers are now working to get rid of AF_ALG is that it has proven to be not only unnecessary, but a regular source of kernel vulnerabilities as well, as Biggers pointed out in his patch documenting the deprecation of AF_ALG.

AF_ALG is almost completely unnecessary, and it exposes a massive attack surface that hasn't been standing up to modern vulnerability discovery tools. [...]

This isn't sustainable, especially as LLMs have accelerated the rate the vulnerabilities are coming in. The effort that is being put into this thing is vastly disproportional to the few programs that actually use it, and those programs would be better served by userspace code anyway.

The time has clearly come to rid the kernel of AF_ALG, but kernel developers have to be cautious about ripping it out to avoid disrupting user-space programs that have come to rely on it.

One of the popular user-space programs that makes use of AF_ALG is the cryptsetup utility, which is used to set up disk encryption, such as LUKS volumes, using dm-crypt. The project pointed out that AF_ALG had been deprecated in its release notes for cryptsetup 2.8.7.

The release notes state that cryptsetup would be able to use a user-space crypto library in lieu of AF_ALG if it was not present, though some methods would require root access. Users were warned that the absence of AF_ALG "could cause severe compatibility issues if the required algorithm (or encryption mode) is not implemented in the userspace library". The Serpent and Twofish ciphers are specifically mentioned as missing from several user-space libraries.

Christoph Anton Mitterer had spotted the warning when cryptosetup 2.8.7-rc1 was published. He raised his hand on the linux-crypto mailing list, on July 8, to ask about potential fallout from the deprecation of AF_ALG. Mitterer said that he did use those ciphers and "it would really be quite unfortunate if sooner or later I couldn't use them". He asked if anything was being done to ensure that those would remain available.

Biggers replied that Mitterer might have gotten the wrong impression from the cryptsetup release notes. The things that had been removed from AF_ALG so far, zero-copy and async-execution support, should have no impact on cryptsetup. "There are indeed more people turning off AF_ALG in their kernels now; however, general-purpose distros aren't doing that." That statement was true in July, but it will not be true much longer.

General purpose distributions are doing that

Justin Forbes and Peter Robinson put forward the "Disable in Kernel Crypto Userspace API (Phase 1)" change proposal for Fedora 45, which was announced by Aoife Moloney on July 22. The proposal notes that AF_ALG is deprecated in the kernel "with some parts of it being actively removed early in the 7.2 cycle" due to security risks. It recommends restricting AF_ALG's use in the Fedora 45 release "so we can do a controlled ending of support". Change proposals are expected to identify the impact that a change would have on the distribution—the proposal says that there are not many Fedora packages that are known users of AF_ALG, "so the impact should be minimal".

The proposal does identify a few known users of AF_ALG in Fedora, however: cryptsetup, the iNet Wireless Daemon (iwd), and the Linux kernel crypto API user-space interface library (libkcapi), which is used by dracut. It says that those users are unaffected by the change, though there may be third-party packages that use AF_ALG. In that case, it makes sense to identify them now so that they can be modified before AF_ALG goes away entirely.

The first phase uses the upstream patches due to land shortly, likely in 7.3, to limit the use of the API to the known apps and restricts the use. This allows Fedora to identify unknown users and gracefully deal with them before the active demise of the interface upstream providing users a more graceful process rather than universally pulling the rug without any notice.

The upstream patch being referred to is not identified, but it seems to be the one posted by Biggers on June 22, and applied by Xu on July 5. Biggers added a sysctl knob, af_alg_restrict, with three possible settings for AF_ALG: a zero for unrestricted, one for limited functionality, or two for completely disabled.

Beginning with Linux 7.3 the default value will be set to 1: that will enable a limited algorithm allowlist for unprivileged processes such as iwd, bluez, and iproute2, and a longer one for privileged processes. He said that "common use cases such as iwd and bluez [Bluetooth] are taken into account already", and he had verified that iwd still worked with the new default setting.

The contingency plan for the Fedora change proposal is to re-enable AF_ALG before Fedora 45 is released if it is found to cause too many problems. The presumption is that Fedora users will not notice.

Discussion

During the discussion on the Fedora devel mailing list, Ondrej Kozina said that he did not understand why the change was needed, given that AF_ALG was already being removed from the kernel.

Robinson replied that there were a few reasons for the change. One was to communicate the coming removal of AF_ALG so that Fedora users were aware; the other was to ensure that the breaking change was made on a release boundary rather than in the middle of a release cycle, since Fedora 45 will ship with the 7.2 kernel and then move to the 7.3 kernel once it is released. "We don't want the upstream patches heading to 7.3 to suddenly break users [systems] mid-release when upstream yanks whatever rug they choose whenever they choose. It doesn't make for a good user experience does it?"

That did not quite satisfy Kozina, who argued against turning off AF_ALG without a replacement. He complained, for example, that cryptsetup would require users to have CAP_SYS_ADMIN for use with some of the ciphers, and that Fedora would have limited support for TrueCrypt and VeraCrypt containers. Robinson pointed out that many of the use cases identified by Kozina were not present in Fedora itself. "I believe these would only be used if a user when out of their way to use those, generally via a manual install process." He reiterated that AF_ALG is going away "whether we like it or not" and the idea was to get Fedora users ready ahead of time.

Barry Scott said that he had a LUKS 2 vault on a Raspberry Pi 4 he had configured "with advice from the *internet*" using a cipher that would be affected by the AF_ALG restrictions. "Clearly I will have to migrate to a supported cipher before upgrading to f45." Robinson observed that "the internet wasn't entirely correct", and said that Scott would need to migrate to a different cipher "before long", but not for Fedora 45.

Ian McInerney wondered what this meant for Fedora 44, which was released in April. "Since this change is targeted at F45 and kernel 7.2, does this mean that F44 will not get kernel 7.2 released to it and stay on kernel 7.1?" Forbes replied that he had a method for adding or removing patches for specific Fedora releases, so Fedora 44 would still get 7.2 without the AF_ALG restriction patch.

The Fedora Engineering Steering Committee (FESCo) discussed the change in a ticket and voted to approve the change with five in favor of the change, and no votes against. The beta release for Fedora 45 is scheduled for September 15. It will be interesting to see whether restricting AF_ALG causes many problems for Fedora users, or if its phase out will be relatively uneventful.