16 de octubre de 2014

Las novedades de Linux 3.17

Ya se ha anunciado la versión 3.17 de Linux. Entre las novedades de esta versión se encuentra el soporte para compartir dispositivos USB vía IP, soporte para los controladores de la Xbox One, soporte para el Thunderbolt de Apple, una nueva API que restringe las operaciones en archivos de memoria compartida para hacer la vida más fácil a los desarrolladores, soporte para el traceado de fallos de páginas en perf trace, soporte para que kexec sólo pueda arrancar kernels firmados, y una nueva llamada al sistema getrandom() para una generación de números aleatorios más segura. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.


· Compartición de dispositivos USB vía IP

USB/IP es un proyecto que proporciona un sistema de compartición de dispositivos USB a través de la red. Para compartir dispositivos USB entre ordenadores con su funcionalidad completa, USB/IP encapsula los mensajes de E/S USB en paquetes TCP/IP. Los controladores y aplicaciones pueden usarse en dispositivos USB remotos sin ninguna modificación, permitiendo usarlos como si fueran dispositivos locales.

Este proyecto ha estado durante mucho tiempo en el área "staging" para código inestable. En esta versión pasa a considerarse estable. Las herramientas de espacio de usuario pueden encontrase en tools/usb/usbip

· 'Sellado de archivos' para facilitar el uso de la memoria compartida

Cuando varios procesos se comunican entre ellos mediante memoria compartida, tienen que ser cuidadosos y sincronizarse, porque cualquier proceso puede modificar los contenidos de la memoria compartida en cualquier momento, o cambiar el tamaño del buffer. Esto hace que la comunicación de procesos mediante memoria compartida sea frágil, requiera mucho cuidado por parte de los programadores, incentive a hacer copias privadas de la memoria compartida, y haga imposible las operaciones zero-copy si no se puede confiar en los procesos con quien se comparte la memoria.

Esta versión incluye el concepto de "sellado de archivos". Los archivos de shmfs podrán ser "sellados" con fcntl(2) para restringir ciertos comportamientos: ampliar o reducir el tamaño del archivo, escribir en él, o aplicar nuevos "sellos"
El sellado permite compartir archivos de shmfs sin ninguna relación de confianza. Esto es reforzado por el hecho de que se rechazan modificaciones de sellados si no se posee una referencia exclusiva al archivo. De modo que si un proceso posee un descriptor de archivo, puede estar seguro de que nadie excepto él puede modificar los sellos de ese archivo. Esto permite mapear archivos compartidos de procesos en los que no se confía sin miedo de que te vayan a truncar el archivo o de que un atacante lo vaya a modificar.

Esta característica tiene muchas utilidades. Un servidor gráfico -Wayland, por ejemplo- podría querer rechazar descriptores de archivos que no tengan el sello SEAL_SHRINK. De ese modo, se garantiza que la memoria estará accesible (mientras al mismo tiempo se permite ampliar el buffer). Otro ejemplo sería la construcción de un sistema de IPC genérico, como dbus. Con los sellados, es posible hacer zero-copy fácilmente compartiendo un descriptor de archivo que tenga los sellos SEAL_SHRINK | SEAL_GROW | SEAL_WRITE. De este modo, la fuente puede almacenar datos en el archivo, sellarlo y entonces pasárselo al destinatario. El destinatario puede verificar que esos sellos están puestos y entonces parsear los datos del archivo directamente, o incluso hacer multicasts del mensaje y permitir a todos los receptores parsear con zero-copy el mismo archivo. Artículo de LWN recomendado: Sealed files, artículo de blog recomendado: memfd_create(2)

· "Render nodes" activado por defecto

"Render nodes" es una característica incluída en Linux 3.12. Permite crear diferentes nodos de dispositivo en /dev para la GPU y para la salida de vídeo, de modo que las aplicaciones puedan usar la GPU directamente para renderizar cosas en la memoria hablando directamente al nodo de dispositivo de la GPU.

Esta característica ha sido considerada experimental desde el principio y sólo podía ser activada con el parámetro "drm.rnodes=1". En esta versión, ha sido activada por defecto. Para más detalles, ver este blog

· Mejora de la gestión energética en más GPUs Radeon

La característica de gestión de energía "dpm" ha sido reactivada por defecto para las GPUs cayman y BTC.


También se ha añadido un nuevo parámetro de módulo (radeon.bapm=1) para permitir la característica (bapm, incluída en la anterior versión de Linux) en las APUs en las que esté desactivada por defecto debido a problemas de estabilidad.

· Soporte de Thunderbolt

Thunderbolt es una interfaz de hardware que combina PCI Express y Displayport en una señal en serie junto con una conexión de corriente continua, todo en un mismo cable. Un conector soporta hasta seis periféricos en diferentes topologías. Co-desarrollado por Intel y Apple, es utilizado sobre todo en dispositivos Apple. En esta versión, se añade soporte para Linux.

· Soporte para los controladores de la Xbox One
Esta versión añade soporte para los controladores de la Xbox One.

·Generación de números aleatorios más segura mediante la llamada al sistema getrandom()
Los sistemas Linux generalmente consiguen sus números alteatorios de /dev/[u]random. Esta interfaz, sin embargo, es vulnerable a ataques de exahustación de descriptores de archivo, en los que el atacante consume todos los descriptores de archivo que puede hasta llegar al límite. Además, es inconveniente para los contenedores. La llamada al sistema getrandom(2), análoga a la getentropy(2) de OpenBSD, solventa esos problemas. Artículo recomendado de LWN: A system call for random numbers: getrandom()

· Soporte para el traceado de fallos de página en perf trace
En esta versión se incluye soporte para tracear los fallos de página en "perf trace"- Utilizando la opción -F/--pf el usuario puede especificar si quiere tracear los eventos de fallos de páginas menores, mayores o todos ellos.

· perf timechart añade un modo de ES

Además de grabar información de eventos sobre el gestor de procesos y la CPU (cambios de tarea, tiempos de ejecución, estados energéticos de la CPU, etc) esta versión añade un modo E/S que hace posible grabar información de actividad de E/S. En este modo, "perf timechart" generará un SVG con gráficos de E/S (lecturas, escrituras, tx, rx, polls).

· Kernels firmados para kexec

Kexec es una característica de Linux que permite ejecutar un kernel desde un kernel Linux ya existente. Se utiliza para el reinicio rápido, o incluso para ejecutar automáticamente un nuevo kernel tras un crash. Sin embargo, los sistemas con  "arranque seguro" UEFI no deberían poder ejecutar sistemas operativos no firmados. Kexec permite ejecutar la protección del "arranque seguro de UEFI" haciendo kexec a un kernel no firmado desde dentro de un kernel firmado. Para solventar ese problema, esta versión incorpora soporte para que los sistemas con "arranque seguro" sólo puedan arrancar con kexec kernels que también estén firmados. Artículo LWN recomendado: Reworking kexec for signatures

Y eso es todo. La lista completa de cambios en inglés, aquí.

16 de septiembre de 2014

Las novedades de Linux 3.16

Hace ya más de un mes que Linus Torvalds anunció la versión 3.16 de Linux. Con mucho retraso procedo a resumir las principales novedades de esta versión, entre las que se encuentra la mejora de rendimiento en algunas tarjetas gráficas Nvidia, gracias al soporte para alterar la frecuencia de funcionamiento de la GPU; se añade soporte para mapear memoria de espacio de usuario en la GPU en GPUs Intel; se ha añadido un btree de inodos libres a XFS para mejorar el rendimiento en la asignación de inodos, los kernels de ARM64 pueden ser utilizados como aplicación EFI, se ha añadido soporte de IPv6 a la funcionalidad TCP Fast Open , algunas tarjetas graficas AMD Radeon tiene mejor rendimiento gracias a la mejora de la gestión energética, se ha añadido soporte para las GPUs de Intel Cherryview, y los control groups han añadido un modo de jerarquía unificada. También se han incluido drivers nuevos y muchas otras mejoras y pequeños cambios. La lista completa de cambios, en inglés, puede encontrarse aquí, como siempre.


· Mejoras en el rendimiento gráfico de tarjetas Nvidia, soporte inicial de GK20A y GK110B
Nouveau, el controlador libre para GPUs Nvidia, ha añadido soporte para cambiar la frecuencia de funcionamiento de la GPU. Esta característica (que por ahora tiene que ser activada manualmente) mejora el rendimiento notablemente. Las GPUs Nvidia que soportan esta funcionalidad son las que tienen relojes de tipos nv40, nvaa, y nve0.

Esta versión también añade soporte inicial (pero incompleto) para GPUs Nvidia GK20A, que se encuentran en los SoCs Tegra K1 SoC; y también para los GK110B.


· El driver para GPUs Intel permite mapear memoria de espacio de usuario en la memoria de vídeo
Al permitir mapear direcciones de espacio de usuario en la memoria de video, es posible utilizar datos de la aplicación como fuente para texturas o incluso como destinación de un proceso de renderizado (dependiendo de las capacidades del chipset). Esto tiene usos útiles, tales como descargas de memoria a la GPU sin copias y mejoras de rendimiento en varios casos. Esta capacidad tiene consecuencias extensas, desde renderizado por software más veloz (chromium) o mitigación de pausas en ciertos casos en firefox.

 
· Jerarquía unificada en los control groups
Los control groups permiten crear grupos arbitrarios de procesos y aplicarl restricciones de CPU, disco o memoria a esos procesos. La implementación actual permite crear varias jerarquías y aplicar diferentes restricciones a cada jerarquía. Por varias razones, detalladas en este artículo de LWN (en inglés), esta manera de funcionar no está considerada apropiada, y se ha estado trabajando para migrar hacia una implementación en la que sólo exista una jerarquía. Esta versión incluye por primera vez esta jerarquía unificada para los control groups (opcional por ahora)

· btree de inodos libres en XFS, para mejorar el rendimiento de la asignación de inodos

En esta versión, XFS ha añadido un btree que almacena información sobre los inodos libres. El propósito es mejorar la búsqueda de inodos libres durante la asignación de inodos.

Esta característica no modifica las estructuras de disco existentes, pero añade una nueva que debe permanecer consistente con el btree de inodos asignados; por esta razón kernels anteriores sólo podrán montar sistemas de archivos que soporten esta nueva característica en modo de sólo lectura.

· Permitir arrancar kernels ARM64 como aplicaciones EFI

Esta versión permite arrancar un kernel Linux compilado para ARM64 como una aplicación EFI en sistemas que tengan firmware UEFI, sin que sea necesario un cargador de arranque.

· Soporte de TCP Fast Open con IPv6

TCP Fast Open es una característica de TCP diseñada para que las conexiones TCP sean más rápidas. El primer soporte fue añadido en Linux 3.6 para clientes, en 3.7 se añadió soporte para servidores y en 3.13 Fast Open fue activado por defecto. Esta versión añade soporte de Fast Open en servidores IPv6

· Soporte de gráficos Intel Cherryview

Esta versión añade soporte para GPUs Broadwell que se encuentran en SoCs Cherryview.

· Mejora de rendimiento en APUs AMD Radeon

Se ha implementado para algunas APUs un modo con una mejor gestión energética, "bapm" o "bidirectional application power management". Es una característica que consiste en que la GPU y la CPU comparten el TDP, lo cual permite ofrecer rendimiento extra en la GPU cuando hay margen disponible en la CPU. En esta versión, se ha activado bpam por defecto, pero sólo en unos pocos dispositivos y casos. En el futuro se mejorará el soporte para bapm.

Y eso es todo. La lista completa de cambios en inglés, aquí

28 de julio de 2014

X.Org Server 1.16: Ahora empezaba a ponerse interesante

No deja de ser paradójico que, ahora que Wayland se está consolidando, nos vengan con una nueva versión del servidor gráfico de X.org, la 1.16, que incorpora unas novedades que, de no existir Wayland, causarían muchísimo más ruido del que hemos visto.

Me refiero, por supuesto, a la inclusión de Glamor. Se trata de un proyecto con ya unos añitos de edad, consistente en utilizar OpenGL en todas las APIs 2D de X.org. Las ventajas son múltiples: por una parte, se aprovechan las capacidades de aceleración del hardware moderno, por otra, ofrece la oportunidad de consolidar la forma de acelerar esas APIs en una sola solución para todas las GPUs que elimine optimizaciones particulares para cada GPU, y de ese modo establecer una arquitectura de aceleración definitiva que resuelva los problemas de rendimiento de la extensión Render que las anteriores arquitecturas nunca resolvieron del todo.

El problema de Glamor y la razón por la que esto no se hizo antes es que que, como es sabido, las impresionantes capacidades del hardware gráfico moderno no son siempre capaces de implementar con buen rendimiento las tradicionales y aparentemente estúpidas operaciones "2D". Sin embargo, parece ser que a base de trabajo duro (Keith Packard ha escrito bastante sobre ello: 1, 2, 3, 4) han conseguido una solución decente.

Y lo curioso es que un titular como "los gráficos de Linux pasarán a estar completamente acelerados vía OpenGL" hubiese causado sensación hace sólo unos años. Pero hoy la gente está más interesada en Wayland, que ofrece eso y más.

Lo mismo pasa con otra de las novedades: integración con systemd-logind, que no sólo permite a X.org funcionar mejor como servicio de sistema, permite ejecutar el servidor de X.org sin privilegios root.

Esta versión del servidor de X.org es, sin duda, una de las más importantes en mucho tiempo. Pero el hecho de que su otra gran novedad sea la inclusión de XWayland, da una pista de por dónde van los tiros.

14 de julio de 2014

Avanzando a golpe de actualizaciones de systemd

El debate frenético que generó la adopción debianera de systemd, seguida de la consecuente adopción ubuntera, ha consumido los flamewars sobre sistemas de inicio. No es que haya desaparecido: el tema sigue viéndose, y se discute -y más que se discutirá-, pero se trata de una discusión aislada y repetitiva, desapegada de los eventos del mundo del software libre, que ya ha pasado página. Systemd ha ganado, y el ruido de la oposición no se ha transformado en proyectos capaces de sustituirlo (y por capaces no me refiero a openrc), , lo cual es un indicativo fiable de que, en realidad, systemd es una mejora bienvenida por la mayoría.

Tenemos, por tanto, un mundo Linux que, en su gran mayoría, usa systemd o lo usará en próximas versiones. Las consecuencias de este cambio son muy importantes y son, de hecho, la que probablemente es la mayor ventaja de systemd, y la menos discutida: la unificación del sistema base de la mayoría de las distros en un mismo proyecto, una utopía soñada que existía literalmente desde el nacimiento de las primeras distros, y que sólo systemd ha logrado materializar.

Y esta es una ventaja que Lennart Poettering tiene toda la intención de utilizar. Sin ningún complejo, hace tiempo que proclama a los cuatro vientos que systemd ya no sólo un sistema de inicio y de gestión de servicios, sino una plataforma, e incluso el pegamento que une a las aplicaciones con el kernel. Casi nada. Entre sus últimas novedades y sus planes de futuro se encuentran un pequeño sustituto de network-manager, de ntpd, una implementación simple de containers, sandboxing de aplicaciones y servicios, gestión de servicios de todas las instancias de un proyecto albergado en la nube o de todos los containers que estén siendo ejecutados en el sistema...características que la práctica totalidad del mundo Linux conseguirá con una simple actualización. Y esto es lo verdaderamente novedoso: que el sistema base de Linux pueda evolucionar con una simple actualización.

Como ejemplo de esto último están las últimas novedades que están trabajando. Consiste en convertir a todo sistema que use systemd en un sistema "sin estado", un concepto que consiste en esencia en hacer lo necesario para que todo el software de la distribución se instale en /usr, y que en /etc y /var se almacene exclusivamente la configuración y datos generados por el usuario - el "estado" del sistema. Esto permite características curiosas, como un "reseteo del sistema": bastará vaciar el contenido de /etc y /var, y el sistema regresará al mismo estado inmaculado que tendría tras haber reinstalado la distro de cero. Es decir, se eliminará la necesidad de reinstalar la distro, bastará utilizar esta función de reseteo. También ayudará a la implementación de instaladores que distribuyan un sistema reseteado como método de instalación. Y como /usr pasa a consolidarse como el lugar donde reside el software de la distribución y donde normalmente nunca se escribe nada, se podrán crear instaladores que consistan simplemente en actualizar /usr, y tener varios snapshots de /usr, y garantizar mediante cifrado la integridad de /usr.

Antes de systemd, cosas así eran difíciles de ver. Cada distribución se lo hubiese montado a su manera, con sus propios scripts, sin fuerza agregada suficiente como para forzar a programas upstream a adoptar los cambios necesarios que las hiciesen posible. Pero systemd si tiene la fuerza necesaria para implementar estos cambios, y para animar a upstream a incorporar cambios que harán más fácil la adopción de estas características en todas las distros. Se trata de un círculo virtuoso que hace más fácil hacer cambios revolucionarios con cada vez menor coste para las distros. Sólo hay un precio a pagar: vender el alma a systemd.