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.

More in Tux Machines

NomadBSD 1.2 released!

We are pleased to announce the release of NomadBSD 1.2! We would like to thank all the testers who sent us feedback and bug reports. Read more

Review: Alpine Linux 3.9.2

Alpine Linux is different in some important ways compared to most other distributions. It uses different libraries, it uses a different service manager (than most), it has different command line tools and a custom installer. All of this can, at first, make Alpine feel a bit unfamiliar, a bit alien. But what I found was that, after a little work had been done to get the system up and running (and after a few missteps on my part) I began to greatly appreciate the distribution. Alpine is unusually small and requires few resources. Even the larger Extended edition I was running required less than 100MB of RAM and less than a gigabyte of disk space after all my services were enabled. I also appreciated that Alpine ships with some security features, like PIE, and does not enable any services it does not need to run. I believe it is fair to say this distribution requires more work to set up. Installing Alpine is not a point-n-click experience, it's more manual and requires a bit of typing. Not as much as setting up Arch Linux, but still more work than average. Setting up services requires a little more work and, in some cases, reading too since Alpine works a little differently than mainstream Linux projects. I repeatedly found it was a good idea to refer to the project's wiki to learn which steps were different on Alpine. What I came away thinking at the end of my trial, and I probably sound old (or at least old fashioned), is Alpine Linux reminds me of what got me into running Linux in the first place, about 20 years ago. Alpine is fast, light, and transparent. It offered very few surprises and does almost nothing automatically. This results in a little more effort on our parts, but it means that Alpine does not do things unless we ask it to perform an action. It is lean, efficient and does not go around changing things or trying to guess what we want to do. These are characteristics I sometimes miss these days in the Linux ecosystem. Read more

today's howtos

Linux v5.1-rc6

It's Easter Sunday here, but I don't let little things like random major religious holidays interrupt my kernel development workflow. The occasional scuba trip? Sure. But everybody sitting around eating traditional foods? No. You have to have priorities. There's only so much memma you can eat even if your wife had to make it from scratch because nobody eats that stuff in the US. Anyway, rc6 is actually larger than I would have liked, which made me go back and look at history, and for some reason that's not all that unusual. We recently had similar rc6 bumps in both 4.18 and 5.0. So I'm not going to worry about it. I think it's just random timing of pull requests, and almost certainly at least partly due to the networking pull request in here (with just over a third of the changes being networking-related, either in drivers or core networking). Read more Also: Linux 5.1-rc6 Kernel Released In Linus Torvalds' Easter Day Message