¿Cómo compruebo si KPTI está habilitado en Linux?

Las cosas que sí indican el estado de KPTI:

• En los kernels estándar, las cadenas Kernel/User page tables isolation: enabled o Kernel/User page tables isolation: force enabled on command line en la salida dmesg significa que el kernel está realizando el aislamiento de la tabla de páginas del kernel. El último mensaje adicionalmente significa que el kernel cree que el aislamiento de la tabla de páginas no es necesario para esta CPU.

• En algunos núcleos parcheados por el vendedor (principalmente RedHat y derivados): un valor distinto de cero en /sys/kernel/debug/x86/pti_enabled . Sin embargo, la ausencia de este archivo no significa nada: el kernel estándar no lo proporciona.

• En el kernel 4.14.18 o más reciente y las versiones correspondientes de los kernels LTS, el contenido de /sys/devices/system/cpu/vulnerabilities/meltdown : una línea que comienza con Mitigation: indica que hay una mitigación (KPTI, microcódigo, o algo más) en su lugar, una línea que comienza con Not affected indica que se cree que la CPU no se ve afectada por el problema, y una línea que comienza con Vulnerable indica que se cree que la CPU es vulnerable, pero no existe una mitigación o una mitigación insuficiente. .

Cosas que no indican el estado de KPTI:

• Versión del kernel. El kernel 4.14.11 y más reciente, y las versiones correspondientes de los kernels LTS 4.1, 4,4 y 4.9 son capaces de KPTI, pero se pueden compilar con el mismo deshabilitado, y se puede deshabilitar en tiempo de arranque. Además, las versiones más antiguas que estas no están en riesgo automáticamente: algunas distribuciones han portado los parches KPTI a kernels anteriores.

• bugs : cpu_insecure en /proc/cpuinfo . La presencia de esto indica que si el kernel se compila para el aislamiento de la tabla de páginas, y si el aislamiento de la tabla de páginas no se ha deshabilitado en el momento del arranque o en el tiempo de ejecución, entonces la página -Se utilizará aislamiento de mesa. Además, no indica que una CPU es vulnerable al ataque de Meltdown: el kernel 4.14.11 lo establece para todas las CPU x86, mientras que el kernel 4.14.12 lo establece para todas las CPU que no son AMD, incluso algunos como el Pentium MMX o las CPU Atom "Bonnell" que no son vulnerables.

• CONFIG_PAGE_TABLE_ISOLATION=y en la configuración del kernel. Esto solo indica que el kernel es capaz de aislar la tabla de páginas del kernel. KPTI se puede deshabilitar durante el arranque desde la línea de comando del kernel a través de las opciones nopti o pti=off . En algunos sistemas, se puede deshabilitar en tiempo de ejecución escribiendo 0 en /sys/kernel/debug/x86/pti_enabled .

El kernel de Linux registra el estado de KPTI en el arranque, por lo que ejecutar el siguiente comando imprimirá el estado en granos parcheados. Si no se imprime nada, KPTI está deshabilitado.

dmesg -wH | grep 'Kernel/User page tables isolation'

Linux Kernel 4.15rc6 ha habilitado KPTI (aislamiento de tabla de páginas del kernel) y ha sido espalda portada a Linux Kernel 4.14.11 , 4.9.74, 4.4.109, 3.16.52 y 3.2.97.

Entonces, si está ejecutando cualquiera de estas versiones, KPTI está en su lugar. La mayoría de las distribuciones (que ejecutan cualquier versión de kernel de Linux) enviarán una actualización al kernel de Linux dentro de uno o dos días para corregir Meltdown y spectre.

Nota: Agregue el parámetro pti=off a GRUB para deshabilitar el KPTI. Para información: enlace

En un kernel soportado:

dmesg | grep 'Kernel / tablas de páginas de usuario de aislamiento'

resultará en habilitado o deshabilitado.

Si no hay un resultado, entonces el núcleo no tiene soporte para KPTI.

Compruebe la salida de dmesg, como dmesg | grep isolation , para determinar si está activada para su máquina en ejecución.

Algunos detalles adicionales se mencionan aquí: enlace

• Habrá una opción de línea de comandos nopti para deshabilitar este mecanismo en el momento del arranque.
• Existe la opción PAGE_TABLE_ISOLATION del kernel que habilita los parches KPTI, y si CONFIG_IKCONFIG está habilitado, puede verificar el kernel en ejecución mediante zcat /proc/config.gz | grep CONFIG_PAGE_TABLE_ISOLATION=y
• Hay un indicador de función X86_BUG_CPU_INSECURE, y si se sabe que la CPU no está afectada, el aislamiento de la tabla de páginas está desactivado.

Compruebe si hay una línea que contenga Kernel/User page tables isolation en la salida de dmesg . Pero dado que es posible que el inicio del búfer de anillo del núcleo ya no esté allí, otra posibilidad es buscar la misma cadena en /var/log/kern.log (o una de sus versiones rotadas, o algún otro archivo de registro).

También tenga en cuenta que los invitados Xen pueden no tener una línea de este tipo. Por ejemplo, este es el caso silent_disable en arch/x86/mm/kaiser.c del núcleo Debian / stretch (4.9.65-3 + deb9u2):

void __init kaiser_check_boottime_disable(void)
{
[...]
        if (boot_cpu_has(X86_FEATURE_XENPV))
                goto silent_disable;
[...]
disable:
        pr_info("disabled\n");

silent_disable:
        kaiser_enabled = 0;
        setup_clear_cpu_cap(X86_FEATURE_KAISER);
}

También me preocupa el impacto en el rendimiento del parche de fusión. Ejecutamos la mayor parte de la carga de trabajo en Amazon Linux en EC2.

Noté que la actualización más reciente del kernel (compilación 03 de enero de 2018) - 4.9.70-25.242 incluye todos los parches de fusión ascendentes (ver rpm -q --changelog kernel ).

Por defecto, el kernel de Amazon Linux 4.9.70-25.242 y versiones posteriores habilitan el aislamiento de la tabla de páginas ( CONFIG_PAGE_TABLE_ISOLATION=y ), por lo que supongo que siempre que este indicador sea y, KPTI esté habilitado, por desgracia. Sin embargo, no he hecho ninguna comparación de rendimiento (debería ser notable).