CentOS 確認方法 – 近代的CPUの脆弱性

araraboLinux、RHEL/CentOS/Fedora/Mageia、セキュリティ

CentOS は安定性を第一に考える RHEL シリーズのクローン（ソースコードを元に完全互換を目指している）です。
インストール後のカーネルは古いため、アップデートをしてから確認を行っています。

目次

確認方法

まず、Ubuntu の確認方法同様に dmesg と proc/cpuinfo を利用して確認してみます。

base on kernel - How to check that KPTI is enabled on my Ubuntu? - Ask Ubuntu

  • /proc/cpuinfo
    grep -q "cpu_insecure|cpu_meltdown|kaiser" /proc/cpuinfo && echo "patched :)" || echo "unpatched :("
  • dmesg
    dmesg | grep -q "Kernel/User page tables isolation: enabled" && echo "patched :)" || echo "unpatched :("

確認環境

Spec Details
OS CentOS 7.3 x64
CPU Celeron 1007U (2M Cache, 1.50 GHz)
MEM 2GB

カーネルバージョン確認

エンタープライズ向け重視のRHEL系だけあって、カーネルは古いです。

# cat /etc/redhat-release 
CentOS Linux release 7.3.1611 (Core) 
# uname -r
3.10.0-514.el7.x86_64

実行サンプル

古いカーネルなので、当然対応していません。

# dmesg | grep -q "Kernel/User page tables isolation: enabled" && echo "patched :)" || echo "unpatched :("
unpatched :(

# grep -q "cpu_insecure\|cpu_meltdown\|kaiser" /proc/cpuinfo && echo "patched :)" || echo "unpatched :("
unpatched :(

# ls -lh /sys/devices/system/cpu/vulnerabilities/
ls: /sys/devices/system/cpu/vulnerabilities/ にアクセスできません: そのようなファイルやディレクトリはありません

カーネル VerUP

アップデート

update ではカーネルバージョンは変わりません。
RHEL系は、カーネルアップデートには upgrade コマンドが必要です。

# dnf update

# uname -r
3.10.0-514.el7.x86_64

# rpm -qa | grep "^kernel" | sort
kernel-3.10.0-514.el7.x86_64
kernel-3.10.0-862.3.3.el7.x86_64
kernel-tools-3.10.0-862.3.3.el7.x86_64
kernel-tools-libs-3.10.0-862.3.3.el7.x86_64

カーネルアップデート

バージョン 7 のカーネルアップデートには、kernel-ml パッケージを導入します。

base on Enterprise Linux (ELRepo) リポジトリ追加 - eTuts+ Server Tutorial
2017.06.12
チャネル 3.　elrepo-kernel
次に、Enterprise Linux Kernel Repository。 ELRepo の中で、一番重要なチャネルとして、最新安定版のカーネルを提供しており、主に、カーネルの最新化・アップデート時に使います。

カーネルのインストール方式は、以下の 2種類をサポートします。

  • kernel-lt
  • kernel-ml

kernel-lt は、long term の略で、Enterprise Linux 5 と 6 用です。
kernel-ml は、mainline stable の略で、Enterprise Linux 7 用です。

ELRepo

kernel-ml パッケージ導入のため、ELRepo （Enterprise Linux Kernel Repository） をインストールします。

base on ELRepo : HomePage

To install ELRepo for RHEL-7, SL-7 or CentOS-7:
rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

base on Index of /linux/kernel/el7/x86_64/RPMS

elrepo-release-7.0-3.el7.elrepo.noarch.rpm 23-Jul-2017 13:09 8.5K

インストール

ELRepo
# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
kernel-ml
# yum --enablerepo=elrepo-kernel install kernel-ml

================================================================================
 Package        アーキテクチャー
                            バージョン                 リポジトリー        容量
================================================================================
インストール中:
 kernel-ml      x86_64      4.17.2-1.el7.elrepo        elrepo-kernel       45 M

Downloading packages:
kernel-ml-4.17.2-1.el7.elrepo.x86_64.rpm                   |  45 MB   00:06     

インストール:
  kernel-ml.x86_64 0:4.17.2-1.el7.elrepo
再起動
# reboot

確認

再起動後に確認すると、以前のカーネルが選択されていることを確認できます。

# uname -r
3.10.0-862.3.3.el7.x86_64

念の為、導入されているか確認します。

# rpm -qa | grep "^kernel" | sort
kernel-3.10.0-514.el7.x86_64
kernel-3.10.0-862.3.3.el7.x86_64
kernel-ml-4.17.2-1.el7.elrepo.x86_64
kernel-tools-3.10.0-862.3.3.el7.x86_64
kernel-tools-libs-3.10.0-862.3.3.el7.x86_64

カーネル選択

導入した新しいカーネルを使用して起動するように設定します。

起動確認

導入カーネルで問題なく起動できるか確認します。

起動時にカーネル選択画面が出るので、当該カーネルを選択して Enterキーを押下します。

# uname -r
4.17.2-1.el7.elrepo.x86_64

設定

正常起動したら、設定するカーネル名を確認します。

# cat /boot/grub2/grub.cfg | grep menuentry
if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
  menuentry_id_option=""
export menuentry_id_option
menuentry 'CentOS Linux (4.17.2-1.el7.elrepo.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-514.el7.x86_64-advanced-86083fb8-7e5b-4c55-97de-b3106a6fefdd' {
menuentry 'CentOS Linux (3.10.0-862.3.3.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-514.el7.x86_64-advanced-86083fb8-7e5b-4c55-97de-b3106a6fefdd' {
menuentry 'CentOS Linux (3.10.0-514.el7.x86_64) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-514.el7.x86_64-advanced-86083fb8-7e5b-4c55-97de-b3106a6fefdd' {
menuentry 'CentOS Linux (0-rescue-4100cafdc4c04253b07cffd96046cfbf) 7 (Core)' --class centos --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-4100cafdc4c04253b07cffd96046cfbf-advanced-86083fb8-7e5b-4c55-97de-b3106a6fefdd' {

カーネルの設定変更

# cat /etc/default/grub 
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet"
GRUB_DISABLE_RECOVERY="true"
  • GRUB_DEFAULT=saved
    行に番号０から記載するのですが、saved の場合は別ファイル（/boot/grub2/grubenv）に記載されています。
    ファイルの他にコマンドでも確認できます。
# grub2-editenv list
saved_entry=CentOS Linux (3.10.0-862.3.3.el7.x86_64) 7 (Core)

GRUB 2 環境ファイル更新

  • grub2-set-default コマンドで 先頭(0)をデフォルトにした後、
  • 念のため、設定を確認し、
  • grub.cfgを再生成します。
# grub2-set-default 0

# grub2-editenv list
saved_entry=0

# grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.17.2-1.el7.elrepo.x86_64
Found initrd image: /boot/initramfs-4.17.2-1.el7.elrepo.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-862.3.3.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-862.3.3.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-514.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-514.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-4100cafdc4c04253b07cffd96046cfbf
Found initrd image: /boot/initramfs-0-rescue-4100cafdc4c04253b07cffd96046cfbf.img
done

# reboot

確認

再起動すると、カーネル選択画面で最新カーネルにフォーカスが移っています。

# uname -r
4.17.2-1.el7.elrepo.x86_64

結果

詳細は、下記diffを見ていただくとして、大まかには以下のとおりです。

脆弱性 状態 diff該当行
Spectre Variant 1 OK STATUS: NOT VULNERABLE
Spectre Variant 2 NG IBPB support: YES となっているが、CPUのマイクロコードがIBPB（間接分岐予測バリア）をサポートしておらず、IBPB enabled and active: NO となっている
Variant 3 OK Kernel supports Page Table Isolation (PTI): YES
Variant 3a NG The microcode of your CPU needs to be upgraded to mitigate this vulnerability. つまり、CPUのマイクロコードをアップグレードする必要があるがM/Bメーカーから未リリースのため不対応
Variant 4 NG Kernel supports speculation store bypass: YES とあるが、Your CPU doesn't support SSBD（投機的ストア バイパスの無効化にCPUが対応していない）とあるため

詳細

# diff -u check1.txt check2.txt
--- check1.txt  2018-06-20 22:09:53.096755433 +0900
+++ check2.txt  2018-06-20 22:55:47.746366155 +0900
@@ -1,7 +1,7 @@
 Spectre and Meltdown mitigation detection tool v0.37+

 Checking for vulnerabilities on current system
-Kernel is Linux 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64
+Kernel is Linux 4.17.2-1.el7.elrepo.x86_64 #1 SMP Sat Jun 16 11:18:11 EDT 2018 x86_64
 CPU is Intel(R) Celeron(R) CPU 1007U @ 1.50GHz

 Hardware check
@@ -31,43 +31,33 @@
   * Vulnerable to Variant 4:  YES 

 CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
+* Mitigated according to the /sys interface:  YES  (Mitigation: __user pointer sanitization)
 * Kernel has array_index_mask_nospec (x86):  UNKNOWN  (missing 'perl' binary, please install it)
 * Kernel has the Red Hat/Ubuntu patch:  NO 
 * Kernel has mask_nospec64 (arm):  UNKNOWN  (missing 'perl' binary, please install it)
-* Checking count of LFENCE instructions following a jump in kernel...  NO  (only 2 jump-then-lfence instructions found, should be >= 30 (heuristic))
-> STATUS:  VULNERABLE  (Kernel source needs to be patched to mitigate the vulnerability)
-
-> How to fix: Your kernel is too old to have the mitigation for Variant 1, you should upgrade to a newer kernel. If you're using a Linux distro and didn't compile the kernel yourself, you should upgrade your distro to get a newer kernel.
+* Checking count of LFENCE instructions following a jump in kernel...  NO  (only 5 jump-then-lfence instructions found, should be >= 30 (heuristic))
+> STATUS:  NOT VULNERABLE  (Mitigation: __user pointer sanitization)

 CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
+* Mitigated according to the /sys interface:  YES  (Mitigation: Full generic retpoline)
 * Mitigation 1
-  * Kernel is compiled with IBRS support:  NO 
+  * Kernel is compiled with IBRS support:  YES 
     * IBRS enabled and active:  NO 
-  * Kernel is compiled with IBPB support:  NO 
+  * Kernel is compiled with IBPB support:  YES 
     * IBPB enabled and active:  NO 
 * Mitigation 2
   * Kernel has branch predictor hardening (arm):  NO 
-  * Kernel compiled with retpoline option:  NO 
-> STATUS:  VULNERABLE  (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability)
-
-> How to fix: To mitigate this vulnerability, you need either IBRS + IBPB, both requiring hardware support from your CPU microcode in addition to kernel support, or a kernel compiled with retpoline and IBPB, with retpoline requiring a retpoline-aware compiler (re-run this script with -v to know if your version of gcc is retpoline-aware) and IBPB requiring hardware support from your CPU microcode. The retpoline + IBPB approach is generally preferred as the performance impact is lower. More information about how to enable the missing bits for those two possible mitigations on your system follow. You only need to take one of the two approaches.
-
-> How to fix: The microcode of your CPU needs to be upgraded to be able to use IBPB. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). An updated CPU microcode will have IBRS/IBPB capabilities indicated in the Hardware Check section above. If you're running under an hypervisor (KVM, Xen, VirtualBox, VMware, ...), the hypervisor needs to be up to date to be able to export the new host CPU flags to the guest. You can run this script on the host to check if the host CPU is IBRS/IBPB. If it is, and it doesn't show up in the guest, upgrade the hypervisor. You may need to reconfigure your VM to use a CPU model that has IBRS capability; in Libvirt, such CPUs are listed with an IBRS suffix.
-
-> How to fix: Your kernel doesn't have IBPB support, so you need to either upgrade your kernel (if you're using a distro) or recompiling a more recent kernel.
-
-> How to fix: The microcode of your CPU needs to be upgraded to be able to use IBRS. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). An updated CPU microcode will have IBRS/IBPB capabilities indicated in the Hardware Check section above. If you're running under an hypervisor (KVM, Xen, VirtualBox, VMware, ...), the hypervisor needs to be up to date to be able to export the new host CPU flags to the guest. You can run this script on the host to check if the host CPU is IBRS/IBPB. If it is, and it doesn't show up in the guest, upgrade the hypervisor. You may need to reconfigure your VM to use a CPU model that has IBRS capability; in Libvirt, such CPUs are listed with an IBRS suffix.
-
-> How to fix: Your kernel doesn't have IBRS support, so you need to either upgrade your kernel (if you're using a distro) or recompiling a more recent kernel.
+  * Kernel compiled with retpoline option:  YES 
+    * Kernel compiled with a retpoline-aware compiler:  YES  (kernel reports full retpoline compilation)
+> STATUS:  NOT VULNERABLE  (Full retpoline is mitigating the vulnerability)

 CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
-* Kernel supports Page Table Isolation (PTI):  NO 
-  * PTI enabled and active:  NO 
+* Mitigated according to the /sys interface:  YES  (Mitigation: PTI)
+* Kernel supports Page Table Isolation (PTI):  YES 
+  * PTI enabled and active:  YES 
   * Reduced performance impact of PTI:  YES  (CPU supports PCID, performance impact of PTI will be reduced)
 * Running as a Xen PV DomU:  NO 
-> STATUS:  VULNERABLE  (PTI is needed to mitigate the vulnerability)
-
-> How to fix: If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel with the CONFIG_PAGE_TABLE_ISOLATION option (named CONFIG_KAISER for some kernels), or the CONFIG_UNMAP_KERNEL_AT_EL0 option (for ARM64)
+> STATUS:  NOT VULNERABLE  (Mitigation: PTI)

 CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
 * CPU microcode mitigates the vulnerability:  NO 
@@ -76,9 +66,10 @@
 > How to fix: The microcode of your CPU needs to be upgraded to mitigate this vulnerability. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section). The microcode update is enough, there is no additional OS, kernel or software change needed.

 CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
-* Kernel supports speculation store bypass:  NO 
-> STATUS:  VULNERABLE  (Neither your CPU nor your kernel support SSBD)
+* Mitigated according to the /sys interface:  NO  (Vulnerable)
+* Kernel supports speculation store bypass:  YES  (found in /proc/self/status)
+> STATUS:  VULNERABLE  (Your CPU doesn't support SSBD)

-> How to fix: Both your CPU microcode and your kernel are lacking support for mitigation. If you're using a distro kernel, upgrade your distro to get the latest kernel available. Otherwise, recompile the kernel from recent-enough sources. The microcode of your CPU also needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).
+> How to fix: Your kernel is recent enough to use the CPU microcode features for mitigation, but your CPU microcode doesn't actually provide the necessary features for the kernel to use. The microcode of your CPU hence needs to be upgraded. This is usually done at boot time by your kernel (the upgrade is not persistent across reboots which is why it's done at each boot). If you're using a distro, make sure you are up to date, as microcode updates are usually shipped alongside with the distro kernel. Availability of a microcode update for you CPU model depends on your CPU vendor. You can usually find out online if a microcode update is available for your CPU by searching for your CPUID (indicated in the Hardware Check section).

 A false sense of security is worse than no security at all, see --disclaimer

Linux 共通 確認方法

チェック用のシェルスクリプトが有志の方から公開されています。
これを使うと、ディストリビューションに捕らわれず利用することができます。

base on GitHub - speed47/spectre-meltdown-checker: Spectre & Meltdown vulnerability/mitigation checker for Linux

  • Get the latest version of the script using curl or wget
curl -L https://meltdown.ovh -o spectre-meltdown-checker.sh
wget https://meltdown.ovh -O spectre-meltdown-checker.sh
  • When you're ready, run the script as root
chmod +x spectre-meltdown-checker.sh
sudo ./spectre-meltdown-checker.sh

実行方法サンプル

  • 取得後に
  • 実行権限を付与して
  • 実行します。
# wget https://meltdown.ovh -O spectre-meltdown-checker.sh
# chmod +x ./spectre-meltdown-checker.sh
# sh ./spectre-meltdown-checker.sh

※実行結果のサンプルについては、Fedora 確認方法 – 近代的CPUの脆弱性をご参照ください。