Llenguatges de programació: com Google està millorant la seguretat de la memòria C++

L’equip de Chrome de Google està buscant l’exploració de pila per reduir els errors de seguretat relacionats amb la memòria a la base de codis C++ de Chrome, però la tècnica crea un peatge a la memòria, excepte quan s’utilitza el maquinari Arm més nou.

Google no pot esquivar i substituir el codi C++ existent de Chromium per un Rust més segur de memòria, però està treballant en maneres de millorar la seguretat de la memòria de C++ mitjançant l’escaneig de la memòria assignada. El problema és que és car en memòria i de moment només experimental.

Google i Microsoft són els principals usuaris i col·laboradors del llenguatge de programació ràpid C++, que s’utilitza en projectes com Chromium, Windows, el nucli de Linux i Android. Hi ha un interès creixent per utilitzar Rust a causa de les seves garanties de seguretat de memòria.

VEURE: Treballant dur o treballant gairebé? Els empleats no confien que els seus companys siguin productius mentre treballen des de casa

Però canviar a l’engròs de C++ a Chrome a un llenguatge com Rust simplement no pot passar a curt termini.

“Tot i que hi ha apetit per diferents idiomes que el C++ amb garanties de seguretat de memòria més fortes, grans bases de codi com Chromium utilitzaran C++ en un futur previsible”, expliquen Anton Bikineev, Michael Lippautz i Hannes Payer de l’equip de seguretat de Chrome.

Tenint en compte aquest estat, els enginyers de Chrome han trobat maneres de fer C++ més segur per reduir els errors de seguretat relacionats amb la memòria, com ara el desbordament de la memòria intermèdia i l’ús després de l’ús lliure (UAF), que representen el 70% de tots els errors de seguretat del programari.

C++ no garanteix que sempre s’accedeixi a la memòria amb la informació més recent de la seva estructura. Per tant, l’equip de Chrome de Google ha estat explorant l’ús d’una “quarantena de memòria” i una exploració de pila per aturar la reutilització de la memòria que encara és accessible.

Els UAF constitueixen la majoria dels problemes d’alta gravetat que afecten el navegador. Un exemple és el Chrome 102 d’aquesta setmana, que va solucionar un UAF crític, mentre que sis dels vuit defectes d’alta gravetat eren UAF.

L’accés UAF a la memòria assignada a l’munt és causat per “punters penjants”, que es produeix quan la memòria utilitzada per una aplicació es torna al sistema subjacent però el punter apunta a un objecte obsolet. L’accés a través del punter penjant dóna lloc a un UAF, que és difícil de detectar en grans bases de codi.

Per detectar UAF, Google ja utilitza punters intel·ligents C++ com MiraclePtr, que també va provocar un èxit de rendiment, així com anàlisi estàtica en compiladors, desinfectants C++, fuzzers de codi i un col·lector d’escombraries anomenat Oilpan. L’atractiu de Rust és que el seu compilador detecta errors del punter abans que el codi s’executi en un dispositiu, evitant així penalitzacions de rendiment.

L’escaneig de pila pot afegir-se a aquest arsenal si supera la fase experimental, però l’adopció dependrà dels dispositius que utilitzin el darrer maquinari Arm.

Google explica com funcionen les quarantenes i l’exploració de pila: “La idea principal darrere de garantir la seguretat temporal amb la quarantena i l’exploració de pila és evitar la reutilització de la memòria fins que no s’hagi demostrat que no hi ha més punters (pengants) que hi facin referència. Per evitar canviar l’usuari de C++. codi o la seva semàntica, s’intercepta l’assignador de memòria que proporciona nou i esborrat.

En invocar la supressió, la memòria es posa en quarantena, on no està disponible per ser reutilitzada per a noves trucades posteriors per part de l’aplicació, va dir Google. “En algun moment s’activa una exploració de l’munt, que escaneja tot el munt, com un col·lector d’escombraries, per trobar referències a blocs de memòria en quarantena. Els blocs que no tenen referències entrants de la memòria de l’aplicació normal es transfereixen de nou a l’assignador on poden ser reutilitzats per a assignacions posteriors”.

L’exploració de pila de Google consisteix en un conjunt d’algorismes que anomena StarScan (*Scan). Però una versió de *Scan va provocar una regressió de memòria del 8% a les proves de referència de rendiment del navegador Speedometer2. * L’escaneig durant el procés de renderització va reduir el consum de memòria aproximadament un 12%, assenyala Google.

A continuació, Google va provar l’etiquetatge de memòria assistit per maquinari mitjançant l’extensió d’etiquetatge de memòria relativa (MTE) a ARM v8.5A per reduir les despeses generals de rendiment.

EES: Els desenvolupadors estan esgotats. Això és el que estan fent per afrontar-ho

Els resultats de la prova de referència *Scan amb MTE eren prometedors. Després de tornar a fer els *experiments d’escaneig a la part superior del MTE en el procés del renderitzador, la regressió de la memòria va ser d’aproximadament un 2% al Speedometer2.

“L’experiment també mostra que afegir * Escaneig a sobre de MTE no té un cost mesurable”, van escriure.

Però de moment, dur a terme l’exploració de pila d’una manera que no creï un èxit de rendiment inacceptable segueix sent una cosa per al futur, quan MTE s’adopti més àmpliament.

“C++ permet escriure aplicacions d’alt rendiment, però això té un preu, seguretat. L’etiquetatge de memòria de maquinari pot solucionar alguns inconvenients de seguretat de C++, alhora que permet un alt rendiment”, va concloure l’equip de seguretat de Chrome.

“Estem desitjant veure una adopció més àmplia de l’etiquetatge de memòria de maquinari en el futur i suggerim utilitzar *Scan a sobre de l’etiquetatge de memòria de maquinari per arreglar la seguretat temporal de la memòria per a C++. Tant el maquinari MTE utilitzat com la implementació de *Scan són prototips. i esperem que encara hi hagi espai per optimitzar el rendiment”.

Leave a Comment

Your email address will not be published. Required fields are marked *