Welcome to LWN.net

When a veteran kernel developer introduces a severe security hole into the kernel, it can be instructive to look at how the vulnerability came about. Among other things, it can point the finger at an API that lends itself toward the creation of such problems. And, as it turns out, the knowledge that the API is dangerous at the outset and marking it as such may not be enough to prevent problems.

Full Story (comments: 7)

Mozilla's manifesto commits the organization to a number of principles, including support for individual privacy and an individual's right to control how they experience the Internet. As a result, when Mozilla recently stated its intent to remove the "text only" option from its mailing lists — for the purpose of tracking whether recipients are reading its emails — the reaction was, to put it lightly, not entirely positive. The text-only option has been saved, but the motivation behind this change is indicative of the challenges facing independent senders of email.

Full Story (comments: 62)

Two separate talks, at two different venues, give us a look into the kinds of testing that the Intel graphics team is doing. Daniel Vetter had a short presentation as part of the Testing and Fuzzing microconference at the Linux Plumbers Conference (LPC). His colleague, Martin Peres, gave a somewhat longer talk, complete with demos, at the X.Org Developers Conference (XDC). The picture they paint is a pleasing one: there is lots of testing going on there. But there are problems as well; that amount of testing runs afoul of bugs elsewhere in the kernel, which makes the job harder.

Full Story (comments: 32)

While the 4.14 development cycle has not been the busiest ever (12,500 changesets merged as of this writing, slightly more than 4.13 at this stage of the cycle), it has been seen as a rougher experience than its predecessors. There are all kinds of reasons why one cycle might be smoother than another, but it is not unreasonable to wonder whether the fact that 4.14 is a long-term support (LTS) release has affected how this cycle has gone. Indeed, when he released 4.14-rc3, Linus Torvalds complained that this cycle was more painful than most, and suggested that the long-term support status may be a part of the problem. A couple of recent pulls into the mainline highlight the pressures that, increasingly, apply to LTS releases.

Full Story (comments: 11)

The GNU Privacy Guard (GnuPG) is one of the fundamental tools that allows a distributed group to have trust in its communications. Werner Koch, lead developer of GnuPG, spoke about it at Kernel Recipes: what's in the new 2.2 version, when older versions will reach their end of life, and how development will proceed going forward. He also spoke at some length on the issue of best-practice key management and how GnuPG is evolving to assist. Subscribers can click below for a report on the talk by guest author Tom Yates.

Full Story (comments: 12)

The kernel's timer interface has been around for a long time, and its API shows it. Beyond a lack of conformance with current in-kernel interface patterns, the timer API is not as efficient as it could be and stands in the way of ongoing kernel-hardening efforts. A late addition to the 4.14 kernel paves the way toward a wholesale change of this API to address these problems.

Full Story (comments: 11)

What kind of cell phone would emerge from a concerted effort to design privacy in from the beginning, using free software as much as possible? Some answers are provided by a crowdfunding campaign launched in August by Purism SPC, which has used two such campaigns successfully in the past to build a business around secure laptops. The Librem 5, with a five-inch screen and radio chip for communicating with cell phone companies, represents Purism's hope to bring the same privacy-enhancing vision to the mobile space, which is much more demanding in its threats, technology components, and user experience.

Full Story (comments: 45)

An attacker who seeks to compromise a running kernel by overwriting kernel data structures or forcing a jump to specific kernel code must, in either case, have some idea of where the target objects are in memory. Techniques like kernel address-space layout randomization have been created in the hope of denying that knowledge, but that effort is wasted if the kernel leaks information about where it has been placed in memory. Developers have been plugging pointer leaks for years but, as a recent discussion shows, there is still some disagreement over the best way to prevent attackers from learning about the kernel's address-space layout.

Full Story (comments: 6)