MeltdownおよびSpectreの脆弱性に関するUbuntuのステータスは何ですか？

Question

ステータスの更新に関連する質問、またはこれらの脆弱性に対してパッチを適用するかどうかを尋ねる質問は、この質問の重複として終了する必要があります。

MeltdownとSpectre は現在ニュースにあり、かなり厳しい音です。これらの脆弱性をカバーするUbuntuのセキュリティ更新プログラムは見当たりません。

Ubuntuはこれらの脆弱性について何をしていて、Ubuntuユーザーは何をすべきでしょうか？

これらは、CVE-2017-5753、CVE-2017-5715、およびCVE-2017-5754です。

Robie Basak · Accepted Answer

新しいクラスのサイドチャネル攻撃は、Intel、AMD、ARMのプロセッサを含むほとんどのプロセッサに影響を与えることが発見されました。この攻撃により、悪意のあるユーザースペースプロセスがカーネルメモリを読み取り、ゲストの悪意のあるコードがハイパーバイザーメモリを読み取ることができます。

この問題に対処するには、Ubuntuカーネルとプロセッサマイクロコードの更新が必要です。アップデートは Ubuntu Security Notices で発表されます。 Meltdown/Spectre関連のアップデートが発表され、カーネルと一部のユーザースペースソフトウェアのアップデートをカバーしています。

以下の更新がリリースされました。

Ubuntuカーネルアップデートは、 USN 3522-1 （Ubuntu 16.04 LTSの場合）、 USN 3523-1 （ Ubuntu 17.10の場合）、 USN 3522-2 （Ubuntu 14.04 LTS（HWE）の場合）、および USN-3524-1 （Ubuntu 14.04 LTSの場合）。
カーネルの更なる更新（Specterバリアントの緩和策とMeltdownの追加緩和策の両方を含む）は、2018年1月22日に USN-3541-2 （Ubuntu 16.04 LTS（ HWE））、 USN-3540-1 （Ubuntu 16.04 LTSの場合）、 USN-3541-1 （ Ubuntu 17.10の場合）、 USN-3540-2 （Ubuntu 14.04 LTS（HWE）の場合）、 USN-3542-1 （Ubuntu 14.04 LTSの場合）、 USN-3542-2 （Ubuntu 12.04 LTS（HWE）の場合）。
USN-3516-1 は、Firefoxの更新を提供します。
USN-3521-1 は、NVIDIAドライバーの更新を提供します。
~~USN-3531-1 は、Intelマイクロコードの更新を提供します。~~ 回帰のため、マイクロコードの更新は今のところ元に戻されています（ USN-3531-2 ）。

ユーザーは、アップデートがリリースされたらすぐにを通常の方法でインストールする必要があります。カーネルとマイクロコードの更新を有効にするには、再起動が必要です。

ユーザーは、カーネルページテーブル分離パッチがアクティブであることを確認できます再起動後に。

Ubuntu 17.04（Zesty Zapus）の更新は提供されませんそのまま reached end-of-life 1月13 2018年。

セキュリティアップデートがリリースされる前に、Dustin Kirklandは blog post で期待するアップデートの詳細を提供していました。これには、カーネルアップデートやCPUマイクロコードの言及、 gccおよびqemuの更新。

CanonicalのKiko Reisは、2018年1月24日にUbuntuユーザー向けに、これらの脆弱性の影響とその緩和策に関する accessibleの記述を書きました .

Ubuntuセキュリティチームは、これらの問題に関する現在のステータスを維持するおよび公式の技術的なFAQ について詳しく説明しています特定の個々の脆弱性バリアントと、さまざまなユースケースでのそれらのミギテーション。

V4.15（2018年1月28日）以降のLinuxメインラインおよび安定版リリースの更新には適切な修正が含まれており、Ubuntuカーネルはそれらに基づいていることに注意してください。そのため、Linuxカーネルバージョン4.15.0以降を使用するUbuntuのすべてのバージョンにパッチが適用されます（18.04および18.10を含む）。

Thomas Ward · Answer

ここで心に留めておくべき特定の事柄があります。これは、Ubuntuだけでなく、分析とセキュリティに関するメーリングリストの一部からも取り上げられています。

Meltdown攻撃は、カーネルレベルでパッチを適用できます。これは、Meltdownの一連の脆弱性から保護するのに役立ちます。
Spectre攻撃ベクトルは、保護がはるかに困難ですが、悪者が悪用することもはるかに困難です。 既知の攻撃ベクトル（パッチ可能なLLVM攻撃ベクトルなど）のソフトウェアパッチがありますが、中心的な問題は、Spectreを実際に修正するにはCPUハードウェアの動作を変更する必要があることですそして振る舞います。これにより、既知の攻撃ベクトルのみが実際にパッチされるため、保護が非常に難しくなります。ただし、すべてのソフトウェアには、この問題のために個別の強化が必要です。つまり、「1つのパッチですべてが修正されるわけではない」種類の取引の1つです。

さて、大きな質問のために：

注目すべきその他の関連リンク：

WinEunuuchs2Unix · Answer

2018年1月20日

カーネル4.9.77および4.14.14のスペクター保護（ Retpoline ）は、Linuxカーネルチームによって2018年1月15日にリリースされました。Ubuntuカーネルチームは、カーネルバージョン4.9.77を2018年1月17日にのみリリースカーネルバージョン4.14.14を公開していません。理由は不明ですが、Ask Ubuntuで回答されたように4.14.14が再リクエストされました：なぜカーネル4.9.77がリリースされたが、カーネル4.14.14ではなかったのですか？で、今日まで表示されませんでした。

2018年1月17日、メルトダウンへのスペクターサポートの追加

プログラマーのコメントに文書化されている4.14.14の変更（4.14.13から）に興味がある人はいると思いますが、これは私の露出が少ないカーネルCプログラマーにとってかなり詳細だと思います。主に Spectre サポートに焦点を当てた4.14.13から4.14.14カーネルへの変更点は次のとおりです。

+What: /sys/devices/system/cpu/vulnerabilities + /sys/devices/system/cpu/vulnerabilities/meltdown + /sys/devices/system/cpu/vulnerabilities/spectre_v1 + /sys/devices/system/cpu/vulnerabilities/spectre_v2 +Date: January 2018 +Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> +Description: Information about CPU vulnerabilities + + The files are named after the code names of CPU + vulnerabilities. The output of those files reflects the + state of the CPUs in the system. Possible output values: + + "Not affected" CPU is not affected by the vulnerability + "Vulnerable" CPU is affected and no mitigation in effect + "Mitigation: $M" CPU is affected and mitigation $M is in effect diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 520fdec15bbb..8122b5f98ea1 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2599,6 +2599,11 @@ nosmt [KNL,S390] Disable symmetric multithreading (SMT). Equivalent to smt=1. + nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2 + (indirect branch prediction) vulnerability. System may + allow data leaks with this option, which is equivalent + to spectre_v2=off. + noxsave [BUGS=X86] Disables x86 extended register state save and restore using xsave. The kernel will fallback to enabling legacy floating-point and sse state. @@ -2685,8 +2690,6 @@ steal time is computed, but won't influence scheduler behaviour - nopti [X86-64] Disable kernel page table isolation - nolapic [X86-32,APIC] Do not enable or use the local APIC. nolapic_timer [X86-32,APIC] Do not use the local APIC timer. @@ -3255,11 +3258,20 @@ pt. [PARIDE] See Documentation/blockdev/paride.txt. - pti= [X86_64] - Control user/kernel address space isolation: - on - enable - off - disable - auto - default setting + pti= [X86_64] Control Page Table Isolation of user and + kernel address spaces. Disabling this feature + removes hardening, but improves performance of + system calls and interrupts. + + on - unconditionally enable + off - unconditionally disable + auto - kernel detects whether your CPU model is + vulnerable to issues that PTI mitigates + + Not specifying this option is equivalent to pti=auto. + + nopti [X86_64] + Equivalent to pti=off pty.legacy_count= [KNL] Number of legacy pty's. Overwrites compiled-in @@ -3901,6 +3913,29 @@ sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/laptops/sonypi.txt + spectre_v2= [X86] Control mitigation of Spectre variant 2 + (indirect branch speculation) vulnerability. + + on - unconditionally enable + off - unconditionally disable + auto - kernel detects whether your CPU model is + vulnerable + + Selecting 'on' will, and 'auto' may, choose a + mitigation method at run time according to the + CPU, the available microcode, the setting of the + CONFIG_RETPOLINE configuration option, and the + compiler with which the kernel was built. + + Specific mitigations can also be selected manually: + + retpoline - replace indirect branches + retpoline,generic - google's original retpoline + retpoline,AMD - AMD-specific minimal thunk + + Not specifying this option is equivalent to + spectre_v2=auto. + spia_io_base= [HW,MTD] spia_fio_base= spia_pedr= diff --git a/Documentation/x86/pti.txt b/Documentation/x86/pti.txt new file mode 100644 index 000000000000..d11eff61fc9a --- /dev/null +++ b/Documentation/x86/pti.txt @@ -0,0 +1,186 @@ +Overview +======== + +Page Table Isolation (pti, previously known as KAISER[1]) is a +countermeasure against attacks on the shared user/kernel address +space such as the "Meltdown" approach[2]. + +To mitigate this class of attacks, we create an independent set of +page tables for use only when running userspace applications. When +the kernel is entered via syscalls, interrupts or exceptions, the +page tables are switched to the full "kernel" copy. When the system +switches back to user mode, the user copy is used again. + +The userspace page tables contain only a minimal amount of kernel +data: only what is needed to enter/exit the kernel such as the +entry/exit functions themselves and the interrupt descriptor table +(IDT). There are a few strictly unnecessary things that get mapped +such as the first C function when entering an interrupt (see +comments in pti.c). + +This approach helps to ensure that side-channel attacks leveraging +the paging structures do not function when PTI is enabled. It can be +enabled by setting CONFIG_PAGE_TABLE_ISOLATION=y at compile time. +Once enabled at compile-time, it can be disabled at boot with the +'nopti' or 'pti=' kernel parameters (see kernel-parameters.txt). + +Page Table Management +===================== + +When PTI is enabled, the kernel manages two sets of page tables. +The first set is very similar to the single set which is present in +kernels without PTI. This includes a complete mapping of userspace +that the kernel can use for things like copy_to_user(). + +Although _complete_, the user portion of the kernel page tables is +crippled by setting the NX bit in the top level. This ensures +that any missed kernel->user CR3 switch will immediately crash +userspace upon executing its first instruction. + +The userspace page tables map only the kernel data needed to enter +and exit the kernel. This data is entirely contained in the 'struct +cpu_entry_area' structure which is placed in the fixmap which gives +each CPU's copy of the area a compile-time-fixed virtual address. + +For new userspace mappings, the kernel makes the entries in its +page tables like normal. The only difference is when the kernel +makes entries in the top (PGD) level. In addition to setting the +entry in the main kernel PGD, a copy of the entry is made in the +userspace page tables' PGD. + +This sharing at the PGD level also inherently shares all the lower +layers of the page tables. This leaves a single, shared set of +userspace page tables to manage. One PTE to lock, one set of +accessed bits, dirty bits, etc... + +Overhead +======== + +Protection against side-channel attacks is important. But, +this protection comes at a cost: + +1. Increased Memory Use + a. Each process now needs an order-1 PGD instead of order-0. + (Consumes an additional 4k per process). + b. The 'cpu_entry_area' structure must be 2MB in size and 2MB + aligned so that it can be mapped by setting a single PMD + entry. This consumes nearly 2MB of RAM once the kernel + is decompressed, but no space in the kernel image itself. + +2. Runtime Cost + a. CR3 manipulation to switch between the page table copies + must be done at interrupt, syscall, and exception entry + and exit (it can be skipped when the kernel is interrupted, + though.) Moves to CR3 are on the order of a hundred + cycles, and are required at every entry and exit. + b. A "trampoline" must be used for SYSCALL entry. This + trampoline depends on a smaller set of resources than the + non-PTI SYSCALL entry code, so requires mapping fewer + things into the userspace page tables. The downside is + that stacks must be switched at entry time. + d. Global pages are disabled for all kernel structures not + mapped into both kernel and userspace page tables. This + feature of the MMU allows different processes to share TLB + entries mapping the kernel. Losing the feature means more + TLB misses after a context switch. The actual loss of + performance is very small, however, never exceeding 1%. + d. Process Context IDentifiers (PCID) is a CPU feature that + allows us to skip flushing the entire TLB when switching page + tables by setting a special bit in CR3 when the page tables + are changed. This makes switching the page tables (at context + switch, or kernel entry/exit) cheaper. But, on systems with + PCID support, the context switch code must flush both the user + and kernel entries out of the TLB. The user PCID TLB flush is + deferred until the exit to userspace, minimizing the cost. + See intel.com/sdm for the gory PCID/INVPCID details. + e. The userspace page tables must be populated for each new + process. Even without PTI, the shared kernel mappings + are created by copying top-level (PGD) entries into each + new process. But, with PTI, there are now *two* kernel + mappings: one in the kernel page tables that maps everything + and one for the entry/exit structures. At fork(), we need to + copy both. + f. In addition to the fork()-time copying, there must also + be an update to the userspace PGD any time a set_pgd() is done + on a PGD used to map userspace. This ensures that the kernel + and userspace copies always map the same userspace + memory. + g. On systems without PCID support, each CR3 write flushes + the entire TLB. That means that each syscall, interrupt + or exception flushes the TLB. + h. INVPCID is a TLB-flushing instruction which allows flushing + of TLB entries for non-current PCIDs. Some systems support + PCIDs, but do not support INVPCID. On these systems, addresses + can only be flushed from the TLB for the current PCID. When + flushing a kernel address, we need to flush all PCIDs, so a + single kernel address flush will require a TLB-flushing CR3 + write upon the next use of every PCID. + +Possible Future Work +==================== +1. We can be more careful about not actually writing to CR3 + unless its value is actually changed. +2. Allow PTI to be enabled/disabled at runtime in addition to the + boot-time switching. + +Testing +======== + +To test stability of PTI, the following test procedure is recommended, +ideally doing all of these in parallel: + +1. Set CONFIG_DEBUG_ENTRY=y +2. Run several copies of all of the tools/testing/selftests/x86/ tests + (excluding MPX and protection_keys) in a loop on multiple CPUs for + several minutes. These tests frequently uncover corner cases in the + kernel entry code. In general, old kernels might cause these tests + themselves to crash, but they should never crash the kernel. +3. Run the 'perf' tool in a mode (top or record) that generates many + frequent performance monitoring non-maskable interrupts (see "NMI" + in /proc/interrupts). This exercises the NMI entry/exit code which + is known to trigger bugs in code paths that did not expect to be + interrupted, including nested NMIs. Using "-c" boosts the rate of + NMIs, and using two -c with separate counters encourages nested NMIs + and less deterministic behavior. + + while true; do perf record -c 10000 -e instructions,cycles -a sleep 10; done + +4. Launch a KVM virtual machine. +5. Run 32-bit binaries on systems supporting the SYSCALL instruction. + This has been a lightly-tested code path and needs extra scrutiny. + +Debugging +========= + +Bugs in PTI cause a few different signatures of crashes +that are worth noting here. + + * Failures of the selftests/x86 code. Usually a bug in one of the + more obscure corners of entry_64.S + * Crashes in early boot, especially around CPU bringup. Bugs + in the trampoline code or mappings cause these. + * Crashes at the first interrupt. Caused by bugs in entry_64.S, + like screwing up a page table switch. Also caused by + incorrectly mapping the IRQ handler entry code. + * Crashes at the first NMI. The NMI code is separate from main + interrupt handlers and can have bugs that do not affect + normal interrupts. Also caused by incorrectly mapping NMI + code. NMIs that interrupt the entry code must be very + careful and can be the cause of crashes that show up when + running perf. + * Kernel crashes at the first exit to userspace. entry_64.S + bugs, or failing to map some of the exit code. + * Crashes at first interrupt that interrupts userspace. The paths + in entry_64.S that return to userspace are sometimes separate + from the ones that return to the kernel. + * Double faults: overflowing the kernel stack because of page + faults upon page faults. Caused by touching non-pti-mapped + data in the entry code, or forgetting to switch to kernel + CR3 before calling into C functions which are not pti-mapped. + * Userspace segfaults early in boot, sometimes manifesting + as mount(8) failing to mount the rootfs. These have + tended to be TLB invalidation issues. Usually invalidating + the wrong PCID, or otherwise missing an invalidation.

プログラマーのドキュメントについて質問がある場合は、下にコメントを投稿してください。回答するように最善を尽くします。

2018年1月16日、4.14.14および4.9.77のSpectreを更新

カーネルバージョン4.14.13または4.9.76を既に実行している場合は、数日後に4.14.14および4.9.77がインストールされ、Spectreセキュリティホールを緩和するのは簡単です。この修正の名前は Retpoline であり、以前に推測された深刻なパフォーマンスヒットはありません。

Greg Kroah-HartmanがLinux 4.9および4.14ポイントリリースの最新パッチを送信しました。これには現在、Retpolineサポートが含まれています。

このX86_FEATURE_RETPOLINEは、すべてのAMD/Intel CPUで有効です。完全にサポートするには、-mindirect-branch = thunk-externサポートを含む新しいGCCコンパイラでカーネルを構築する必要もあります。 GCCの変更は、昨日GCC 8.0に上陸し、GCC 7.3にバックポートされる可能性があります。

Retpolineサポートを無効にしたい人は、noretpolineでパッチを適用したカーネルを起動できます。

2018年1月12日更新

Spectreからの初期保護はここにあり、今後数週間から数か月で改善されます。

Linuxカーネル4.14.13、4.9.76 LTS、および4.4.111 LTS

これから Softpediaの記事：

Linuxカーネル4.14.13、4.9.76 LTS、および4.4.111 LTSがkernel.orgからダウンロードできるようになりました。これらには、Spectreセキュリティ脆弱性に対する修正が追加され、Linux 4.14.12、4.9からのいくつかの回帰が含まれています。先週リリースされた.75 LTSおよび4.4.110 LTSカーネルは、いくつかのマイナーな問題を報告したためです。

これらの問題は現在修正されているように見えるので、Linuxベースのオペレーティングシステムを、今日リリースされた新しいカーネルバージョンに安全に更新できます。これには、x86アップデート、PA-RISC、s390、PowerPC（PPC）の修正、ドライバー（Intel i915、暗号、IOMMU、MTD）、および通常のmmおよびコアカーネルの変更。

多くのユーザーは、2018年1月4日と2018年1月10日にUbuntu LTSの更新に問題がありました。問題なく、数日間4.14.13を使用していましたYMMV。カーネル14.14.13のインストール手順については、一番下までスキップしてください。

2018年1月7日更新

Greg Kroah-Hartmanは、昨日、MeltdownとSpectre Linux Kernelのセキュリティホールに status update を書きました。ある人は、彼をLinuxの世界で2番目に強力な男であり、Linusのすぐ隣と呼ぶかもしれません。この記事では、安定したカーネル（以下で説明）とUbuntuの大部分が使用するLTSカーネルについて説明しています。

平均的なUbuntuユーザーには推奨されません

この方法では、最新のメインライン（安定した）カーネルを手動でインストールする必要があり、平均的なUbuntuユーザーにはお勧めできません。安定したカーネルを手動でインストールした後、新しい（または古い）カーネルを手動でインストールするまでそこにとどまるためです。 Ubuntuの平均的なユーザーは、新しいカーネルを自動的にインストールするLTSブランチにいます。

他の人が述べたように、Ubuntu Kernel Teamが通常のプロセスで更新をプッシュするのを待つ方が簡単です。

この答えは、「Meltdown」セキュリティ全体をすぐに修正し、追加の手動作業を希望する上級Ubuntuユーザー向けです。

Linuxカーネル4.14.11、4.9.74、4.4.109、3.16.52、および3.2.97パッチのメルトダウンの欠陥

この記事から：

ユーザーは、すぐにシステムを更新することをお勧めします

2018年1月4日01:42 GMT・マリウスネストル

LinuxカーネルメンテナーのGreg Kroah-HartmanとBen Hutchingsは、最新バージョンのLinux 4.14、4.9、4.4、3.16、3.18、3.12 LTS（長期サポート）カーネルシリーズの新しいバージョンをリリースしました。プロセッサ。

Linux 4.14.11、4.9.74、4.4.109、3.16.52、3.18.91、および3.2.97カーネルがkernel.org Webサイトからダウンロードできるようになりました。ユーザーはGNU/Linuxディストリビューションを更新することをお勧めしますこれらのカーネルシリーズのいずれかをすぐに実行する場合、これらの新しいバージョンに。更新する理由明らかに、Meltdownと呼ばれる重大な脆弱性にパッチを当てているためです。

前述のとおり、MeltdownとSpectreは、過去25年間にリリースされた最新のプロセッサ（CPU）を搭載したほぼすべてのデバイスに影響を与える2つのエクスプロイトです。はい、それはほとんどすべての携帯電話とパソコンを意味します。メルトダウンは、特権のない攻撃者によって悪用され、カーネルメモリに保存されている機密情報を悪意を持って取得する可能性があります。

まだ進行中のSpectre脆弱性に対するパッチ

Meltdownは、パスワードや暗号化キーなどの秘密データを公開する可能性がある重大な脆弱性ですが、Specterはさらに悪化し、修正するのは簡単ではありません。セキュリティ研究者は、かなりの期間、それが私たちを悩ませると言います。 Spectreは、パフォーマンスを最適化するために最新のCPUで使用される投機的実行手法を活用することが知られています。

Spectreのバグにもパッチが適用されるまで、少なくともGNU/Linuxディストリビューションを新しくリリースされたLinuxカーネルバージョンにアップデートすることを強くお勧めします。お気に入りのディストリビューションのソフトウェアリポジトリで新しいカーネルアップデートを検索し、できるだけ早くインストールしてください。手遅れになるまで待ってはいけません、今すぐやってください！

カーネル4.14.10を1週間使用していたので、Ubuntu Mainline Kernelバージョンをダウンロードして起動します 4.14.11 はあまり気になりませんでした。

Ubuntu 16.04ユーザーは、4.14.11と同時にリリースされた4.4.109または4.9.74カーネルバージョンの方が快適かもしれません。

定期的な更新で希望するカーネルバージョンがインストールされない場合、Ubuntuの質問に答えて手動で実行できます。カーネルを最新のメインラインバージョンに更新するにはどうすればよいですか？

4.14.12-1日がもたらす違い

最初の回答から24時間以内に、4.14.11カーネルバージョンを修正するためのパッチがリリースされました。すべての4.14.11ユーザーに 4.14.12 へのアップグレードをお勧めします。 Greg-KHは言う：

4.14.12カーネルのリリースを発表しています。

4.14カーネルシリーズのすべてのユーザーはアップグレードする必要があります。

このリリースには、人々が遭遇したいくつかの小さな問題がまだ知られています。パッチがLinusのツリーに到着していないため、今週の週末に解決されることを願っています。

今のところ、いつものように、環境でテストしてください。

この更新を見ると、ソースコードの行はほとんど変更されていません。

カーネル4.14.13のインストール

Linuxカーネル4.14.13、4.9.76、および4.4.111では、より多くのMeltdownリビジョンとSpectre機能の開始が導入されました。

最新のメインラインカーネルをインストールする理由はいくつかあります。

最後のUbuntu LTSカーネルアップデートのバグ
現在のUbuntu LTSカーネル更新ストリームでサポートされていない新しいハードウェアがあります
最新のメインラインカーネルバージョンでのみ利用可能なセキュリティアップグレードまたは新機能が必要な場合。

2018年1月15日現在、最新の安定したメインラインカーネルは4.14.13です。手動でインストールする場合は、次のことを知っておく必要があります。

古いLTSカーネルは、Ubuntuというタイトルのメインメニューの最初のオプションよりも大きくなるまで、更新しません。
手動でインストールされたカーネルは、通常のSudo apt auto-removeコマンドでは削除されません。これに従う必要があります：ブートメニューをクリーンアップするために古いカーネルバージョンを削除するにはどうすればよいですか？
通常のLTSカーネル更新方法に戻りたいときのために、古いカーネルの開発を監視します。次に、前の箇条書きリンクの説明に従って、手動でインストールされたメインラインカーネルを削除します。
最新のメインラインカーネルを手動で削除した後、Sudo update-grubを実行すると、GrubのメインメニューでUbuntuという最初のオプションがUbuntuの最新のLTSカーネルになります。

警告が表示されなくなったので、最新のメインラインカーネル（4.14.13）をインストールするには、次のリンクに従ってください：更新方法ディストリビューションをアップグレードせずにカーネルを最新のメインラインバージョンにアップグレードしますか？