LWN.net News from the source
LWN.net is a reader-supported news site dedicated to producing the best coverage from within the Linux and free software development communities. See the LWN FAQ for more information, and please consider subscribing to gain full access and support our activities.
Polling a set of file descriptors to see which ones can perform I/O without blocking is a useful thing to do — so useful that the kernel provides three different system calls (select(), poll(), and epoll_wait() — plus some variants) to perform it. But sometimes three is not enough; there is now a proposal circulating for a fourth kernel polling interface. As is usually the case, the motivation for this change is performance.
Security updates have been issued by Arch Linux (graphicsmagick and linux-lts), CentOS (thunderbird), Debian (kernel, opencv, php5, and php7.0), Fedora (electrum), Gentoo (libXfont), openSUSE (gimp, java-1_7_0-openjdk, and libvorbis), Oracle (thunderbird), Slackware (irssi), SUSE (kernel, kernel-firmware, and kvm), and Ubuntu (awstats, nvidia-graphics-drivers-384, python-pysaml2, and tomcat7, tomcat8).
The disclosure of the Meltdown and Spectre vulnerabilities has brought a new level of attention to the security bugs that can lurk at the hardware level. Massive amounts of work have gone into improving the (still poor) security of our software, but all of that is in vain if the hardware gives away the game. The CPUs that we run in our systems are highly proprietary and have been shown to contain unpleasant surprises (the Intel management engine, for example). It is thus natural to wonder whether it is time to make a move to open-source hardware, much like we have done with our software. Such a move may well be possible, and it would certainly offer some benefits, but it would be no panacea.
Three years after the last stable release, version 3.0 of the MusE MIDI/Audio sequencer is now available. As you might expect there many changes since the last release including a switch to Qt5, a new Plugin Path editor in Global Settings, a mixer makeover with lots of fixes, a system-wide move to double precision of all audio paths, and much more.
When the Meltdown and Spectre vulnerabilities were disclosed on January 3, attention quickly turned to mitigations. There was already a clear defense against Meltdown in the form of kernel page-table isolation (KPTI), but the defenses against the two Spectre variants had not been developed in public and still do not exist in the mainline kernel. Initial versions of proposed defenses have now been disclosed. The resulting picture shows what has been done to fend off Spectre-based attacks in the near future, but the situation remains chaotic, to put it lightly.
Security updates have been issued by Arch Linux (linux-hardened, linux-lts, linux-zen, and mongodb), Debian (gdk-pixbuf, gifsicle, graphicsmagick, kernel, and poppler), Fedora (dracut, electron-cash, and firefox), Gentoo (backintime, binutils, chromium, emacs, libXcursor, miniupnpc, openssh, optipng, and webkit-gtk), Mageia (kernel, kernel-linus, kernel-tmb, openafs, and python-mistune), openSUSE (clamav-database, ImageMagick, kernel-firmware, nodejs4, and qemu), Red Hat (linux-firmware, ovirt-guest-agent-docker, qemu-kvm-rhev, redhat-virtualization-host, rhev-hypervisor7, rhvm-appliance, thunderbird, and vdsm), Scientific Linux (thunderbird), SUSE (kernel and qemu), and Ubuntu (firefox and poppler).
The LWN.net Weekly Edition for January 4, 2018 is available.
Inside this week's LWN.net Weekly Edition
Linus has released the 4.15-rc7 kernel prepatch. "Ok, we had an interesting week, and by now everybody knows why we were merging all those odd x86 page table isolation patches without following all of the normal release timing rules. But rc7 itself is actually pretty calm. "
Rumors of an undisclosed CPU security issue have been circulating since before LWN first covered the kernel page-table isolation patch set in November 2017. Now, finally, the information is out — and the problem is even worse than had been expected. Read on for a summary of these issues and what has to be done to respond to them in the kernel.
Here's an update from Greg Kroah-Hartman on the kernel's response to Meltdown and Spectre. "If you rely on any other kernel tree other than 4.4, 4.9, or 4.14 right now, and you do not have a distribution supporting you, you are out of luck. The lack of patches to resolve the Meltdown problem is so minor compared to the hundreds of other known exploits and bugs that your kernel version currently contains. You need to worry about that more than anything else at this moment, and get your systems up to date first. Also, go yell at the people who forced you to run an obsoleted and insecure kernel version, they are the ones that need to learn that doing so is a totally reckless act."
One of the motivations behind projects like kdbus and bus1, both of which have fallen short of mainline inclusion, is to have an interprocess communication (IPC) mechanism available early in the boot process. The D-Bus IPC mechanism has a daemon that cannot be started until filesystems are mounted and the like, but what if the early boot process wants to perform IPC? A new project, varlink, was recently announced; it aims to provide IPC from early boot onward, though it does not really address the longtime D-Bus performance complaints that also served as motivation for kdbus and bus1.
Robert Haas continues his series on the PostgreSQL VACUUM operation with this survey of recent work and unsolved problems. "What is left to be done? The PostgreSQL development community has made great progress in reducing the degree to which VACUUM performs unnecessary scans of table pages, but basically no progress at all in avoiding unnecessary scanning of index pages. For instance, even a VACUUM which finds no dead row versions will still scan btree indexes to recycle empty pages."
We have covered the Fedora Modularity initiative a time or two over the years but, just as the modular "product" started rolling out, Fedora went back to the drawing board. There were a number of fundamental problems with Modularity as it was to be delivered in the Fedora 27 server edition, so a classic version of the distribution was released instead. But Modularity is far from dead; there is a new plan afoot to deliver it for Fedora 28, which is due in May.
One of the main concerns about the mitigations for the Meltdown/Spectre speculative execution bugs has been performance. The Google Security Blog is reporting negligible performance impact on Google systems for two of the mitigations (kernel page-table isolation and Retpoline): "In response to the vulnerabilities that were discovered we developed a novel mitigation called “Retpoline” -- a binary modification technique that protects against “branch target injection” attacks. We shared Retpoline with our industry partners and have deployed it on Google’s systems, where we have observed negligible impact on performance. In addition, we have deployed Kernel Page Table Isolation (KPTI) -- a general purpose technique for better protecting sensitive information in memory from other software running on a machine -- to the entire fleet of Google Linux production servers that support all of our products, including Search, Gmail, YouTube, and Google Cloud Platform. There has been speculation that the deployment of KPTI causes significant performance slowdowns. Performance can vary, as the impact of the KPTI mitigations depends on the rate of system calls made by an application. On most of our workloads, including our cloud infrastructure, we see negligible impact on performance."
The 4.15 kernel is likely to require a relatively long development cycle as a result of the post-rc5 merge of the kernel page-table isolation patches. That said, it should be in something close to its final form, modulo some inevitable bug fixes. The development statistics for this kernel release look fairly normal, but they do reveal an unexpectedly busy cycle overall.
Greg Kroah-Hartman has announced the release of the 4.14.12, 4.9.75, and 4.4.110 stable kernels. The bulk of the changes are either to fix the mitigations for Meltdown/Spectre (in 4.14.12) or to backport those mitigations (in the two older kernels). There are apparently known (or suspected) problems with each of the releases, which Kroah-Hartman is hoping to get shaken out in the near term. For example, the 4.4.110 announcement warns: "But be careful, there have been some reports of problems with this release during the -rc review cycle. Hopefully all of those issues are now resolved. So please test, as of right now, it should be 'bug compatible' with the 'enterprise' kernel releases with regards to the Meltdown bug and proper support on all virtual platforms (meaning there is still a vdso issue that might trip up some old binaries, again, please test!)"
Back in October, LWN reported on a talk about the state of the GNU Privacy Guard (GnuPG) project, an asymmetric public-key encryption and signing tool that had been almost abandoned by its lead developer due to lack of resources before receiving a significant infusion of funding and community attention. GnuPG 2 has brought about a number of changes and improvements but, at the same time, several efforts are underway to significantly change the way GnuPG and OpenPGP are used. This article will look at the current state of GnuPG and the OpenPGP web of trust, as compared to new implementations of the OpenPGP standard and other trust systems.
Security updates have been issued by Arch Linux (kernel), CentOS (kernel, libvirt, microcode_ctl, and qemu-kvm), Debian (kernel and xen), Fedora (kernel), Mageia (backintime, erlang, and wildmidi), openSUSE (kernel and ucode-intel), Oracle (kernel, libvirt, microcode_ctl, and qemu-kvm), Red Hat (kernel, kernel-rt, libvirt, microcode_ctl, qemu-kvm, and qemu-kvm-rhev), Scientific Linux (libvirt and qemu-kvm), SUSE (kvm and qemu), and Ubuntu (ruby1.9.1, ruby2.0, ruby2.3).
Welcome to the first LWN.net feature article for 2018. The holidays are over and it's time to get back to work. One of the first orders of business here at LWN is keeping up with our ill-advised tradition of making unlikely predictions for the coming year. There can be no doubt that 2018 will be an eventful and interesting year; here's our attempt at guessing how it will play out.
There's lots of material out on the net regarding the just-disclosed processor vulnerabilities and their impact on users. Here is a list of worthwhile stuff we have found.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds