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

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í