Language Selection

English French German Italian Portuguese Spanish

LWN Kernel Articles: 4.20/5.0 Merge, Jiri Kosina, Arnd Bergmann and Greg Kroah-Hartman

Filed under
Linux
  • 4.20/5.0 Merge window part 1

    Linus Torvalds has returned as the keeper of the mainline kernel repository, and the merge window for the next release which, depending on his mood, could be called either 4.20 or 5.0, is well underway. As of this writing, 5,735 non-merge changesets have been pulled for this release; experience suggests that we are thus at roughly the halfway point.

  • Improving the handling of embargoed hardware-security bugs

    Jiri Kosina kicked off a session on hardware vulnerabilities at the 2018 Kernel Maintainers Summit by noting that there are few complaints about how the kernel community deals with security issues in general. That does not hold for Meltdown and Spectre which, he said, had been "completely mishandled". The subsequent handling of the L1TF vulnerability suggests that some lessons have been learned, but there is still plenty of room for improvement in how hardware vulnerabilities are handled in general.

    There are a number of reasons why the handling of Meltdown and Spectre went bad, he said, starting with the fact that the hardware vendors simply did not know how to do it right. They didn't think that the normal security contact (security@kernel.org) could be used, since there was no non-disclosure agreement (NDA) in place there. Perhaps what is needed is the creation of such an agreement or, as was discussed in September, a "gentleman's agreement" that would serve the same role.

  • Removing support for old hardware from the kernel

    The kernel supports a wide range of hardware. Or, at least, the kernel contains drivers for a lot of hardware, but the hardware for which many of those drivers was written is old and, perhaps, no longer in actual use. Some of those drivers would certainly no longer work even if the hardware could be found. These drivers provide no value, but they are still an ongoing maintenance burden; it would be better to simply remove them from the kernel. But identifying which drivers can go is not as easy as one might think. Arnd Bergmann led an inconclusive session on this topic at the 2018 Kernel Maintainers Summit.

    Bergmann started by noting (to applause) that he recently removed support for eight processor architectures from the kernel. It was, he said, a lot of work to track down the right people to talk to before removing that code. In almost every case, the outgoing architectures were replaced — by their creators — by Arm-based systems. There probably are not any more architectures that can go anytime soon; Thomas Gleixner's suggestion that x86 should be next failed to win the support of the group.

  • The proper use of EXPORT_SYMBOL_GPL()

    The kernel, in theory, puts strict limits on which functions and data structures are available to loadable kernel modules; only those that have been explicitly exported with EXPORT_SYMBOL() or EXPORT_SYMBOL_GPL() are accessible. In the case of EXPORT_SYMBOL_GPL(), only modules that declare a GPL-compatible license will be able to see the symbol. There have been questions about when EXPORT_SYMBOL_GPL() should be used for almost as long as it has existed. The latest attempt to answer those questions was a session run by Greg Kroah-Hartman at the 2018 Kernel Maintainers Summit; that session offered little in the way of general guidance, but it did address one specific case.