meltdown-spectre-cpu-security-vulnerabilities-logos

Después de pasar la semana pasada insistiendo en que el impacto en el rendimiento de las vulnerabilidades de la CPU Meltdown y Spectre “no debería ser significativo”, Intel intentó mantener esa posición el martes, incluso reconociendo las pruebas SYSmark que evalúan las desaceleraciones posteriores al parche que van del 2 por ciento al 14 por ciento.

Reiterando que el uso típico de consumidores y negocios -como leer correos electrónicos, abrir documentos y acceder a fotos digitales- no debería exhibir ningún impacto de rendimiento de la solución, Intel dijo, “las plataformas centrales de 8ª generación con almacenamiento de estado sólido verán un impacto de rendimiento del 6 por ciento o menos.”

Es una excepción sospechosa porque gran parte de la informática de consumo y empresarial se basa en servidores basados ​​en la nube que, como The Register informó el lunes, han mostrado tiempos de respuesta más lentos y una mayor utilización de la CPU como resultado de las correcciones implementadas por los proveedores afectados.

El esfuerzo de Intel para minimizar las consecuencias de los dos defectos se parece mucho a una defensa preventiva contra el litigio.

Es muy tarde para eso. Se han presentado al menos ocho demandas contra Intel desde que The Register informó por primera vez sobre los fallos el 2 de enero.

Chipzilla también podría estar preocupado por el escrutinio de la Comisión de Bolsa y Valores: el CEO Brian Krzanich vendió la mayoría de las acciones de su compañía en noviembre, varios meses después de que Intel conociera las vulnerabilidades de Meltdown y Spectre. Incluso si la venta se realizó como parte de un plan preestablecido, el momento de la venta se ve terrible.

También es difícil la decisión del Instituto de Ingeniería de Software de la Universidad Carnegie Mellon (CMU) de diluir el aviso de vulnerabilidad Meltdown/Spectre inicial de CERT/CC, ya que se interpreta fácilmente como un intento de atenuar las preocupaciones.

El consejo inicial de CMU, emitido el 3 de enero, aconseja reemplazar las CPU porque “la vulnerabilidad subyacente es causada principalmente por las opciones de diseño de la arquitectura de la CPU”.

Una revisión que apareció al día siguiente eliminó esa recomendación a pesar de que otros hayan insistido. Por ejemplo, Daniel Genkin, un investigador postdoctoral que ayudó a descubrir los defectos, le dijo a The Register que una solución duradera requiere un rediseño del hardware.

En una entrevista telefónica,  The Register le preguntó a Art Manion, gerente técnico de análisis de vulnerabilidad en la división CERT del Software Engineering Institute de CMU y al autor de Vulnerability Note VU # 584653, si Intel había presionado al CERT para que revisara su lenguaje.

Manion reconoció que los proveedores, incluido Intel, habían estado en contacto como parte del proceso de divulgación, pero insistió en que la redacción inicial y la revisión provenían del Centro de Coordinación CERT en lugar de en otro lugar.

En esta instancia particular, dijo, CERT no estuvo involucrado en la coordinación previa a la divulgación pública. Y una vez que la historia se rompió, “estábamos luchando”, dijo.

Inicialmente, dijo, parecía un problema relacionado con el hardware. Luego de análisis y comunicación con los proveedores, dijo: “Decidimos que el lenguaje era demasiado directo”.

El hardware desempeña un papel, dijo, “pero uno de los principios de nuestro asesoramiento es proporcionar información procesable”.

En otras palabras, decirle al mundo que arroje la mayor parte de los procesadores producidos en la última década simplemente no fue una respuesta realista.

En un correo electrónico, un interlocutor de Intel dijo: “Puedo confirmar que estuvimos en contacto con CERT. No tengo nada que agregar a eso”.

La aterradora respuesta de Chipzilla: una nueva sucursal en el organigrama

Mientras Intel haría que el mundo exterior pasara por alto todo el asunto, el fabricante de chips se reorganizó internamente para centrarse más en la seguridad. El lunes, The Oregonian informó que Krzanich ha barajado a altos ejecutivos para crear un nuevo grupo de seguridad interno llamado Intel Product Assurance and Security, encabezado por el jefe de recursos humanos Leslie Culbertson.

En un reconocimiento relacionado y tardío del valor de la seguridad, Intel presentó su primer programa de recompensas de errores para sus propios productos en marzo del año pasado.

En cualquier caso, la minimización de Intel de las consecuencias significativas de Meltdown y Spectre parece haberse vuelto insostenible después de que Red Hat dijera la semana pasada que el impacto de los parches oscilaba entre 1 y 20 por ciento en sus puntos de referencia y Microsoft dijo el martes algo similar.

Microsoft no dio a conocer los números de referencia específicos y se negó a proporcionarlos a The Register, por lo que dijo que publicaría los resultados una vez que se completen las pruebas.

Sin embargo, en una publicación de blog el martes, Terry Myerson, presidente del grupo de dispositivos y Windows de Microsoft, sí confirmó diversos grados de retraso, dependiendo del hardware y el software involucrados.

En las PC con Windows 10 con Skylake, Kabylake o las CPU más nuevas, el efecto de la mitigación de la vulnerabilidad es mínimo. Pero con Windows 10 corriendo en hardware más antiguo, Myerson dijo, “esperamos que algunos usuarios noten una disminución en el rendimiento del sistema”.

Para los usuarios de Windows 8 y Windows 7, dijo Myerson, “esperamos que la mayoría de los usuarios noten una disminución en el rendimiento del sistema”.

Para Windows Server, sugirió Myerson, podría ser aún peor, con aplicaciones intensivas de IO que muestran “un impacto de rendimiento más significativo cuando habilita las mitigaciones para aislar el código que no es de confianza dentro de una instancia de Windows Server”.

De hecho, el impacto es lo suficientemente significativo en los clientes de Windows Server que Myerson sugiere dejar escudos para mayor velocidad. Aconseja a aquellos que ejecutan Windows Server “evaluar el riesgo del código que no es de confianza para cada instancia de Windows Server, y equilibrar la compensación de seguridad versus el rendimiento para su entorno”.

 

Fuente: The Register | maslinux

¿Quién está en línea?

Hay 18144 invitados y ningún miembro en línea