18 de diciembre de 2014

Las novedades de Linux 3.18

Ya se ha anunciado la versión 3.18 de Linux. Esta versión añade soporte para overlayfs, que permite combinar dos sistemas de archivos en un sólo punto de montaje, se añade soporte para mapear memoria de espacio de usuario en la memoria de vídeo en los drivers Radeon, se añade una llamada de sistema bpf() que permite la ejecución de programas en bytecode al estilo de BPF; se añade también un algoritmo de congestión de tráfico TCP optimizado para centros de datos, un protocolo de encapsulado optimizado para virtualización, soporte para incrustar protocolos IP en paquetes UDP, y soporte de la capa de bloques multi-cola en la implementación SCSI. 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.


· Overlayfs
El sistema de archivos overlayfs permite combinar dos sistemas de archivos, uno "superior" y otro "inferior", en un sólo punto de montaje. Las modificaciones a ese sistema de archivos mezclado se hacen en el sistema de archivos superior. Este sistema tiene muchos usos, pero es conocido sobre todo por ser utilizado en los live-CD, en los que se monta una imagen del sistema operativo como sistema de archivos inferior, y un sistema de archivos en RAM, en el que se hacen las modificaciones, como superior; de ese modo se puede utilizar el live-CD como un sistema real. Overlayfs se diferencia de otros mecanismos de unión de sistemas de archivos en que tras abrirse un archivo todas las operaciones van a los sistemas de archivos inferiores o superiores, lo cual simplifica la implementación y permite tener rendimiento nativo.

Es posible que ambos arboles de directorio estén en el mismo sistema de archivos. El sistema de archivos inferior puede ser cualquier sistema de archivos soportado por Linux y no necesita permisos de escritura. El sistema de archivos inferior puede ser otro overlayfs. El sistema superior será normalmente escribible y si lo es debe permitir la creación de atributos extendidos trusted.*, y debe retornar un d_type válido en readdir(), de modo que NFS no está permitido.

· Radeon: mapeado de espacio de usuario en la memoria de vídeo
Linux 3.16 añadió la posibilidad de mapear direcciones de espacio de usuario en la memoria de vídeo para chips Intel. En esta versión, también se ha incorporado en el driver Radeon soporte de esta característica, que permite 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.

· Llamada al sistema bpf() para programas de máquina virtual eBPF

La llamada al sistema bpf() es un multiplexador para una serie de operaciones en eBPF que pueden ser descritas como "máquina virtual universal en el kernel". eBPF es similar al Berkeley Packet Filter que se usa para filtrar paquetes de red. eBPF "extiende" el BPF clásico de múltiples maneras incluyendo la capacidad de hacer llamadas a funciones de ayuda en el kernel y acceso a estructuras de datos compartidas. Los programas pueden ser escritos en un C restringido que se compila a bytecode eBPF y se ejecuta en la máquina virtual eBPF o se convierte en instrucciones nativas con un JIT.

Los programas eBPF son similares a módulos de kernel. Los carga un proceso de usuario y se descargan automáticamente cuando el proceso sale. Cada programa eBPF es un conjunto de instrucciones seguro. El verificador eBPF determina estáticamente que el programa termina y es seguro de ejecutar. Los programas pueden estar conectados a diferentes eventos. Estos eventos pueden ser paquetes o eventos de trazado. Más allá de almacenar datos los programas pueden llamar a funciones de ayuda del kernel que podrían, por ejemplo, volcar la pila, invocar trace_printk u otras ayudas para la depuración del kernel.

· TCP: algoritmo de congestión Data Center TCP
Esta versión añade el algoritmo de control de congestión Data Center TCP (DCTCP). Se trata de un algoritmo diseñado para optimizar el rendimiento de las redes de centros de datos, centrándose en proporcionar: alta resistencia a las ráfagas de tráfico alto, baja latencia y alto rendimiento.

· Geneve: Protocolo de encapsulación para virtualización
El advenimiento de las redes virtualizadas ha provocado un aumento del interés y de la creación de nuevos protocolos. Los protocolos de túneles existentes han intentado resolver diferentes aspectos de los nuevos requerimientos de las redes virtualizadas, pero pronto quedaban desfasados. Linux 3.18 añade Geneve, un protocolo que intenta evitar esos problemas proporcionando un protocolo para túneles que proporciona redes de nivel 2 sobre redes de nivel 3.

· Mejora del rendimiento de red: agrupación del procesamiento de la cola de envío
Esta versión añade soporte para retrasar el procesado de SKBs (buffers de sockets). Procesar la cola de envíos del driver de la tarjeta de red es costoso, de modo que es posible compartir ese coste acumulando varios búfers y procesándolos al mismo tiempo. Varios drivers han incorporado esta característica: i40e, igb, ixgbe, mlx4, virtio_net, se añadirán más en futuras versiones.

· Soporte para foo-sobre-UDP
Esta versión añade soporte para encapsular cualquier protocolo IP sobre UDP incluyendo túneles (IPIP, GRE, SIT).

La motivación para esta funcionalidad es que el hardware y software de red existente están optimizados para UDP y pueden utilizarse para proporcionar un mejor servicio. En esta versión se ha añadido soporte para usar foo-sobre-UDP en GRE, IPIP, y SIT. Se ha añadido un nuevo comando "ip fou" en las nuevas versiones de ip para usar esta característica.

· Soporte de SCSI multicola opcional
Linux 3.13 añadió un nuevo diseño para la capa de bloques que permitía procesar múltiples colas IOs en paralelo. Esta característica, sin embargo, no era transparente y requería adaptación de los drivers. En esta versión, se ha añadido soporte para esta capa multi-cola en la capa SCSI (usada por los drives ATA y SATA) como una opción

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

16 de noviembre de 2014

Android 5, una versión para olvidar las anteriores

Ayer flaseé Android 5.0 a mi Nexus 4 -un modelo que ya tiene dos años-, y he podido comprobar como todas las cosas buenas que se dicen sobre esta nueva versión son ciertas. La interfaz es mejor, el uso ingente de animaciones por doquier no me resulta molesto porque se utilizan para explicar visualmente las transiciones de los elementos de la interfaz, el uso de batería ha mejorado enormemente, y mejorará más a medida que las aplicaciones hagan uso de las nuevas APIs, las notificaciones, runtime ART, etc. Me he topado ya con un par de crashes de aplicaciones del sistema, pero nada que se salga de lo habitual en una version .0.

Lo paradójico de Android 5.0 es que las mejoras son tan buenas, que ponen en evidencia una verdad impopular: Android 4.x era una castaña.

Seguramente muchos hayan leído alguna vez el mote burlesco "lagdroid", referente a la lentitud y falta de respuesta de la interfaz de Android. ¿Cuántas veces han escuchado a fans de Android decir que en esta nueva subversión, en este nuevo teléfono último modelo, el "lag" pasaba a ser historia? Pues no, el lag seguía ahí. Cierto, la respuesta de la interfaz mejoró mucho en las últimas versiones (especialmente con las mejoras de 4.3). Pero no dejó de existir.

La notable mejora de rendimiento del nuevo runtime java ART -que estaba en 4.4, pero sólo opcional en el menú para desarrolladores- es la mejor prueba de que hasta ahora, usar Android era usar un sistema lento. El propio Google cita, como característica de ART en 5.0, una interfaz con mejor respuesta. Y en esta versión se incorpora también un proceso dedicado a hacer las animaciones, para que sean siempre fluidas. Y hay que tener en cuenta que el salto de Dalvik a ART sea tan grande no implica necesariamente que ART tenga un rendimiento sobresaliente. Mientras tanto, los usuarios de iPhone y Windows Phone han disfrutado de una interfaz con buena respuesta desde el primer día.

Lo mismo se puede decir del uso de batería: Las mejoras de 5.0 son brutales (en gran parte, por el cambio a ART), y no responden a un paso adelante respecto a otros sistemas, sino a una puesta al día de Android.

Digo todo esto porque existe un intenso fenómeno de fandroidismo en Internet y un desprecio hacia Apple y a sus productos, que se venden a precio de oro a pesar de ser menos versátiles y menos capaces; y también hacia Windows Phone. Está muy bien usar Android -yo también lo uso-, pero el elitismo fandroidero sobra. Vistos los defectos de anteriores versiones de Android, comprar un iPhone o Windows Phone estaba plenamente justificado, y probablemente lo siga estando en muchas facetas. Aunque gracias a Android 5, eso si, en muchas menos.

5 de noviembre de 2014

Apple Pay, un ejemplo del valor de la integración

El pasado lunes 20 de Octubre empezó a funcionar Apple Pay, el sistema de pagos NFC para el iPhone 6. Es difícil predecir si va a tener éxito en EE.UU., donde Android es, también allí, mayoría; pero hay optimismo. Sin embargo, muchas reacciones en Internet han sido recordar que los pagos NFC ya están inventados, que Google Wallet existe desde 2011, y que si Apple Pay tiene éxito será debido al marketing, ese mago oculto al que Apple parece deber el no estar en la bancarrota. Se equivocan, Apple Pay no sólo es interesante, sino que es un buen ejemplo del estilo de trabajo de integración vertical de Apple.

Hay que empezar diciendo que hay mucha confusión sobre qué son exactamente los pagos móviles vía NFC. Muchos -Apple la primera- se empeñan en describirlo como algo de ciencia ficción, vanguardia tecnológica que casi debería hacernos llorar de emoción al usarla. Hay que dejarse de tanto humo: esto no es más que pagar las cosas, pero de otra manera. Pagar cosas no es emocionante, y no lo será nunca. En rigor, Apple Pay no es más que una manera de automatizar el uso de tarjetas de crédito, y el grandioso progreso que puede traer a la vida diaria es el de no cargar en el bolsillo con tarjetitas de plástico y/o dinero en efectivo: algo más bien poco importante. Los pagos NFC son una mejora marginal, una pequeña comodidad añadida, no una revolución.

Respecto a la fama de inventor, puede que los pagos NFC ya estén inventados, pero aparte del este asiático y otros países anecdóticos, apenas están extendidos, y desde luego estamos lejísimos de ver un país en el que una generación de niños crezca sin saber qué es una moneda. EE.UU., el imperio del consumo, no es una excepción. Quien popularice el uso de pagos telefónicos vía NFC será considerado allí como su inventor, guste o no.

Yendo al grano: ¿Qué tiene Apple Pay de interesante? Lo que más destaca es su seguridad y anonimato. En el mundo actual las empresas hay robos de millones de tarjetas que pueden usarse para fraude (especialmente en EE.UU., donde aun usan tarjetas de banda magnética). Para solucionar ese y otros problemas Apple Pay usa algo llamado "tokenización" (que también utiliza Google Wallet). Al activar una tarjeta, la red de tarjetas genera un número aleatorio, el "token". Este token se utiliza como identificador para hacer transacciones en lugar del número de tarjeta, evitando que las empresas tengan los números de tarjeta de sus clientes, e impidiendo así que alguien pueda robarlos y cargar gastos a la tarjeta.

Naturalmente, la mejora no está tan sólo en cambiar un número de tarjeta por uno de token, de ser así los atacantes pasarían a cargar pagos al token. La mejora está en que no es posible hacer una transacción sólo con el token, es necesario también un código específico llamado criptograma. Este criptograma, que posteriormente es cifrado con claves públicas proporcionadas por la red de pagos, incluye varios datos, entre ellos uno que identifique al dispositivo que usa el token. Pero además, cada criptograma sólo es válido para una transacción. El objetivo es que cada token sólo pueda usarse con una tarjeta determinada y con un dispositivo determinado para una transacción determinada. Los ataques a las bases de datos de las empresas pasan a ser inútiles, los datos extraídos de ahí no valen para nada, la única manera de cargar pagos ilícitos es atacar el teléfono de los usuarios e intentar conseguir el token y las claves asociadas, que ya de por si no es fácil. Atacar a millones de usuarios pasará a ser prácticamente imposible.

La implementación de todo este sistema en el iPhone se hace en gran medida en dos chips de hardware, uno de ellos el Secure Element, un chip para hacer pagos seguros utilizado en muchos dispositivos, como sensores NFC. Este chip almacena la información del token de las tarjetas de crédito y las claves de las redes de pago. El otro chip es el Security Enclave, específico de Apple (y que curiosamente funciona con un microkernel L4), dedicado a almacenar y procesar información crítica, como la identificación de las huellas dactilares de Touch ID. El encargado de hacer la transacción, a través del sensor NFC, es el Secure Element, pero sólo permite hacer pagos si lo confirma el Security Enclave, algo que hace tras comprobar que la huella dactilar del Touch ID se corresponde con las que tiene almacenadas. Todo el proceso del pago se hace por hardware, la CPU del iPhone jamás procesa datos sobre tokens o claves de ningún tipo, lo cual dificulta conseguir esos datos fácilmente mediante vulnerabilidades en iOS (el Secure Element no se puede acceder directamente).

¿Dónde están las ventajas sobre Google Wallet? Una de las más importantes es que muchas multinacionales de telecomunicaciones han vetado el chip Secure Element de los teléfonos que venden: quieren que el chip esté en la tarjeta SIM y así abusar de su posición para crear sus propias plataformas de pagos y controlar el sector . Esto no es culpa de Google, pero es consecuencia del modelo de Android, y Google Wallet se ha visto obligado a incorporar una implementación de un Secure Element virtual por software que puede conectarse a un Secure Element "real" que está en la nube de Google Wallet. Este ha sido uno de los principales obstáculos de Google Wallet. Apple, en cambio, controla su hardware, así que añade un chip Secure Element y punto, sin que nadie rechiste.

Aparte de esto, ¿dónde están la ventaja de Apple Pay? ¿No tiene Google Wallet también tokenización? Si, pero Apple Pay tiene aquí otra ventaja: la privacidad. En Apple Pay el número de tarjeta de crédito o los detalles completos de la transacción no están disponibles ni en el iPhone ni en los servidores de Apple Pay, ni se utilizan en ningún momento a lo largo de una transacción, ni Apple sabe ni puede saber nada de lo que compras en ningún momento. Con Google Wallet, Google tiene acceso a tus números de tus tarjetas de crédito -puedes verlas en la web- y a todas tus transacciones: datos que Google accederá sin complejos para personalizar anuncios. A grandes rasgos, Apple Pay sólo es un wrapper del sistema financiero actual, proporciona lo necesario para que las tarjetas de crédito hagan pagos NFC, pero más allá de facilitar el pago no se mete ni mete las narices. Google Wallet en cambio intenta ser un intermediario, gestionando los pagos por si mismo. Incluso te proporciona una tarjeta virtual creada por la misma Google, a la que puedes cargar pagos que posteriormente sean cargados a tus tarjetas reales. ¡Incluso puedes tener un balance en tu cuenta de Google Wallet y almacenar dinero, prácticamente equivalente a una pequeña cuenta de banco!

Estos últimos detalles no son irrelevantes y no tienen sólo que ver con la privacidad. La consecuencia del modelo elegido por Google es que los bancos y las redes de tarjetas no tienen grandes incentivos para apoyarlo, cuando no a verlo como un competidor directo. No ha habido grandes bancos asociados a Google Wallet, ninguno está desesperado por su falta de popularización.

Apple ha sabido comprender que el sistema financiero sólo aceptaría una solución para pagos con teléfono móvil que les incluya, y no pretenda quitarles del medio o ignorarles. Visa ha tenido alrededor de mil personas trabajando en Apple Pay y en la adaptación al modelo de tokenización, y el banco JPMorgan 300. Es más, las redes de tarjetas y los bancos de EE.UU están poniendo anuncios en la televisión para animar a la gente a usar Apple Pay con ellos. Literalmente, están haciendo publicidad, ¡gratis!, a Apple, y además están facilitando a las empresas la renovación de terminales de pago que incluyan soporte NFC.

En resumidas cuentas, Apple Pay parece haber atajado el importantísimo problema circular que tienen los pagos NFC: no pueden usarse masivamente por escasez de terminales NFC en el mundo real, y al mismo tiempo hay una escasez de terminales NFC debido a la escasez de gente interesada en usarlo. Han sabido diseñar un buen sistema de pagos y, al mismo tiempo, han sido capaces de colaborar con el sistema financiero y encontrar una solución que haga que la adopción masiva de Apple Pay sea beneficiosa para todas las partes. Todo ello sin dejarse chantajear por las operadoras, tan interesadas en controlar todo lo que circula por sus redes, y con una interfaz sencilla. Digan lo que digan, es un producto bien hecho, y es muy posible que sea el detonante que haga avanzar los pagos NFC, incluso en España. Y entonces la gente dirá que Apple ha inventado los pagos NFC, guste o no.

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í.