Brief items
Security
"ZombieLoad": a new set of speculative-execution attacks
The curtain has finally been lifted on the latest set of speculative-execution vulnerabilities. This one has the delightful name of ZombieLoad; it is also known as "microarchitectural data sampling", but what's the fun in that? Various x86 processors stash data into hidden buffers that can, in some cases, be revealed via speculative execution. Exploits appear to be relatively hard. See this page from the kernel documentation for a fairly detailed description of the problem, and this page for mitigation information.An MDS reading list
We contemplated putting together an LWN article on the "microarchitectural data sampling" (MDS) vulnerabilities, as we've done for past speculative-execution issues. But the truth of the matter is that it's really more of the same, and there is a lot of material out there on the net already. So, for those who would like to learn more, here's a list of resources.
- This page from the kernel documentation contains a fairly detailed description of the problem and this page has mitigation information.
- ZombieLoadAttack.com
describes the ZombieLoad MDS attack and, in particular, contains this paper
[PDF] from Michael Schwarz et al. with the details.
- mdsattacks.com holds academic papers on the Fallout [PDF] (Marina Minkin et al.) and RIDL [PDF] (Stephan van Schaik et al.) attacks.
- Jon Masters has written an overview article complete with a three-minute video on the vulnerabilities and their exploits. For those wanting more Masters, there is also a longer video that goes deeper.
- Here is Intel's "deep dive" into the MDS vulnerabilities.
- Cyberus Technology has put up an overview article that discusses some of the possible attacks enabled by the MDS vulnerabilities.
Security quotes of the week
It's bizarre to suggest that end-to-end encryption is useless because
there are some advanced ways that people can get around it, ignoring all
the other ways that it helps protect most people. End-to-end encryption
does much more to protect tons of people, and saying that we can ignore it
just because it doesn't stop all attacks is really dangerous.
— Mike
Masnick
Bloomberg should be ashamed to be publishing such dangerous nonsense. It is the equivalent of anti-vax nonsense, telling people not to protect themselves.
THE BINS HAVE BEEN REINSTATED.
— Tim
Cushing
This is the stupid world the EU Parliament has gifted us. A breathtakingly broad law that regulates every entity that might possess the personal information of others has, however briefly, resulted in the removal of trash cans to ensure compliance. This may be the dumbest collateral damage yet, but it certainly won't be the last.
Kernel development
Kernel release status
The 5.2 merge window remains open; it can be expected to close on May 19.Stable updates: The stable-kernel machine continues to operate at full speed. 5.1.1, 5.0.15, 4.19.42, 4.14.118, and 4.9.175 came out on May 11, followed by 5.1.2, 5.0.16, 4.19.43, 4.14.119, and 4.9.176 on May 14. The latter set contains the fixes for the newly disclosed MDS vulnerabilities.
The (large) 5.1.3, 5.0.17, 4.19.44, 4.14.120, 4.9.177, 4.4.180, and 3.18.140 updates are all in the review process; they are due on May 17. This set adds the MDS fixes to 4.4; 3.18 remains unpatched.
Maintainer's / Kernel Summit 2019 planning kick-off
The planning process for the 2019 Linux Kernel and Maintainer's Summits (Lisbon, Portugal, September 9 to 12) has begun. If you have a topic that you would like to see discussed at either event, now is the time to send in a proposal to the ksummit-discuss list; click below for the details.An eBPF overview, part 5: Tracing user processes (Collabora blog)
The fifth and final article in Adrian Ratiu's series on eBPF delves into userspace tracing. "In our previous parts we focused on tracing the Linux kernel, for which the eBPF-based projects are, in our humble opinion, the most safe, widely available and useful methods (eBPF is fully upstreamed in Linux, guarantees a stable ABI, comes enabled by default in almost all distributions and integrates with all other tracing mechanisms). It has really become a no-brainer choice for kernel work. However, up until now, talking in-depth about userspace tracing was deliberately avoided because it merits special treatment, hence this full part 5 article devoted to it."
Quotes of the week
When the "highlight" is the movement of the documentation from .txt
to .rst files, it's a good merge window.
— Greg Kroah-Hartman
So don't think you are done updating your kernel, you
never are done with that.
— Greg again
Development
Rescorla: technical details on the recent Firefox add-on outage
Eric Rescorla has written a detailed summary of how the Firefox add-on fiasco happened, how it was addressed, and how a repeat might be avoided. "First, we should have a much better way of tracking the status of everything in Firefox that is a potential time bomb and making sure that we don’t find ourselves in a situation where one goes off unexpectedly. We’re still working out the details here, but at minimum we need to inventory everything of this nature."
PHP in 2019
Here's a blog post from "Brent" on how PHP deserves another look. "Today I want to look at the bright side: let's focus on the things that have changed and ways to write clean and maintainable PHP code. I want to ask you to set aside any prejudice for just a few minutes. Afterwards you're free to think exactly the same about PHP as you did before. Though chances are you will be surprised by some of the improvements made to PHP in the last few years."
Development quote of the week
If, in the future, AI systems will be able to write our code, what kind of language will we need to describe the code we want? That language certainly won’t be a language with loops and conditionals; nor do I think it will be a language based on the mathematical abstraction given by functions.
[Andrej] Karpathy suggests that the core of this language will be tagged datasets for training AI models. Instead of writing step-by-step instructions, we will show the computer what we want it to do. If you think such a programming paradigm is too radical, too far away from the process of making a machine do your bidding, think about what the machine language programmers of the 1950s would think about a modern optimizing compiler.
— Mike Loukides
Page editor: Jake Edge
Next page:
Announcements>>