WireGuard, una VPN rápida, moderna y (esperemos) segura

Desde su presentación hace unas semanas atrás le estoy siguiendo el hilo a la nueva implementación de túnel VPN denominada WireGuard que, básicamente, y copypasteando el marketing de su sitio web,

WireGuard es una VPN extremadamente sencilla, aunque rápida y moderna que utiliza técnicas de criptografía avanzadas. Apunta a ser más rápida, más simple, más reducida y más útil que IPSec, evitando a la vez los dolores de cabeza [de su implementación]. Además, busca ser considerablemente más performante que OpenVPN…

Los puntos fuertes de este software son:

  • Sencillez y facilidad de uso: Busca ser tan fácil de configurar y desplegar como SSH. Una conexión VPN requiere el intercambio de claves públicas sencillas -tal como el intercambio de claves SSH- y todo lo demás se maneja en forma transparente por el software.
  • Criptográficamente robusto: Utiliza criptografía moderna: Noise protocol framework y los algoritmos Curve25519, ChaCha20, Poly1305 (estos últimos de la mente de D. J. Bernstein), BLAKE2, SipHash24, HKDF, con decisiones conservadoras y razonables, y ha sido revisado por criptógrafos [aunque no sabemos quienes].
  • Mínima superficie de ataque: Fue diseñado teniendo en mente la sencillez y la facilidad de implementación, siendo implementable fácilmente con pocas líneas de código, y fácilmente auditable por vulnerabilidades de seguridad.
  • De alto rendimiento: Utiliza instrucciones criptográficas disponibles en los procesadores modernos y está implementado en el propio núcleo de Linux, con lo que permite armar una red segura manteniendo altas tasas de transferencia. Puede ser usado tanto en smartphones como en routers de backbone.
  • Bien definido y estudiado: WireGuard es el resultado de un extenso proceso académico detallado y extenso, cuyo resultado es un documento de investigación técnica que define claramente el protocolo y las consideraciones que se tomaron en cuenta en cada decisión.

Más allá de la propaganda del sitio web, además de su pequeño tamaño (en líneas de código) y de estar implementado sobre UDP, lo más relevante de esta implementación es que corre enteramente en el kernel, evitando los cambios de contexto de las implementaciones tradicionales de VPN. WireGuard parece haber sido desarrollado inicialmente por una sola persona: Jason A. Donenfeld, y está licenciado como GPLv2. A él agradecemos, entonces, haberse tomado este tremendo trabajo.

Al dia de hoy es posible probarlo en Debian gracias al trabajo de Daniel Kahn Gillmor (dkg), quien se encargó de empaquetarlo muy responsablemente.

En principio se requiere un kernel Linux igual o mayor a 4.1, pero eso se consigue fácilmente desde backports:

echo "deb http://httpredir.debian.org/debian/ jessie-backports main" \
    > /etc/apt/sources.list.d/jessie-backports.list
apt update
apt -t jessie-backports install linux-image-amd64 linux-headers-amd64

Luego de reiniciar con el kernel nuevo, descargar e instalar los paquetes wireguard-dkms y wireguard-tools desde el repositorio experimental. Esto instalará el código fuente del módulo y la aplicación de configuración. La infraestructura de compilación dkms se encarga de compilar el código a un módulo usable.

echo "deb http://httpredir.debian.org/debian/ experimental main" \
    > /etc/apt/sources.list.d/experimental.list
apt update
apt install dkms
apt -t experimental install wireguard-dkms wireguard-tools

En caso de no disponer de una instalación de Debian a mano, hay otras opciones, como también está el último recurso de compilarlo a la vieja usanza.

Finalmente, una vez que está todo listo,

Quick Start Walkthrough

Para todo lo demás, los remito a la documentación en línea, y al paper que detalla el protocolo.

Vale decir que esto aún está en los principios de su desarrollo. No hay una versión estable y su implementación real aún no ha tenido análisis relevantes desde la comunidad de seguridad en redes, pero vale decir que suena prometedor. Desde luego, si están interesados en participar/desarrollarlo/probarlo/documentarlo, el grupo acepta nueva gente.

Actualización 08/02/2017: Jason ha publicado en el sitio web los videos y slides de sus últimas presentaciones, de las cuales recomiendo particularmente la de FOSDEM 2017: Next Generation Secure Kernel Network Tunnel como visión rápida del proyecto y actualización del estado del mismo.

Analizando logs en 5 minutos con ELK

A partir de una idea de Santiago, y tomando como base algunos componentes que los muchachos de MercadoLibre utilizan para su infraestructura de gestión de logs, se me ocurrió hacer una prueba de concepto de a lo que es posible arribar rápidamente utilizando la tríada ElasticSearch + Logstash + Kibana, más conocida com ELK.

Para dar una mínima introducción, diremos que ElasticSearch es un motor de búsqueda RESTful basado en el archiconocido Lucene, Logstash es una especie de concentrador/manipulador/estandarizador de logs provenientes de múltiples fuentes, y Kibana es un visualizador de eventos que corre enteramente en el navegador. Los tres son componentes que pueden utilizarse en forma separada, pero en conjunto aplican precisamente esto de que el todo es más que la suma de las partes. De hecho yo había estado viendo Logstash aparte para una charla sobre logging que diera algunos años atrás, cuando aún era un proyecto incipiente, y ahora me encuentro con que es un proyecto ampliamente utilizado en un montón de lados.

Pero hoy no quiero detenerme demasiado en la teoría; la idea de este post es analizar registros yendo de 0 a 100 en 5 minutos (o lo que tarde en bajar cada aplicación) y para ello nada mejor que arrancar ahora. Así que…

Analizando logs en 5 minutos con ELK

Prerrequisitos

Como prerequisito es necesario el motor de ejecución java 1.6 o 1.7. En distribuciones basadas en debian alcanza con instalar openjdk-6-jre u openjdk-7-jre. O eso creo, a lo mejor es necesario el jdk también; prueben por las dudas. El resto de los pasos se pueden hacer sin necesidad de ser root, como usuario común.

Paso 0. Ubicarnos en un directorio limpio

mkdir elk
cd elk

Paso 1. Obtener logstash

wget -c https://download.elasticsearch.org/logstash/logstash/logstash-1.4.2.tar.gz
tar zxf logstash-1.4.2.tar.gz

Paso 2. Obtener elasticsearch

wget -c https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.1.1.tar.gz
tar zxf elasticsearch-1.1.1.tar.gz

Paso 3. Obtener un log de apache

… de algún lado. Si tienen un apache a mano, cópiense el archivo al directorio actual y dénle permisos de lectura para su usuario

cp /var/log/apache2/access.log access.log
chmod go+r access.log

O si no tienen ninguno a mano, acá les dejo uno que es un fragmento del log de este mismo sitio. Ustedes pueden hacer lo que les plazca con él, total este es un blog personal. Si quieren optar por otra alternativa, google hacking es su amigo y yo no se los recomendé.

wget -c http://maurom.com/files/access.elk.log -O access.log

Paso 4. Iniciar elasticsearch

echo Iniciando Elasticsearch. Aguarde 15s ...
elasticsearch-1.1.1/bin/elasticsearch &
sleep 15

Paso 5. Crear un archivo de configuración para parsear logs de apache

Para ello, creen un archivo de texto llamado logstash-apache.conf en el directorio actual y copien y peguen el siguiente bloque. Luego editen la ruta al archivo de logs, indicándola en forma absoluta, y configuren el tipo de entradas de log y el lenguaje de los meses según corresponda (sino tira unos errores horribles).

input {
  file {
    # apuntar a donde haga falta, con ruta absoluta!
    path => "/home/usuario/elk/access.log"
    # desde donde leer el log ("end" para tomar datos en vivo)
    start_position => beginning
  }
}
filter {
  if [path] =~ "access" {
    mutate { replace => { "type" => "apache_access" } }
    grok {
      # depende del formato de archivo
      match => { "message" => "%{COMBINEDAPACHELOG}" }
      # match => { "message" => "%{COMMONAPACHELOG}" }
    }
    kv {
      # con esto parsea incluso querystrings
      source => "request"
      target => "params"
      field_split => "?&"
    }
  }
  date {
    match => [ "timestamp" , "dd/MMM/yyyy:HH:mm:ss Z" ]
    # si los meses estan en ingles, u otro lenguaje en tal caso
    locale => "en"
  }
}
output {
  elasticsearch { host => localhost }
  # salida estandar coloreada, util para debug
  #stdout { codec => rubydebug }
}

Todo este archivo tiene su lógica según la documentación de logstash.

Paso 6. Iniciar logstash+kibana con la configuracion dada

echo Iniciando Logstash. Aguarde 15s ...
logstash-1.4.2/bin/logstash -f logstash-apache.conf -- web &
sleep 15

Paso 7. Levantar un navegador web

xdg-open "http://localhost:9292/index.html#/dashboard/file/logstash.json"

Paso 8. Jueguen con los filtros, los gráficos y deléitense con la visualización.

Fíjense de qué epoca son las entradas del log, pues puede que tengan que modificar algunas cosas para que Kibana les encuentre los eventos para esas fechas. Por ejemplo, el log de apache que les pasé solo tiene entradas para el mes de julio de 2014, así que seleccionen ese rango en el filtro de fechas de Kibana.

Acá les dejo algunas capturas de lo que pueden llegar a hacer, que si bien no son de análisis de apache, dan una idea de las posibilidades:

Paso 9. Terminar la tarea

Para cerrar los procesos, matelos sanamente con kill PID a cada proceso java asociado.

Ah, y una mención antes de terminar: cada vez que logstash procesa un archivo, anota hasta donde leyó para no volver a cargar la información, por lo que si están jugando con la configuración van a tener que borrar unos archivos .sincedb_algo que genera en el directorio $HOME del usuario para que vuelva a recorrer el mismo log.

Por último, en este caso estamos parseando son entradas de accesos a un sitio web, pero el combo ELK puede procesar casi cualquier tipo de flujo de eventos, y si bien java mucho no me atrae, todo este paquete vale la pena; piensen cuanto habrían tardado en programar ustedes una interfaz tan flexible y completa…

Como sé que ustedes son tan haraganes como yo, acá tienen todo en un solo script que lo hace de una.

Si se quedaron manija, acá van algunas demos y algo de documentación:

Eso es todo por hoy. Feliz análisis y Felices fiestas!

Indistinguible de la magia

En 1981, una IBM PC XT no podía reproducir video en una tasa de cuadros que fuera satisfactoria para el ser humano.

Hoy, en el mismo equipamiento:

Todo gracias a la curiosidad del genial scener Jim Leonard (trixter), que redacta en su blog la complejidad de lograr tal hazaña en su demo 8088 Domination. Mierda, se me caen las lágrimas.

Vía OSNews

gzip y poesía

Cómo gunzip decodificaría una versión comprimida de “El cuervo” de Poe. Cada secuencia de caracteres entre llaves es una referencia a una secuencia previa del texto. Créditos a Julia Evans!

Un vistazo a código de la demoscene ’93

Desde mis primeros años cerca de las computadoras siempre me fascinaron las demos.

No, no me refiero a las versiones recortadas de programas o juegos que se dan con fines comerciales, nada de eso. En nuestro contexto también se denominan demos a ciertas presentaciones multimedia creadas por programadores y artistas como una forma de arte alternativo y como muestra de sus capacidades.

Cualquiera que vea una demo en funcionamiento podría confundirla simplemente con un videoclip medio bizarro que se reproduce en la PC. A simple vista parecería ser sólo eso. Sin embargo, el archivo que almacena ese “video”, por así decirlo, suele pesar apenas 64 kilobytes, o incluso menos, 4 kilobytes; y una de las características que más asombran es precisamente esa: ¿cómo logran “almacenar” este tipo de animaciones en un archivo tan pequeño?

El truco, en realidad, radica en que el video en sí (y la música, normalmente) no está contenido en el archivo binario, sino que el binario es un archivo que al ejecutarse genera completamente la animación, como una especie de “mueble autoensamblable”.

Además de este detalle, los programadores de demos buscan aprovechar al máximo las características del hardware para el cual están trabajando, logrando animaciones que en muchos casos son impensables de ver en esos limitados equipos.

Buena parte de estas demos son creadas por grupos multidisciplinarios denominados demogroups, cuyos miembros son muy buscados por los departamentos de recursos humanos de la industria de videojuegos, sea como programadores, artistas gráficos o músicos, e incluso figuran entre los participantes de la reconocida conferencia académica de gráficos por computadora SIGGRAPH.

El coder aancsiid resume en pocos párrafos “Qué es una demo”, y los artículos Demo (Computer_programming) y Demoscene en Wikipedia son buenos puntos de partida para acercarse a la historia y las particularidades de las demos, pero lo que no pueden dejar de conocer son los clásicos sitios Pouet.net y Scene.org, dedicados exclusivamente a las obras de esta subcultura.

De las que me han dejado con la mente en blanco recuerdo a heaven seven de exceed, fr-041:debris de farbrausch,  elevated de rgba&tbc, chaos theory de conspiracy/cns, y las mas nuevas como agenda de fairlight, spin de asd.

Para que se den una idea, el ejecutable de heaven seven pesa 64 kilobytes, y logra todo esto …

con sólo 64 kilobytes !!!debris pesa 177 kilobytes, y la demo elevated pesa 4 kilobytes… Piensen que al día de hoy el código HTML de una página web pesa en promedio unos 52 kb, y una fotografía digital pesa por lo menos 3.000 kb. Esta gente logra toda una experiencia multimedia en apenas una fracción de eso… Pero no se queden con lo que les digo: si tienen una máquina a mano, bájense los binarios y ejecútenlos, para ver la realidad.

Cyberhades tiene también una buena lista de posts dedicados al tema, y precisamente es por ellos que me entero de que el grupo Future Crew ha dejado disponible el código fuente de la demo “Second Reality” con motivo del 20 aniversario de su creación.

Y aquí repito: el CÓDIGO FUENTE DE LA DEMO. Piensen que, dadas las exepcionales secuencias gráficas que los demogroups eran capaces de generar en aquella época, los hacks que éstos utilizaban para lograrlas eran secretos muy bien protegidos que muchas veces definían los primeros puestos en las competencias internacionales (demoparties). Por ello, poder acceder al código completo de una, ver su estructura interna y descifrar su funcionamiento es un regalo que hay que agradecer.

Además de felicitar a Future Crew por su amplia trayectoria, merece mis respetos Fabien Sanglard al acercarnos esta maravilla a los mortales mediante un ilustrado análisis de los fuentes de Second Reality que, por caso, contienen código en Assembler, C y Pascal. Recordemos que Sanglard nos viene deleitando ya con la aproximación al código fuente detrás de Prince of Persia, Doom y Quake.

Me encantaría seguir charlando de demos, pero mejor que eso es sentarse a ver algunas por demoscene.tv, capped.tv, o mejor, ejecutándolas en vivo en la PC.

Software privativo: por qué es malo y por qué lo odio tanto

Ya hemos hablado aquí de mis sentimientos hacia el software cerrado, y particularmente de aquellos sentimientos que nos genera una empresa bien conocida. Normalmente cuando alguien me pregunta el porqué de la elección de tal sistema operativo para uso diario, uno suele traer a la memoria un montón de ventajas técnicas, seguramente sesgadas, y olvida los motivos por los cuales “hizo la conversión”. Hablando francamente, a muchos de los que venimos del lado oscuro, de algún momento a otro el bocho nos hizo un clic, después de haber renegado tanto con ello.

El tiempo me ha enseñado que evitar este tipo de software reduce en gran medida el estrés, algo más que beneficioso para la salud, pero sin embargo cada tanto caigo, o me cae, algún amigo con un problemilla en su máquina, y como todos sabemos eso es el dulce que nos mueve a los informáticos de corazón.

Esta vez la paciente fue una portátil con un Windows 7, un equipo razonable, un sistema operativo cuidado, con antivirus al día, pocas aplicaciones, ninguna de ellas trucha, uso esporádico, actualizado a la fecha. Bueno, casi hasta la fecha, porque precisamente las “Actualizaciones de Windows” se negaban a funcionar. ¿El error? Este:

En un castellano impecable: “Windows Update no puede buscar actualizaciones porque el servicio no se está ejecutando. Puede que tenga que reiniciar el equipo.”

Hasta ahora, solo un inconveniente menor. Vale decir que no había motivos para semejante advertencia: la semana anterior el sistema operativo se actualizó correctamente, el equipo andaba sin inconvenientes, no se instaló nada en el medio, se apagó correctamente, el chequeo con antivirus actualizado no encontró ninguna amenaza, y hoy muestra este mensaje. Lo que se dice, un error sacado de la galera.

Bueno, al menos nos da una punta por donde comenzar a investigar. Según el error, el servicio de Windows Update se encuentra detenido. ¡Elemental! Vamos al gestor de servicios y vemos que, efectivamente, el servicio Windows Update se encuentra…

Iniciado? Pero cómo, no era que…

Bueno, seguramente ha sido todo un malentendido, vamos a reiniciar el servicio e intentar de nuevo. Y procedemos a cumplir con la formalidad. De hecho, para hacerla completa y evitar cualquier interferencia casual vamos a reiniciar el ordenador para luego intentar bajar nuevamente las actualizaciones… así que, reboot de por medio…

Debe ser un problema temporal, probemos con otro reinicio, funcionará bien la próxima…

A esta altura la heurística del cerebro nos lleva de inmediato a preguntarnos: seremos los únicos a los que nos toca la nube con más rayos? no, no puede ser… y vamos como un disparo a consultarle en Google, repitiendo la frase como en la escuela primaria: “Windows Update no puede buscar actualizaciones porque el servicio no se está ejecutando.”. Google engulle nuestra consulta cual galletita de chocolate y nos devuelve foros, foros y más foros de gente que se desgarra las vestiduras por ese error. No somos los únicos, hay más como nosotros.

Y navegando por los foros, allí, iluminado por la luz de las estrellas, está el link con la solución, justo en el sitio de soporte de Microsoft. Un artículo titulado ¿Cómo se pueden restablecer los componentes de Windows Update? Ohhh! toda la inmensidad se reduce a ese cartel azul que dice “Microsoft Fix It”: un extraordinario plan que nuestra empresa de confianza pone a disposición de sus apreciados clientes… “Fix It”, tan sencillo como un botón mágico que nos salva del hastío, de la oscuridad, y de los dolores de cabeza.

Asi que sin perder un segundo, damos clic al botón “Ejecutar ahora”, y luego “Acepto”, “Siguiente”, “Siguiente”, “Siguiente”, viendo una tenue barra de progreso hasta encontrar, ¡al fin!, que nuestro problema “ha sido corregido”.

O no, no ha sido corregido. Sigue igual. Igual que antes. Ni se ha inmutado:

Bueno, seamos optimistas, quizás ese parche no era el adecuado, quizás haya otro que lo resuelva. Probemos con este que parece similar:

No che, tampoco funciona. El fix no fixea nada. Todo muy bonito y lleno de firuletes, pero a la hora de correr se queda en la gatera:

Siguiendo con la lectura doy con otro enlace que puede ser el santo grial de las Actualizaciones de Windows. Se titula “Herramienta de preparación para Windows 7 sistemas basados en x64 (KB947821)” y se describe como:

“Esta herramienta ha sido puesta a su disposición porque se ha detectado una incoherencia en el almacén de servicios de mantenimiento de Windows que podría impedir la correcta instalación de futuras actualizaciones, service packs y otro tipo de software.”

Tan explicativo como ya nos tienen acostumbrados: una “incoherencia en el almacén de servicios de mantenimientos”, ¡pero que obvio! ¡quién lo hubiera dicho! Tan solo hay que bajar un parche de apenas… 340 MB… 340 megabytes por un Windows Update que no funciona. Un parche que pesa tanto o más que el instalador de Windows 98 tiene que arreglarlo todo: este problema y los que vaya a tener dentro de un año. Un parche de 340 megabytes tiene que arreglar TODOS los problemas.

no? NO.

Me hace acordar a una frase de la tira ECOL: “Mierda, mierda en estado puro.”

¿Que nos queda? Un poco más de lectura nos lleva a este post en el sitio de preguntas y respuestas de Microsoft, una especie de Yahoo Answers donde MVPs y usuarios intercambian sus miserias con el sistema operativo de las ventanitas.

La primera respuesta nos dice todo: “You are seeing the effects of a hijackware infection. Only the format & clean install will resolve the problem.” Y te lo dice un MVP con un montón de medallas, eh!

Ahhh, si me dieran un billete por cada vez que escucho eso… Verán, en el gremio informático es materia de todos los días que chantas que arreglan computadoras le achaquen los problemas a los virus. Ojo, en un cierto porcentaje es así, pero buena parte de ellos -los que degradan el oficio- aprovechan la ignorancia del cliente y le cargan al código malicioso todo aquello que ellos mismos no pueden resolver. Les suena…

  • ¿Te anda lento el explorer? Ah, tenés un virus.
  • ¿No abre facebook? Huy, un virus.
  • ¿La impresora no toma las hojas? Zás, tenés un virus.
  • ¿Se tapó el desagüe de la pileta? Que crees, un virus seguro!

Fíjense que hemos llegado a exportar -o quizás lo hemos importado de ellos- el mismo vicio a los médicos cuando no saben el origen de una molestia:

  • Una mancha y picazón en el brazo? Ah, tenés un virus.
  • Dolor de estómago y malestar general? Que crees, un virus seguro!

Y así como nos dan una bayaspirina y nos mandan de vuelta al hogar, los técnicos chantas inmediatamente dan la solución infalible: reinstalar, reinstalar, reinstalar.

No es una solución que me convenza, y evidentemente tampoco le convence al usuario j15Gatz quien, en la segunda respuesta y con buen pensamiento crítico, da la posta: apunta a un blog, que no pertenece a Windows ni a MSDN, donde sí está la solución:

Tres pasos sencillos:

  1. detener el servicio de Windows Update,
  2. eliminar el contenido de la carpeta C:\Windows\SoftwareDistribution\
     
  3. volver a iniciar el servicio.

Listo. Sólo eso.

A esto se enfrenta, sin saberlo, quien utiliza aplicaciones de código cerrado:

  • no conoce la interacción entre componentes,
  • no puede saber la causa de los problemas,
  • el desarrollador le impide por todos los medios que efectúe un diagnóstico preciso -de hecho se lo prohíbe explícitamente-,
  • debe confiar en “soluciones mágicas” sin fundamento ni asidero alguno,
  • el soporte técnico es un pozo negro de tiempo y dinero desperdiciado,

Your browser matters nothing to me

Your browser matters” dicen en Microsoft, porque en un montón de medios salieron a vitorear que publicaron con un sitio web que “analiza la seguridad que nos brinda nuestro navegador web”.

Pfffff… Puro verso. Qué me dicen de esto?

Chromium 6.0 no está mal. Llega a puntuar 4/4 (el máximo) .

Prueben ejecutando:

$ chromium-browser --user-agent="Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" http://www.yourbrowsermatters.org/

o bien

$ chrome --user-agent="Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" http://www.yourbrowsermatters.org/

Your browser matters… Mentira, lo único que importa es el User-Agent.

Reiniciando [rebooting]

Matthew Garrett es un biólogo (ahá) y reconocido hacker de Linux que lidia normalmente con complejas cuestiones de bajo nivel, pegadas al hardware, tales como ACPI, EFI, power management, y otras, que normalmente publica sus desventuras en el campo digital en un blog en livejournal. Muchos de sus artículos me han resultado realmente sorprendentes en cuanto a los intrincados detalles que pueblan los componentes de hardware desarrollados por diversos fabricantes.

Esta última semana publicó un artículo sobre el sencillo problema de cómo reiniciar correctamente una computadora. Me he tomado la libertad de traducir mejor dicho, interpretar ilegalmente, el post en cuestión. Para aquellos que se sientan cómodos con el inglés, les recomiendo el artículo original.


Reiniciando

Se podría pensar que es fácil reiniciar una PC, ¿no? Pero también podría pensarse que es fácil convencer a la gente de que al menos hacer un esfuerzo para ser amable con los demás es una propuesta de beneficio mutuo, y miren lo bien que nos ha funcionado.

Linux tiene un montón de maneras diferentes de reiniciar un sistema x86. Algunas de ellas son exclusivas para 32 bits y por eso las voy a ignorar porque, honestamente, que estás haciendo de tu vida [si estás trabajando en 32 bits]. Además, son horribles. Entonces, esto nos deja con cinco de ellas:

  • kbd – reiniciar a través del controlador de teclado. La IBM PC original tenía la línea [el cable] de reinicio de la CPU asociada a la controladora del teclado. Escribiendo la apropiada cantidad mágica de pulsos en la línea y la máquina se reinicia. Todo esto es muy sencillo, salvo por el hecho de que las máquinas modernas no tienen controladores de teclado (en realidad son parte del controlador embebido) e incluso las máquinas más modernas ni siquiera pretenden tener un controlador de teclado. Ahora, los controladores embebidos ejecutan software. Y, como todos sabemos, el software es terrible. Pero, aún peor, el software del controlador embebido está escrito por autores de BIOS. Así que claramente cualquier pretensión de que esto funcione es una especie de ficción complicada. Algunas máquinas son muy exigentes con el hardware, exigiendo que esté en el estado exacto que Windows lo programaría. Algunas máquinas funcionan 9 de cada 10 veces y luego se bloquean debido a algún raro problema de temporización. Y otras simplemente no funcionan en absoluto. ¡Hurra!
  • triple – intentar generar una falla triple. Esto se realiza cargando una tabla vacía como vector de interrupciones, y luego llamando a int(3). Falla la interrupción (no hay IDT), falla el manejador de fallos (no hay IDT) y la CPU entra en un estado que debería, en teoría, desencadenar un reinicio. Salvo que no parece haber un requerimiento de que esto suceda, y esto simplemente no funciona en un montón de máquinas.
  • pci – en realidad no pci. Tradicionalmente, el acceso al espacio de configuración PCI se logra escribiendo un valor de 32 bits al puerto io 0xcf8 para identificar el bus, el dispositivo, la función y el registro de configuración. El puerto 0xcfc luego contiene el [valor del] registro en cuestión. Pero si se escribe el par apropiado de valores mágicos en 0xcf9, la máquina se reiniciará. Espectacular! Y no estandarizado de ninguna manera (ciertamente no es parte de la especificación PCI), por lo que chipsets diferentes pueden tener diferentes requisitos. Booo.
  • efi – Los servicios EFI en tiempo de ejecución proporcionan un punto de entrada para reiniciar la máquina. Incluso a veces funciona! Siempre y cuando los servicios de tiempo de ejecución EFI estén funcionando, lo que puede ser una exageración.
  • acpi – Las versiones recientes de la especificación ACPI permiten especificar una dirección (por lo general en espacio de memoria o E/S de sistema) y un valor a escribir ahí. La idea es que escribir el valor a la dirección reinicia el sistema. Resulta que eso, a menudo, falla. También es imposible representar el método de reinicio PCI a través de ACPI, porque el método de reinicio PCI requiere un par de valores y ACPI sólo da uno.

Ahora, debo admitir que esto suena bastante deprimente. Pero la gente claramente vende computadoras con la expectativa de que van a reiniciarse correctamente, entonces ¿qué es lo que pasa?

Hace un tiempo hice algunas pruebas con Windows corriendo sobre qemu. Esta es una buena manera de evaluar el comportamiento del sistema operativo, porque uno tiene el control completo de lo que se entrega al sistema operativo y lo que el sistema operativo trata de hacer con el hardware. Y lo que descubrí fue un poco sorprendente. En ausencia de un vector de reinicio ACPI, Windows utiliza el controlador del teclado, espera un momento, lo intenta de nuevo y luego abandona. Si existe un vector de reinicio ACPI, Windows lo utiliza, luego prueba con el controlador del teclado, luego vuelve a utilizar el vector ACPI y prueba el controlador del teclado una vez más.

Esto resulta ser importante. Lo primero que significa es que genera dos escrituras en el vector ACPI de reinicio el sistema. El segundo es que deja un espacio entre ellas mientras toquetea el controlador de teclado. Y, sorprendentemente, resulta que en la mayoría de los sistemas el vector de reinicio ACPI apunta a 0xcf9 en el espacio de E/S del sistema. Incluso cuando la mayoría de las implementaciones nominalmente requieren escribir dos valores distintos, parece que este no es un requisito estricto y el método ACPI funciona.

[La versión del kernel Linux] 3.0 incluirá este comportamiento por defecto. Hace que varias máquinas funcionen (algunas Apple, por ejemplo), mejora las cosas en otras (algunas Thinkpad parecen quedarse tiesas durante largos períodos de tiempo, de otra manera) y con un poco de suerte evitará la necesidad de añadir más peculiaridades específicos al código de reinicio. Todavía hay algunas divergencias entre nosotros y Windows (mayormente en cuán seguido escribimos en el controlador de teclado), que se puede limpiar si resulta que hace alguna diferencia en cualquier lugar.

Ahora. De vuelta a los bugs de EFI.

– mjg59

Diez sistemas operativos en una netbook

Mi buen amigo Efraim es de esos informáticos que la tienen muy pero muy clara. Es de los administradores que hacen su trabajo con seriedad, pero de forma casi imperceptible para que las redes de las organizaciones sigan funcionando a pesar de las barbaridades que se ven en los desarrollos que corren sobre ellas (y de esas anécdotas hay para hacer un libro). Tiene, eso sí, la costumbre de exprimir al máximo todo hardware que pasa por sus manos; de hecho más de una vez lo he encontrado dejado procesando equipos una semana entera para entrenar redes neuronales.

Entre esos arranques -que a mi no se me ocurren ni por casualidad- se preguntó que tal andaría una netbook con diez sistemas operativos corriendo a la vez. Nueve Ubuntu(s), para ser preciso, virtualizados con KVM + KSM sobre un Debian que actúa de host, y todos al mismo tiempo y todos en una netbook. Contrario a lo que uno hubiera esperado, la verdad se la bancó muy bien, manteniendo responsivo el escritorio, como pueden ver por la captura de pantalla (de paso, con compiz). Allí está ingresando en uno de los virtualizados, mientras los restantes aún muestran la pantalla de inicio de sesión.

Por supuesto que no es cualquier netbook; de todas las que hay en el mercado, esta belleza de Asus [ver reviews 1 y 2] tiene un procesador de 64 bits y virtualización por hardware, lo que hace posible semejante comportamiento.

0x4001100200001012, o que te repare Magoya

Por puro divertimento se me ocurrió iniciar en Windows para crear y probar el “Disco de Recuperación del Sistema de Windows 7” que vino con la portátil.

Menos mal! Porque lo que se dice “reparar”, no “repara” nada… más que nada devuelve este muy explícito error:

“Error 0x4001100200001012. Si este problema persiste, comuníquese con la”

Con la…??? Y ahora sí, que te lo repare Magoya

Por supuesto, el que quiere sufrir, que siga con lo mismo. Yo me quedo con sistemas operativos serios…

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress