Maintaining the embedded Linux kernel--so Easy

A security vulnerability that only happens on Windows is fast passing. Malware hackers and denial-of-service veterans are increasingly targeting outdated embedded Linux devices, so the topic of several lectures on the October European Embedded Linux Conference (ELCE) is related to fixing Linux security vulnerabilities.

One of the most worthy speeches is the Pengutronix kernel hacker Lübbe's "long-term maintenance or management (or management-free) embedded systems for more than 10 years." After summarizing the growing security threats in embedded Linux, Lübbe has developed a plan to ensure the security and functionality of long-term equipment. "We need to move to a newer, more stable kernel and maintain it continuously to fix critical vulnerabilities," Lübbe said. We need to do upstream updates and automated processes and build a sustainable workflow. There is no reason to leave outdated software in the system. ”

As Linux devices get older, traditional life cycle processes no longer apply. "Typically, you get the kernel from the SoC vendor or the main line, build the system, and add it to the user space," Lübbe says. You can customize and add programs, and do some testing. However, after 15 years of maintenance, you'd better expect the platform not to change, you won't want to add new features, and you don't need to implement administrative tweaks. ”

All these changes are increasingly causing your system to expose new errors and require a lot of updates to stay in sync with the upstream software. "The error in the kernel that caused the problem is not always unintentional," Lübbe said. For the backdoor found in the Allwinner kernel last year, he added: "These vendors ' cores never perform the review process of the mainline kernel community."

Lübbe continued: "You can't think your supplier has been okay." Perhaps only one or two engineers have looked at the backdoor code block. If the patch is posted on the Linux kernel mailing list, there will be no such thing, because there is always someone to notice. Hardware vendors don't care about security or maintenance, and maybe you'll get updated after a year or two, but even then, they start with a fixed version, which usually takes years to release a stable version. If you start developing on this basis again, it may be a half year later, which is even more outdated. ”

More and more embedded developers build long-term products on long-term stable (LTS) cores. But that doesn't mean it's okay. "Once a product is released, people often stop following a stable distribution chain and no longer apply security patches," Lübbe said. This way you get two of the worst results: outdated kernels and no security. You have lost the benefits of a multiplayer test. ”

Lübbe points out that Pengutronix customers using server-oriented distributions like Red Hat are often experiencing problems due to rapid customization, deployment and upgrade systems that require system administrator intervention.

"Updates are useful for something, especially on x86, but each project basically builds its own infrastructure to update to the new version. ”

Many developers choose to migrate backwards as a solution for updating long-term products. "It's easy at first, but once you're not in the project's maintenance, they won't tell you if the version you're using is affected by a bug, so it's hard to determine whether a fix is relevant," Lübbe says. So you keep patching and updating, and bugs are accumulating, and these you have to maintain yourself, because others don't use these patches. The benefits of using open source software are lost. ”

650) this.width=650; "src=" Http://www.linuxprobe.com/wp-content/uploads/2017/03/011322tsh9l27fnlezqgzn.png "alt=" Maintaining the embedded Linux kernel--so Easy maintenance of the embedded Linux kernel--so easy "/>

Follow the upstream project

Lübbe believes that the best solution is to track the version maintained by the upstream project. "Our main focus is on the development of the mainline core, so we can make as little difference as possible between the product and the mainstream kernel and other upstream projects." Long-term systems are well supported on the mainline core. Most systems that do not use 3D graphics require only a few patches. Newer kernel versions also have many new enhancements that can reduce the impact of the vulnerability.

Following the mainline development may seem daunting for many developers, but it would be relatively easy to do so from the start, and Lübbe said: "You need to develop processes for everything you do on the system." You always need to know what software is running, which is easier when using a good build system. Each software version should define a complete system so that you can update everything about it. If you don't know what's there, you can't solve it. You also need an automated test and automatic deployment of updates. ”

To "Reduce the update cycle", Lübbe recommends using the latest Linux kernel when you start development and going to a stable kernel when you enter the test. Later, he recommends that all software in the system, including the kernel, build systems, user space, glibc, and components (such as OpenSSL), be updated annually to the version supported by the upstream project of the current year.

"Getting updated doesn't mean you need to deploy," says Lübbe. If you don't see a security breach, you can put the patch aside and use it when you need it. ”

Finally, Lübbe recommends reviewing the release bulletins each month and checking the security bulletins on the CVE and mainline lists weekly. You just have to ask yourself, "Does the security bulletin affect you?" He added: "If your kernel is new enough, there won't be much work." You don't want to get feedback about your product by seeing your device in the news. ”

Original from:

Maintaining the embedded Linux kernel--so Easy