„Trifecta Tech Foundation“, tokių projektų kaip „ntpd-rs“, „sudo-rs“, „zlib-rs“ ir „bzip2-rs“ kūrėja, paskelbė, kad „Firefox“ perėjo prie „zlib-rs“ bibliotekos naudojimo „gzip“ glaudinimui ir išskleidimui. Be apsaugos nuo atminties klaidų, perėjimas nuo „zlib“ prie „zlib-rs“ žymiai padidino našumą – bandymų metu pagreitėjimas svyravo nuo 3.3 iki 32.5 karto atliekant vieną dekodavimo operaciją ir nuo 2.7 iki 10.86 karto atliekant nuolatinį srautinį dekodavimą.
„Zlib-rs“ biblioteka buvo įtraukta į „Firefox“ 151 versiją, tačiau po jos integracijos kai kurie vartotojai susidūrė su problema, dėl kurios programa strigdavo dėl vykdymo už ribų. Pastebėta, kad „Rust“ kode ši problema sukeldavo strigimą, o C kode panaši situacija būtų sukėlusi tylų duomenų sugadinimą nesustabdant programos. Kaip sprendimas, 151.0.1 versijoje buvo grąžinta naudoti senesnė „zlib“ biblioteka.
Pirmieji problemos požymiai buvo pastebėti testuojant ankstyvąsias versijas daugiau nei prieš metus, tačiau kūrėjų sistemose jų atkurti nepavyko. Galiausiai, po metų trukusių bandymų su beta versijos naudotojais, buvo nuspręsta įjungti zlib-rs „Firefox 151“ versijoje. Po naujos problemų ataskaitų serijos ir modelio tyrimo buvo nustatyta, kad gedimą sukėlė mikrokodo klaida „Intel“ procesoriuose, pagrįstuose 13 ir 14 kartos „Raptor Lake“ mikroarchitektūra, susijusi su neteisingo registro naudojimu.
Problema kilo dėl to, kad LLVM kodo generatorius, įrašydamas Huffmano kodavimo rezultatus į atmintį, naudojo instrukciją „mov byte ptr [rsi + rdi + 1], ch“. Vykdant šią instrukciją „Raptor Lake“ procesoriuje, užuot įrašius 8–15 bitų iš RCX registro, atitinkančio instrukcijoje nurodytą CH registrą, į atmintį buvo įrašomi 0–7 bitai, atitinkantys CL registrą. Rengiantis „Firefox 152“, buvo įdiegtas laikinas sprendimas, o pataisa buvo perkelta į pagrindinę „zlib-rs“ versiją. Probleminės instrukcijos generavimas buvo pastebėtas LLVM 22 (ji negeneruojama LLVM 23 kūrimo šakoje).
Šaltinis: opennet.ru
