Brief items

Horn: Racing against the clock

Jann Horn describes in great detail the process he went through to exploit a tiny race window in the kernel.

Luckily for us, the race window contains the first few memory accesses to the struct file; therefore, by making sure that the struct file is not present in the fastest CPU caches, we can widen the race window by as much time as the memory accesses take. The standard way to do this is to use an eviction pattern / eviction set; but instead we can also make the cache line dirty on another core.

Comments (10 posted)

Security quotes of the week

Virtually all major technology companies serving large numbers of users online have departments that routinely review and process such requests, which are typically granted as long as the proper documents are provided and the request appears to come from an email address connected to an actual police department domain name.

But in certain circumstances — such as a case involving imminent harm or death — an investigating authority may make what’s known as an Emergency Data Request (EDR), which largely bypasses any official review and does not require the requestor to supply any court-approved documents.

It is now clear that some hackers have figured out there is no quick and easy way for a company that receives one of these EDRs to know whether it is legitimate. Using their illicit access to police email systems, the hackers will send a fake EDR along with an attestation that innocent people will likely suffer greatly or die unless the requested data is provided immediately.

In this scenario, the receiving company finds itself caught between two unsavory outcomes: Failing to immediately comply with an EDR — and potentially having someone’s blood on their hands — or possibly leaking a customer record to the wrong person.

— Brian Krebs

Any time you mandate "extraordinary access" to an otherwise secure system, you create an opportunity for exploitation by criminals, spies, and snoops.

[...] This is a lesson as old as CALEA [Communications Assistance for Law Enforcement Act] – if you create a backdoor that tens of thousands of people can access, then you create a backdoor that anyone can access, because it's impossible to prevent the impersonation, subordination, or corruption of that many people.

— Cory Doctorow comments on Krebs's report

Comments (3 posted)

Kernel release status

The 5.18 merge window is open; it can be expected to close on April 3.

Stable updates: 5.17.1, 5.16.18, 5.15.32, 5.10.109, 5.4.188, 4.19.237, 4.14.274, and 4.9.309 were released on March 28.

Comments (none posted)

Some nftables security vulnerabilities

A new set of vulnerabilities has been disclosed in the nftables subsystem; these lead fairly easily to a local system compromise, on some configurations at least. Fixes for these vulnerabilities were present in the March 28 stable updates; upgrading seems like a good idea.

Comments (none posted)

Debian decides to allow secret votes

The Debian project has been voting on a general resolution that would allow secret voting on future issues. The results have been posted in unofficial form, and the winner was "proposal B": "Hide identities of Developers casting a particular vote and allow verification". One might think that closes the discussion, but Debian project leader candidate Felix Lechner is questioning the election and calling for it to be redone — something that the Debian constitution lacks provisions for.

Comments (19 posted)

Fedora 36 beta released

The Fedora 36 beta release has been announced.

Fedora 36 Workstation Beta includes GNOME 42, the newest release of the GNOME desktop environment. GNOME 42 includes a global dark style UI setting. It also has a redesigned screenshot tool. And many core GNOME apps have been ported to the latest version of the GTK toolkit, providing improved performance and a modern look.

If all goes well, the final Fedora 36 release will happen at the end of April.

Comments (4 posted)

OpenSUSE adopts a new code of conduct

The openSUSE project has announced the adoption of a new code of conduct: "We hope that by having a clear and concise Code of Conduct for the project, the openSUSE Community can continue to grow and prosper in the years to come".

Comments (94 posted)

Distributions quote of the week

In a previous DPL talk from me, I explained that Debian is a bottomless pit of problems. This might sound harsh, or mean, but if you look at our scope of work, we're affected by just about every problem that exists in computer science and the general computing world. I suppose at least we're not too concerned about quantum computing problems... yet.

— Jonathan Carter on the state of Debian

Comments (2 posted)

Ekstrand: How to write a Vulkan driver in 2022

Over on the Collabora blog, Jason Ekstrand has a detailed look at writing a Vulkan graphics driver in today's world. "Not only has Vulkan grown, but Mesa has as well, and we've built up quite a suite of utilities and helpers for making writing Vulkan drivers easier." The blog post takes the form of a tutorial of sorts, though the end result is not a functioning Vulkan driver, the framework of one is shown.

At the time we were developing ANV (the Intel Vulkan driver), the Vulkan spec itself was still under development and everything was constantly in flux. There were no best practices; there were barely even tools. Everyone working on Vulkan was making it up as they went because it was a totally new API. Most of the code we wrote was purpose-built for the Intel driver because there were no other Mesa drivers to share code. (Except for the short-lived LunarG Intel driver based in ilo, which we were replacing.) If we had tried to build abstractions, they could have gotten shot to pieces at any moment by a spec change. (We rewrote the descriptor set layout code from scratch at least five or six times before the driver ever shipped.) It was frustrating, exhausting, and a whole lot of fun.

These days, however, the Vulkan spec has been stable and shipping for six years, the tooling and testing situation is pretty solid, and there are six Vulkan drivers in the Mesa tree with more on the way. We've also built up a lot of common infrastructure. This is important both because it makes writing a Vulkan driver easier and because it lets us fix certain classes of annoying bugs in a common place instead of everyone copying and pasting those bugs.

Comments (6 posted)

Development quote of the week

We tried a bunch of names for which I could register a domain name, and each time the IBM naming authority would reject our choice. Changing the name of a program is a lot of work; it is worse than changing the name of the main character in a story.

Then we found out that a different IBM team had open-sourced their PKIX code under an external name "Jonah". So we gave my code two names: the approved internal name "IBM secure Mailer", and the external name "Postfix". "post" was a different word for "mail", and "fix" was for Sendmail, the inspiration for my efforts.

— Wietse Venema (Thanks to Sven Hoexter)

Comments (none posted)