EDICIóN GENERAL
299 meneos
1485 clics
La fundación RISC-V da importancia a las ISA de código abierto tras el descubrimiento de «Meltdown» y «Spectre» [ING]

La fundación RISC-V da importancia a las ISA de código abierto tras el descubrimiento de «Meltdown» y «Spectre» [ING]

La Fundación RISC-V dice que ninguna «CPU» RISC-V es vulnerable a «Meltdown» y «Spectre», y recalcó la importancia del desarrollo de código abierto y una ISA moderna para prevenir vulnerabilidades. En los ordenadore de consumo usamos habitualmente dos ISA: x86 y ARM. x86 domina el escritorio y los servidores. Con el advenimiento de los teléfonos inteligentes, los procesadores ARM han dominado el mercado móvil. Aparte de x86 no hay muchas otras arquitecturas «CISC». En cambio hay muchas «RISC» más allá de ARM. RISC-V es una de ellas.

| etiquetas: risc-v , meltdown , spectre , intel , arm , amd
Que tranquilidad dá saber que El raspberry no está afectado.

Voy a trasladar toda la documentación importante y confidencial a su SD desde el NAS y el servidor.
#1 Raspberry no usa RISC-V.
#4 creo que tiene que ver mi comentario más con esta noticia que el tuyo, pero ¿para qué discutir?
#5 Podemos darnos de hostias directamente. Te espero fuera.
#7 las hostias no son un buen regalo de reyes.
#8 Mejor carbón.
#19 Mejor cabrón
#7 No te metas con él que es del Depor, no tendrías nada que hacer.
#1, el antiguo Professor sí que era un buen troll, que sabía que a la raspberry le puedes enganchar discos duros o incluso usarla de NAS, así que sabría que tu chiste no tiene sentido.

Ni los trolls son ya lo que eran :-P
#1 Ya no eres el Professor que yo recordaba :-(
Que nadie se confunda. Una ISA de código abierto (como RISC-V) no soluciona por si solo Meltdown y Spectre. Lo que si es útil, es tener una microarquitectura pública (como si hace RISC-V con su proyecto de ejemplo rocket-chip: github.com/freechipsproject/rocket-chip) para que expertos puedan revisar el diseño en busca de fallos.
#3 esto es lo que venía a decir. Lo de la ISA de por sí no significa nada.
#6
La ISA por sí sola sí tiene significado. Existen instrucciones para forzar barreras de memoria de manera que las «loads» no adelanten nunca a «stores» o «branches». Si ese tipo de instrucciones están especificadas en la ISA ya tienes algo con lo que trabajar. Y más aún si se especifica en la ISA que en determinados casos no pueda haber ejecución especulativa.

cc #3.
#9 x86 ya tiene esa instrucción (www.felixcloutier.com/x86/MFENCE.html) y su mera existencia no va a arreglar este problema.

Podríamos hablar de instrucciones para activar o desactivar ciertas optimizaciones de la CPU en tiempo de arranque, pero no creo que sea necesario una ISA diferente para llevar eso a cabo.
#10
Respecto a la primera parte de tu comentario, eso es lo que he dicho en mi comentario.

Respecto a la segunda parte, no hace falta desactivar optimizaciones. Hay que modificar compiladores y bibliotecas para insertar las instrucciones donde toca.
#11 y yo lo que digo es que la ISA en sí no es el problema, sino cómo se implementa un procesador y lo deseable que sería poder desactivar ciertas funcionalidades.
#12
Ya he contestado a lo que dices. Compiladores y bibliotecas modificadas insertando instrucciones donde toca.

El compilador es quien tiene la información para insertar dichas instrucciones.
Lo de desactivar optimizaciones en tiempo de arranque no tiene sentido.
#13

No es tan simple.

Primero habría que recompilar y hablamos de muchos millones de líneas y aun así sigues siendo vulnerable a los accesos en ensamblador.
#40
Cuñao seal of approval.
#42
Con un binario implementando las protecciones necesarias y el núcleo del sistema operativo con lo mismo.
Puro estilo retpoline.
#43

Vale, que no tienes ni idea.

Queda claro.
#47
Queda claro que no la tienes tu.
#11 " Hay que modificar compiladores y bibliotecas para insertar las instrucciones donde toca."

xD xD xD

Gracias, señor experto en seguridad.
#23
Más experto que tu si debo de serlo, o bien se me ha muerto el canario.
#23 aja y a parte de una chorrada irónica.. Explicarme que yo no se nada... Como se corrige este tipo de cosas?
#26 En #35 he puesto un par de enlaces. Por lo que leí, uno de los problemas estaba en la ejecución especulativa de saltos indirectos, así que lo que se ha hecho es parchear los compiladores para que, en esos casos, emitan una secuencia de instrucciones que "desactive" la ejecución especulativa.
#23 Mira, parches para GCC y LLVM para mitigar Spectre:

reviews.llvm.org/D41723
lkml.org/lkml/2018/1/3/871
#9 En general todas las ISAs (que no sean de juguete) implementan memory barriers. Ya sea x86, ARM o RISC-V.

Yo me refiero a que RISC-V lo que aporta es libertad de diseñar y/o fabricar y/o vender tu CPU sin que un ejército de abogados te persiga. Y aquí mi comentario en #3. Este hecho por si sólo no soluciona el problema.
#14
La ISA determina cuándo se puede y cuándo no realizar lecturas y escrituras a memoria.
Los compiladores son los que utilizan la ISA. Son los encargados de generar los binarios que la respetan. Y los procesadores se ven delimitados por las decisiones de especificación de la ISA.
#14 La libertad es nula lo único que te permite usarlo en fgas no es que cualquiera pueda fabricar un chip y sus chipsets en un nodo de digamos 28nm sin palmar una burrada de pasta sin garantizarte un retorno.
Los fgas baratos están apunto de explotar así que RISC-V es inversión muy buena ya se están mirando en ociloscopios la bajada de precio de ellos 4 canales 100mhz por 400€ impensable hace 5 años.
#3 para que expertos puedan revisar el diseño en busca de fallos.

Lo mismo dicen del software libre y los problemas nos los hemos comido con patatas (¿openssl?)

Eso de hacer las cosas públicas para que las revisen otros no ha funcionado nunca.
#17 Lo que seguro que no funciona es lo que tenemos actualmente, donde una empresa saca una cpu en 1995 con un bug y nadie lo descubre hasta 2017.
#17 O sea, que como uno o dos problemas no pudieron hallarse -en gran medida por falta de medios materiales- todos los innumerables problemas que sí se han corregido y se corrigen gracias a la revisión del código abierto no cuentan.

A ver si nos enteramos ya de que no se pueden comparar características entre la revisión de código abierto sin medios y sin un duro, contando sólo con la ayuda desinteresada de la comunidad a la misma revisión de código abierto hecha de forma planificada con…   » ver todo el comentario
#20 pero es que es aun mas divertido y preguntarle al nuevo responsable de microsoft, la agilidad de la comunidad no la da nunca el sistema de un equipo privado, por motivos tan obvios que microsoft creo el programa insider.
#28 "agilidad". No me hagas reír, la revisión de código y contribución en proyectos de software libre es directamente proporcional al interés o hype que despierta su desarrollo, además de la pasta que metan empresas concretas.

Si te vas a librerías y proyectos pequeños, vas a ver cómo hay bugs que llevan meses o incluso años parados, porque a nadie le apetece ponerse a ello, no tienen tiempo, conocimientos, o interés suficiente. Esto es porque se trata de revisión y desarrollo por parte de voluntarios, no hay nadie que tenga por obligación mantenerlo y avanzarlo a buen ritmo.
#29 Exacto, así que deja de asumir que el hecho de que un código sea abierto significa que no puede tener capital detrás ni puede ser auditado usando resursos y medios que aseguren una continuidad y calidad adecuadas en el proceso. Y no, ser código abierto no significa per sé que dependa de voluntarios. De hecho es lo que pasó con OpenSSL, cuando todas esas empresas que se estaban beneficiando de ese código vieron que no había dinero ni medios para poder asegurar revisiones de calidad lo pusieron porque sabían lo mucho que dependían de él y pusieron recursos y personal a colaborar con el proyecto.
#17 ajá, así que la detección y corrección de errores lleva el mismo ritmo en el soft privado que en el libre.... Cuentame mas.
#37 :tinfoil: se te va la cabeza xD

By the way, el nombre SORS viene de Severo Ochoa Research Seminar...
Los estándares abiertos favorecen la competencia, la seguridad, la diversidad y el conocimiento.
#33 El hardware está hecho por humanos con lo que también puede ser parte del problema.

menéame