标签 内核 下的文章

让我们先看一下 kdump 的基本使用方法,和 kdump/kexec 在内核中是如何实现。

 title=

kdump 是获取崩溃的 Linux 内核转储的一种方法,但是想找到解释其使用和内部结构的文档可能有点困难。在本文中,我将研究 kdump 的基本使用方法,和 kdump/kexec 在内核中是如何实现。

kexec 是一个 Linux 内核到内核的引导加载程序,可以帮助从第一个内核的上下文引导到第二个内核。kexec 会关闭第一个内核,绕过 BIOS 或固件阶段,并跳转到第二个内核。因此,在没有 BIOS 阶段的情况下,重新启动变得更快。

kdump 可以与 kexec 应用程序一起使用 —— 例如,当第一个内核崩溃时第二个内核启动,第二个内核用于复制第一个内核的内存转储,可以使用 gdbcrash 等工具分析崩溃的原因。(在本文中,我将使用术语“第一内核”作为当前运行的内核,“第二内核” 作为使用 kexec 运行的内核,“捕获内核” 表示在当前内核崩溃时运行的内核。)

kexec 机制在内核以及用户空间中都有组件。内核提供了几个用于 kexec 重启功能的系统调用。名为 kexec-tools 的用户空间工具使用这些调用,并提供可执行文件来加载和引导“第二内核”。有的发行版还会在 kexec-tools 上添加封装器,这有助于捕获并保存各种转储目标配置的转储。在本文中,我将使用名为 distro-kexec-tools 的工具来避免上游 kexec 工具和特定于发行版的 kexec-tools 代码之间的混淆。我的例子将使用 Fedora Linux 发行版。

Fedora kexec-tools 工具

使用 dnf install kexec-tools 命令在 Fedora 机器上安装 fedora-kexec-tools。在安装 fedora-kexec-tools 后可以执行 systemctl start kdump 命令来启动 kdump 服务。当此服务启动时,它将创建一个根文件系统(initramfs),其中包含了要挂载到目标位置的资源,以保存 vmcore,以及用来复制和转储 vmcore 到目标位置的命令。然后,该服务将内核和 initramfs 加载到崩溃内核区域内的合适位置,以便在内核崩溃时可以执行它们。

Fedora 封装器提供了两个用户配置文件:

  1. /etc/kdump.conf 指定修改后需要重建 initramfs 的配置参数。例如,如果将转储目标从本地磁盘更改为 NFS 挂载的磁盘,则需要由“捕获内核”所加载的 NFS 相关的内核模块。
  2. /etc/sysconfig/kdump 指定修改后不需要重新构建 initramfs 的配置参数。例如,如果只需修改传递给“捕获内核”的命令行参数,则不需要重新构建 initramfs。

如果内核在 kdump 服务启动之后出现故障,那么“捕获内核”就会执行,其将进一步执行 initramfs 中的 vmcore 保存过程,然后重新启动到稳定的内核。

kexec-tools 工具

编译 kexec-tools 的源代码得到了一个名为 kexec 的可执行文件。这个同名的可执行文件可用于加载和执行“第二内核”,或加载“捕获内核”,它可以在内核崩溃时执行。

加载“第二内核”的命令:

# kexec -l kernel.img --initrd=initramfs-image.img –reuse-cmdline

--reuse-command 参数表示使用与“第一内核”相同的命令行。使用 --initrd 传递 initramfs。 -l 表明你正在加载“第二内核”,其可以由 kexec 应用程序本身执行(kexec -e)。使用 -l 加载的内核不能在内核崩溃时执行。为了加载可以在内核崩溃时执行的“捕获内核”,必须传递参数 -p 取代 -l

加载捕获内核的命令:

# kexec -p kernel.img --initrd=initramfs-image.img –reuse-cmdline

echo c > /pros/sysrq-trigger 可用于使内核崩溃以进行测试。有关 kexec-tools 提供的选项的详细信息,请参阅 man kexec。在转到下一个部分之前,请看这个 kexec\_dump 的演示:

kdump: 端到端流

下图展示了流程图。必须在引导“第一内核”期间为捕获内核保留 crashkernel 的内存。您可以在内核命令行中传递 crashkernel=Y@X,其中 @X 是可选的。crashkernel=256M 适用于大多数 x86\_64 系统;然而,为崩溃内核选择适当的内存取决于许多因素,如内核大小和 initramfs,以及 initramfs 中包含的模块和应用程序运行时的内存需求。有关传递崩溃内核参数的更多方法,请参阅 kernel-parameters 文档

pratyush_f1.png

您可以将内核和 initramfs 镜像传递给 kexec 可执行文件,如(kexec-tools)部分的命令所示。“捕获内核”可以与“第一内核”相同,也可以不同。通常,一样即可。Initramfs 是可选的;例如,当内核使用 CONFIG_INITRAMFS_SOURCE 编译时,您不需要它。通常,从第一个 initramfs 中保存一个不一样的捕获 initramfs,因为在捕获 initramfs 中自动执行 vmcore 的副本能获得更好的效果。当执行 kexec 时,它还加载了 elfcorehdr 数据和 purgatory 可执行文件(LCTT 译注:purgatory 就是一个引导加载程序,是为 kdump 定作的。它被赋予了“炼狱”这样一个古怪的名字应该只是一种调侃)。 elfcorehdr 具有关于系统内存组织的信息,而 purgatory 可以在“捕获内核”执行之前执行并验证第二阶段的二进制或数据是否具有正确的 SHA。purgatory 也是可选的。

当“第一内核”崩溃时,它执行必要的退出过程并切换到 purgatory(如果存在)。purgatory 验证加载二进制文件的 SHA256,如果是正确的,则将控制权传递给“捕获内核”。“捕获内核”根据从 elfcorehdr 接收到的系统内存信息创建 vmcore。因此,“捕获内核”启动后,您将看到 /proc/vmcore 中“第一内核”的转储。根据您使用的 initramfs,您现在可以分析转储,将其复制到任何磁盘,也可以是自动复制的,然后重新启动到稳定的内核。

内核系统调用

内核提供了两个系统调用:kexec_load()kexec_file_load(),可以用于在执行 kexec -l 时加载“第二内核”。它还为 reboot() 系统调用提供了一个额外的标志,可用于使用 kexec -e 引导到“第二内核”。

kexec_load()kexec_load() 系统调用加载一个可以在之后通过 reboot() 执行的新的内核。其原型定义如下:

long kexec_load(unsigned long entry, unsigned long nr_segments,
struct kexec_segment *segments, unsigned long flags);

用户空间需要为不同的组件传递不同的段,如内核,initramfs 等。因此,kexec 可执行文件有助于准备这些段。kexec_segment 的结构如下所示:

struct kexec_segment {
    void *buf;
    /* 用户空间缓冲区 */
    size_t bufsz;
    /* 用户空间中的缓冲区长度 */
    void *mem;
    /* 内核的物理地址 */
    size_t memsz;
    /* 物理地址长度 */
};

当使用 LINUX_REBOOT_CMD_KEXEC 调用 reboot() 时,它会引导进入由 kexec_load 加载的内核。如果标志 KEXEC_ON_CRASH 被传递给 kexec_load(),则加载的内核将不会使用 reboot(LINUX_REBOOT_CMD_KEXEC) 来启动;相反,这将在内核崩溃中执行。必须定义 CONFIG_KEXEC 才能使用 kexec,并且为 kdump 定义 CONFIG_CRASH_DUMP

kexec_file_load():作为用户,你只需传递两个参数(即 kernelinitramfs)到 kexec 可执行文件。然后,kexec 从 sysfs 或其他内核信息源中读取数据,并创建所有段。所以使用 kexec_file_load() 可以简化用户空间,只传递内核和 initramfs 的文件描述符。其余部分由内核本身完成。使用此系统调用时应该启用 CONFIG_KEXEC_FILE。它的原型如下:

long kexec_file_load(int kernel_fd, int initrd_fd, unsigned long
cmdline_len, const char __user * cmdline_ptr, unsigned long
flags);

请注意,kexec_file_load 也可以接受命令行,而 kexec_load() 不行。内核根据不同的系统架构来接受和执行命令行。因此,在 kexec_load() 的情况下,kexec-tools 将通过其中一个段(如在 dtb 或 ELF 引导注释等)中传递命令行。

目前,kexec_file_load() 仅支持 x86 和 PowerPC。

当内核崩溃时会发生什么

当第一个内核崩溃时,在控制权传递给 purgatory 或“捕获内核”之前,会执行以下操作:

  • 准备 CPU 寄存器(参见内核代码中的 crash_setup_regs());
  • 更新 vmcoreinfo 备注(请参阅 crash_save_vmcoreinfo());
  • 关闭非崩溃的 CPU 并保存准备好的寄存器(请参阅 machine_crash_shutdown()crash_save_cpu());
  • 您可能需要在此处禁用中断控制器;
  • 最后,它执行 kexec 重新启动(请参阅 machine_kexec()),它将加载或刷新 kexec 段到内存,并将控制权传递给进入段的执行文件。输入段可以是下一个内核的 purgatory 或开始地址。

ELF 程序头

kdump 中涉及的大多数转储核心都是 ELF 格式。因此,理解 ELF 程序头部很重要,特别是当您想要找到 vmcore 准备的问题。每个 ELF 文件都有一个程序头:

  • 由系统加载器读取,
  • 描述如何将程序加载到内存中,
  • 可以使用 Objdump -p elf_file 来查看程序头。

vmcore 的 ELF 程序头的示例如下:

# objdump -p vmcore
vmcore:
file format elf64-littleaarch64
Program Header:
NOTE off 0x0000000000010000 vaddr 0x0000000000000000 paddr 0x0000000000000000 align 2**0 filesz
0x00000000000013e8 memsz 0x00000000000013e8 flags ---
LOAD off 0x0000000000020000 vaddr 0xffff000008080000 paddr 0x0000004000280000 align 2**0 filesz
0x0000000001460000 memsz 0x0000000001460000 flags rwx
LOAD off 0x0000000001480000 vaddr 0xffff800000200000 paddr 0x0000004000200000 align 2**0 filesz
0x000000007fc00000 memsz 0x000000007fc00000 flags rwx
LOAD off 0x0000000081080000 vaddr 0xffff8000ffe00000 paddr 0x00000040ffe00000 align 2**0 filesz
0x00000002fa7a0000 memsz 0x00000002fa7a0000 flags rwx
LOAD off 0x000000037b820000 vaddr 0xffff8003fa9e0000 paddr 0x00000043fa9e0000 align 2**0 filesz
0x0000000004fc0000 memsz 0x0000000004fc0000 flags rwx
LOAD off 0x00000003807e0000 vaddr 0xffff8003ff9b0000 paddr 0x00000043ff9b0000 align 2**0 filesz
0x0000000000010000 memsz 0x0000000000010000 flags rwx
LOAD off 0x00000003807f0000 vaddr 0xffff8003ff9f0000 paddr 0x00000043ff9f0000 align 2**0 filesz
0x0000000000610000 memsz 0x0000000000610000 flags rwx

在这个例子中,有一个 note 段,其余的是 load 段。note 段提供了有关 CPU 信息,load 段提供了关于复制的系统内存组件的信息。

vmcore 从 elfcorehdr 开始,它具有与 ELF 程序头相同的结构。参见下图中 elfcorehdr 的表示:

pratyush_f2.png

kexec-tools 读取 /sys/devices/system/cpu/cpu%d/crash_notes 并准备 CPU PT_NOTE 的标头。同样,它读取 /sys/kernel/vmcoreinfo 并准备 vmcoreinfo PT_NOTE 的标头,从 /proc/iomem 读取系统内存并准备存储器 PT_LOAD 标头。当“捕获内核”接收到 elfcorehdr 时,它从标头中提到的地址中读取数据,并准备 vmcore。

Crash note

Crash notes 是每个 CPU 中用于在系统崩溃的情况下存储 CPU 状态的区域;它有关于当前 PID 和 CPU 寄存器的信息。

vmcoreinfo

该 note 段具有各种内核调试信息,如结构体大小、符号值、页面大小等。这些值由捕获内核解析并嵌入到 /proc/vmcore 中。 vmcoreinfo 主要由 makedumpfile 应用程序使用。在 Linux 内核,include/linux/kexec.h 宏定义了一个新的 vmcoreinfo。 一些示例宏如下所示:

  • VMCOREINFO_PAGESIZE()
  • VMCOREINFO_SYMBOL()
  • VMCOREINFO_SIZE()
  • VMCOREINFO_STRUCT_SIZE()

makedumpfile

vmcore 中的许多信息(如可用页面)都没有用处。makedumpfile 是一个用于排除不必要的页面的应用程序,如:

  • 填满零的页面;
  • 没有私有标志的缓存页面(非专用缓存);
  • 具有私有标志的缓存页面(专用缓存);
  • 用户进程数据页;
  • 可用页面。

此外,makedumpfile 在复制时压缩 /proc/vmcore 的数据。它也可以从转储中删除敏感的符号信息; 然而,为了做到这一点,它首先需要内核的调试信息。该调试信息来自 VMLINUXvmcoreinfo,其输出可以是 ELF 格式或 kdump 压缩格式。

典型用法:

# makedumpfile -l --message-level 1 -d 31 /proc/vmcore makedumpfilecore

详细信息请参阅 man makedumpfile

kdump 调试

新手在使用 kdump 时可能会遇到的问题:

kexec -p kernel_image 没有成功

  • 检查是否分配了崩溃内存。
  • cat /sys/kernel/kexec_crash_size 不应该有零值。
  • cat /proc/iomem | grep "Crash kernel" 应该有一个分配的范围。
  • 如果未分配,则在命令行中传递正确的 crashkernel= 参数。
  • 如果没有显示,则在 kexec 命令中传递参数 -d,并将输出信息发送到 kexec-tools 邮件列表。

在“第一内核”的最后一个消息之后,在控制台上看不到任何东西(比如“bye”)

  • 检查 kexec -e 之后的 kexec -l kernel_image 命令是否工作。
  • 可能缺少支持的体系结构或特定机器的选项。
  • 可能是 purgatory 的 SHA 验证失败。如果您的体系结构不支持 purgatory 中的控制台,则很难进行调试。
  • 可能是“第二内核”早已崩溃。
  • 将您的系统的 earlyconearlyprintk 选项传递给“第二内核”的命令行。
  • 使用 kexec-tools 邮件列表共享第一个内核和捕获内核的 dmesg 日志。

资源

fedora-kexec-tools

  • GitHub 仓库:git://pkgs.fedoraproject.org/kexec-tools
  • 邮件列表:[email protected]
  • 说明:Specs 文件和脚本提供了用户友好的命令和服务,以便 kexec-tools 可以在不同的用户场景下实现自动化。

kexec-tools

  • GitHub 仓库:git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git
  • 邮件列表:[email protected]
  • 说明:使用内核系统调用并提供用户命令 kexec

Linux kernel

  • GitHub 仓库: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  • 邮件列表:[email protected]
  • 说明:实现了 kexec_load()kexec_file_load()reboot() 系统调用和特定体系结构的代码,例如 machine_kexec()machine_crash_shutdown()

Makedumpfile

  • GitHub 仓库: git://git.code.sf.net/p/makedumpfile/code
  • 邮件列表:[email protected]
  • 说明:从转储文件中压缩和过滤不必要的组件。

(题图:PenguinBoot,修改:Opensource.com. CC BY-SA 4.0


作者简介:

Pratyush Anand - Pratyush 正在以以为 Linux 内核专家的身份与 Red Hat 合作。他主要负责 Red Hat 产品和上游所面临的几个 kexec/kdump 问题。他还处理 Red Hat 支持的 ARM64 平台周围的其他内核调试、跟踪和性能问题。除了 Linux 内核,他还在上游的 kexec-tools 和 makedumpfile 项目中做出了贡献。他是一名开源爱好者,并在教育机构举办志愿者讲座,促进了 FOSS。


via: https://opensource.com/article/17/6/kdump-usage-and-internals

作者:Pratyush Anand 译者:firmianay 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

欢迎来到 Linux 天气预报

本页面是为了跟踪在不久的将来某个时间内有可能出现在主线内核和/或主要发行版中的 Linux 开发社区的进展情况。你的“首席气象学家”是 LWN.net 执行主编 Jonathan Corbet。如果你有改进预测的建议(特别是如果你有一个你认为应该跟踪的项目或修补程序的情况下),请在下面补充你的意见。

预测摘要

当前情况:内核 4.12 于 7 月 2 日发布。它包含了许多新功能,包括:

  • BFQ 和 Kyber 块 I/O 调度器。已经开发多年的 BFQ 在交互式系统上表现更好,这引起了移动设备领域的兴趣。相反,Kyber 是一个更简单的调度程序,旨在用于通常出现在企业配置中的快速设备。
  • epoll\_wait() 系统调用现在可以执行网络套接字的繁忙轮询。
  • 实时修补机制已经实现了混合一致性模型,这将可以把更复杂的补丁应用于运行中的内核。
  • 可信执行框架应该使得内核与在 ARM TrustZone 安全世界中运行的代码之间的交互更加容易。

4.12 是最繁忙的内核开发周期之一,合并了近 15000 次更新。有关这些变化来源的概述,请参阅这里

短期预测:4.13 内核预期在 2017 年 9 月初发布。这个内核中会出现的一些变化是:

4.13 内核现在处于稳定时期,所以在这个开发周期的剩余时间内只会接受修复补丁。

这篇文章根据知识共享署名 - 共享 3.0 许可证获得许可。


via: https://www.linux.com/news/2017/7/linux-weather-forecast

作者:JONATHAN CORBET 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

Linus Torvalds 发布了 Linux 内核 4.12。你可以从这里直接下载相关的 deb 包来安装。或者,继续阅读本文,按下面的步骤安装新内核。

警告:Linux 内核是系统的关键元素。在某个硬件设备不正常工作时,可以尝试执行升级,新的内核可能会解决此问题。 但同样的,非必须地更新一个新的内核也可能导致不必要的回滚,例如,无网络连接, 没有声音,甚至是无法正常启动系统,所以安装一个新的内核,请正确认识风险。

最简单的安装任意内核方法 - 在Linux Mint 使用 UKUU

TerminalShekin@mylinuxmintpc~$sudo apt-add-repository -y ppa:teejee2008/ppa 
sudo apt-get update
sudo apt-get install ukuu

提醒:所有的 Nvidia/AMD 电脑用户, 在安装内核之前,建议切换到 free 版本的驱动。

如果决定删除内核 4.12,

  1. 首先,重启计算机,选择 GRUB 菜单中的旧内核启动。系统引导完成之后,通过以下命令删除新的内核:
  2. 然后,使用 UKUU 程序,或者命令:sudo apt purge linux-image-4.12-*
  3. 最后,更新 GRUB 或者 BURGsudo update-grub

在启动 GRUB 的时候,选择以前的 Linux 版本即可回到以前版本的内核。

Good Luck!!!


via: https://mintguide.org/system/798-install-linux-kernel-4-12-stable-on-linux-mint.html

作者:Shekin 译者:VicYu 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

在 Linux 内核中发现了一个名为 “Stack Clash” 的严重安全问题,攻击者能够利用它来破坏内存数据并执行任意代码。攻击者可以利用这个及另一个漏洞来执行任意代码并获得管理帐户(root)权限。

在 Linux 中该如何解决这个问题?

the-stack-clash-on-linux-openbsd-netbsd-freebsd-solaris

Qualys 研究实验室在 GNU C Library(CVE-2017-1000366)的动态链接器中发现了许多问题,它们通过与 Linux 内核内的堆栈冲突来允许本地特权升级。这个 bug 影响到了 i386 和 amd64 上的 Linux、OpenBSD、NetBSD、FreeBSD 和 Solaris。攻击者可以利用它来破坏内存数据并执行任意代码。

什么是 CVE-2017-1000364 bug?

来自 RHN

在用户空间二进制文件的堆栈中分配内存的方式发现了一个缺陷。如果堆(或不同的内存区域)和堆栈内存区域彼此相邻,则攻击者可以使用此缺陷跳过堆栈保护区域,从而导致进程堆栈或相邻内存区域的受控内存损坏,从而增加其系统权限。有一个在内核中减轻这个漏洞的方法,将堆栈保护区域大小从一页增加到 1 MiB,从而使成功利用这个功能变得困难。

据原研究文章

计算机上运行的每个程序都使用一个称为堆栈的特殊内存区域。这个内存区域是特别的,因为当程序需要更多的堆栈内存时,它会自动增长。但是,如果它增长太多,并且与另一个内存区域太接近,程序可能会将堆栈与其他内存区域混淆。攻击者可以利用这种混乱来覆盖其他内存区域的堆栈,或者反过来。

受到影响的 Linux 发行版

  1. Red Hat Enterprise Linux Server 5.x
  2. Red Hat Enterprise Linux Server 6.x
  3. Red Hat Enterprise Linux Server 7.x
  4. CentOS Linux Server 5.x
  5. CentOS Linux Server 6.x
  6. CentOS Linux Server 7.x
  7. Oracle Enterprise Linux Server 5.x
  8. Oracle Enterprise Linux Server 6.x
  9. Oracle Enterprise Linux Server 7.x
  10. Ubuntu 17.10
  11. Ubuntu 17.04
  12. Ubuntu 16.10
  13. Ubuntu 16.04 LTS
  14. Ubuntu 12.04 ESM (Precise Pangolin)
  15. Debian 9 stretch
  16. Debian 8 jessie
  17. Debian 7 wheezy
  18. Debian unstable
  19. SUSE Linux Enterprise Desktop 12 SP2
  20. SUSE Linux Enterprise High Availability 12 SP2
  21. SUSE Linux Enterprise Live Patching 12
  22. SUSE Linux Enterprise Module for Public Cloud 12
  23. SUSE Linux Enterprise Build System Kit 12 SP2
  24. SUSE Openstack Cloud Magnum Orchestration 7
  25. SUSE Linux Enterprise Server 11 SP3-LTSS
  26. SUSE Linux Enterprise Server 11 SP4
  27. SUSE Linux Enterprise Server 12 SP1-LTSS
  28. SUSE Linux Enterprise Server 12 SP2
  29. SUSE Linux Enterprise Server for Raspberry Pi 12 SP2

我需要重启我的电脑么?

是的,由于大多数服务依赖于 GNU C Library 的动态连接器,并且内核自身需要在内存中重新加载。

我该如何在 Linux 中修复 CVE-2017-1000364?

根据你的 Linux 发行版来输入命令。你需要重启电脑。在应用补丁之前,记下你当前内核的版本:

$ uname -a
$ uname -mrs

示例输出:

Linux 4.4.0-78-generic x86_64

Debian 或者 Ubuntu Linux

输入下面的 apt 命令 / apt-get 命令来应用更新:

$ sudo apt-get update && sudo apt-get upgrade && sudo apt-get dist-upgrade

示例输出:

Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libc-bin libc-dev-bin libc-l10n libc6 libc6-dev libc6-i386 linux-compiler-gcc-6-x86 linux-headers-4.9.0-3-amd64 linux-headers-4.9.0-3-common linux-image-4.9.0-3-amd64
  linux-kbuild-4.9 linux-libc-dev locales multiarch-support
14 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/62.0 MB of archives.
After this operation, 4,096 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
Preconfiguring packages ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../libc6-i386_2.24-11+deb9u1_amd64.deb ...
Unpacking libc6-i386 (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../libc6-dev_2.24-11+deb9u1_amd64.deb ...
Unpacking libc6-dev:amd64 (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../libc-dev-bin_2.24-11+deb9u1_amd64.deb ...
Unpacking libc-dev-bin (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../linux-libc-dev_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-libc-dev:amd64 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../libc6_2.24-11+deb9u1_amd64.deb ...
Unpacking libc6:amd64 (2.24-11+deb9u1) over (2.24-11) ...
Setting up libc6:amd64 (2.24-11+deb9u1) ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../libc-bin_2.24-11+deb9u1_amd64.deb ...
Unpacking libc-bin (2.24-11+deb9u1) over (2.24-11) ...
Setting up libc-bin (2.24-11+deb9u1) ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../multiarch-support_2.24-11+deb9u1_amd64.deb ...
Unpacking multiarch-support (2.24-11+deb9u1) over (2.24-11) ...
Setting up multiarch-support (2.24-11+deb9u1) ...
(Reading database ... 115123 files and directories currently installed.)
Preparing to unpack .../0-libc-l10n_2.24-11+deb9u1_all.deb ...
Unpacking libc-l10n (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../1-locales_2.24-11+deb9u1_all.deb ...
Unpacking locales (2.24-11+deb9u1) over (2.24-11) ...
Preparing to unpack .../2-linux-compiler-gcc-6-x86_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-compiler-gcc-6-x86 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../3-linux-headers-4.9.0-3-amd64_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-headers-4.9.0-3-amd64 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../4-linux-headers-4.9.0-3-common_4.9.30-2+deb9u1_all.deb ...
Unpacking linux-headers-4.9.0-3-common (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../5-linux-kbuild-4.9_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-kbuild-4.9 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Preparing to unpack .../6-linux-image-4.9.0-3-amd64_4.9.30-2+deb9u1_amd64.deb ...
Unpacking linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u1) over (4.9.30-2) ...
Setting up linux-libc-dev:amd64 (4.9.30-2+deb9u1) ...
Setting up linux-headers-4.9.0-3-common (4.9.30-2+deb9u1) ...
Setting up libc6-i386 (2.24-11+deb9u1) ...
Setting up linux-compiler-gcc-6-x86 (4.9.30-2+deb9u1) ...
Setting up linux-kbuild-4.9 (4.9.30-2+deb9u1) ...
Setting up libc-l10n (2.24-11+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libc-dev-bin (2.24-11+deb9u1) ...
Setting up linux-image-4.9.0-3-amd64 (4.9.30-2+deb9u1) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-3-amd64
cryptsetup: WARNING: failed to detect canonical device of /dev/md0
cryptsetup: WARNING: could not determine root device from /etc/fstab
W: initramfs-tools configuration sets RESUME=UUID=054b217a-306b-4c18-b0bf-0ed85af6c6e1
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/md1p1
I: (UUID=bf72f3d4-3be4-4f68-8aae-4edfe5431670)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-update-grub:
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /boot/vmlinuz-4.9.0-3-amd64
Found kernel: /boot/vmlinuz-3.16.0-4-amd64
Updating /boot/grub/menu.lst ... done

Setting up libc6-dev:amd64 (2.24-11+deb9u1) ...
Setting up locales (2.24-11+deb9u1) ...
Generating locales (this might take a while)...
  en_IN.UTF-8... done
Generation complete.
Setting up linux-headers-4.9.0-3-amd64 (4.9.30-2+deb9u1) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...

使用 reboot 命令重启桌面/服务器:

$ sudo reboot

Oracle/RHEL/CentOS/Scientific Linux

输入下面的 yum 命令

$ sudo yum update
$ sudo reboot

Fedora Linux

输入下面的 dnf 命令:

$ sudo dnf update
$ sudo reboot

Suse Enterprise Linux 或者 Opensuse Linux

输入下面的 zypper 命令:

$ sudo zypper patch
$ sudo reboot

SUSE OpenStack Cloud 6

$ sudo zypper in -t patch SUSE-OpenStack-Cloud-6-2017-996=1
$ sudo reboot

SUSE Linux Enterprise Server for SAP 12-SP1

$ sudo zypper in -t patch SUSE-SLE-SAP-12-SP1-2017-996=1
$ sudo reboot

SUSE Linux Enterprise Server 12-SP1-LTSS

$ sudo zypper in -t patch SUSE-SLE-SERVER-12-SP1-2017-996=1
$ sudo reboot

SUSE Linux Enterprise Module for Public Cloud 12

$ sudo zypper in -t patch SUSE-SLE-Module-Public-Cloud-12-2017-996=1
$ sudo reboot

验证

你需要确认你的版本号在 reboot 命令之后改变了。

$ uname -a
$ uname -r
$ uname -mrs

示例输出:

Linux 4.4.0-81-generic x86_64

给 OpenBSD 用户的注意事项

此页获取更多信息。

给 Oracle Solaris 的注意事项

见此页获取更多信息。

参考


作者简介:

Vivek Gite

作者是 nixCraft 的创始人,对于 Linux 操作系统/Unix shell脚本有经验丰富的系统管理员和培训师。他曾与全球客户及各行各业,包括 IT、教育、国防和空间研究以及非营利部门合作。在 TwitterFacebookGoogle + 上关注他。


via: https://www.cyberciti.biz/faq/howto-patch-linux-kernel-stack-clash-vulnerability-cve-2017-1000364/

作者:Vivek Gite 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

OpenBSD logo

在 OpenBSD 的测试快照中加入了一个新的功能,每次当 OpenBSD 用户重启或升级计算机时都会创建一个独特的内核。

该功能被称之为 KARL( 内核地址随机化链接 Kernel Address Randomized Link ),即以随机的顺序重新链接其内部的内核文件,从而每次生成一个独特的内核二进制文件。

当前的稳定版中,OpenBSD 内核使用预先定义好的顺序来链接和加载内核二进制文件中的内部文件,这导致所有用户的内核都是一样的。

KARL 与 ASLR 不同

KARL 由 Theo de Raadt 开发。KARL 会在安装、升级和重启时生成一个新的内核二进制文件。当用户启动、升级和重启机器时,最新生成的内核会替换已有的内核二进制,而操作系统会生成一个新的内核,其将用于下次启动、升级和重启,周而复始。

不要将 KARL 和 ASLR( 地址空间布局随机化 Address Space Layout Randomization )相混淆,ASLR 是一种用于随机化应用代码执行的内存地址的技术,以防止知道应用或内核运行的特定区域而被针对性利用。

de Raadt 说,“它仍然装载在 KVA( 内核虚拟地址空间 Kernel Virtual Address Space )中的同样位置,这不是内核的 ASLR!”

相反,KARL 以随机的内部结构生成内核二进制,这样漏洞利用程序就不能泄露或攻击内核内部函数、指针或对象。技术性的解释参见下面内容。

一个独特的内核是这样链接的,启动汇编代码仍放在原处,接着是随机大小的空隙,然后是随机重组的其它 .o 文件。这样的结果就是函数和变量之间的距离是全新的。一个指针的信息泄露将不会暴露其它指针或对象。这或许会减少可变体系架构的组件,因为指令流的多态性被嵌套偏移的改变所破坏。

“因此,每次的新内核都是独特的。”de Raadt 说。

该功能是最近两个月开发的

该功能的开发始于五月份,首次讨论出现于六月中旬的 OpenBSD 技术邮件列表中。KARL 最近出现于 OpenBSD 6.1 的快照版本中。

“当今的情况是许多人从 OpenBSD 安装内核二进制,然后这个相同的内核二进制将运行六个月以上。当然,如果你重复地引导这个相同的内核二进制,其内存布局也是一样的。这就是现在我们所提交的代码解决的问题。”de Raadt 说,“然而, -current 快照包含了一些我正在和 Robert Peichaer 开发的将来的变化。那个变化将可以使你每次重启都启动到一个新链接的内核上。”

KARL 是一个独有的功能

一个销售针对隐私的硬件产品的初创企业 Technoethical 的创始人 Tiberiu C. Turbureanu 对 Bleeping Computer 说,这是一个 OpenBSD 独有的功能。

“在 Linux 中没有实现它,”Turbureanu 说,“看起来很棒的想法”,估计有可能该功能会移植到 Linux 内核中。

不过,Linux 刚刚增加了对 KASLR( 内核地址空间布局随机化 Kernel Address Space Layout Randomization )的支持,该功能是将 KSLR 移植到了内核本身,它会将内核加载到随机的内存地址。

该功能在上周发布的 Linux 4.12 中默认启用。这两者的不同是 KARL 是装载不同的内核到同一个位置,而 KASLR 则是装载相同的二进制到随机的位置。目标相同,做法不同。

在 Windows 中没有支持 KARL,但是微软使用 KASLR 已经很多年了。反病毒创客公司 Emsisoft 的 CTO Fabian Wosar 正在全力将 KARL 增加到 Windows 内核中。

“OpenBSD 的这个思路需要进一步发扬到(当前的 Windows 内核防护中),这样大家都可以有一个独特内核二进制了,”Wosar 在和 Bleeping Computer 的私人谈话中说到。

“即便是你知道了(随机的)内核起始点,你也不能用它来找到要定位的特定函数,函数相对于内核起始点的位置是随系统不同而不同的,”Wosar 补充说。

其它的操作系统平台,如 Windows 和 Linux ,如果拥有 KARL 将极大的改善其用户的安全性。

备受关注的 LinuxCon 2017(北京)即将在一周后在北京首秀,而国内已经连续举办了 11 届的中国 Linux 内核开发者大会(CLK)也将在金秋十月的北京举办第 12 届。值此 Linux 界两大盛会举办之际,我特意收集了一些 Linux 内核方面的文章分享给大家。

让我们先以一篇漫画开端:《漫画赏析:Linux 内核到底长啥样》,这篇并不算严谨的漫画,来自极客漫画站 TurnOff.us,由 LCTT 翻译组进行汉化和点评,以有趣的方式向大众展示了内核里面都发生了些什么:

Linux 内核都有啥

当然, 作为非专业陈述,就不必深究细节了,但是这篇漫画成功地引起了诸多(伪)Linux 内核爱好者的兴趣。

如果你对 Linux 内核发生了兴趣,想要知道 Linux 内核是如何构建的,那这里也有一篇文章可以指导你,这是一篇由 GitHub 上 0xAX 写的一系列 Linux 内核文章中的一篇, LCTT 成员 @mudongliang 参与了组织翻译。

此系列我们还翻译了数篇数据结构方面的文章,如:双向链表基数树位数组,这些在你做内核开发和研究时肯定会用到。当然,Linus Torvalds 大神向来以对进入内核的代码审核严苛而著称,比如说,他曾经就如何写出具有 “good taste” 的代码而发表过演讲。

说起来,现在内核的变化太快了,简直是日新月异,比如说,我们就注意到 BPF 进入了 4.9 内核,它相当于 BSD 中的 DTrace 一样。另外,据闻 Linux 内核将新增一种异构内存管理,将会加快 Linux 上的机器学习处理能力。

这么多的新特性的涌现,背后代表着大量的代码和贡献人员的辛勤付出。据 2016 年度《Linux 内核开发》报告,自版本 3.18 于 2014 年 12 月 7 日发布以来,已合并了近 115000 个变更,这些贡献来自近 500 家公司的 5062 名开发人员。

当然,Linux 内核发展这么迅速,随着影响力的提升,也越来越引起各界的注意,比如说,华盛顿邮报就曾经批评 Linux “没有一个系统性的机制以在骇客之前发现和解决安全问题,或引入更新的防御技术”,“Linux 内核开发社区没有一个首席安全官”等等。针对这篇文章,LWN 上也有人对此进行了一些回应,并就一些问题进行了辨析和反思。

所以,现在 Linux 内核不仅仅需要更好的安全机制的出现和贡献者的努力,也需要解决 Linux 内核代码审查人员短缺问题

前面说了很多 Linux 内核开发人员更关注的话题, 对于普通的 Linux 用户来说,可能更关注的是如何在 CentOSUbuntu 上升级内核。不过,现在的内核已经支持升级后不重启了,对于某些内核补丁,可以热应用而不用重启。这对于生产环境中的 Linux 服务器很重要,比如 UbuntuOracle Linux 等发行版已经支持了。

作为 Linux 的使用者,尤其是 Linux 服务器的运维人员,密切监控 Linux 的各项性能指标也是必需的工作,无论是传统工具: top、ps、pstree、vmstatiostat,还是 htopnmonntopng 这样的新工具;而且不但有 cpustatCoreFreq 这样专门监控 CPU 的工具,也有各种大而全的全面监控系统,如 GlancesnetdataMunin。总之,用于监控的工具和系统不要太多了

那么,你喜欢 Linux ,喜欢研究下 Linux 内核么?如果是,那么这两场大会你一定要关注: