Ingeniero húngaro encuentra misteriosas instrucciones en microprocesadores Intel[ENG]

Un ingeniero húngaro emprendedor, Can Bölük en Verilave, ha hecho algo similar, sondeando el oscuro sistema nervioso de los fabulosamente complejos microprocesadores x86 de Intel. Lo investigan en busca de códigos de operación no utilizados e indocumentados en los conjuntos de instrucciones de los chips. Y está bastante descubierto. Su código está disponible en Github. Si alguna vez ha programado un chip x86 en lenguaje ensamblador, su primer pensamiento podría ser: "No sabía que había códigos de operación sin usar".

[#6 woody_alien]

Como noticia lo encuentro pelín tonta. Desde el 8088 existen "códigos misteriosos"en los Intel. Precisamente se usaban esas instrucciones no documentadas para distinguir entre el 8088,86,286 y si era Intel,Cyrix,AMD, IBM pues cada modelo y marca llevaba alguna instrucción única, Peter Norton ya publicaba una rutina de detección de CPU y velocidad en base a opcodes ocultos en el Libro del Sr. Rosa. Como el x86 define un vector de interrupción para Bad Opcode (instucción incorrecta) puedes hacer una rutinilla que vaya probando instrucciones y ver si "saltan" o "hacen algo" de manera contolada.

[#18 Tannhauser]

#6 ¿Libro del Sr. Rosa?

Por cierto, #5, #6, #11, los típicos comentarios que aportaban información en el menáeme de los inicios.
Al igual que Barrapunto, Menéame ya no es lo que era.

[#21 lp0onfire]

#18 Creo que se refiere a este.

[#22 Tannhauser]

#21 Sí, es muy probable.

[#51 woody_alien]

#18 Sep, libro del Sr. Rosa. Si no sabes de qué va es que eres "joven"

[#59 Tannhauser]

#51 No te creas, tuve el "Computer SpaceGames" (Daniel Isaaman y Jenny Tyler, 1982) y el "BASIC para niños".

[#67 meneandro]

#18 Tiene guasa que (dos de) los libros más emblemáticos en la informática sean el del dragón y el del hombre rosa...

[#31 noexisto]

#6 Yo, que no tengo npi, sí me ha descrito a modo introducirlo problemas que me han parecido Interesantísimas aunque sea a modo general
Tambien es un sub generalista
Para el que lo desconozca DDev (software)

[#46 teseo]

#6 ¿Estos códigos son o pueden llegar a ser malignos?

[#58 woody_alien]

#46 Los códigos no pueden ser "malignos" pues la CPU solo ejecuta cosas a muy bajo nivel y, si está procesando algo, no sabe si es una contraseña, un pedazo de JPG o un chiste de Forges.

Sin embargo una CPU sí puede ser "maligna". Como apuntaron ya hace unos años las "nuevas" CPUs son en realidad microordenadores encapsulados que simulan ser una CPU simple. Estas CPUs llevan otra CPU interna no documentada en absoluto, con su RAM, su ROM, su FLASH y su propio sistema operativo que solo conoce el fabicante. Por ejemplo una CPU de movil tipo ARM suele ofrecer, aparte de función CPU un chip gráfico, de red, radio (GSM, Blutú, etc). Todo en un solo chip. Por mucho que le pongas un Linux por encima y parezca un entorno controlado no hay manera de saber qué está haciendo la CPU por dentro y si está enviando tus datos bancarios a China mediante espacios no usados en los paquetes de datos.

[#60 teseo]

#58 muchas gracias por tu respuesta

[#72 apetor]

#58 Se refiere a instrucciones tipo backdoor, creo..

[#55 Kr0n0]

#6 Da gusto encontrar comentarios así. Gracias

[#63 navi2000]

#6 No es tan fácil. Tal y como se explica en el artículo (a nivel introductorio, claro), los x86 tienen una arquitectura externa CISC con opcodes de diferentes números de bytes y con diferentes posibles parámetros. Simplemente probar a saco en un bucle un opcode tras otro podría tomar una eternidad de tiempo y no dar resultado. En un RISC es más sencillo, pero los opcodes de tamaño variable pueden hacer explotar el número de combinaciones.

[#5 meneandro]

"Some instructions appear to be deeply buried maintenance functions while others look like Easter eggs, forgotten bugs, or partially implemented instructions that never quite saw the light of day. A few seem to provide remarkably godlike powers that appear to circumvent on-chip security or even to rewrite the chip’s internal microcode."

Probablemente se trate de, como dice el artículo, instrucciones que quedan ahí por compatibilidad hacia atrás (muchas, "deshabilitadas" antes de lanzar el procesador de turno por no ser funcionales o adecuadas) y luego instrucciones para el remapeo de las propias instrucciones y debugueo a ultrabajo nivel.

Recordemos que desde el pentium pro los procesadores x86 son RISC y las instrucciones son "configurables" (cada instrucción es un conjunto de microinstrucciones, que son las que realmente se ejecutan; como pueden haber bugs de distinto tipo, poder actualizar los microcódigos que conforman las instrucciones es una ventaja).

https://www.intel.com/content/www/us/en/support/articles/000029051/processors.html

Que no quiere decir que no haya instrucciones ocultas con fines maléficos (no voy a poner la mano en el fuego), pero si que casi siempre que salen cosas de estas en realidad son pajas mentales de la gente que malinterpreta cosas que tienen otras funciones pero que evidentemente no deberían ser públicas (si fuera fácil poner en modo debug un procesador o acceder a la ejecución de microinstrucciones individuales, la seguridad brillaría por su ausencia; que no soy fan de la seguridad por ofuscación, pero...)

[#48 thingoldedoriath]

#5 Recordemos que desde el pentium pro los procesadores x86 son RISC

Supongo que sí... aunque en unos cuantos lo más adecuado sería decir que son "RISC-like"... o que son una mezcla de RISC y CISC.

https://architecnologia.es/x86-risc-o-cisc

[#66 meneandro]

#48 No son mezcla de nada. A nivel de hard, lo que se ejecutan son microinstrucciones simples. Si nos ponemos tontos, el M1 de apple (y cualquier ARM moderno) también son RISC de aquella manera porque las instrucciones también se dividen en microinstrucciones (aunque sean de características más simples que las del x86), sólo Risc-V es un RISC 100% puro (el juego de instrucciones se mantiene simple y se ejecutan directamente; Risc-V en principio está pensado para que cualquier cosa que no sea el juego básico de instrucciones vaya en aceleradores especializados).

[#68 Parodper]

#66 ARM directamente es RISC, por cualquiera definición.
#5 Y x86 no es para nada un RISC, es un CISC por que solo acepta instrucciones CISC. Y lo de que internamente es RISC, un exingeniero de Intel difiere: https://www.quora.com/Why-are-RISC-processors-considered-faster-than-CISC-processors/answer/Bob-Colwell-1?ch=10&share=85b12e6e&srid=2Qns

[#71 apetor]

#68 Si, pero #66 tiene razon. Los procesadores modernos tienen un deco, y hay niveles de "RIS", un reduced instruction set puede ser reducido, pero se puede reducir mucho mas para ejecutarlo, sobre
todo si hay multiples unidades de ejecucion y si es una arquitectura Out Of Order Execution.

RiSC, hoy dia, mas que reducido, deberia entenderse como computacion con instrucciines de tamaño fijo + instrucciones con codificacion ortogonal/simetrica, sobre todo.

[#78 Parodper]

#77 «Si esas instrucciones desconocidas estuviesen contempladas en algún compilador ya no serían desconocidas, no?»
Eso supone que tienes acceso al compilador. Además de que el primer compilador de C tenía una puerta trasera, y aún con acceso al compilador la gente tardó en darse cuenta.

De acuerdo con lo del SO, hay varios proyectos que intentan conseguir compilar un sistema operativo partiendo de lo que puedas escribir a mano.

#75 «¿En qué se diferencia a nivel de ejecución de un x86 moderno [...] ¿porque tiene un conjunto de instrucciones complejas desde el punto de vista del programador»
Si. Si solo acepta CISC no importa como sea el interior, es un procesador CISC. Incluso si internamente use un RISC (aunque al exingeniero de Intel no le guste llamarlo así) el procesador es un conjunto de elementos: internamente también tiene ALU y no por eso es una calculadora.

#71 Leyendo un poco por ahí, concuerdo sobre ARM. Tienen bastantes más instrucciones de las que yo diría que necesita.

[#79 meneandro]

#78 "Si solo acepta CISC no importa como sea el interior, es un procesador CISC."

No, no sólo acepta CISC. Pero para bajar y programar al nivel de microinstrucciones tienes que estar mal de la cabeza por una serie de razones*, supone un nivel de complejidad inaceptable. Todo el hecho de que a nivel de instrucciones siguan siendo CISC y por debajo RISC es por una serie de razones, más allá de la compatibilidad hacia atrás (si sólo fuera eso, hacías un RISC puro y un "copro-compatibilidad" aparte y listos. No, las instrucciones CISC (desde el punto de vista del programador) tienen sus ventajas también, a nivel de compilador poder jugar con instrucciones que te solucionan asuntos complejos (o poder tener dos rutas, una optimizada para según qué cosas y otra para otras distintas) es una ventaja clara en reducción de número de instrucciones (tamaño de código) y por lo tanto facilita también la optimización de las cachés. También es un infierno para otras cosas (la alineación en las cachés, el cálculo de tiempos de ejecución para saber qué ruta de compilado es más conveniente, etc).

Por otro lado, a nivel de programador da un poco igual porque no vas a programar en ensamblador casi nunca. Y si lo haces, tener más instrucciones y más complejas te facilita la vida, no es precisamente un handicap, por eso tiende a usarse lenguajes de más alto nivel para casi todo lo que no sea programar sistemas.

*Las microops no son estándares como las instrucciones. Cada modelo, chip y procesador específicos de cada familia pueden tener sus propias microops, programar con microops es casi hacerlo para un único modelo específico porque no hay garantías de que puedan funcionarte en otro. Y olvídate de ejecutar microcódigo intel en un amd, por ejemplo. Que poderse se puede, ojo, pero sólo para tu ordenador y equivalentes y ya sólo eso restringe muchísimo la utilidad y conveniencia de hacerlo. Es como programar usando las APIs que te da el fabricante o tirar de las propias funciones internas... mañana te cambian las funciones internas y tu programa deja de funcionar o lo hace mal, mientras que usar las APIs te blinda contra esas cosas.

[#80 Parodper]

#79 La cosa es que no se puede programar con microinstrucciones. Lo único que encuentro es cargar microinstrucciones, que ocurre al arranque y actualiza la maquinaria interna del procesador; pero no ejecuta nada.

[#81 meneandro]

#80 Cuestión de buscar un poco:
https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf

"Our analysis focuses on the AMD K8/K10 microarchitecture since these CPUs do not use cryptographic signatures to verify the integrity and authenticity of microcode updates. Note that Intel started to cryptographically sign microcode updates in 1995 [15] and AMD started to de-ploy strong cryptographic protection in 2011 [15]. We assume that the underlying microcode update mechanism is similar, but cannot analyze the microcode updates since we cannot decrypt them.Contributions.In summary, our main contributions in this paper are as follows:•In-depth Analysis of Microcode.

We provide an in-depth overview of the opaque role of microcode in modern CPUs. In particular, we present the fundamental principles of microcode updates as deployed by vendors to patch CPU defects and errors.

•Novel RE Technique.
We introduce the first semi-automatic reverse engineering technique to disclose microcode encoding of general-purpose CPUs. Furthermore, we describe the design and implementation of our framework that allows us to perform this reverse engineering.

•Comprehensive Evaluation.
We demonstrate the efficacy of our technique on several Commercial Off-The-Shelf (COTS) AMD x86CPUarchitectures. We provide the microcode encoding format and report novel insights into AMD x86CPUinternals. Additionally, we present our hardware reverse engineering findings based on delayering actual CPUs.

•Proof-of-Concept Microprograms.
We are the first to present fully-fledged microprograms for x86CPUs. Our carefully chosen microprograms highlight benefits as well as severe consequences of unveiled microcode to real-world systems."

"7 Microprograms
In this section, we demonstrate the effectiveness of our re-verse engineering effort by presenting microprograms that successfully augment existing x86 instructions and add foreign logic. With this paper, we also publish microcode patches [42] that are compiled from scratch and run on unmodified AMD CPUs, namely K8 Sempron 3100+ andK10 Athlon II X2 260/280. We found that the microcode ROM content varies between different processors, but the macroinstruction entry points into the microcode ROM are constant. Thus we assume our microcode patches are compatible with a wider range of K8/K10-based CPUs. We discuss additional applications of microcode in Sec-tion 8"

El problema es que no están documentadas y la ingeniería inversa vale para un modelo o unos pocos, el esfuerzo puede tranquilamente no valer la pena salvo para conseguir conocimiento, aparte de otras trabas (parece que, según el documento, todos los procesadores más modernos encriptan para dificultar aún más la labor).

[#82 meneandro]

#81 Por otro lado, parece que lo que se puede es "reescribir" una instrucción con un microprograma nuevo y no crear instrucciones nuevas (los códigos de instrucción serán los que son, fijados de alguna manera en rom o vaya usted a saber). Igualmente, se pueden definir y ejecutar microprogramas de esta manera (no es lo mismo que prescindir de las instrucciones e ir a pelo con microinstrucciones, salvo que yo haya entendido mal, pero salvo que encuentren algún hack específico para hacerlo, es lo más cerca que se puede estar de eso).

[#73 apetor]

#68 ARM, de hecho, tiene su pequeño cancer legacy, no muy RISC, el Thumb mode...

[#75 meneandro]

#68 Te estoy diciendo que tienen instrucciones que se decodifican en microinstrucciones. Lo que se ejecutan son las microinstrucciones (si que hay muchas diferencias de ahí para arriba, entre cómo se despachan y tratan dichas microinstrucciones a partir de las instrucciones, empezando porque en los x86 las instrucciones tienen tamaños variables y eso complica las cosas). ¿En qué se diferencia a nivel de ejecución de un x86 moderno, cuando ambos ejecutan microinstrucciones? ¿porque tiene un conjunto de instrucciones complejas desde el punto de vista del programador, cuando bajo las tripas son iguales?

[#70 apetor]

#5 Hace meses que no lo toco pero tengo un "proyectillo" personal para hacer una especie de SoftICE ( los que conozcais esto si que soys viejunos y/o muy metidos en el tema x86 ), un depurador de systema para UEFI y NT... el caso es que cuando salieron los parches de windows para meltdown y spectre, que estaba con ello bastante metido, probando y depurando la entrada y salida de syscalls en el kernel de NT con el depurador, vi unos MSR ( Model Specific Registers ) que no me sonaban nada ( 0x00000DB2 y alguna otra, creo recordar... y, sinceramente, no es por ir de guay, es algo que me llamo la atencion y me hizo buscarlas ) y no encontre informacion sobre ellas. Creo, no estoy seguro, que estas MSRs o bien existian pa controlar cosas indocumentadas o bien se introdujeron mediante microcode updates.

Tambien vi cosas bastante raras en el codigo, como usar RSP ( el registro de puntero de pila ) como registro de proposito general ( !!! ) en un pequeño tramo del codigo. Intuyo por que hicieron esto pero no estoy seguro... podria ser mera optimizacion, pero seria un poco jarto... no se.

Pues bien, no es solo instrucciones, el binomio microsoftintel ( y supongo que AMD tambien, aunque en este caso AMD no fue tan vulnerable ) lleva tiempo haciendo cosas de estas.

Muestra de lo que hablo para los que sepan de arquitectura x86(-64):

Lo que digo de la dicotomia de direccionamiento ( CR3 ) entre kernel y usuario, es cosa aparte, esto es la solucion que se hizo para meltdown, que... en fin , pero bueno, cosas bastante esotericas se introdujeron en esos parches.

[#74 meneandro]

#70 Te confirmo que hubo muchas actualizaciones de microcódigos para intentar paliar las vulnerabilidades o al menos adaptar las instrucciones para poder controlar mejor las vulnerabilidades a través de software a más alto nivel.

También te confirmo que inicialmente las soluciones que se tomaron para evitar o paliar las vulnerabilidades provocaban un bajón de rendimiento más que notable, mientras que ahora entre unas cosas y otras el impacto es mucho menor (aunque siguen saliendo formas de aprovechar las vulnerabilidades y se sigue trabajando en formas de evitar el impacto que introducen)

[#76 apetor]

#74 Si, ya vi benchmarks y demas

[#2 pkreuzt]

Hombre, eso de "sin usar" habría que analizarlo con cuidado. A lo mejor están ahí para que las use cierta gente en exclusiva. Alguna poderosa agencia de inteligencia, por ejemplo.

[#11 Desactivado]

#2 No tiene por qué, como dicen ahí en #8 existen instrucciones para el z80 que no estaban documentadas y se usaban para algunos juegos (realmente eran opcodes sin tener NPI a lo que afectaban desde los propios ensambladores de máquinas, pero estaban ahí).

La gente de los emuladores sabe un rato largo de esto.

Puedes emular un Z80 con una facilidad pasmosa con simplemente los datashets y un triste switch/case en C o cualquier lenguaje de forma similar (literal lo digo), pero luego aunque lo hagas a la perfección muchos juegos pasan de la preicisión como de la mierda y no tiras.

Ejemplo con el primo hermano del Z80 en la Game Boy: Iridium D y un juego de pinball con graficazos ambos y que se dibujaban fatal en cualquier emulador hasta hace dos días.

[#14 gonas]

#2 Analizando los ejecutables, se puede saber fácilmente si se usan o no.

[#20 avalancha971]

#2 A mi lo que me sorprendería es que no existiesen dichas instrucciones.

[#23 int21h]

#2 Para que alguien use esas instrucciones tendría que introducir un programa que las contuviese, y eso implicaría tener acceso a la máquina. Y una vez se tiene acceso a la máquina, lo de menos es las instrucciones que usen...

[#25 pkreuzt]

#23 No se donde has estado metido estos últimos años, pero la cosa esta no sería muy diferente de atacar una máquina vía Meltdown o Spectre. Hay PoC de exploits para esas vulnerabilidades en Javascript, lo que significa que sería suficiente con visitar una web trampa.

[#37 int21h]

#25 Mis conocimientos no son profundos pero para que fuese como tú dices, y siendo el Javascript un lenguaje interpretado, sería el motor de ejecución (instalado en tu máquina) el que tendría que contener esas instrucciones especiales, ¿no?

Hasta donde yo sé, en un JavaScript no hay código máquina.

Pero insisto en lo limitado de mis conocimientos.

[#44 pkreuzt]

#37 El motor de ejecución en ese caso era el navegador. Hasta el punto de que mientras se esperaba un firmware nuevo que solventara los problemas del hardware, hubo que parchear varios navegadores. Pero el caso es que si existe esa ruta en el hardware, solo necesitas un software específico que la utilice. La parte dificil es que esas cosas no están documentadas (salvo, probablemente, para los que las pusieron ahí en primer lugar) y por tanto hay que experimentar un poco.

[#53 int21h]

#44 Entonces me estás dando la razón. El programa que contenga esas instrucciones no documentadas tiene que estar instalado en la máquina.

[#54 pkreuzt]

#53 No necesariamente. Tiene que ejecutarse en la máquina, pero como el caso del javascript no tiene que estar "instalado". De hecho lo que hicieron en los navegadores para parchearlo fué limitar la ejecución de ciertas cosas que antes si se permitían y que sin ese problema de hardware tampoco hubieran sido peligrosas.

[#65 int21h]

#54 A ver pero Spectre o Meltdown no usan instrucciones del micro "nuevas" u "ocultas". Simplemente aprovechan fallos de diseño para que, ejecutando ciertas acciones de un modo concreto, se consiga acceso a zonas de memoria que no deberían estar accesibles.

Sin embargo, en el caso de estas instrucciones no documentadas, para que se pudiesen usar tendrían que estar en el ejecutable que tengas corriendo en tu máquina, y ese ejecutable tendría que estar hecho con un compilador que tuviese constancia de la existencia de dichas instrucciones.

Por lo tanto, es imposible que un JavaScript, que no deja de ser algo interpretado en tiempo de ejecución y no de compilación, use esas instrucciones desconocidas si el motor de ejecución (sea el navegador, sea el motor de java, o lo que sea) no fue compilado para utilizarlas.

[#69 Parodper]

#65 ¿Y como sabes que el compilador usado no incluye esas instrucciones? Un ejecutable, que crees seguro por el sistema operativo, puede estarlo evitando completamente por alguna instrucción desconocida.

[#77 int21h]

#69 Si esas instrucciones desconocidas estuviesen contempladas en algún compilador ya no serían desconocidas, no?

Además, si alguien tiene los medios para colar sw en medio de un ejecutable del SO, ¿para qué iba a necesitar instrucciones especiales? Ya tiene la forma de colarse en tu máquina simplemente por el hecho de que confías en el suministrador del SO. No necesita instrucciones no documentadas para hacer lo que quiera.

[#1 futsuu]

Notícia de interés para quién haya programado en assembler. El resto de mortales no sabrán qué significa. Cada vez quedamos menos.

[#3 box3d]

#1
LD HL, $i_feel_you_bro
CALL print
RET

[#4 Desactivado]

#3 ¿Ensamblador del Z80?

[#7 futsuu]

#4 Me sabía ese manual de memoria. Por algún sitio lo tendré todavía.
https://www.zilog.com/docs/z80/um0080.pdf

[#9 Desactivado]

#7 #8 es que hacía tanto que no veía un código así... ese doble registro HL... qué viejo soy.

[#15 eqas]

#7 ¿por qué pide ese enlace que me identifique con certificado digital?

[#28 vitichenko]

#15 para nada, siguiente siguiente ok ok palante siguiente activar notificaciones y listo, que para eso somos informáticos

[#32 eqas]

#28 lo preguntaba en serio. La web de zilog.com me pide que me autentifique con certificado digiatl, tanto en Chrome como en Firefox. No es algo normal.

[#38 itomailg_ito]

#32 Pues a mi no me ha pedido nada

[#45 Itrio]

#38 Sí lo pide, pero supongo que sólo lo notas si tienes algún certificado instalado en el navegador, que te salta la ventana para que 'elijas' el certificado.

[#56 eqas]

#45 o si no lo tiene para que te pida permiso cada vez que "algo" quiera usar el certificado.

[#42 Desactivado]

#32 eso es por tu color de piel.

[#47 vitichenko]

#32 si, a mí también me lo pidió, le di a denegar y me bajo el PDF .. tampoco lo entiendo mucho y no sé si quiero entenderlo

[#8 Desactivado]

#4 El Z80 también tenía instrucciones indocumentadas, pero ya se sabía hace mucho tiempo

[#10 Desactivado]

#3 #8 El de la GB también al ser primo hermano. Y el 6502.

[#41 box3d]

#4 #10
Z80, sí.
Premio para el meneante

[#19 bargusi]

#4 recuerdo haber programado el Z80 con un teclado hexadecimal. Tenía que mirar la instrucción en assembler y traducirla con una tabla donde venía en hexadecimal y en binario.

[#27 Desactivado]

#19 eso mismo hice yo hace... muchos años. Aunque no sé qué quieres decir con un teclado hexadecimal; yo sólo tenía un Amstrad.

[#33 bargusi]

#27 No era con un microordenador. Era una placa de desarrollo parecida a la de la foto

[#49 Pitufo]

#33 La denominación del bicho creo que era entrenador. Malditos indexados indirectos e indirectos indexados.

LDAA 07

[#52 bargusi]

#49 Sí. Escribías las instrucciones codificadas en hexadecimal, que salían por el display según las tecleabas, pero sólo aparecía lo último que escribías. Depurar era un infierno, pero molaba.

[#12 mcfgdbbn3]

#1: Tampoco hace falta saber programar en ensamblador, con saber en qué consiste un poco es suficiente.

[#16 Kasterot]

#1 lo aprobé de chiripa, como se me atragantó esa asignatura,.
Aprobar y olvidar en el mismo acto fue

[#61 futsuu]

#16 Es ya un arte arcano, pero solamente porque nadie quiere meterse ahí. En ciertas aplicaciones tiene mucha utilidad. Solo con assembler puedes utilizar "de verdad" la increible velocidad de un procesador.

También es cierto que te puedes acercar mucho con compiladores optimizantes. El de Ada tiene mucha fama en eso.

[#26 nomasderroches]

#1 gracias por tu comentario de auto bombo sin aportar mucho.

Para el que esté interesado en instrucciones no documentadas x86, recomiendo este video

[#34 ccguy]

#1 Yo me conformo con que no la hayan tumbado por irrelevante. Al menos han respetado lo que es una noticia de interés.

No sé, si yo veo una noticia "descubierto un nuevo órgano sin usar en una rana" no lo considero irrelevante aunque no tenga ni puta idea de ranas.

[#39 Desactivado]

#1 sólo lo toqué en la universidad pero me gustó bastante, aunque no lo he vuelto a tocar.

[#24 Javi-_Nux]

Todavia tengo pesadillas programando las torres de hanoi en ensamblador sin poder usar nop

[#17 Kirchhoff]

Lo que más me gusta de meneame es co.o llegan a portadas siempre noticias para el pueblo en general...

[#29 Lord_Lurker]

Mis cojones 100001

[#43 safeman]

#29 O Carallo 00011101, que decimos en Galicia.

[#13 Desactivado]

Millenials descubren las instrucciones indocumentadas

[#35 KimDeal]

#13 hombre, pues los milenials documentan menos que las anteriores generaciones de programadores.

[#36 AubreyDG]

El texto resumen traducido es tan apasionante que me leería la novela.

[#30 Indepe]

Habra que ver , que parte de la reprogramacion del microcodigo sirve de puerta trasera a sus amos....

[#40 RazorCrest]

Un amigo , húngaro para más señas, me dijo que nunca me fiara de un húngaro.

[#50 Manuel.G]

¿Algún alma caritativa me lo explica en castellano?

editado:

Entiéndase por castellano "lenguaje para alguien que no tiene pajolera idea de informática", no como la lengua romance que hablamos en esta página.

[#62 VRSquid]

#50 Intel les da a los programadores un manual con todas las ordenes, con su codigo numerico, que se le pueden dar al procesador.

Lo que el ingeniero quiere saber es si existen ordenes que Intel no ha puesto en el manual pero existen dentro del procesador así que va a probar todos los códigos numericos uno tras otro y comprobar el resultado automaticamente con un programa. Esto tiene el problema de evitar que se cuelgue por usar codigos al tun tun y saber si un codigo ha hecho algo.

Para que no se cuelgue se aprovecha que los procesadores ejecutan partes del programa por adelantado como borrador y si el programa llega a esa parte se marca como definitivo para ahorrar tiempo. Si el programa se desvia por otro lado se descarta el borrador. Ojo que aunque el borrador se descarte y se resetea el estado del procesador a como si nunca se hubiesen ejecutado, las instrucciones en realidad si pasaron por el procesador. Lo que hace es apañarselas para que las partes con los codigos de prueba siempre esten en borradores que se descartan.

Para saber si el codigo ha hecho algo se aprovecha que desde hace 20 años los codigos de orden no se ejecutan directamente. Dentro del chip no hay un i7, i5 o lo que sea. Lo que hay un emulador y un procesador parecido a los de movil pero mucho mas potente. Cada codigo que le llega al chip pasa por la capa de emulacion para traducirlo a algo que entienda ese procesador de movil interno. Gracias a que descubrio una forma de leer el numero de pasos que ha dado ese procesador interno al recibir un codigo puede adivinar con bastante precision si un codigo hace algo o no.

TL;DR Los procesadores funcionan con codigos numericos para cada tipo de comando a ejecutar. Los fabricantes dan una lista oficial de comandos. El ingeniero por curiosidad prueba con todos los numeros de forma muy ingeniosa para ver que pasa con cada uno automaticamente.

[#64 goldiloc11]

#50 Si alguien ve que meto la gamba decidlo pero aqui va mi intento de explicartelo. Los procesadores o CPUs tiene dentro una serie de instrucciones que llamamos de "bajo nivel" que son las que se gestionan multiples cosas como privilegios de los programas, recursos, como hablar con las otras partes del ordenador, etc.

El articulo se basa en que muchas de esas funciones no estan documentadas oficialmente o si le preguntas a Intel/AMD/ARM/Via te diran que "no existen". Como algunos ya han mencionado, no es una gran novedad, pero el hecho de que esten ahi hace que desconfies de lo que tu CPU esta haciendo. Como ejemplo, un par de casos: El modo Dios, que permite ejecutar cualquier cosa saltandote todas las medidas de seguridad de la CPU o los procesadores secundarios que permiten cambiar el microcodigo (otro conjunto de instrucciones) de forma transparente sin que nadie se entere. Y me voy a guardar el sombrerito de aluminio para otro dia

[#57 Desactivado]

Posiblemente sufra un desafortunado accidente.