Actividad de GrapheneOS en redes sociales
- GrapheneOS forma parte de una red social descentralizada basada en Mastodon.
- Opera un servidor de GrapheneOS para la cuenta oficial del proyecto y para miembros del proyecto.
- El servidor cuenta con 5 usuarios activos.
Soporte de etiquetado de memoria por hardware en Pixel 8 y Pixel 8 Pro
- Descubrieron un bug de daño de memoria en Bluetooth LE presente en Android 14 QPR2 gracias al soporte de etiquetado de memoria por hardware en Pixel 8 y Pixel 8 Pro.
- Actualmente están investigando este bug para corregirlo o encontrar una solución temporal que desactive de forma provisional la funcionalidad recién introducida.
Desactivar el etiquetado de memoria no es una solución temporal adecuada
- Solo ocurre con ciertos dispositivos Bluetooth LE, no con todos los dispositivos Bluetooth.
- Desactivar el etiquetado de memoria para este proceso no es aceptable ni siquiera como solución de corto plazo.
Desarrollo de un parche para el bug de Android 14 QPR2
- Encontraron un bug de use-after-free relacionado con Bluetooth LE y desarrollaron un parche.
- La prioridad es incluir la corrección en la versión de GrapheneOS y planean reportarlo como un bug de seguridad de Android.
- También se espera que se resuelvan problemas de audio BLE.
Verificación de la corrección del bug
- Un usuario con Samsung Galaxy Buds2 Pro reprodujo el problema en modo Bluetooth LE y confirmó que la corrección funciona.
- Este problema también afecta al Pixel OS base.
- GrapheneOS lo detectó mediante el soporte de etiquetado de memoria de hardened_malloc y añadió una función para enviar notificaciones e informes de fallos de MTE.
Reportado como bug de seguridad
- El problema de use-after-free fue reportado como bug de seguridad (b/328916844 para empleados de Google).
- Se proporcionó un parche inicial mínimamente invasivo.
- El código requiere una gran refactorización y no debería usar punteros sin procesar, pero quieren evitar introducir nuevos bugs con un parche apresurado.
Portar el código de Bluetooth a Rust
- Android ha portado mucho código de Bluetooth a Rust.
- Se deben dedicar más recursos a portar también el resto del código a Rust.
- Hay que probar builds con HWASan y MTE en diversos entornos de uso real.
La importancia de MTE
- Los Pixels ofrecen una importante función de seguridad de hardware llamada MTE para ahorrar 3.125% de uso de memoria/caché al no activarla en el OS.
- GrapheneOS activa MTE por defecto para el OS base y para apps instaladas por el usuario con compatibilidad conocida.
- Los usuarios pueden activar MTE para todas las apps instaladas por el usuario desde la configuración.
Implementación de MTE en GrapheneOS
- GrapheneOS ofrece una mejor implementación de MTE como parte de hardened_malloc, usando etiquetas aleatorias estándar y una etiqueta dedicada para
free.
- Corrigieron la integración de Chromium y planean mejorar PartitionAlloc.
Uso de MTE en GrapheneOS
- GrapheneOS es la primera plataforma en usar MTE en producción.
- El navegador Vanadium es el primero en usar MTE en producción.
- Planean añadir stack MTE, mejorar PartitionAlloc y crear un nuevo slab MTE para el kernel.
Agradecimiento de los usuarios
- Los usuarios expresaron agradecimiento por la función de desactivación automática de Bluetooth de GrapheneOS.
Opinión de GN⁺
- GrapheneOS es un sistema operativo centrado en la seguridad basado en Android, y mostró cómo detectó y respondió rápidamente a un bug de daño de memoria encontrado en dispositivos Pixel recientes.
- Esta respuesta rápida muestra bien las ventajas de la comunidad de código abierto y contribuye a ofrecer un entorno móvil más seguro para los usuarios.
- Portar código a Rust, un lenguaje que refuerza la seguridad de memoria, es un paso importante para fortalecer la seguridad a largo plazo.
- Activar MTE, una función de seguridad basada en hardware, es una forma eficaz de reforzar la seguridad minimizando la pérdida de rendimiento.
- Al adoptar esta tecnología, se debe considerar la compatibilidad con las aplicaciones existentes, y se requieren pruebas y mantenimiento adecuados para fortalecer la seguridad.
1 comentarios
Opiniones en Hacker News
La extensión de etiquetado de memoria no está habilitada por defecto, pero cualquiera puede activarla desde las opciones de desarrollador. Se puede activar una sola vez al querer probar una app específica, o mantenerla activa hasta que se desee.
Se espera la respuesta de usuarios de Graphene OS sobre si instalar Graphene OS es difícil, si se necesita un cable especial, si hay que conocer bien los dispositivos Android, o si basta con seguir las instrucciones.
Solicitan compartir experiencias sobre si usar Graphene OS en el día a día es incómodo, si el teléfono falla con frecuencia al punto de requerir varios días de depuración, y si las apps bancarias funcionan.
Se preguntan cómo el equipo de Pixel justifica la decisión de no habilitar en el SO una función crítica de seguridad de hardware (MTE) para ahorrar 3.125% de uso de memoria/caché. Heap MTE casi no tiene sobrecarga de rendimiento en modo asíncrono, y en modo asimétrico es más barato que protecciones existentes como SSP, cuya efectividad disminuye cada vez más.
Preguntan por una comparación entre las tecnologías de seguridad MTE y CHERI.
GrapheneOS está tan por delante de otras opciones en términos de seguridad que elegir algo distinto de hardware Pixel resulta cuestionable. Aun así, expresan un fuerte deseo de tener una batería reemplazable.
Preguntan si computadoras de placa única como las Raspberry Pi más recientes implementan Arm MTE.
Esperan hardware mainstream que pueda resolver problemas de corrupción de memoria, como la arquitectura de etiquetas de memoria del hardware Solaris SPARC de 2015 o anterior. Sostienen que estos problemas en su mayoría son causados por desarrolladores con poca habilidad técnica.
En 2024 hacen falta sistemas operativos, aplicaciones y herramientas que hereden el espíritu de seL4, pero verificados formalmente de manera más estricta. Usar sistemas de codebases sobreingenierizadas y no suficientemente probadas como los actuales implica riesgos para los usuarios y ofrece una gran superficie de ataque para bugs, malware y hackeos.
Si no se ofrece una experiencia de usuario (UX) limpia e integrada junto con funciones utilizables, toda la ingeniería es en vano.
Android ya ha migrado una parte considerable del código de Bluetooth a Rust. Esto demuestra que se deberían dedicar más recursos a migrar más código a Rust.
Alguien con años de experiencia trabajando en C y C++, pero sin experiencia en Rust, se pregunta cuánto refactoring se necesita en el proceso de portar de C a Rust. Preguntan cómo lo está abordando Google: si intenta hacer una "traducción" lo más directa posible, o si lo ve como una oportunidad para una reescritura/refactorización importante.
Hay curiosidad sobre si el stack de Bluetooth de Android puede usarse en sistemas de escritorio con distribuciones estándar de Linux.