Notebookcheck Logo

Unos documentos filtrados revelan que Google planeó y posteriormente eliminó una función de seguridad clave del Pixel 11 para GrapheneOS

A la serie Pixel 11 se le ha eliminado una característica de seguridad clave que GrapheneOS considera crucial, pero ¿es esa toda la historia? (En la imagen, el Pixel 11 Pro)
ⓘ Google
A la serie Pixel 11 se le ha eliminado una característica de seguridad clave que GrapheneOS considera crucial, pero ¿es esa toda la historia? (En la imagen, el Pixel 11 Pro)
GrapheneOS afirma que no será compatible con el Pixel 11 de Google debido a que el chip Tensor G6 carece de la Memory Tagging Extension (MTE), una función de seguridad de hardware fundamental para este sistema operativo centrado en la privacidad. El análisis del gestor de arranque y los documentos filtrados de Google sugieren que la MTE se eliminó deliberadamente, lo que ha llevado a GrapheneOS a recomendar modelos Pixel más antiguos, al tiempo que estudia la posibilidad de ofrecer compatibilidad con un próximo modelo insignia de Motorola.

GrapheneOS, la variante de Android con privacidad reforzada que se ha incluido en exclusiva en los teléfonos Pixel de Google durante años, afirma que no puede ofrecer compatibilidad adecuada con la nueva serie Pixel 11. Tras una semana intentando forzar la adaptación del sistema, el equipo descubrió que al chip Tensor G6 del Pixel 11 le falta compatibilidad de hardware con una función denominada «Memory Tagging Extension» (MTE), una característica de seguridad con la que cuentan todos los chips Pixel desde el Pixel 8 en 2023.

Esto es, básicamente, lo que hace MTE: la memoria de su teléfono es una enorme cuadrícula de pequeñas casillas de almacenamiento. Muchos exploits funcionan engañando a una aplicación para que lea o escriba en la casilla equivocada, aquella a la que no debía acceder. MTE lo impide colocando una nota adhesiva invisible en cada bloque de memoria de 16 bytes y en cada puntero autorizado para acceder a él. Si las notas adhesivas no coinciden cuando un programa intenta leer o escribir, el chip frena en seco, terminando el proceso en lugar de permitir silenciosamente que la vulnerabilidad se ejecute. GrapheneOS utiliza MTE en todo su sistema operativo y sostiene que elimina categorías enteras de intentos de piratería remota antes incluso de que puedan comenzar. El equipo afirma que parece que Google ha eliminado la tecnología MTE del Pixel 11 para ahorrar dinero; Google no ha hecho comentarios al respecto. GrapheneOS recomienda ahora a los usuarios que se salten el Pixel 11 y compren en su lugar un Pixel 8, 9 o 10 si desean utilizar GrapheneOS.

Lo que realmente ahorra a Google la eliminación del MTE

Un artículo de investigación elaborado por investigadores de la Universidad de Texas en Austin, la Universidad de California en Berkeley, Google y Ampere Computing (arXiv:2601.11786) nos da una idea de lo que cuesta implementar la MTE en hardware real, lo que también nos indica cuánto ahorra una empresa al prescindir de ella.

Las propias «notas adhesivas» son bastante pequeñas: 4 bits por cada 16 bytes de memoria, lo que supone una sobrecarga de aproximadamente el 3,125 %. El reglamento de ARM no especifica dónde deben almacenar los fabricantes de chips estas «notas adhesivas», solo que deben existir en algún lugar. Por eso, las empresas lo hacen de forma diferente. El propio diseño de referencia de ARM reserva un bloque específico de RAM y realiza dos operaciones de recuperación de memoria independientes en caso de fallo de caché: una para los datos y otra para su «nota adhesiva». Ampere, fabricante de chips para servidores, en cambio, incorpora las notas en los bits que normalmente se utilizan para la corrección de errores y recupera los datos y la nota juntos en una sola operación. Ninguno de los dos enfoques es más correcto; ARM incorporó esa flexibilidad a propósito.

El mayor coste no es el 3,125 % adicional de memoria que se necesita en el chip, sino el trabajo extra que el chip tiene que realizar en cada acceso a la memoria. Cada vez que su teléfono accede a la memoria, tiene que comprobar esa pequeña etiqueta, lo que requiere circuitos de comparación específicos. Asignar etiquetas de forma aleatoria para que los atacantes no puedan predecirlas requiere un generador de números aleatorios integrado en el chip, y resulta difícil construir uno rápido con suficiente entropía sin tomar atajos. Algunas instrucciones especiales para escribir etiquetas necesitan su propia ruta a través del chip, en lugar de reutilizar la ruta normal.

Deterioro del rendimiento al activar diferentes modos de MTE en el Pixel 8 en la prueba SPEC CPU INT 2006

Piense en un núcleo de CPU «out-of-order» como una cocina en la que varios cocineros trabajan por adelantado en diferentes partes de un pedido a la vez, no necesariamente en el orden en que se recibió el pedido, siempre y cuando nada dependa de algo que aún no esté listo. Así es como, normalmente, un núcleo moderno «fuera de orden» mantiene su velocidad: no se queda esperando; trabaja en lo que pueda mientras los pasos más lentos se ponen al día.

El modo SYNC estricto de MTE complica una parte de esa cocina: la escritura en la memoria. Normalmente, un núcleo puede escribir datos en la memoria y seguir trabajando en las siguientes instrucciones mientras esa escritura finaliza en segundo plano. Sin embargo, en el modo SYNC de MTE, cada escritura requiere primero que se compruebe su pequeña etiqueta y se confirme su validez, y hasta que no se apruebe esa comprobación, el núcleo no puede pasar a la siguiente escritura. No es que toda la cocina se paralice: la preparación (lecturas, cálculos, ramificaciones, etc.) continúa sin problemas y fuera de orden. Es específicamente el paso de «dejar el plato terminado en la mesa» el que ahora tiene que realizarse de uno en uno, en orden, mientras se espera una comprobación de la etiqueta cada vez. El código que escribe en la memoria repetidamente en un bucle cerrado nota este efecto constantemente, lo cual explica exactamente por qué algunas pruebas de rendimiento se ralentizaron hasta 6,64 veces. El código que se dedica principalmente a leer, calcular o realizar ramificaciones apenas lo nota, ya que la parte de la canalización que se ha ralentizado no es aquella de la que depende.

Incluso en el modo ligero de MTE, el núcleo «Big» estándar siguió registrando ralentizaciones de hasta 1,82 veces, y este es precisamente el modo que utiliza actualmente la propia función de Protección Avanzada de Google. Por su parte, tanto el chip para servidores de Ampere como el nuevo M5 de Apple apenas notaron que MTE estaba activado, con una sobrecarga media de solo entre el 2 % y el 3 %, y una ralentización máxima del 10 %. Esa diferencia demuestra que estas ralentizaciones no son una ley ineludible de la física; reflejan lo bien (o mal) que los ingenieros de un chip concreto han implementado la función. Y, conociendo a Tensor, no esperamos gran cosa de él.

Alguien ha comprobado el gestor de arranque y, efectivamente, ha desaparecido.

Ahora existen pruebas que van más allá de las propias declaraciones de GrapheneOS al respecto. Un desarrollador conocido como Romashka, que también gestiona el canal de Telegram Mystic Leaks, ha analizado a fondo los bootloaders del Pixel 10 (nombre en clave interno «deepspace») y del Pixel 11 («spacecraft») utilizando un desensamblador, una herramienta que convierte el código compilado de nuevo en algo semilegible. En el gestor de arranque del Pixel 10, «MTE» aparece por todas partes: nombres de funciones como «gs_mte_enable», mensajes de depuración como «MTE cmdline override ON» e incluso comandos ocultos como «fastboot_oem_cmd_mte».

El gestor de arranque del Pixel 10 en comparación con el del Pixel 11, del que se ha eliminado toda mención a MTE
ⓘ Romashka
Comparación de los bootloaders del Pixel 10 y el Pixel 11, con todas las menciones a MTE eliminadas de este último

Si busca lo mismo en el gestor de arranque del Pixel 11, no encontrará nada. Ni un solo rastro. Esa es una diferencia bastante significativa: si Google simplemente hubiera pulsado un botón para desactivar MTE, cabría esperar encontrar esos nombres de funciones y mensajes en el código, aunque estuvieran sin utilizar. Su ausencia total sugiere que el código fue eliminado por completo, no solo desactivado. Eso respalda exactamente lo que afirmó GrapheneOS tras abandonar su adaptación.

Los documentos internos filtrados sugieren que MTE estaba previsto para el Tensor G6, pero que posteriormente se descartó.

Varios documentos internos filtrados del equipo de chips de Google, conocido internamente como «gChips» desde hace unos años, apuntan a que la tecnología MTE se barajó en una fase temprana y posteriormente se eliminó de forma deliberada.

Una diapositiva muy antigua de la hoja de ruta de «Malibu», el nombre en clave interno del G6, incluye la MTE como parte de las especificaciones básicas del chip, apareciendo como «Hela (la interconexión de núcleos propia de Google) + MTE en SLC». Esto apunta a otra diapositiva filtrada titulada «Especificación de la arquitectura de la caché a nivel de sistema de Google (GSLC)», cuyo historial de revisiones se remonta a mayo de 2022. En una lista de «Características P0» —que significa máxima prioridad—, el documento incluye «Compatibilidad con MTE» como segundo elemento, tachado en rojo. No sabemos cuándo se añadió la tachadura, pero sí sabemos que Google tenía prevista una implementación diferente de MTE para el G6 y la había estado desarrollando antes de cancelarla por razones desconocidas.

La diapositiva filtrada de gChips en la que se detallan las especificaciones previstas para el Tensor G6, cuyo nombre en clave era «Malibu» antes del retraso de la GPU.
ⓘ gChips
La diapositiva filtrada de gChips en la que se detallan las especificaciones previstas para el Tensor G6, cuyo nombre en clave era «Malibu» antes del retraso de la GPU.
Se ha dejado de ofrecer soporte para MTE en alguna fase del desarrollo del nuevo sistema SLC
ⓘ gChips
Se va a eliminar la compatibilidad con MTE durante el desarrollo del nuevo sistema SLC

La respuesta de Motorola tiene un nombre: Wukong

Por otra parte, GrapheneOS está ultimando un acuerdo con Motorola para llevar el sistema operativo a un teléfono que no sea de la gama Pixel por primera vez, mientras que Qualcomm ha comenzado a incorporar compatibilidad con MTE en sus últimos chips, incluido el Snapdragon 8 Elite Gen 5.

NotebookCheck ha sabido que Motorola está trabajando en un teléfono insignia cuyo nombre en clave interno es «Wukong», basado en el próximo chip insignia de Qualcomm, el Snapdragon 8 Elite Extreme Gen 6 (SM8975), que se presentará en su totalidad en la Snapdragon Summit el 22 de septiembre. Por el momento, es el único dispositivo de Motorola previsto en torno a ese chip. Si «Wukong» acaba siendo el teléfono de lanzamiento de GrapheneOS con Motorola, será el primer teléfono en combinar compatibilidad plena con MTE, un chip insignia de Qualcomm y compatibilidad con GrapheneOS, algo que actualmente no se puede obtener en un Pixel 11, independientemente del precio que se pague.

Cabe hacer la advertencia habitual: en esta fase tan temprana del desarrollo, las especificaciones e incluso el nombre en clave «Wukong» proceden de material interno y aún podrían cambiar antes de que se haga oficial. Motorola no ha confirmado la existencia de este teléfono.

Por último, pero no por ello menos importante: ¿realmente reviste tanta importancia la traducción técnica para la mayoría de las personas?

Para el usuario medio que adquiera un Pixel 11, no creo que la pérdida de MTE sea el desastre que este artículo podría dar a entender.

El MTE es probabilístico, no una garantía absoluta. Existe una probabilidad de 1 entre 16 de que un acceso fuera de límites determinado eluda por completo la comprobación de etiquetas, y la investigación citada en el mismo artículo (TikTag) rompió el secreto de las etiquetas en hardware real de Pixel mediante la ejecución especulativa, lo que significa que ni siquiera la protección que ofrece es, en la práctica, tan fiable como sugiere la proporción «15/16». Y, lo que es más importante, casi ninguna de las vulnerabilidades por las que un propietario medio de un teléfono debe preocuparse realmente son, en primer lugar, errores de seguridad de la memoria. El phishing, los permisos maliciosos de las aplicaciones, el intercambio de tarjetas SIM, el stalkerware y la apropiación de cuentas: nada de eso tiene que ver con lo que protege el MTE. Incluso el propio GrapheneOS admite que la cobertura para aplicaciones de terceros es opcional y rara vez se utiliza; Signal no la activa.

Donde el MTE realmente demuestra su valía es en el modelo de amenazas para el que se ha diseñado el propio GrapheneOS: costosas cadenas de exploits de «cero clics» que dependen de la fiabilidad, del tipo que se venden por millones de dólares y se utilizan casi exclusivamente contra periodistas, disidentes y objetivos gubernamentales, no contra el consumidor medio. Ese es un caso de uso real e importante. Simplemente es un caso muy concreto. Un teléfono que se bloquea en lugar de ser controlado silenciosamente supone una gran diferencia si es usted un objetivo de alto riesgo vigilado por un actor estatal. Resulta mucho menos relevante si su riesgo real es perder el teléfono en un bar o hacer clic en un enlace malicioso en un mensaje de texto. Practicar una buena seguridad operativa (OPSEC), utilizar contraseñas únicas, evitar los códigos QR aleatorios y no dispersar su información personal por todas las páginas web que la solicitan ofrece a la mayoría de las personas una protección más efectiva en el mundo real que cualquier función de seguridad de memoria a nivel de silicio que pueda existir jamás.

Nada de eso hace que la regresión en el chip del Pixel 11 deje de ser una noticia. La base de usuarios de GrapheneOS es precisamente el colectivo para el que esto es más importante, y perder el soporte para toda una generación de Pixel supone un duro golpe para ese proyecto. Pero conviene ser sinceros: la tecnología MTE se percibe más bien como una medida de mitigación de gran valor para empresas o usuarios de alto riesgo que, por casualidad, ha llegado a los chips de consumo, que como una función cuya ausencia vaya a notar alguna vez el usuario medio que compre un Pixel 11. Y hay cierta ironía en cómo Google ha llegado a esta situación: fue la propia empresa la que impulsó la adopción generalizada de MTE en primer lugar, al incorporarlo en Tensor antes que casi cualquier otro fabricante de Android, financiar la investigación al respecto y desarrollar todo un modo de seguridad en torno a él. Ahora, sus propios documentos internos sugieren que incorporó MTE en su próximo chip, lo describió con detalle y, a continuación, lo eliminó discretamente antes del lanzamiento. Nadie superó a Google en ingeniería en este caso. Fue la propia empresa la que, con su ingeniería, se quedó sin esa función.

Google LogoAdd as a preferred source on Google
Mail Logo
> Análisis y pruebas de ordenadores portátiles y móviles teléfonos > Noticias > Archivo de noticias > Archivo de noticias 2026 08 > Unos documentos filtrados revelan que Google planeó y posteriormente eliminó una función de seguridad clave del Pixel 11 para GrapheneOS
Bùi Giang, 2026-08-31 (Update: 2026-08-31)