2018 년 1 월 20 일
스펙터 보호 ( Retpoline )는 2018 년 1 월 15 일 Linux Kernel 팀이 Kernel 4.9.77 및 4.14.14에 대해 릴리스했습니다. Ubuntu Kernel 팀은 2018 년 1 월 17 일에 커널 버전 4.9.77 만 릴리스했으며 커널 버전 4.14는 게시하지 않았습니다. .14. 이유는 불분명하다. Ask Ubuntu : 왜 커널 4.9.77이 릴리스 되었으나 커널 4.14.14가 아닌 이유는 4.14.14가 다시 요청 되었는가? 오늘까지 나타나지 않았습니다.
2018 년 1 월 17 일 Meltdown에 Spectre 지원 추가
나는 프로그래머의 의견에 문서화 된 4.14.14 (4.14.13)의 변화에 관심이있을 것이라고 생각했다. 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.
프로그래머의 문서에 대해 궁금한 점이 있으면 아래에 의견을 게시하고 최선을 다해 답변 해 드리겠습니다.
4.14.14 및 4.9.77의 2018 년 1 월 16 일 업데이트 스펙터
이미 커널 버전을 4.14.13 또는 4.9.76를 실행하는 경우 나는 그것을 설치하는 생각할 필요 없다 생각처럼 4.14.14그리고 4.9.77그들은 며칠에서 나올 때 유령 보안 구멍을 완화 할 수 있습니다. 이 수정의 이름은 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 커널이 지난 주에 릴리스되었습니다.
이러한 문제는 현재 해결 된 것으로 보이므로 더 많은 x86 업데이트, 일부 PA-RISC, s390 및 PowerPC (PPC) 수정, 다양한 개선 사항 등 Linux 기반 운영 체제를 오늘 출시 된 새로운 커널 버전으로 업데이트하는 것이 안전합니다. 드라이버 (Intel i915, crypto, IOMMU, MTD) 및 일반적인 mm 및 코어 커널 변경.
많은 사용자들이 2018 년 1 월 4 일과 2018 년 1 월 10 일에 Ubuntu LTS 업데이트에 문제가있었습니다 . YMMV4.14.13 는 며칠 동안 문제없이 사용하고 있습니다 . 커널 14.14.13 설치에 대한 지침은 아래로 건너 뛰십시오.
2018 년 1 월 7 일 업데이트
Greg Kroah-Hartman 은 어제 Meltdown 및 Spectre Linux Kernel 보안 취약점에 대한 상태 업데이트 를 작성했습니다 . 일부는 그를 리눅스 세계에서 Linus 바로 옆에서 두 번째로 강력한 인물이라고 부를 수도 있습니다. 이 기사는 대부분의 우분투에서 사용하는 안정적인 커널 (아래에서 설명)과 LTS 커널을 다룹니다.
평균 우분투 사용자에게는 권장되지 않습니다
이 방법에는 최신 메인 라인 (안정된) 커널을 수동으로 설치하는 것이 포함되며 일반 우분투 사용자에게는 권장되지 않습니다. 안정적인 커널을 수동으로 설치 한 후에는 새 커널을 수동으로 설치할 때까지 유지됩니다. 평균 우분투 사용자는 새로운 커널을 자동으로 설치할 LTS 지점에 있습니다.
다른 사람들이 언급했듯이 우분투 커널 팀이 정기적 인 프로세스를 통해 업데이트를 푸시하기를 기다리는 것이 더 간단합니다.
이 답변은 "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 (Long Term Support) 커널 시리즈를 출시하여 가장 현대에 영향을 미치는 두 가지 중요한 보안 결함 중 하나를 패치했습니다. 프로세서.
Linux 4.14.11, 4.9.74, 4.4.109, 3.16.52, 3.18.91 및 3.2.97 커널은 이제 kernel.org 웹 사이트에서 다운로드 할 수 있으며 사용자는 GNU / Linux 배포판을 업데이트해야합니다. 커널 시리즈를 즉시 실행하는 경우이 새 버전으로 왜 업데이트해야합니까? 그들은 분명히 Meltdown이라는 중요한 취약점을 패치하기 때문입니다.
앞서보고 한 것처럼 Meltdown과 Specter는 지난 25 년 동안 출시 된 최신 프로세서 (CPU)로 구동되는 거의 모든 장치에 영향을주는 두 가지 악용입니다. 예, 거의 모든 휴대 전화와 개인용 컴퓨터를 의미합니다. 권한이없는 공격자는 멜트 다운을 악용하여 커널 메모리에 저장된 중요한 정보를 악의적으로 얻을 수 있습니다.
여전히 작동중인 Spectre 취약점 패치
Meltdown은 암호 및 암호화 키를 포함하여 비밀 데이터를 노출시킬 수있는 심각한 취약점이지만 Specter는 더 나빠서 쉽게 고칠 수 없습니다. 보안 연구원들은 그것이 꽤 오랫동안 우리를 괴롭힐 것이라고 말합니다. Specter는 최신 CPU에서 성능을 최적화하기 위해 사용하는 추측 실행 기술을 활용하는 것으로 알려져 있습니다.
스펙터 버그가 패치 될 때까지 최소한 GNU / Linux 배포판을 새로 릴리스 된 Linux 커널 버전으로 업데이트하는 것이 좋습니다. 따라서 좋아하는 배포판의 소프트웨어 저장소에서 새 커널 업데이트를 검색하여 가능한 빨리 설치하십시오. 너무 늦을 때까지 기다리지 말고 지금하십시오!
나는 일주일 동안 Kernel 4.14.10을 사용하고 있었으므로 Ubuntu Mainline Kernel 버전 4.14.11 을 다운로드하고 부팅 하는 것은 나에게별로 중요하지 않았습니다.
Ubuntu 16.04 사용자는 4.14.11과 동시에 릴리스 된 4.4.109 또는 4.9.74 커널 버전에 더 익숙 할 수 있습니다.
정기 업데이트가 커널 버전을 설치하지 않으면 다음 우분투 요청 답변을 따라 수동으로 수행 할 수 있습니다. 커널을 최신 기본 버전으로 업데이트하려면 어떻게합니까?
4.14.12-하루의 차이점
초기 응답 후 24 시간 이내에 패치가 릴리스되어 4.14.11 커널 버전을 수정했습니다. 모든 4.14.11 사용자에게 4.14.12 로 업그레이드하는 것이 좋습니다. 그렉 -KH의 말 :
4.14.12 커널 릴리스를 발표합니다.
4.14 커널 시리즈의 모든 사용자는 업그레이드해야합니다.
이 릴리스에는 여전히 알려진 몇 가지 사소한 문제가 있습니다. 패치가 Linus의 나무에 떨어지지 않았기 때문에 이번 주말에 해결 될 것입니다.
지금처럼 항상 환경에서 테스트하십시오.
이 업데이트를 살펴보면 소스 코드 라인이 그리 많지 않았습니다.
커널 4.14.13 설치
Linux 커널 4.14.13, 4.9.76 및 4.4.111에는 Meltdown 개정판 및 Specter 기능의 시작 부분이 추가되었습니다.
최신 메인 라인 커널을 설치하려는 이유는 다음과 같습니다.
- 마지막 우분투 LTS 커널 업데이트의 버그
- 현재 Ubuntu LTS 커널 업데이트 스트림에서 지원되지 않는 새 하드웨어가 있습니다
- 최신 기본 커널 버전에서만 사용 가능한 보안 업그레이드 또는 새로운 기능이 필요합니다.
2018 년 1 월 15 일 현재 최신 안정적인 메인 라인 커널은 4.14.13입니다. 수동으로 설치하기로 선택한 경우 다음을 알아야합니다.
- 이전 LTS 커널은 Ubuntu 라는 메인 메뉴 첫 번째 옵션보다 클 때까지 업데이트 되지 않습니다 .
- 수동으로 설치된 커널은 일반적인
sudo apt auto-remove명령으로 제거되지 않습니다 . 다음을 따라야합니다 : 부팅 메뉴를 정리하기 위해 이전 커널 버전을 어떻게 제거합니까?
- 일반 LTS 커널 업데이트 방법으로 돌아가고 싶을 때 이전 커널의 개발을 모니터링하십시오. 그런 다음 이전 글 머리 기호 링크에 설명 된대로 수동으로 설치된 기본 커널을 삭제하십시오.
- 최신 메인 라인 커널 실행을 수동으로 제거한
sudo update-grub후 Ubuntu의 최신 LTS 커널은 Grub의 기본 메뉴에서 Ubuntu 라는 첫 번째 옵션이 됩니다.
최신 메인 라인 커널 ( 4.14.13 ) 을 설치하려면 경고가 제대로 표시되지 않습니다. 다음 링크를 따르십시오. Distro-upgrade없이 최신 메인 라인 버전으로 커널을 업데이트하는 방법은 무엇입니까?
