¿Qué muestra realmente la sección de "errores" de / proc / cpuinfo?

En un sistema Debian Stretch and testing / Buster con un kernel actual y un microcódigo instalado, todavía veo colapsos y espectros listados como errores /proc/cpuinfo.

Sin embargo, ejecutar los spectre-meltdown-checkershows no es vulnerable.

Entonces me pregunto qué /proc/cpuinfomuestra. ¿Estas son solo las vulnerabilidades de esta CPU y se enumerarán siempre a pesar de tener un sistema parcheado?

linux cpu proc

— Hurrbert
fuente

Respuestas:

La intención del campo "errores" en /proc/cpuinfose describe en el mensaje de confirmación que lo introdujo :

x86/cpufeature: Agregar indicadores de error a /proc/cpuinfo

Volcar las banderas que denotan que hemos detectado y / o aplicado soluciones alternativas a la CPU en la que estamos ejecutando, de manera similar a las banderas de funciones.

La ventaja es que no se acumulan con el tiempo como las funciones de la CPU.

Anteriormente, los errores de hardware que el núcleo detectaba se enumeraban como características separadas ( por ejemplo, el infame error F00F, que tiene su propia f00f_bugentrada en los /proc/cpuinfosistemas x86 de 32 bits). La entrada "bugs" se introdujo para mantenerlos en una sola función que avanza, en el mismo estilo que las banderas de CPU x86 .

En cuanto a lo que significan las entradas en la práctica, como puede ver en el mensaje, todo lo que está garantizado es que el núcleo detectó un error de hardware. Tendrá que buscar en otro lado (mensajes de arranque o /procentradas específicas o /sysentradas como los archivos /sys/devices/system/cpu/vulnerabilities/) para determinar si se tratan los problemas.

La utilidad de las entradas de "errores" está limitada de dos maneras. La primera es que los verdaderos negativos no se pueden distinguir de las incógnitas: si el campo no especifica "cpu_meltdown", no puede saber (solo desde el campo) si eso significa que el núcleo no sabe acerca de Meltdown, o que su CPU no se ve afectada por Meltdown. El segundo es que la detección puede ser demasiado simplista; se equivoca por el lado de la precaución, por lo que podría informar que su CPU es vulnerable cuando no lo es. Debido a que la "detección" está basada en tablas, su precisión depende de la versión del núcleo que esté ejecutando.

En el caso de los errores Meltdown y Spectre, el proceso de detección que alimenta los valores en /proc/cpuinfo funciona de la siguiente manera , en x86:

si la CPU no realiza ninguna especulación (clase 486, alguna clase Pentium, algunos átomos), no se marca como afectada por Meltdown o Spectre;
todas las CPU restantes se marcan como afectadas por las variantes 1 y 2 de Spectre (independientemente de la revisión del microcódigo, etc.);
si la CPU no aparece como no susceptible de omisión especulativa de la tienda , si su microcódigo no pretende mitigar SSB, y si la CPU no pretende mitigar SSB, entonces se marca como afectada por SSB;
si la CPU no aparece como no susceptible a Meltdown (AMD), y si su microcódigo no pretende mitigar Meltdown, entonces se marca como afectada por Meltdown.

— Stephen Kitt
fuente

En el caso del espectro y la fusión, ni siquiera se detectan, sino que simplemente se asumen . Tengo un x86 en orden que no se ve afectado por ninguno de los dos, pero el kernel solo informa que es de todos modos debido a una regla codificada que básicamente dice que "cualquier CPU Intel anterior a X sin un parche de microcódigo aplicado es vulnerable a la fusión".

— R ..

@R .. ¿está incluida su CPU en las tablas en orden del núcleo? (Busque "cpu_no_speculation" aquí para ver las últimas tablas). Ese es de hecho uno de los problemas con la entrada "bugs" wrt. Meltdown, Spectre y compañía, su precisión realmente depende de cuán reciente sea su núcleo, ya que su "detección" está basada en tablas.

— Stephen Kitt

No, es un Centerton Bonnell y falta desde allí. Veré sobre cómo enviar un parche.

— R ..

¿Alguien sabe si esto sigue siendo correcto cuando se han aplicado actualizaciones de microcódigo durante el arranque pero después de cargar el núcleo?

— Bachsau

Las vulnerabilidades Meltdown / Spectre están en el diseño / arquitectura del conjunto de chips de la CPU, y a falta de comprar nuevo hardware futuro, los parches son una buena ilusión de seguridad a largo plazo . Los nuevos métodos para explotar las fallas pueden surgir con el tiempo y evitar los parches actuales.

En resumen, los parches / microcódigos de software actuales mitigan los problemas contra los métodos conocidos de la familia de exploits Specter / Meltdown, pero no resuelven los problemas de diseño de CPU subyacentes que los permiten en primer lugar. Las CPU afectadas (varias generaciones) no han dejado de ser vulnerables a largo plazo (y probablemente nunca lo harán).

Sin embargo, como dice @Gilles correctamente, tener esa advertencia no significa que los métodos actuales de Spectre / Meltdown funcionarán; no funcionarán si los parches están instalados.

En el caso mencionado en la pregunta, el kernel solo está verificando los modelos de CPU que se sabe que están afectados por Spectre / Meltdown (todas las CPU x86 por ahora si estamos hablando solo de x86), y por lo tanto, cpu-insecuretodavía se enumeran en la sección de errores / línea de entrada /proc/cpuinfo.

Ve a revisar tu /proc/cpuinfo. Contendrá cpu_insecure si su kernel tiene el parche KPTI

Descubrí que el parche KPTI tiene este código:
   /* Assume for now that ALL x86 CPUs are insecure */
   setup_force_cpu_bug(X86_BUG_CPU_INSECURE);
Y después de la actualización del kernel, obtienes:
bugs      : cpu_insecure

PD. Ya había una ronda de actualizaciones para un nuevo método para explotar los "errores" Spectre / Meltdown. Probablemente no sea la última vez.

— Rui F Ribeiro
fuente

Por ejemplo, si puede esperar comprar hw por un tiempo, espere una nueva generación de CPU. Mi bola de cristal me dice que tendremos muchos servidores de segunda mano que se venden por maní en el mediano plazo.

— Rui F Ribeiro

Los errores de CPU se enumeran /proc/cpuinfoincluso si están completamente mitigados por un parche de software. Su presencia no significa que su sistema sea vulnerable a ese error en particular.

— Gilles 'SO- deja de ser malvado'

@Gilles concedido, no podrás aplicar exploits conocidos. Sin embargo, ya teníamos una ronda de exploits en torno a la primera generación de parches, y me aventuraría a decir que hay muchos intereses comerciales por ahí silenciando las críticas de que este es un defecto de diseño fundamental que forzará un importante rediseño de la CPU.

— Rui F Ribeiro

Eso es cierto para los exploits de tipo Spectre / Meltdown, son problemas fundamentales de diseño que seguirán dando. Pero usted escribió que esto es cierto para los bugsprogramas de línea, y esto es simplemente incorrecto. La mayoría de los errores de diseño de la CPU tienen una solución de software completa que solo cuesta un poco de rendimiento. Si el núcleo aplica la solución, entonces el error es inofensivo.

— Gilles 'SO- deja de ser malvado'

@Rui, oh, creo que no me expresé con suficiente claridad: quise decir que el artículo no respondió la pregunta que hizo su propio título, no que no respondiera a esta pregunta ;-). (Como en, el título del artículo es "Cómo el error Specter, que rompió la industria, permaneció en secreto durante siete meses", pero el artículo no explica cómo es la OMI)

— Stephen Kitt,