Trifecta Tech Foundation, tādu projektu kā ntpd-rs, sudo-rs, zlib-rs un bzip2-rs izstrādātājs, paziņoja par Firefox pāreju uz zlib-rs bibliotēkas izmantošanu gzip saspiešanai un dekompresijai. Papildus aizsardzībai pret atmiņas kļūdām, pāreja no zlib uz zlib-rs ievērojami uzlaboja veiktspēju — testos paātrinājums svārstījās no 3.3 līdz 32.5 reizēm atsevišķām dekodēšanas darbībām un no 2.7 līdz 10.86 reizēm nepārtrauktas straumes dekodēšanai.
Zlib-rs bibliotēka bija iekļauta Firefox 151. laidienā, taču pēc tās integrācijas daži lietotāji saskārās ar problēmu, kuras dēļ programma avarēja ārpus robežām izpildes dēļ. Tika atzīmēts, ka Rust kodā šī problēma izraisīja avāriju, savukārt C kodā līdzīga situācija būtu izraisījusi klusu datu bojāšanu, neapturot programmas darbību. Kā risinājums 151.0.1. laidienā tika atjaunota vecākās zlib bibliotēkas izmantošana.
Pirmā problēmas izpausme tika pamanīta agrīno versiju testēšanas laikā pirms vairāk nekā gada, taču to nevarēja reproducēt izstrādātāju sistēmās. Galu galā pēc gada ilgas testēšanas ar beta lietotājiem tika nolemts iespējot zlib-rs Firefox 151 versijā. Pēc jaunas problēmu ziņojumu sērijas un modeļa izpētes tika atklāts, ka avāriju izraisīja mikrokoda kļūda Intel procesoros, kuru pamatā ir 13. un 14. paaudzes Raptor Lake mikroarhitektūra, kas saistīta ar nepareiza reģistra izmantošanu.
Problēma radās tāpēc, ka LLVM koda ģenerators, rakstot Huffman kodēšanas rezultātus atmiņā, izmantoja instrukciju "mov byte ptr [rsi + rdi + 1], ch". Izpildot šo instrukciju Raptor Lake centrālajā procesorā, tā vietā, lai ierakstītu 8–15 bitus no RCX reģistra, kas atbilst instrukcijā norādītajam CH reģistram, atmiņā tika ierakstīti biti 0–7, kas atbilst CL reģistram. Gatavojoties Firefox 152, tika ieviests risinājums, un ielāps tika pārnests uz galveno zlib-rs laidienu. Problemātiskās instrukcijas ģenerēšana tika novērota LLVM 22 (tā netiek ģenerēta LLVM 23 izstrādes atzarā).
Avots: opennet.ru
