3 de enero de 2017

Las novedades de Linux 4.8


(Post muy retrasado)
La versión 4.8 de Linux se anunció el  2 de Octubre de 2016. Esta versión añade soporte para el uso de páginas gigantes en el caché de páginas; soporte de eXpress Data Path, una opción para el tráfico de red programable y de alto rendimiento; soporte para mapeados inversos en XFS que son la fundación de varias mejoras que se añadirán en el futuro; verificación más estricta de las copias de memoria de espacio de usuario; soporte de etiquetado de seguridad en IPv6 (CALIPSO, RFC 5570); soporte para plugins de GCC; una nueva funcionalidad de virtio, vsocks, para facilitar la comunicación entre huéspedes y anfitriones; un nuevo algoritmo de congestión, TCP New Vegas; y la documentación ha sido convertida al formato reStructuredText. 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.


· Soporte para el uso de páginas gigantes transparentes en el caché de páginas
Las páginas gigantes permiten la utilización de páginas mayores de 4Kb (en x86); cuando el sistema utiliza estas páginas automáticamente las llamamos "transparentes". Hasta ahora, Linux no soportaba el uso de páginas gigantes en el caché de páginas (páginas utilizadas para almacenar un caché de los sistemas de archivos). En esta versión se añade soporte para el uso de páginas gigantes transparentes en el caché de páginas cuando se utilicen sistemas de archivo tmpfs/shmem (el soporte para otros sistemas de archivo se añadirá en el futuro).

Se puede controlar el uso de páginas gigantes en tmpfs utilizando la opción de montaje huge=, que puede recibir cuatro parámetros: always (se intentará utilizar páginas gigantes cada vez que se necesite una nueva página); never (no utilizar páginas gigantes - este es el valor por defecto); within_size (solo se utilizarán páginas gigantes si no sobrepasa el tamaño de archivo, también se respetan las pistas a fadvise()/madvise()); advise (sólo se utilizarán páginas gigantes si son solicitadas con fadvise()/madvise()).

También hay un archivo en sysfs para controlar la asignación de páginas gigantes en montajes internos shmem: /sys/kernel/mm/transparent_hugepage/shmem_enabled. Este valor es utilizado para SysV SHM, memfds, shared anonymous mmaps (de /dev/zero de MAP_ANONYMOUS), objetos DRM de controladores GPU, ashmem. Además de las políticas señaladas arriba, shmem_enabled permite dos valores adicionales: deny (para ser usado en emergencias, para forzar la opción de páginas gigantes de todos los montajes); force (forzar el uso de páginas gigantes para todos - útil principalmente para pruebas)


· Soporte de eXpress Data Path

XDP o eXpress Data Path proporciona una ruta para datos de red de alto rendimiento y programable. Proporciona procesamiento de paquetes con poca sobrecarga al nivel más bajo de la capa de software. La mayor parte de la gran mejora de velocidad viene del procesado de páginas-paquetes RX directamente fuera del anillo RX del driver, antes de que haya alguna asignación de estructuras de metadatos, como SKBs. Sus propiedades son: XDP está diseñado para alto rendimiento; XDP está diseñado para ser programable, se puede implementar nueva funcionalidad al vuelo sin requerir modificaciones en el kernel; XDP no intenta circunvalar el kernel, se integra en las rutas rápidas de la pila de red; XDP no reemplaza a la pila TCP/IP, la complementa y se coordina con ella; XDP no requiere hardware especializado. Para más información, ver https://www.iovisor.org/technology/xdp y Express_Data_Path.pdf


· Mapeado inverso en XFS

El mapeado inverso permite a XFS localizar al propietario de un bloque específico en el disco de manera precisa. Está implementado como una serie de btrees (uno por cada grupo de asignación) que llevan cuenta de los propietarios de los extents. Se trata, de hecho, de un "árbol de espacio utilizado" que se actualiza cuando el sistema de archivos asigna o libera extents y es por tanto coherente con los btrees de espacio libres.

Esta infraestructura de mapeo inverso es el bloque fundacional de varias características que se añadirán a XFS en el futuro - reflink, copy-on-write, deduplicación, scrubbing online de metadatos y datos, reporte detallado de errores a los usuarios, y reconstrucción de sistemas de archivos dañados y corruptos significativamente mejorada. Hay muchas cosas nuevas que se incorporarán en las próximas versiones, y todo se basa en esta infraestructura. Por esa razón, se trata de una gran cantidad de código nuevo con nuevas características de formato de disco e infraestructura interna. Se trata de una característica experimental y no se recomienda su uso por el momento.


· Verificación más estricta de las copias de memoria desde el espacio de usuario

Esta es una característica de seguridad portada de Grsecurity. Cuando el kernel copie memoria desde o hacia el kernel (mediante las funciones copy_to_user() y copy_from_user()), se harán comprobaciones extra para asegurarse de que los rangos de memoria afectados no son sospechosos. Esto imposibilita toda una serie de exploits de heap overflow y exposiciones de memoria del kernel. El impacto en el rendimiento es apenas notable.


· Soporte para plugins de GCC

Al igual que el anterior, esta característica ha sido portada de Grsecurity. Permite el uso de plugins de GCC, que son pequeños módulos de compilador cargables que permiten analizar, cambiar y añadir código durante la compilación y pueden utilizarse para la instrumentación en tiempo de ejecución y análisis estático de código. Grsecurity utilizar estos mecanismos para mejorar la seguridad. Esta versión incluye dos plugins: sancov, un plugin que se utiliza como ayuda para kcov; y el plugin cyclomatic para el análisis de la complejidad ciclomática de una función


· virtio-vsocks para facilitar la comunicación entre huésped y anfitrión

Esta version añade virtio-vsock, que proporciona sockets AF_VSOCK que permiten la comunicación entre aplicaciones del huésped y el anfitrión. A diferencia de virtio-serial, virtio-vsock soporta la API de sockets POSIX, de modo que las aplicaciones de red existentes necesitan pocas modificaciones. La API permite conexiones N:1, de modo que múltiples clientes pueden conectarse a un mismo servidor simultáneamente. El dispositivo tiene una dirección asignada automáticamente, de modo que no es necesaria configuración alguna dentro del huésped.



· Soporte de etiquetado de seguridad IPv6 (CALIPSO, RFC 5570)

Esta versión implementa el RFC 5570 - Common Architecture Label IPv6 Security Option (CALIPSO). Está diseñado para ser usado en entornos de red MLS confiables. CALIPSO es muy similar a su primo de IPv4 CIPSO, y esta característica está basada en gran medida en ese código.



· Nuevo algoritmo de control de congestión TCP New Vegas

Esta versión añade un nuevo algoritmo de control de congestión, TCP New Vegas, que es una actualización importante de TCP Vegas. Al igual que Vegas, New Vegas es un sistema para evitar la congestión basado en el retraso. Su mecanismo de filtrado es similar: utiliza las mejores mediciones en un periodo concreto para detectar y medir la congestión. Está desarrollado para coexistir con redes modernas donde los anchos de banda son de 10 Gbps o mayores, donde los RTTs son de décimas de microsegundos, etc.Puede encontrarse una descripción aquí: http://www.brakmo.org/networking/tcp-nv/


· Documentación convertida al formato reStructuredText 

En un intento de modernizar la documentación del kernel, va a ser convertida al sistema Sphinx, que utiliza el formato reStructuredText.






Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.

25 de julio de 2016

Las novedades de Linux 4.7

Ya se ha anunciado la versión 4.7 de Linux. Esta versión añade soporte para las recientemente puestas en venta GPUs Radeon RX 480 'Polaris', soporte para búsquedas de rutas de archivo paralelas en el mismo directorio, un nuevo gobernador de frecuencia experimental "schedutils" que debería ser más rápido y veloz que otros gobernadores, soporte para el mecanismo EFI "Capsule" que facilita las actualizaciones de firmware, soporte de controladores virtuales USB en la funcionalidad USB/IP para que los emuladores de teléfonos puedan funcionar como dispositivos USB reales, un módulo de seguridad llamado "LoadPin" que asegura que los módulos del kernel sólo se puedan cargar desde un sistema de archivos determinado, soporte para construir histogramas de eventos en la interfaz de trazado ftrace, soporte para asociar programas BPF a tracepoints del kernel, soporte para callchains en la utilidad perf trace, y soporte estable para la funcionalidad sync_file de Android. 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.



· Soporte para GPUs Radeon RX 480 'Polaris'

Como resultado de la nueva política de drivers libres de AMD, esta versión incluye soporte en el driver amdgpu para las recientísimamente puestas en venta GPUs Polaris, la nueva generación de  GPUs Radeon RX 480. El soporte está al mismo nivel que el resto de dispositivos del driver.



· Búsquedas de ruta de archivo paralelas en el mismo directorio

El caché de directorio (conocido como "dcache") es una de las partes más críticas del kernel, se trata de un caché de las rutas de los sistema de archivos, lo cual permite agilizar enormemente ciertas operaciones; por ejemplo, permite determinar si cierto archivo o directorio existe o no sin tener que leer datos del disco. Este cache usa un mutex para serializar las búsquedas de rutas en el mismo directorio.

Esta versión permite hacer búsquedas de rutas en el mismo directorio; el mutex serializador ha sido sustituido por un semáforo de lectura-escritura. Esta mejora no se notará en la vastísima mayoría de casos, porque las búsquedas en el caché de directorios son muy rápidas y es muy raro que se convierta en un punto de contención. Pero para algunas cargas específicas que utilizan la búsqueda de rutas muy intensivamente, verán una mejora del rendimiento porque a partir de ahora podrán hacerse en paralelo. La mayor parte  de los sistemas de archivos han sido convertidos para utilizar esta característica.


· Nuevo gobernador de frecuencia experimental 'schedutils'

Esta versión incorpora un nuevo gobernador para el subsistema de escalado de frecuencias (cpufreq). Hay dos grandes diferencias entre este nuevo gobernador y los existentes. Primero, schedutils utiliza información proporcionada directamente por el planificador de procesos. Segundo, puede invocar los drivers cpufreq y cambiar la frecuencia más rápidamente.

Lo que esto significa es que el tiempo que tarda el gobernador en hacer cambios de frecuencia y la calidad de las decisiones tomadas mejora respecto a anteriores gobernadores. Nótese que este nuevo gobernador es muy simple, y está considerado como una base sobre la que fundar futuros cambios que mejoren la integración entre el planificador de procesos y la gestión de energía. Sin embargo, funciona y los resultados preliminares son prometedores. Este gobernador comparte algunos valores tuneables con los otros gobernadores.


· Soporte para construir histogramas de eventos en la interfaz de trazado ftrace

Los "Hist triggers" son una funcionalidad que se incorpora a ftrace, la infraestructura de trazado de Linux disponible desde 2.6.27 que está embebida en el kernel y disponible en /sys/kernel/debug/tracing. Esta versión añade el comando "hist" a ftrace, que permite construir "histogramas" de eventos, agregando el número de eventos en una tabla hash. Como ejemplo, vamos a suponer que un usuario quiere conseguir una lista de bytes leídos por cada proceso en el sistema. Se puede hacer con el comando "hist" de la siguiente manera:

# echo 'hist:key=common_pid.execname:val=count:sort=count.descending' > /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger

Lo que hace este extraño comando es escribir un comando al archivo trigger del evento sys_enter_read (el evento que corresponde a entrar en la llamada al sistema read(), es decir, intentar leer un archivo). Cuando se produzca el evento, se ejecutará un comando hist (hist:) que significa lo siguiente: cada vez que se dispare el evento, leer el PID (common_pid - puedes ver todos los campos posibles del evento en el archivo /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/format) y convertirlo a nombre de proceso (sufijo .execname); esto será usado como clave (key=) en el histograma. El parámetro val=count hace que se lea también el campo count, que en el evento sys_enter_read se refiere al número de bytes leídos. Finalmente, tras el separador :, el parámetro sort=count.descending hace que el comando ordene el resultado por el campo count en orden descendiente. La salida resultante es esta:


Esta salida muestra qué procesos han leído archivos, cuantos bytes (count), y con cuanta frecuencia (hitcount, que no fue especificado en el comando pero se incluye por defecto).

Como se puede observar, esta pequeña herramienta permite hacer análisis muy útiles del sistema, y si bien ftrace no puede competir (ni lo pretende) con herramientas de trazado más potentes como LTTng, perf o SystemTap, puede ser una herramienta muy conveniente. Para más información, puedes ver la documentación sobre hist triggers, or leer este post recomendado de Brendan Egg: Hist Triggers in Linux 4.7. Para más documentation sobre ftrace, ver Documentation/trace/ftrace.txt


· Soporte para callchains en la utilidad perf trace

En esta versión, perf trace añade la habilidad de mostrar callchains cada vez que el proceso a trazar encuentra una llamada al sistema. Puedes probarlo con comandos como # perf trace --call dwarf ping 127.0.0.1. Puedes mostrar callchains para los eventos deseados: # perf trace --event sched:sched_switch/call-graph=fp/ -a sleep 1. El trazado de fallos de página (options -F/--pf) también lo soportan, por ejemplo, para trazar las llamadas a write() y los fallos de página con callchains mientras se inicia firefox, puede hacerse con # perf trace -e write --pf maj --max-stack 5 firefox. Una análisis de perf trace con callchains de todos los procesos de un sistema completo puede encontrarse aquí.


· Permitir que los programas BPF usen tracepoints

Los tracepoints son una suerte de printf()s dinámicos que los desarrolladores introducen en su código para que puedan ser utilizados más tarde para analizar el comportamiento del sistema. Los Tracepoints pueden ser utilizados por muchas utilidades: LTTng, perf, SystemTap, ftrace...pero no podían ser utilizados por programas BPF

Esta versión añade un nuevo tipo de programa BPF (BPF_PROG_TYPE_TRACEPOINT) que puede usarse para construir programas BPF que puedan recoger datos de los tracepoints y procesarlos dentro del programa BPF. Esta alternativa puede ser más rápida que acceder a los tracepoints mediante kprobes, puede hacer las interfaces de los programas de trazado más estable, y permite la construcción de herramientas de trazado más complejas.


· Soporte para el mecanismo 'Capsule' de EFI

Esta versión añade soporte para el mecanismo 'Capsule' de EFI, que permite pasar a EFI archivos de datos. EFI los valida y toma decisiones de acuerdo con sus contenidos. El uso más común para este mecanismo es incluir actualizaciones de firmware en una Capsule para que EFI haga la actualización en el próximo reinicio. Los usuarios pueden subir datos a Capsule escribiendo el firmware en el dispositivo /dev/efi_capsule_loader device.


· Soporte para controladores de USB virtuales en USB/IP

USB/IP permite compartir dispositivos USB sobre la red. Los dispositivos a compartir necesitan, sin emabrgo, ser reales. Esta versión soporte la capacidad de crear dispositivos USB virtuales sin necesidad de tener un dispositivo USB físico, tal sólo utilizando el subsistema de USB gadgets.

Esta característica tiene varios usos; el más obvio (el que ha motivado su desarrollo) es la mejora de la emulación de teléfonos en los entornos de desarrollo. Los teléfonos emulados pueden ahora conectarse a la máquina del desarrollador, o a una virtual, mediante USB/IP, y así utilizarlos como si fuera un teléfono físico. También es útil, por razones obvias, para pruebas y experimentos.


· El mecanismo de fencing de Android, sync_file, se considera estable

En esta versión, el código sync_file que estaba en el directorio de pruebas staging/, ha sido movido al kernel principal. Sync_file es una API desarrollada para Android para cubrir las deficiencias del mecanismo de fencing de Linux; para los interesados se pueden encontrar más detalles en la documentación oficial, Documentation/sync_file.txt.


· LoadPin, un módulo de seguridad para restringir el origen de los módulos del kernel 

LoadPin es un módulo de seguridad que se asegura de que todos los archivos cargados por el kernel (módulos del kernel, firmware, imágenes kexec, políticas de seguridad, etc) tengan origen en un mismo sistema de archivos. Las expectativas son que ese sistema de archivos sea de sólo lectura, como por ejemplo un DVD o dm-verity (esta característica viene de ChromeOS, donde el sistema principal está verificado criptográficamente con dm-verity). Los sistemas con este tipo de sistemas de archivos podrán con este sistema forzar las restricciones citadas sin tener que recurrir a firmar criptográficamente los módulos (algo que Linux también soporta), lo cual es obviamente beneficioso para la seguridad


Estas son las novedades principales de este kernel. Como siempre, pueden encontrar la lista completa, y en inglés, en esta página.

14 de junio de 2016

Apple ya tiene su ZFS: APFS

ZFS fue una revolución en el mundo de los sistemas operativos de propósito general, hasta el punto que se puede afirmar tajantemente que el sistema operativo que no tenga un sistema de archivos inspirado en él, está obsoleto. En Apple no son tontos y en seguida se interesaron al menos en facilitar el uso de ZFS, pero acabaron abandonando la idea por problemas de licencia. Aun así, surgieron rumores de que Apple estaba desarrollando un sustituto de HFS+, sin que llegaran nunca a nada.

Hoy, en su conferencia para desarrolladores, Apple ha anunciado su nuevo sistema de archivos APFS. No se han dado muchos detalles, pero no se diferencia en nada de lo que se podría esperar de un clon de ZFS. Habrá que esperar hasta el año que viene para que den más detalles y publiquen el código fuente: APFS está tan verde, que ni tan siquiera garantizan la estabilidad del formato de disco.

Sorprende que Apple, con sus inacabables recursos monetarios, se haya tomado tanto tiempo en crear un clon de ZFS: todos sus sistemas usan aun HFS+ (prueba de que, como se ha sugerido en el pasado en este blog, una implementación rápida y estable de un sistema de archivos es mucho más importante en la práctica que las campanitas y luces de colores de un formato de disco nuevo). Un servidor esperaba a APFS años mucho antes; hace cuatro años predecía, erróneamente, que veríamos un ZFS de Apple antes de ver ReFS -el ZFS de Microsoft, recuerden- en los Windows de escritorio.

Pero sobre todo, lo que esperaba de Apple es que se atreviese a ir más allá de los sistemas de archivo jerárquicos. Tras haber contratado al desarrollador del sistema de archivos de BeOS, uno se esperaba que se atreverían a copiar su implementación de atributos extendidos, pero no parece haber ninguna innovación en ese frente. No pierdo la esperanza de que lo tengan reservado para el futuro.