Kiszivárgott dokumentumok szerint a Google tervezte, majd végül elvetette a Pixel 11 egyik kulcsfontosságú biztonsági funkcióját a GrapheneOS számára

A GrapheneOS, az adatvédelmi szempontból megerősített Android-fork, amelyet évek óta kizárólag a Google Pixel telefonjain szállítanak, közölte, hogy nem tudja megfelelően támogatni az új Pixel 11 sorozatot. Egy héten át tartó portolási kísérletek után a csapat megállapította, hogy a Pixel 11 Tensor G6 chipjéből hiányzik a hardveres támogatás a Memory Tagging Extension (MTE) nevű funkcióhoz, amely egy olyan biztonsági funkció, amellyel minden Pixel chip rendelkezik a 2023-as Pixel 8 óta.

Az MTE lényegében a következőket teszi: a telefon memóriája egy hatalmas rács, amely apró tárolómezőkből áll. Sok biztonsági rés kihasználása úgy működik, hogy ráveszi az alkalmazást, hogy a nem kívánt mezőből olvasson ki vagy oda írjon, amelyhez nem szabadna hozzáférnie. Az MTE ezt úgy akadályozza meg, hogy láthatatlan jegyzeteket helyez el a memória minden 16 bájtos szeletére és minden olyan mutatóra, amely hozzáférhet azokhoz. Ha a jegyzetek nem egyeznek, amikor egy program olvasni vagy írni próbál, a chip hirtelen fékez, és leállítja a folyamatot, ahelyett, hogy csendben átengedné a támadást. A GrapheneOS az operációs rendszer egészében alkalmazza az MTE-t, és azzal érvel, hogy ez a funkció teljes kategóriákat semmisít meg a távoli hackelési kísérletek közül, még mielőtt azok egyáltalán megkezdődhetnének. A csapat szerint úgy tűnik, hogy a Google költségmegtakarítás céljából eltávolította az MTE-t a Pixel 11-ből; a Google nem kommentálta a dolgot. A GrapheneOS most azt tanácsolja a felhasználóknak, hogy ha a GrapheneOS-t szeretnék futtatni, hagyják ki a Pixel 11-et, és inkább vegyenek Pixel 8-at, 9-et vagy 10-et.

Az UT Austin, az UC Berkeley, a Google és az Ampere Computing kutatói által írt tanulmány (arXiv:2601.11786) képet ad arról, mennyibe kerül az MTE megvalósítása valódi hardveren, ami egyben azt is megmutatja, mennyit takarít meg egy vállalat, ha kihagyja.

Maguk a „sticky note”-ok meglehetősen kicsiek: 4 bit minden 16 bájt memóriára, vagyis körülbelül 3,125%-os többletterhelés. Az ARM szabályzata nem írja elő, hogy a chipgyártóknak hol kell tárolniuk ezeket a „sticky note”-okat, csak azt, hogy valahol létezniük kell. Éppen ezért a vállalatok eltérő módon oldják meg ezt. Az ARM saját referencia-terve egy külön RAM-területet különít el, és cache-hibák esetén két külön memória-letöltést hajt végre: egyet az adatokhoz, egyet pedig a „ragadós jegyzethez”. Az Ampere, amely szerverchipeket gyárt, ehelyett a jegyzeteket a hibajavításhoz általában használt bitekre „ráakasztja”, és az adatokat és a jegyzetet egyetlen műveletben tölti le. Egyik megközelítés sem helyesebb a másiknál; az ARM szándékosan építette be ezt a rugalmasságot.

A nagyobb költséget nem a chipen szükséges plusz 3,125%-os memóriafoglalás jelenti, hanem az a többletmunka, amelyet a chipnek minden memóriához való hozzáféréskor el kell végeznie. Valahányszor a telefonod hozzáfér a memóriához, ellenőriznie kell azt a kis címkét, amihez dedikált összehasonlító áramkörre van szükség. Ahhoz, hogy a címkéket véletlenszerűen rendeljék hozzá, így a támadók ne tudják azokat előre jelezni, egy véletlenszám-generátorra van szükség a chipben, és egy olyan gyorsat, amely elegendő entrópiával rendelkezik, nehéz megépíteni anélkül, hogy kompromisszumokat kellene kötni. Néhány speciális utasítás a címkék írásához saját sávot igényel a chipen keresztül, ahelyett, hogy a normál útvonalat használná újra.

Képzelje el egy nem sorrendben működő CPU-magot úgy, mint egy konyhát, ahol több szakács egyszerre dolgozik a rendelés különböző részein, nem feltétlenül a rendelés beérkezésének sorrendjében, feltéve, hogy semmi sem függ attól, ami még nem készült el. A modern, out-of-order magok általában így maradnak gyorsak: nem várakoznak, hanem azon dolgoznak, amin tudnak, miközben a lassabb lépések felzárkóznak.

Az MTE szigorú SYNC módja azonban keresztbe tesz ennek a konyhának egy részének: a memóriába történő írásnak. Normális esetben egy mag adatokat írhat a memóriába, és tovább dolgozhat a következő néhány utasításon, miközben az írás a háttérben befejeződik. Az MTE SYNC módban azonban minden írásnál először ellenőrizni és érvényesnek nyilvánítani kell a hozzá tartozó kis címkét, és amíg ez az ellenőrzés le nem zárul, a mag nem léphet tovább a következő írásra. Nem arról van szó, hogy az egész konyha leállna: a főzés (olvasás, számítás, elágazás stb.) rendkívül jól folytatódik sorrendtől függetlenül. Kifejezetten a „kész tál letétele” lépésnek kell most egyszerre, sorrendben történnie, miközben minden egyes alkalommal meg kell várni a címke ellenőrzését. Az a kód, amely szűk ciklusban ismétlődően ír a memóriába, ezt folyamatosan érezni fogja, és pontosan ez az oka annak, hogy egyes teljesítménymérések során akár 6,64-szeres lassulás is tapasztalható. Az a kód, amely főként olvas, számol vagy elágazik, alig veszi észre ezt, mert a folyamat azon része, amely lelassult, nem az a rész, amelyre támaszkodik.

Még az MTE könnyített üzemmódjában is a hagyományos „Big” mag akár 1,82-szeres lassulást tapasztalt, és pontosan ezt az üzemmódot használja ma a Google saját Advanced Protection funkciója. Ugyanakkor az Ampere szerverchipje és az Apple új M5-je egyaránt alig vette észre, hogy az MTE be van kapcsolva: átlagosan csupán 2–3%-os többletterhelést okozott, a legrosszabb esetben 10%-os lassulással. Ez a különbség bizonyítja, hogy ezek a lassulások nem valami elkerülhetetlen fizikai törvényszerűségek; hanem azt tükrözik, hogy egy adott chip fejlesztői mennyire jól (vagy rosszul) implementálták a funkciót. És ismerve a Tensort, nem várunk tőle sokat.

Ha ugyanezeket a dolgokat keressük a Pixel 11 bootloaderében, semmit sem találunk. Egyetlen nyomot sem. Ez elég jelentős különbség: ha a Google csak egy kapcsolót húzott volna át az MTE kikapcsolásához, akkor is elvárható lenne, hogy azok a függvénynevek és üzenetek ott legyenek a kódban, csak éppen használaton kívül. Teljes hiánya arra utal, hogy a kódot teljes egészében eltávolították, nem csak kikapcsolták. Ez pontosan alátámasztja azt, amit a GrapheneOS mondott, miután feladta a portolást.

Ettől függetlenül a GrapheneOS éppen véglegesíti a Motorola-val kötendő megállapodást, amelynek keretében az operációs rendszer először jelenik meg egy nem Pixel márkájú telefonon, míg a Qualcomm megkezdte az MTE-támogatás beépítését legújabb chipjeibe, beleértve a Snapdragon 8 Elite Gen 5-öt is.

A NotebookCheck értesülései szerint a Motorola egy „Wukong” belső kódnevű zászlóshajó telefonon dolgozik, amely a Qualcomm következő zászlóshajó chipjére, a Snapdragon 8 Elite Extreme Gen 6-ra (SM8975) épül, és amelyet szeptember 22-én, a Snapdragon Summiton fognak teljes egészében bemutatni. Jelenleg ez az egyetlen Motorola-készülék, amelyet ezen a chipre terveznek. Ha a Wukong végül a GrapheneOS Motorola-val való bevezetésének zászlóshajója lesz, akkor ez lesz az első olyan telefon, amely megfelelő MTE-támogatást, egy Qualcomm zászlóshajó chipet és GrapheneOS-támogatást ötvöz, ami jelenleg a Pixel 11-en sem érhető el, függetlenül attól, hogy mennyit költünk rá.

A szokásos fenntartás helyénvaló: a fejlesztés ilyen korai szakaszában a műszaki adatok, sőt még a „Wukong” kódnév is belső forrásokból származik, és még változhatnak, mielőtt bármi is hivatalossá válna. A Motorola még nem erősítette meg a telefon létezését.

A Pixel 11-et vásárló átlagember számára nem hiszem, hogy az MTE elvesztése olyan katasztrófa lenne, amilyennek ez a cikk beállítja.

Az MTE valószínűségi alapú, nem pedig szilárd garancia. 1 a 16-hoz az esélye annak, hogy egy adott határon kívüli hozzáférés teljesen kicsússzon a címkeellenőrzés alól, és ugyanabban a cikkben idézett kutatás (TikTag) spekulatív végrehajtás segítségével feltörte a címke titkosságát valódi Pixel-hardveren, ami azt jelenti, hogy még az általa nyújtott védelem sem olyan megbízható a gyakorlatban, mint azt a „15/16” arány sugallja. És ami a legfontosabb: az átlagos telefonhasználónak valójában szinte egyáltalán nem kell aggódnia olyan sebezhetőségek miatt, amelyek memóriabiztonsági hibák lennének. Adathalászat, rosszindulatú alkalmazás-jogosultságok, SIM-csere, stalkerware és fiókátvétel – ezek közül egyik sem érinti azt, amitől az MTE védelmet nyújt. Még maga a GrapheneOS is elismeri, hogy a harmadik féltől származó alkalmazásokra vonatkozó védelem opcionális, és ritkán használják; a Signal nem kapcsolja be.

Az MTE valójában ott bizonyítja értékét, ahol a GrapheneOS-t eredetileg is megtervezték: drága, megbízhatóságtól függő, kattintásmentes támadási láncok ellen, amelyek milliókért kelnek el, és szinte kizárólag újságírók, ellenzékiek és kormányzati célpontok ellen használják őket, nem pedig az átlagos fogyasztó ellen. Ez egy valós és fontos felhasználási eset. Csak éppen szűk körű. Egy olyan telefon, amely összeomlik ahelyett, hogy észrevétlenül megfertőződne, valóban nagy dolog, ha valaki olyan magas kockázatú célpont, akit állami szereplők figyelnek. Sokkal kevésbé releváns ez, ha a tényleges kockázat az, hogy elveszíti a telefonját egy bárban, vagy rákattint egy rossz linkre egy SMS-ben. A jó OPSEC betartása, egyedi jelszavak használata, a véletlenszerű QR-kódok elkerülése, valamint az, hogy ne szórjuk szét a személyes adatainkat minden olyan weboldalon, amelyik kéri őket, a legtöbb ember számára valósabb védelmet nyújt, mint bármelyik szilícium-szintű memóriabiztonsági funkció valaha is tudna.

Ez azonban nem jelenti azt, hogy a Pixel 11 szilícium-visszalépése nem lenne hírértékű. A GrapheneOS felhasználói bázisa pontosan az a közönség, akinek ez a leginkább számít, és egy egész Pixel-generáció támogatásának elvesztése komoly csapást jelent e projekt számára. De őszintén be kell vallanunk, hogy az MTE sokkal inkább úgy tűnik, mint egy nagy értékű kockázatcsökkentő megoldás vállalatok vagy magas kockázatú felhasználók számára, amely véletlenül a fogyasztói chipekbe is bekerült, mintsem olyan funkció, amelynek hiányát a Pixel 11-et vásárló átlagember valaha is észrevenné. És van némi irónia abban, hogy a Google hogyan jutott el idáig: éppen ez a vállalat volt az, amelyik eleve a mainstreambe emelte az MTE-t, az Android-világban szinte bárki másnál korábban beépítette a Tensorba, finanszírozta a vele kapcsolatos kutatásokat, és egy egész biztonsági módot épített köré. Most pedig a saját belső dokumentumai arra utalnak, hogy beépítette az MTE-t a következő chipjébe, részletesen leírta, majd a piacra dobás előtt csendben eltávolította. Ebben a kérdésben senki sem felülmúlta a Google-t. A Google saját maga tervezte ki magát ebből a funkcióból.