Brief items

Security quotes of the week

This puts me in an awkward position: after all these years fighting for memory safety, I'm disagreeing with the proposal to end it once and for all. For one, I think that security professionals are too keen to collect paychecks for bossing people around and having others do all the hard work. This proposal — demanding that developers re-learn their craft — certainly fits that mold.

My more pragmatic critique is that I doubt it's worth the cost. First, only a small fraction of memory-unsafe code is realistically exposed to attacks. In the context of modern computing paradigms, the primary attack surface is limited chiefly to network stacks, browser APIs, and a handful of multimedia transcoding libraries. Together, these components probably represent less than 10% of the codebase targeted by the proposed mandates; and perhaps 2% is of major economic interest.

Further, thanks to the decades of work on low-overhead exploit mitigations — notably including address space randomization and branch tracking — successful exploitation of memory safety issues has gotten quite challenging and accounts only for a tiny sliver of the overall volume of security incidents. Although memory corruption bugs are favored by some government actors, virtually all large-scale breaches trace back to other issues: outdated or misconfigured software, phishing, and so on.

— Michał Zalewski (lcamtuf) on the memory-safe language "mandate"

Comments (2 posted)

Kernel release status

The current development kernel is 6.8-rc7, which was released on March 3. Linus Torvalds said:

So we finally have a week where things have calmed down, and in fact 6.8-rc7 is smaller than usual at this point in time. So if that keeps up (but that's a fairly notable "if") I won't feel like I need to do an rc8 this release after all.

So no guarantees, but assuming no bad surprises, we'll have the final 6.8 next weekend.

Stable kernel status: 6.7.7, 6.6.19, 6.1.80, 5.15.150, 5.10.211, 5.4.270, and 4.19.308 were all released on March 1, followed by 6.7.8 and 6.6.20 on March 2 to fix a build problem in the ntfs3 filesystem.

On March 6, the 6.7.9, 6.6.21, 6.1.81, 5.15.151, 5.10.212, 5.4.271, and 4.19.309 stable kernels were released as well.

Comments (none posted)

Quotes of the week

As part of the requirement to be a CNA, we have to announce everything that we think is a potential vulnerability, severity not be judged at all as that is NOT part of the CVE project or program. It is up to others to judge the severity, not us, nor the CVE group themselves, that's not what the ID is for.

So, because of this, we are now assigning CVE ids to everything that we review that we think is a vulnerability AND everything that people submit to us to have a CVE assigned to that they deem is a vulnerability. Many groups/people have already asked us for IDs and we have only turned one down so far (the submitter agreed that it wasn't an issue at all).

We also are required to go back through the GSD entries and create CVE entries for them as well, which is why you are seeing these "older" entries be created. We have many thousands to go through of them, so that will take us a while to catch up (next few months.)

— Greg Kroah-Hartman (link added)

I really don't want some kind of top-level CI for the base kernel project.

We already have the situation that the drm people have their own ci model. [I'm] ok with that, partly because then at least the maintainers of that subsystem can agree on the rules for that one subsystem.

I'm not at all interested in having something that people will then either fight about, or - more likely - ignore, at the top level because there isn't some global agreement about what the rules are.

— Linus Torvalds

Comments (none posted)

Adding systemd to postmarketOS

The postmarketOS project, which produces a Linux distribution for phones and mobile devices, has announced that it is in the early stages of adding systemd to make it easier to support GNOME and KDE.

Users who prefer the OpenRC init system are assured they will still have that option when building their own images "as long as OpenRC is in Alpine Linux (on which postmarketOS is based)":

As with text editors, some people are really passionate about their favorite init systems. When discussing this announcement, please keep a friendly tone. Remember that we all share the love for free and open source software, and that our communities work best if we focus on shared values instead of fighting over what implementations to use.

Proof-of-concept images are available now for a limited set of devices. Users are warned these images are "buggy, unreliable, and NOT suitable for use on a device you rely on". Those interested in helping with testing and development are encouraged to follow along and report bugs on the systemd issue at GitLab.

Comments (35 posted)

Musl C library releases support for new architectures

On February 29, the musl project announced release 1.2.5, including support for loongarch64 and riscv32. This release also contains support for the statx(), preadv2(), and pwritev2() system calls.

Comments (7 posted)

NVK is now ready for prime time (Collabora blog)

Over on the Collabora blog, Faith Ekstrand has announced that the NVK Vulkan driver for NVIDIA devices will be part of Mesa 24.1 and is ready for real-world use. It should be appearing in Linux distributions later this year.

Back in october, I announced that NVK had reached Vulkan 1.0 conformance on Turing hardware. As of today NVK is now a conformant Vulkan 1.3 implementation on Turing (RTX 2000 and GTX 1600 series), Ampere (RTX 3000 series), and Ada (RTX 4000 series) GPUs. Not only have we jumped forward three Vulkan versions, but the new test runs were done with the GSP firmware enabled and includes Ampere and Ada GPUs. Also, unlike the initial 1.0 run, there are no hacks this time. Every test we passed in those conformance test runs also passes on upstream Mesa.

Comments (37 posted)