A lassú Firefox 3.5 indulás oka

Mozilla

Mostanában növekszik azon felhasználók száma, akik arra panaszkodnak, hogy a Firefox 3.5 lassan indul. Közben másoknak nincs ezzel problémája. Úgy tűnik, hogy megtalálták a probléma forrását és várhatóan hamarosan orvosolják is azt.

Egyes rendszereken az indítás után 30 vagy több másodperc is eltelik, míg a Mozilla ablak felbukkan. Frans Bouma elemezte a problémát és arra jutott, hogy induláskor a Firefox inicializálja a Network Security Services (NSS) véletlenszám-generátorait. Ezt úgy teszi, hogy fájlokat olvas "random" helyekről. Windows alatt ezekbe a "random" helyekbe beletartozik az Internet Explorer cache és a Windows temp könyvtár is. Mivel ezek gyakran nagyszámú fájlt tartalmaznak, ezek feldolgozása hosszabb időt vehet igénybe.

A H Security szerint ez megmagyarázza a lassú indulást Windows-on. Linux-on és Mac OS X-en az NSS library a /dev/urandom-ot használja.

A Mozilla részéről Johnathan Nightingale megerősítette a H Security-nek a problémát és elmondta, hogy már van javításuk, amelyet tesztelnek.

A Mozilla egyébként a win32 CryptoAPI-t használja, de vannak olyan rendszerek, ahol ez nem érhető el. Ebben az esetben folyamodnak más random forráshoz. Nightingale ígéretet tett egy kifinomultabb megoldásra, amely valóban a CryptoAPI-t használja ha az lehetséges, és csak akkor folyamodik különböző könyvtárak olvasásához, ha az nem érhető el.

A részletek itt.

( crown v | 2009. 07. 15., sze – 13:27 )

Csak nekem tunik ez rettento bena megoldasnak? Hogy jutott ilyen barki eszebe?!

Ez így van, viszont a véletlen számok legnagyobb szerepe a kriptográfiában van, az , meg inkább az utóbbi 10 évben lett igazán fontos az IT iparban.
Mivel a nagy unixok kicsit idősebbek 10 évnél, ezért a néhányba csak akkor került bele, amikor elkerülhetetlenné vált a dolog. Solarisba pl. a valahol a 8-as táján került bele, egy patch formájában. Emlékszem azelőtt mi is egd-vel bohóckodtunk.

Ezt nem tudom megítélni, és ebben valószínűleg a biztonsági múlt végignézése (napvilágra került kritikus hibák) sem segítene, mert az csak a felszín, csalóka mérce.
Biztosabbat olyan tudna mondani, aki ezzel a területtel foglalkozik, és legalább ismer mélyebben több OS-t. Ahogy nézem hungert például már inkább gondolnám illetékesnek (magamnál persze :), nem tudom ő mennyit foglalkozik/-zott Solarisszal.

A Trusted Solaris egyértelműen nem lófasz (de nem is nélkülözi az általános sunos kódminőséget), valóban van köze a securityhez, viszont nem olyan értelemben, mint amire céloztam, de szerintem te érted is a különbséget.

Egy dolog RBAC-ot, MAC-ot, meg ilyeneket implementálni egy OS-ben, és egy másik az, ha ettől még az OS-ben lévő lyukak kihasználhatók, sőt, maguk a biztonsági implementációk is hoznak be extra sérülékenységeket.

A Solaris szerintem nem rendelkezik túl jó biztonsági múlttal, csak erre kívántam rámutatni.

suckIT szopás minden nap! A nagy öreg a fiatal csirke ellen - UFS vs. ZFS

Jah, mondjuk az tényleg tény, hogy voltak igen ciki remote exploit hibák benne. Egyébként szerintem a 90-es évek végéig elég kevés oprendszer gyártó foglalkozott komolyan security-vel. A lyukas third party szotverek miatt (oh, azok a legendás sendmail bugok...) elég hatásos cross-platform remote exploitok léteztek.

( lovas | 2009. 07. 15., sze – 13:37 )

Amellett h a megoldást hülye ötletnek tartom, a tesztelők sem voltak nagy spílerek. Hamár adott egy funkcionalitás, ami az IE cache-től függ, akkor valószínűleg olyan stuff kellett volna, amin jócskán használták előtte valamelyik IE-t

( Zs | 2009. 07. 15., sze – 13:49 )

A nagy többség azért rak fel FF-ot, hogy ne IE-t használjon. Akkor viszont az IE cache mint "random adatok forrása" vajh mennyire állja meg a helyét, mint valóban "random adat" forrás?

( KGer | 2009. 07. 15., sze – 14:17 )

>Ezt úgy teszi, hogy fájlokat olvas "random" helyekről.
Ez igencsak belevag abba a bizonyos adatvedelmi policy-be. Minusz ket bizalom pont a firefoxnak.

Mar csak azert is, mert __pletyka__ szinten a firefox egyik fo huzoereje a nyilt forras, es hogy emiatt nem tud a gonosz M$ kemkedi utanad mint pl a zart IE eseten.
En ebben a szituacioban messzirol elkerulnem meg csak a latszatat is, hogy barmilyen modon felhasznaloi fajlokat olvasgassak a gepen.

A forráskódból megnézheted hogy pontosan mit csinál azokkal a fájlokkal. Ja, de biztos az official build nem is abból van gyártva, hanem bele van emelve az is, hogy adatokra bányásszon, amelyet a Mozilla aztán elad.

********************
"...ha nem tévedek!" (Sam Hawkens)
http://holo-media.hu

( Replaced | 2009. 07. 15., sze – 14:18 )

uhhh

--
When in doubt, use brute force.

( quark | 2009. 07. 15., sze – 14:34 )

erre nincs szo

es nem azert, mert a sajat cuccaim kozott turkal (ha nem ertelmezi, nem kuldi tovabb, kit erdekel); hanem mert ez egy minosithetetlen megoldas

miért kellene pusztán matematikai módszerekkel? a linux random egysége tudtommal a hardver driver-einek meg az egyéb kernel-es környezet zajából állítja elő, pusztán ezért nem kellene diszkhez nyulni imho :)

Szerk.: C64-en volt jó, ott a SID chip $D41B regisztere hardveresen generált 8 bites random értéket tartalmazott :) 

peek (54299)

Miert is lett volna konzol? A PC manapsag viszont inkabb lego jatek mint komoly szamitastechnika, hogy ossze-vissza barkacsol mindenki tizmilliard fele kombinacioban valamit. Akkoriban meg normalis volt a dolog, a Commodore 64 az commodore 64 volt, es igy tovabb. Ennek koszonheto ugye, hogy pl par hw design hibat jo celra hasznalva lehetett trukkozni, stb. Probalnank meg ma ezt egy PC-vel :-P

... Ennek koszonheto ugye, hogy pl par hw design hibat jo celra hasznalva lehetett trukkozni, stb. Probalnank meg ma ezt egy PC-vel :-P

Pár!? PC-nél folyamatosan ezt teszik, ugyanis egy nagy hw design hiba kupac eleve. :-P
--
Those who do not understand Unix are doomed to reinvent it, poorly. -- Henry Spencer, 1987
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/

( wladek1 | 2009. 07. 15., sze – 15:02 )

Komolyan kezdek beleszeretni az Opera -ba, a nyűgjei ellenére is (max default gyorsbillentyűk, fless).
Ott legalább nem ámítanak azzal, hogy milyen k...jó a cucc (mert nem hiszem el nekik).
Tényleg, vajon mi lenne akkor, ha pl beolvasná az egész swapet? Ezután bármi lehet...

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu

( NPeete | 2009. 07. 15., sze – 15:40 )

előre leszögezem, hogy nem értek hozzá, de nem lehetne vinyó helyett pl ramból generálni a véletlen számokat? úgyis gyorsabb az elérése, meg annak a tartalma is folyamatosan változik...

( golgota | 2009. 07. 15., sze – 15:44 )

szerencsére nem érint
de nem hiszem, hogy a win-ben ne lenne normális véletlenszám generátor, amit használhatna az nss lib. fix me aki ért a winhez.

( sh4d0w808 | 2009. 07. 15., sze – 16:32 )

Ebben csak az a furcsa, hogy Windows alatt nálam is lassan indul, de nem használok IE-t...

Valaki említette már, hogy egyrészt ki kellett volna hagyni bizonyos könyvtárakat a véletlenszám-generálásból, másrészt meg ha bizonyos esetekben a crypto API-t használja, akkor azt nem lehetne mellékelni a telepítőhöz? Vagy az egy closed source dll-ben van?

-------------------------
Trust is a weakness...

nem ismered a windowst, nagyon tévednek azok akik azt hiszik ha arra a nagy kék ikonra nem kattintanak, nem használnak ie-t, még azt a kijelentést is megkockáztatnám, hogy sokkal biztosabban, nagyobb mértékben változhat az ie cache, ha csak ritkán ff, neadjisten mindig private browsing

( Nyizsa v | 2009. 07. 15., sze – 17:56 )

Nálam az indulás csak pár (<10) s-t vesz igénybe, a zavaró inkább az, hogy a kilépés lassú. Az Xfce gyakran jelzi is, hogy a program már régóta inaktív, bezárjuk-e erőszakkal, ezután pár (1-2) s után magától kilép. Na erre van valakinek magyarázata?

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Persze, nyilván ezt az üzenetet az ablakkezelő adja, de az ok akkor is a Firefox|Iceweasel. De azért örülök, hogy nem egyedi eset itt nálam. Érdekes módon minden más program azonnal képes kilépni. Esetleg valami hosszadalmas dolgot csinálnak a delete-event handlerében? Lehet, hogy majd vetek rá egy pillantást, ha véget ér az utcazene.

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

( pwm | 2009. 07. 15., sze – 18:06 )

jujj de orulnek en annak a 30mp-nek. Nekem sacc/kb 1-2 perc az.

( bervi | 2009. 07. 15., sze – 18:53 )

hja, p4 laptopon is kész élvezet kivárni a percet, amíg nagy nehezen beindul. kíváncsi leszek, csinálnak-e valami elfogadható megoldást erre, és az beváltja-e a hozzá fűzött reményeket.

szerintem.

( yoursoft | 2009. 07. 16., cs – 06:59 )

Nekem is kb 45-50 sec alatt indult a 3.5.
Vacuum-oztam az SQLite adatbázisait (jól fragmentálódtak a sok upgrade alatt). Most kb. 10 sec alatt indul.