20 de enero de 2018
Specter Protection ( Retpoline ) fue lanzado para Kernel 4.9.77 y 4.14.14 por el equipo de Linux Kernel el 15 de enero de 2018. El equipo de Ubuntu Kernel solo lanzó la versión de kernel 4.9.77 el 17 de enero de 2018 y no ha publicado la versión de kernel 4.14 .14. El motivo no está claro por qué, pero 4.14.14 se volvió a solicitar como se respondió en Preguntar a Ubuntu: ¿Por qué se lanzó el kernel 4.9.77 pero no el kernel 4.14.14? y no apareció hasta hoy.
17 de enero de 2018 Agregando soporte de espectro a Meltdown
Pensé que algunos estarían interesados en los cambios en 4.14.14 (a partir del 4.14.13) como se documenta en los comentarios de los programadores que creo que son bastante detallados para los programadores del núcleo C debido a mi exposición limitada. Estos son los cambios del kernel 4.14.13 al 4.14.14, centrándose principalmente en el soporte de Spectre :
+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.
Si tiene alguna pregunta sobre la documentación de los programadores, publique un comentario a continuación y haré todo lo posible para responder.
16 de enero de 2018 Specter actualización en 4.14.14 y 4.9.77
Si ya está ejecutando Kernel versiones 4.14.13 o 4.9.76 como yo, es fácil de instalar 4.14.14y 4.9.77cuando salgan en un par de días para mitigar el agujero de seguridad de Spectre. El nombre de esta solución es Retpoline, que no tiene el severo impacto en el rendimiento que se especuló anteriormente:
Greg Kroah-Hartman ha enviado los últimos parches para las versiones de Linux 4.9 y 4.14, que ahora incluyen el soporte Retpoline.
Esta X86_FEATURE_RETPOLINE está habilitada para todas las CPU AMD / Intel. Para obtener soporte completo, también debe construir el núcleo con un compilador GCC más nuevo que contenga soporte -mindirect-branch = thunk-extern. Los cambios de GCC aterrizaron en GCC 8.0 ayer y está en proceso de ser potencialmente transferido a GCC 7.3.
Aquellos que deseen desactivar el soporte Retpoline puede iniciar desde los núcleos parcheados con noretpoline .
Actualización del 12 de enero de 2018
La protección inicial de Spectre está aquí y se mejorará en las próximas semanas y meses.
Kernels de Linux 4.14.13, 4.9.76 LTS y 4.4.111 LTS
De este artículo de Softpedia :
Los kernels de Linux 4.14.13, 4.9.76 LTS y 4.4.111 LTS ahora están disponibles para su descarga desde kernel.org, e incluyen más correcciones contra la vulnerabilidad de seguridad de Spectre, así como algunas regresiones de Linux 4.14.12, 4.9 .75 LTS y 4.4.110 núcleos LTS lanzados la semana pasada, ya que algunos informaron problemas menores.
Estos problemas parecen estar solucionados ahora, por lo que es seguro actualizar sus sistemas operativos basados en Linux a las nuevas versiones del kernel lanzadas hoy, que incluyen más actualizaciones x86, algunas correcciones PA-RISC, s390 y PowerPC (PPC), varias mejoras para controladores (Intel i915, crypto, IOMMU, MTD) y los cambios habituales de núcleo y mm.
Muchos usuarios tuvieron problemas con las actualizaciones de Ubuntu LTS el 4 de enero de 2018 y el 10 de enero de 2018. He estado usando 4.14.13durante un par de días sin ningún problema, sin embargo, YMMV . Vaya al final para obtener instrucciones sobre cómo instalar Kernel 14.14.13.
Actualización del 7 de enero de 2018
Greg Kroah-Hartman escribió ayer una actualización de estado sobre los agujeros de seguridad Meltdown y Specter Linux Kernel. Algunos pueden llamarlo el segundo hombre más poderoso del mundo Linux justo al lado de Linus. El artículo aborda los núcleos estables (que se analizan a continuación) y los núcleos LTS que utiliza la mayoría de Ubuntu.
No recomendado para usuarios promedio de Ubuntu
Este método implica la instalación manual del último núcleo principal (estable) y no se recomienda para el usuario promedio de Ubuntu. La razón es que después de instalar manualmente un núcleo estable, permanece allí hasta que instale manualmente uno más nuevo (o más antiguo). Los usuarios promedio de Ubuntu están en la rama LTS que instalará un nuevo núcleo automáticamente.
Como otros han mencionado, es más simple esperar a que el equipo del kernel de Ubuntu envíe actualizaciones a través del proceso regular.
Esta respuesta es para usuarios avanzados de Ubuntu que desean arreglar la seguridad de "Meltdown" de inmediato y están dispuestos a hacer un trabajo manual adicional.
Kernels de Linux 4.14.11, 4.9.74, 4.4.109, 3.16.52 y 3.2.97 Fallo de fusión de parches
De este artículo :
Se insta a los usuarios a actualizar sus sistemas de inmediato
4 de enero de 2018 01:42 GMT · Por Marius Nestor
Los mantenedores de kernel de Linux Greg Kroah-Hartman y Ben Hutchings han lanzado nuevas versiones de la serie de kernel Linux 4.14, 4.9, 4.4, 3.16, 3.18 y 3.12 LTS (Soporte a largo plazo) que aparentemente corrige uno de los dos defectos de seguridad críticos que afectan a la mayoría de los modernos procesadores
Los núcleos Linux 4.14.11, 4.9.74, 4.4.109, 3.16.52, 3.18.91 y 3.2.97 ahora están disponibles para descargar desde el sitio web kernel.org, y se insta a los usuarios a actualizar sus distribuciones GNU / Linux a estas nuevas versiones si ejecutan cualquiera de esas series de kernel inmediatamente. ¿Por qué actualizar? Porque aparentemente corrigen una vulnerabilidad crítica llamada Meltdown.
Como se informó anteriormente, Meltdown y Spectre son dos exploits que afectan a casi todos los dispositivos alimentados por procesadores modernos (CPU) lanzados en los últimos 25 años. Sí, eso significa casi todos los teléfonos móviles y computadoras personales. Meltdown puede ser explotado por un atacante sin privilegios para obtener maliciosamente información confidencial almacenada en la memoria del núcleo.
Parche para la vulnerabilidad Spectre aún en proceso
Si bien Meltdown es una vulnerabilidad grave que puede exponer sus datos secretos, incluidas las contraseñas y las claves de cifrado, Spectre es aún peor, y no es fácil de solucionar. Los investigadores de seguridad dicen que nos perseguirá durante bastante tiempo. Se sabe que Specter explota la técnica de ejecución especulativa utilizada por las CPU modernas para optimizar el rendimiento.
Hasta que se repare también el error de Spectre, se recomienda encarecidamente que al menos actualice sus distribuciones de GNU / Linux a cualquiera de las versiones de kernel de Linux recientemente lanzadas. Por lo tanto, busque en los repositorios de software de su distribución favorita la nueva actualización del kernel e instálela lo antes posible. No esperes hasta que sea demasiado tarde, ¡hazlo ahora!
Había estado usando Kernel 4.14.10 durante una semana, así que descargar y arrancar Ubuntu Mainline Kernel versión 4.14.11 no era una gran preocupación para mí.
Los usuarios de Ubuntu 16.04 pueden sentirse más cómodos con las versiones de kernel 4.4.109 o 4.9.74 que se lanzaron al mismo tiempo que 4.14.11.
Si sus actualizaciones habituales no instalan la versión del kernel que desea, puede hacerlo manualmente siguiendo esta pregunta a Ubuntu: ¿Cómo actualizo el kernel a la última versión de la línea principal?
4.14.12 - Qué diferencia hace un día
Menos de 24 horas después de mi respuesta inicial, se lanzó un parche para corregir la versión del kernel 4.14.11 que pueden haber precipitado. Se recomienda actualizar a 4.14.12 para todos los usuarios de 4.14.11. Greg-KH dice :
Estoy anunciando el lanzamiento del kernel 4.14.12.
Todos los usuarios de la serie de kernel 4.14 deben actualizarse.
Hay algunos problemas menores aún conocidos con esta versión que la gente se ha encontrado. Esperemos que se resuelvan este fin de semana, ya que los parches no han aterrizado en el árbol de Linus.
Por ahora, como siempre, pruebe su entorno.
Mirando esta actualización, no se cambiaron muchas líneas de código fuente.
Kernel 4.14.13 Instalación
Se introdujeron más revisiones de Meltdown y el comienzo de las características de Spectre en Linux Kernels 4.14.13, 4.9.76 y 4.4.111.
Hay razones por las que desea instalar el último núcleo de la línea principal:
- Un error en la última actualización del kernel Ubuntu LTS
- Tiene nuevo hardware no admitido en la secuencia actual de actualización del núcleo Ubuntu LTS
- Desea una actualización de seguridad o una nueva función solo disponible en la última versión del núcleo de la línea principal.
A partir del 15 de enero de 2018, el último núcleo estable estable es 4.14.13. Si elige instalarlo manualmente, debe saber:
- Los núcleos LTS más antiguos no se actualizarán hasta que sean mayores que la primera opción del menú principal titulada Ubuntu .
- Los núcleos instalados manualmente no se eliminan con el
sudo apt auto-removecomando habitual . Debe seguir esto: ¿Cómo elimino las versiones antiguas del kernel para limpiar el menú de arranque?
- Monitoree los desarrollos en los núcleos más antiguos para cuando desee volver al método de actualización del núcleo LTS habitual. Luego elimine el núcleo de línea principal instalado manualmente como se describe en el enlace anterior de viñeta.
- Después de eliminar manualmente la ejecución más reciente del núcleo de la línea principal
sudo update-gruby luego el último núcleo LTS de Ubuntu será la primera opción llamada Ubuntu en el menú principal de Grub.
Ahora que las advertencias están fuera del camino, para instalar el último núcleo de la línea principal ( 4.14.13 ) siga este enlace: ¿Cómo actualizar el núcleo a la última versión de la línea principal sin ninguna actualización de Distro?
