Brief items

Another round of speculative-execution vulnerabilities

There is a newly disclosed set of vulnerabilities in Intel processors that have been given the name Downfall attacks.

Downfall attacks targets a critical weakness found in billions of modern processors used in personal and cloud computers. This vulnerability, identified as CVE-2022-40982, enables a user to access and steal data from other users who share the same computer. For instance, a malicious app obtained from an app store could use the Downfall attack to steal sensitive information like passwords, encryption keys, and private data such as banking details, personal emails, and messages. Similarly, in cloud computing environments, a malicious customer could exploit the Downfall vulnerability to steal data and credentials from other customers who share the same cloud computer.

A series of patches has landed in the mainline kernel, including one for gather data sampling mitigation and one to disable the AVX extension on CPUs where microcode mitigation is not available. "This is a *big* hammer. It is known to break buggy userspace that uses incomplete, buggy AVX enumeration."

Not to be left out, AMD processors suffer from a return-stack overflow vulnerability, again exploitable via speculative execution; this patch, also just merged, describes the problem and its mitigation.

Comments (145 posted)

Security quote of the week

The final obstacle was that several packages depended on rpmlib(CaretInVersions), and building another fake package that provided that didn't work. I shouted into the void and Bill Nottingham answered - rpmlib dependencies are synthesised by rpm itself, indicating that it has the ability to handle extensions that specific packages are making use of. This made things harder, since the list is hard-coded in the binary. But since I'm already committing crimes against humanity with a hex editor, why not go further? Back to editing librpm.so.8 and finding the list of rpmlib() dependencies it provides.

[...] You should not do this. I should not do this. This was a terrible idea. Any situation where you're binary patching your package manager to get it to let you do something is obviously a bad situation. And with hindsight performing 5 independent upgrades might have been faster. But that would have just involved me typing the same thing 5 times, while this way I learned something. And what I learned is "Terrible ideas sometimes work and so you should definitely act upon them rather than doing the sensible thing", so like I said, you should not do this in case you learn the same lesson.

— Matthew Garrett ignores Fedora's usual upgrade path

Comments (2 posted)

Kernel release status

The current development kernel is 6.5-rc5, released on August 6. "Things continue to look pretty normal. Not a huge number of commits, and most of the ones here are tiny".

Things were not entirely normal, though, in that a series of fixes for the Downfall and INCEPTION hardware vulnerabilities was in the works; those landed in the mainline on August 8. It is not clear that this work has settled, though; in particular, Peter Zijlstra is reworking the INCEPTION fixes to more closely match the existing Retbleed mitigations.

Stable updates: 6.4.8, 6.1.43, and 5.15.124 were released on August 3. The 6.4.9, 6.1.44, 5.15.125, 5.10.189, 5.4.252, 4.19.290, and 4.14.321 updates, dominated by the Downfall and INCEPTION fixes, arrived on August 8.

Do note the warning attached to each of these releases:

Note, PLEASE TEST this kernel if you are on the 6.4.y tree before using it in a real workload. This was a quick release due to the obvious security fixes in it, and as such, it has not had very much testing "in the wild". Please let us know of any problems seen. Also note that the user/kernel api for the new security mitigations might be changing over time, so do not get used to them being fixed in stone just yet.

The 6.4.10, 6.1.45, 5.15.126, 5.10.190, 5.4.253, 4.19.291, and 4.14.322 updates are in the review process; they are due on August 11.

Comments (none posted)

Quote of the week

It appears that you might be suffering from Type-of-Speculative-Bug Confusion, an affliction brought on by the chronic lack of documentation and consistency, the fact that almost everything has at least 2 names, and that 6 years in this horror show it's not showing any sign of slowing down.

— Andrew Cooper

Comments (none posted)

Introducing Incus

The Linux Containers project has announced the addition of Incus, which is a fork of LXD 5.16 started by Aleksa Sarai. Incus was created in response to Canonical's removal of LXD from Linux Containers.

After some discussion with Aleksa and a fair bit of encouragement from our community, we have made the decision to take Incus under the umbrella of Linux Containers and will commit to it the infrastructure which was previously made available to LXD.

The goal of Incus is to provide a fully community led alternative to Canonical's LXD as well as providing an opportunity to correct some mistakes that were made during LXD's development which couldn't be corrected without breaking backward compatibility.

In addition to Aleksa, the initial set of maintainers for Incus will include Christian Brauner, Serge Hallyn, Stéphane Graber and Tycho Andersen, effectively including the entire team that once created LXD.

Comments (19 posted)

Ekstrand: NVK Has landed

Faith Ekstrand announces on the Collabora blog that NVK, an open-source Vulkan driver for NVIDIA GPUs, will be included in the Mesa 23.3 release.

Merging into mesa/main is certainly a big milestone but NVK is nowhere near finished. It will take a long time before we get the bugs worked out and get a full feature set with reasonable performance. What it does mean is that we're pretty confident in the core of the driver and that we have a good base to build on going forward.

The necessary kernel support is planned for the 6.6 release; this blog post from David Airlie describes the work being done on that side.

Comments (none posted)

The Sourceware 25 roadmap

Sourceware, the development home for the GNU toolchain and more, is about to celebrate its 25th anniversary and is looking forward to the next 25 years:

That is why in the last couple of years we have started to diversify our hardware partners, setup new services using containers and isolated VMs, investigated secure supply chain issues, added redundant mirrors, created a non-profit home, collected funds, invested in open communication, open office hours and introduced community oversight by a Sourceware Project Leadership Committee with the help from the Software Freedom Conservancy.

Comments (none posted)

Mourning Bram Moolenaar

Bram Moolenaar, the creator of the vim editor, passed away on August 3. "Bram dedicated a large part of his life to VIM and he was very proud of the VIM community that you are all part of." He will be missed.

Comments (24 posted)