mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
translated
This commit is contained in:
geekpi
parent
04f2d66be5
commit
6eaa5442b5
@ -1,55 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
Long-term Embedded Linux Maintenance Made Easier
|
||||
============================================================
|
||||
|
||||
|
||||
Pengutronix kernel hacker Jan Lübbe summarized growing security threats in embedded Linux and outlined a plan to keep long-life devices secure and fully functional in this talk from Embedded Linux Conference Europe.[The Linux Foundation][1]
|
||||
|
||||
The good old days when security breaches only happened to Windows folk are fading fast. Malware hackers and denial of service specialists are increasingly targeting out of date embedded Linux devices, and fixing Linux security vulnerabilities was the topic of several presentations at the [Embedded Linux Conference Europe ][3](ELCE) in October.
|
||||
|
||||
One of the best attended was “Long-Term Maintenance, or How to (Mis-)Manage Embedded Systems for 10+ Years” by [Pengutronix][4] kernel hacker Jan Lübbe. After summarizing the growing security threats in embedded Linux, Lübbe laid out a plan to keep long-life devices secure and fully functional. “We need to move to newer, more stable kernels and do continuous maintenance to fix critical vulnerabilities,” said Lübbe. “We need to do the upstreaming and automate processes, and put in place a sustainable workflow. We don’t have any more excuses for leaving systems in the field with outdated software.”
|
||||
|
||||
As Linux devices grow older, traditional lifecycle procedures are no longer up to the job. “Typically, you would take a kernel from a SoC vendor or mainline, take a build system, and add user space,” said Lübbe. “You customize that and add an application, and do some testing and you’re done. But then there’s a maintenance phase for 15 years, and you better hope you have no platform changes, or want to add new features, or need to apply regulatory changes.”
|
||||
|
||||
All these changes increasingly expose your system to new errors, and require massive updates to keep in sync with upstream software. “But it’s not always unintentional errors that occur in the kernel that lead to problems,” said Lübbe. “These vendor kernels never went through the mainline community review process,” he added, noting the [backdoor][5] found last year in an Allwinner kernel.
|
||||
|
||||
“You cannot trust that your vendor will do the correct thing,” continued Lübbe. “Maybe only one or two engineers looked at that backdoor code. That would never happen if the patch was posted on a Linux kernel mailing list. Somebody would notice. Hardware vendors don’t care about security or maintenance. Maybe you get an update after one or two years, but even then it usually takes years between the time they start developing based on one fixed version to the point they declare it stable. If you then start developing on that base, you add maybe another half a year, and it’s even more obsolete.”
|
||||
|
||||
Increasingly, embedded developers working with long-life products build on Long Term Stable (LTS) kernels. But that doesn’t mean your work is done. “After a product is released, people don’t often follow the stable release chain anymore, so they don’t apply the security patches,” said Lübbe. “You’re getting the worst of both worlds: an obsolete kernel and no security. You don’t get the benefit of testing by many people.”
|
||||
|
||||
Lübbe noted that Pengutronix customers that used server-oriented distributions like Red Hat often ran into problems due to the rapid rate of customizations, as well as deployment and update systems that assume a sysadmin is on duty.
|
||||
|
||||
“The updates can work for some things, especially if they are x86, but each project is basically on its own to build infrastructure to update to new releases.”
|
||||
|
||||
Many developers choose backporting as a solution for updating long-life products. “It’s easy in the beginning, but once you are no longer in the project's maintenance window, they don’t tell you if the version you use is affected by a bug, so it becomes much more difficult to find out if a fix is relevant,” said Lübbe. “So you pile up patches and changes and the bugs accumulate, and you have to maintain them yourself because no one else is using those patches. The benefits of using open source software are lost.”
|
||||
|
||||
### Follow Upstream Projects
|
||||
|
||||
The best solution, argues Lübbe, is to follow releases maintained by upstream projects. “We’ve mostly focused on mainline based development, so we have as little difference as possible between the product and the mainstream kernel and other upstream projects. Long-term systems are well supported in mainline. Most systems that don’t use 3D graphics can run very few patches. Newer kernel versions also have lots of [new hardening features][6] that reduce the impact of vulnerabilities.”
|
||||
|
||||
Following mainline seems daunting to many developers, but it’s relatively easy if you implement procedures from the start, and then stick to them, said Lübbe. “You need to develop processes for everything you do on the system,” he said. “You always need to know what software is running, which is easier when you use a good build system. Each software release should define the complete system so you can update everything in the field. If you don’t know what’s there, you can’t fix it. You also want to have automated testing and automated deployment of updates.”
|
||||
|
||||
To “save an update cycle,” Lübbe recommends using the most recent Linux kernel when you start developing, and only moving to a stable kernel when you enter testing. After that, he suggests updating all the software in the system, including kernel, build system, user space, glibc, and components like OpenSSL every year, to versions that are supported by the upstream projects for the rest of the year.
|
||||
|
||||
“Just because you update at that point doesn’t mean you need to deploy,” said Lübbe. “If you see no security vulnerabilities, you can just put the patch on the shelf and have it ready if you need it.”
|
||||
|
||||
Finally, Lübbe recommends looking at release announcements every month, and checking out security announcements on CVE and mainline lists every week. You only need to respond “if the security announcement actually affects you,” he added. “If your kernel is current enough, it’s not too much work. You don’t want to get feedback on your product by seeing your device in the news.”
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/event/ELCE/2017/long-term-embedded-linux-maintenance-made-easier
|
||||
|
||||
作者：[ERIC BROWN][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/ericstephenbrown
|
||||
[1]:https://www.linux.com/licenses/category/linux-foundation
|
||||
[2]:https://www.linux.com/files/images/jan-lubbe-elcpng
|
||||
[3]:http://events.linuxfoundation.org/events/archive/2016/embedded-linux-conference-europe
|
||||
[4]:http://www.pengutronix.de/index_en.html
|
||||
[5]:http://arstechnica.com/security/2016/05/chinese-arm-vendor-left-developer-backdoor-in-kernel-for-android-pi-devices/
|
||||
[6]:https://www.linux.com/news/event/ELCE/2017hardening-kernel-protect-against-attackers
|
||||
@ -0,0 +1,53 @@
|
||||
长期维护嵌入式 Linux 内核变得容易
|
||||
============================================================
|
||||
|
||||
|
||||
Pengutronix 内核黑客 JanLübbe 总结了嵌入式 Linux 中正在增长的安全威胁，并在这次 [Linux 基金会][1]在欧洲举行的嵌入式 Linux 会议上概述了一个计划，以保持长期设备的安全和完整功能。
|
||||
|
||||
过去安全漏洞只发生在在民间快速衰落的 Windows 上。恶意软件黑客和拒绝服务专家越来越多地针对过时的嵌入式 Linux 设备，因此 10 月在[欧洲举行的嵌入式 Linux 会议][3]（ELCE）上的几个演讲的主题是关于修复 Linux 安全漏洞。
|
||||
|
||||
最好的参加者之一是“长期维护、管理嵌入式系统10年以上“的 [Pengutronix][4]内核黑客 JanLübbe。在总结嵌入式 Linux 中不断增长的安全威胁后，Lübbe 制定了一项计划，以确保长期设备的安全和完整的功能。 Lübbe说：“我们需要迁移到更新、更稳定的内核，并进行持续维护以修复关键漏洞。我们需要做上游和自动化流程，并建立一个可持续的工作流程。我们没有任何借口在系统中使用过时的软件。”
|
||||
|
||||
随着 Linux 设备变得越来越老，传统的生命周期程序已经不再适用。 Lübbe说：“通常，你会从 SoC 供应商或主线上获取内核、构建系统，并添加到用户空间。你自定义并添加了一个程序，并在做了一些检测后就完成了。但是，在 15 年的维护阶段，你最好希望没有平台变化，或者想添加新的功能，或者需要应用监管变化。”
|
||||
|
||||
所有这些变化越来越多地暴露新的系统错误，并需要大量更新以与上游软件保持同步。 Lübbe说：“但这并不总是在内核中发生导致问题的无意错误”。去年在 Allwinner 内核中发现的[后门][5]后，它补充说：“这些供应商内核从来不会执行主线社区的审查流程”。
|
||||
|
||||
Lübbe继续说：“你不能相信你的供应商会做正确的事情。也许只有一两个工程师看到这个后门代码。如果补丁发布在 Linux 内核邮件列表上，这将永远不会发生。因为会有人注意到。硬件供应商不关心安全或维护。也许你会在一两年后得到更新，但是即使这样，他们在一个固定版本开始开发到他们声明稳定的点通常需要几年的时间。如果你开始在这个基础上开发，你可能又增加了半年，甚至更过时了。
|
||||
|
||||
越来越多的嵌入式开发人员在长期稳定（LTS）内核上构建长期产品。但这并不意味着你的工作已经完成。Lübbe说：“一个产品发布后，人们不再经常遵循稳定的发行链，因此他们不应用安全补丁。你会得到两个世界中最糟糕的：一个过时的内核以及没有安全。你不会得到许多人测试的好处。”
|
||||
|
||||
Lübbe 指出，使用像 Red Hat 这样的面向服务器的发行版的 Pengutronix 客户经常遇到问题，因为可以如没有值守人员那样快速的定制、部署、升级系统。
|
||||
|
||||
“更新可以用于某些东西上，特别是如果它们是 x86，但每个项目基本上是自己建立基础设施更新到新版本。”
|
||||
|
||||
许多开发人员选择向后移植作为更新长期产品的解决方案。Lübbe 说：“开始时很容易，但是一旦你不在项目的维护窗口，他们不会告诉你你使用的版本是否受到一个错误的影响，所以很难找出一个修复是否相关。所以你堆积补丁、修改以及 bug 积累，这些你必须自己维护，因为没有人会使用这些补丁。使用开源软件的好处就丢失了。”
|
||||
|
||||
### 跟随上游项目
|
||||
|
||||
Lübbe 认为最好的解决方案是跟踪由上游项目维护的版本。“我们主要关注基于主线的开发，所以我们在产品和主流内核及其他上游项目之间尽可能没有差别。长期系统在主线上得到很好的支持。大多数不使用 3D 图形的系统可以运行很少的补丁。较新的内核版本还有很多[新的强化功能][6]，这些可以减少漏洞的影响。
|
||||
|
||||
跟随主线似乎对许多开发人员来说是令人畏惧的，但是如果从一开始就这样，然后坚持下去，就会相对容易一些，Lübbe说：“你需要为系统制定一切开发过程。你总是需要知道什么软件正在运行，这在使用良好的构建系统时会更容易。每个软件版本应定义完整的系统，以便你可以更新系统中的一切。如果你不知道那里有什么，那么你就不能解决它。你还会想要进行自动测试和自动部署更新。
|
||||
|
||||
为了“保存更新周期”，Lübbe 建议在开始开发时使用最新的 Linux 内核，并且在进入测试时才移动到稳定的内核。之后，他建议每年将系统中的所有软件（包括内核、构建系统、用户空间、glibc 和组件（如 OpenSSL））更新为上一年度其他上游项目支持的版本。
|
||||
|
||||
Lübbe说：“你在这点更新并不意味着你需要部署。如果你没有看到安全漏洞，你可以把补丁放在一版，如果你需要它就准备好了。
|
||||
|
||||
最后，Lübbe 建议每个月查看发布公告，并且每周检查 CVE 和主线列表上的安全公告。你只需要回应 “公告实际影响了你”。他补充说：“如果你的内核足够现代，这并没有太多的工作。你不想在新闻中看到你的设备而获得有关你产品的反馈。”
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/event/ELCE/2017/long-term-embedded-linux-maintenance-made-easier
|
||||
|
||||
作者：[ERIC BROWN][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://www.linux.com/users/ericstephenbrown
|
||||
[1]:https://www.linux.com/licenses/category/linux-foundation
|
||||
[2]:https://www.linux.com/files/images/jan-lubbe-elcpng
|
||||
[3]:http://events.linuxfoundation.org/events/archive/2016/embedded-linux-conference-europe
|
||||
[4]:http://www.pengutronix.de/index_en.html
|
||||
[5]:http://arstechnica.com/security/2016/05/chinese-arm-vendor-left-developer-backdoor-in-kernel-for-android-pi-devices/
|
||||
[6]:https://www.linux.com/news/event/ELCE/2017hardening-kernel-protect-against-attackers
|
||||
Loading…
Reference in New Issue
Block a user