Gyorsabb Firefox indulás preloading-gal a nightly build-ekben

 ( trey | 2011. június 20., hétfő - 13:38 )

A hírek szerint egy 20 soros patch-nek köszönhetően a Firefox 4 akár kétszer gyorsabban indul el Windows-on. Ugyanez az eredmény érhető el állítólag Linux-on egy holt egyszerű egy soros módosítással. A fejlesztők ezen elgondolások mentén elindulva egy, az összes támogatott platformon működő preloading megoldással álltak elő. A funkció a Firefox 7-ben bukkanhat fel. Aki tesztelni szeretné, annak a nigtly build-ekkel érdemes próbálkoznia. Az elindulási időket az about:startup kiterjesztéssel lehet monitorozni.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

+  while (ReadFile(fd, buf, sizeof(buf), &dwBytesRead, NULL) && dwBytesRead == sizeof(buf))
+    /* Nothing */;

LOL? Ez olyan mintha végig catolnám a binárisait h fs cachebe kerüljön bele.

catolnám
azt, lasd 1soros linuxos patch: `cat *.so >/dev/null`, lenyegeben :]

Egszerubb ha az egesz gepen csak firefoxot futtatsz, mert igy valoszinuleg bucsut inthetsz az esetleg mas fontos dolgoknak ami mar cachelve van. Yuppe

Amilyen remek irányba tendál a webes biztonság (webgl lulz) érdemes is lesz dedikált külön gépen böngészni.

Arra van az okostelefonod a naptáraddal, a címjegyzékeddel, az SMS-eiddel, minden privát adatoddal. Oh, wait... :)))

--
Steve Jobsot nagyra becsülöm üzletemberként és sajnálom, mint magánembert.
Viszont mint vallásalapítót, ki nem állhatom.

és Linux esetén nyugodtan legyen a vsyscalls fix címen és titkolják el továbbra is, hogy mely commitok tartalmaznak biztonsági hibajavításokat, hisz így a rosszfiúk se találják meg őket... ;)

Irt mar valaki olyan exploitot ami fix vsyscalls nelkul nem johetett volna letre ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Rossz a kérdés.

Ha haltak már meg autóbalesetben* biztonsági öv használata mellett is, akkor az azt jelenti, hogy nincs értelme a használatának?

Végletekben gondolkodásban kezet foghatsz Ingóval...

(* hup certified autós hasonlat, WROOOM WROOOM)

Mivel haltak mar meg negyfeszultsegtol az emberek, ezert tavel kone tartani oket a mobil telefonoktol is, mert abban is van feszultseg? (Lehet kis fesszel is olni biz. modokon)

Biztonsagi oveddel te is vegletes vagy.

Nagyon furcsallom egyes embereknek azt a hozzallasat akik szerint valamit meg kell valtoztatni mar azonnal, mert hallottak, hogy a szomszedjuk nagybatyanak a testverenek az unokaocse szerint veszelyes a kiscicakra nezve.
Foleg ha valtozas komplexitast novel, felvet kompatibilitasi problemakat, es egyes felhasznalaosok eseten JELENTOS teljesitmeny csokkenest.
Es elvarjak, hogy mindenki higyjen nekik, csak mert ok azt mondtak, aki nem hisz neki vagy mast mond, az meg felelotlen idiota...

Lehet hogy tenyleg kene mar egy ilyen kiscicakra veszelyes agat fentartani, ahol nincsen lelassitva es tulhizlalva minden...

Aztan meg megy a panaszkodas, hogy kernel bonyolulet lett, meg 20ns slower, meg maskep nez ki az API mint 10 eve , kb. ugyan azoktol a kiscica ovoktol is.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nagyon furcsallom egyes embereknek azt a hozzallasat akik szerint valamit meg kell valtoztatni mar azonnal, mert hallottak, hogy a szomszedjuk nagybatyanak a testverenek az unokaocse szerint veszelyes a kiscicakra nezve.

Az meg van, hogy sok éve a Megasploit frameworkben (amely nem csak a script kiddiek kedvenc játékszere) a Linux vsyscall kihasználásának módszere a default?

Ahol pedig nem lehet brute forceolni (pl. mert nem újra forkoló daemont kell exploitálni, vagy csak védelem van ellene, akár okos signal handlerrel), ott ez egy remek lehetőség a oneshot exploitra. Úgyhogy biztos lehetne szép számmal találni példákat az első - téves - kérdésedre is.

Foleg ha valtozas komplexitast novel, felvet kompatibilitasi problemakat, es egyes felhasznalaosok eseten JELENTOS teljesitmeny csokkenest.

Hát persze okoska, sok éve van ellene védelem a PaX-ban és a kedvenc disztród is használja, úgyhogy gyorsan vetesd ki, nehogy belassuljon a turbogentood.

Makes Sense
x86_64 -re is van ?

(Ez a konkret eset engem nem erint karosan, en altalanossagban beszeltem.)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Azt a szot, hogy ironia, ismered?

----------------
Lvl86 Troll

Vmi PaXTeam vs Linux/Ingó flame-en már a múlt héten kifetrengtem magamat, ez az? :)

--
Steve Jobsot nagyra becsülöm üzletemberként és sajnálom, mint magánembert.
Viszont mint vallásalapítót, ki nem állhatom.

Jah, ahogy az LWN idézőtől látszik még az SELinux fejlesztők is csendben egyet értettek PaX Team-mel, csak senki se akar konfrontálódni a kérdésben a magasságos Linussal és kiskutyájával, Ingoval.

> senki se akar konfrontálódni a kérdésben a magasságos Linussal és kiskutyájával, Ingoval.

Helyes. Kooperációval lehet előbbre jutni, nem konfrontációval.

Nalad ez a ket dolog egymassal szemben all?

wow <-

> Nalad ez a ket dolog egymassal szemben all?

Nem, egymás mellett.

Kooperációval lehet előbbre jutni, nem konfrontációval

Ahogy a szálban is látszott PaX Team kooperálni próbált - hisz a saját patch készletében már sok éve megoldott probléma ez és most hajlandóság látszott a mainstreamben való javításra is -, de szokás szerint konfrontáció lett belőle, köszönhetően Linus PaXTeamnek írt "shut up" és "stupid" érveivel...

Ingo pedig beállt puli kutya módjára a gazi mellé miután látta, hogy az megint elfelejtette bevenni a gyógyszerét, holott ő is a probléma gyors megoldásában volt először érdekelt.

> PaX Team kooperálni próbált
> de szokás szerint konfrontáció lett belőle

A "szokás szerint" mindent megmagyaráz.

> köszönhetően Linus PaXTeamnek írt "shut up" és "stupid" érveivel...

... azzal kezdődött, hogy Linus visszaütött ... :-)))

Kicsit lentebb azzal eteted a nepet, h a kooperacio az isten, anelkul semmi sem jo, majd mikor ebben a threadben kiderul az, h PaXTeam konstruktivan allt a kerdeshez, gyakorlatilag kesz megoldast kuldott a problema megoldasahoz es utana Linus szoszerint lehulyezte es elkuldte a francba akkor hirtelen at kell menni ovodaba ? Gyakorlatban a kooperacio azt jelentene, h el kell donteni kinek az apukaja erosebb ?

---
pontscho / fresh!mindworkz

> Kicsit lentebb azzal eteted a nepet,

Szép nyitás; tavaly ráléptem a lábadra, vagy mi?

?

---
pontscho / fresh!mindworkz

Jó döntés; csak így felvetődik a költői kérdés, hogy akkor minek kezdtél bele ... ?

Nem, ez egy ertetlenkedes volt azzal kapcsolatban, h gozom sincs mirol beszelsz.

---
pontscho / fresh!mindworkz

> gozom sincs mirol beszelsz.

Akkor döntetlen, én se tudom miért kezdesz kötekedéssel.

Nem kezdtem, folytattam mert picit elszallt az agyvizem. De mar megy a legkondi.

---
pontscho / fresh!mindworkz

A "szokás szerint" mindent megmagyaráz

Igen, mivel már tapasztalatból lehet tudni, hogy mennyire ért a biztonsághoz a díszes kerneldev társaság.

azzal kezdődött, hogy Linus visszaütött

Esetleg olvasd el a szálat, ne csak vakon trollkodj, mint általában.

> Esetleg olvasd el a szálat,

Felesleges: a célzásodból enélkül is következik, hogy nem ez az 1 szál alakította ki a kapcsolatuk domináns jellegét.

> ne csak vakon trollkodj, mint általában.

Kezdesz kifogyni az IQ-ból, mint általában :-)))

Felesleges: a célzásodból enélkül is következik, hogy nem ez az 1 szál alakította ki a kapcsolatuk domináns jellegét

Természetesen nem, hisz már jópárszor alulmaradt Linus&Co azokban a szálakban, ahol security témakörben kellett volna érvelni.

Nincs is ezzel baj, nem kell, hogy mindenki értsen az IT biztonsághoz, te is elég jól eltrollkodsz itt anélkül, hogy bármilyen fogalmad lenne róla... ;)

Kezdesz kifogyni az IQ-ból, mint általában :-)))

Kemény szavak ezek attól, aki saját bevallása szerint se olvasta el a szálat, csak write-only módban irkál.

> ki saját bevallása szerint se olvasta el a szálat

Látom elnyomtad a szövegértésedet a kötekedés kedvéért. Gyakorolj kicsit:

A: nem olvastam, máshonnan tudom, hogy felesleges elolvasni
B: olvastam, onnan tudom hogy felesleges elolvasni
C: ???
...

:-)))

Jó döntés, akkor erről ennyit.

Most mar igazan eltunhetnel.

> Most mar igazan eltunhetnel.

A nap poénja :-)))

[ hátha ebből rájössz miért: "2011. június 21., kedd - 14:30" ]

Nem mindenki log a hupon 24/7.

> Nem mindenki log a hupon 24/7.

Valóban, de ezt eddig is tudta itt mindenki. Ezentúl közölj inkább olyasmit, aminek legalább néhány olvasó számára hír/információ értéke van. Előre is köszönöm.

Hasonloan a multbeli esetekhez, szeretnem kerni zamboriz kollega eltunteteset, koszi trey. :)

jajne, akkor mártír lenne még a végén kedvenc bohócunkból! :)

Előtte azért még elmesélhetnéd, hogy te meg minek kötözködsz itt velem? Nem jelöltelek vissza a fészbúkon, vagy mi?

lehet uncsizza a produkciódat csak, vagy másik piros pingponglabdaorr kellene már :(

Szabad érdeklődnöm, hogy te hol dolgozol? (Ha akarod, privátban küldd el, de szeretnék látni egy olyan munkahelyet, ill. tudni, hogy ilyen létezik, ahol nem kell konfliktusokat felvállalni ahhoz, hogy normálisan dolgozhasson az ember.)


"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

off: a WebGL-ben konkretan mi a "biztonsagtalan"? (Nem ertek hozza, igy megkerdezem egy okosabbtol, mert meg csak minimalis dolgokat lattam belole, amik amugy tetszettek)

Szakvélemény Redmond-ból:

WebGL Considered Harmful

Vélemény a Mozilla-tól:

a three-dimensional platform

Nemrégi hiba:

Hole found in Firefox 4 WebGL implementation

Ha ki akarod kapcsolni:

about:config -> webgl.disabled -> true

Az Apple azért nem veti el teljesen.

--
trey @ gépház

Hozzafer a hw-hez kozvetlenebbul.

----------------
Lvl86 Troll

Eleg mesze van az a kozvetlentol.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Közvetlenebbült írt, nem közvetlenült.

De nem is érdekes a HW, elég hogy a lyukas video driverekben lévő sebezhetőségeket - amelyeket eddig csak local lehetett kihasználni - most szépen lehetővé teszi remote/client-side oldalról is, mivel semmiféle védelem nincs ez ellen a WebGL specifikációban.

WebGL specifikacio azt sem mondja, hogy tilos nem lyukasra megirni egy video drivert.
Nem tudom mi mast tehetne ez ugyeben a WebGL specifikacio.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Mi mást tehetne? LOL

Pl. hogy az új veszélyforrásokat először feltárja, megérti és elkerülésük érdekében rögzít a specifikációban módszereket, amelyekkel ellehet kerülni a driverekben lévő biztonsági hibák triviális kihasználását (mint ahogy teszi a Silverlight 3D wrapper is).

Így sem lesz tökéletes, de a jelenlegi _semminél_ jobb lenne, az biztos.

> az új veszélyforrásokat először feltárja, megérti és elkerülésük érdekében rögzít a specifikációban módszereket

Ez a "mindent mi magunk csinálunk; nem kooperálunk, mert nincs hiányunk semmiből" stratégia. Egy másik meg a "korán publikálunk, aki tud besegíthet; kooperálunk, mert erőforrás hiányosak vagyunk és/vagy mert így 'közösségi'" stratégia.

Önmagában egyik stratégia sem teljesen helytelen és persze nem is teljesen tökéletes.

Kac-kac, ebből a fene nagy kooperációból lett az, hogy totálisan figyelmen kívül hagyták a biztonsági vonzatát a jelenlegi dizájnnak és így rögzült az elsődleges WebGL specifikáció.

> és így rögzült az elsődleges WebGL specifikáció.

Sok hibás/hiányos első specifikációt lehetne találni. Az számít, hogy érdeklődés hiányában a javítás/fejlesztés elmarad-e vagy sem.

Addig pedig reménykedjünk, hogy az összes Firefox és Chrome user, aki a default bekapcsolt WebGL miatt komoly veszélynek van kitéve megússzák kompromitáció nélkül?

> Addig pedig reménykedjünk, hogy

Tőlem reménykedhetsz nyugodtan, engedélyezem :-)))

> aki a default bekapcsolt WebGL miatt komoly veszélynek van kitéve

Ami nem halálos, az nem "komoly veszély".

Tőlem reménykedhetsz nyugodtan, engedélyezem :-)))

A félelmetesen ostoba logikád ellen érveltem(*), amelyben úgy próbáltad beállítani a WebGL-t, mintha még csak egy tervezőasztalon lévő kezdeményezés lenne csupán, miközben már az összes aktuális Firefox és Chrome verzióban implementálva és alapértelmezetten bekapcsolva van.

(*) ez az a dolog, amit még te sose csináltál

Leesett az IQ-d nagyon. Hallottunk már olyat hogy valami kőbe volt vésve, aztán mégiscsak változtattak rajta.

Hallottunk már olyat

Komoly érvek ezek a tények ellen.

> Komoly érvek ezek a tények ellen.

Szövegértés hiányából fakadó fantáziálás ez a részedről.

a terelős "hallottunk már olyat" dumád az ami fantáziálás csupán :)))

Implementacios kerdes.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Biztos ezt mondták az IEEE 1394 tervezésekor is, amikor szóba került, hogy gond nélkül lehet majd írni/olvasni a teljes memóriaterületet a firewire csatolón keresztül.

+1


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Megvan a megoldás: implementálni kell a WebGL-t Javában framebufferbe renderelős szoftveres OpenGL backenddel :-).

Nem mondtam, hogy hibatlan az Nvidia vagy az AMD Windowsos drivere.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Bezzeg a Linuxos, vagy hogy érted?

Teljesen igazad van abban, hogy ami eddig szinte csak local volt kihasznalhato az remote lesz, mert a driverek bugosak.

Nem a WebGL specifikacio a hibas azert mert szarok a driverek.

Az input megfelelo szuruse meg implementacios kerdes, semmi koze egy alltalans szabvanyhoz.

(Mar driverekenk illene ezt jol csinalni, de nem biztos hogy benchamrkokon javitana, egyesek szerint driver verzio novekedesvel romlo teljesitmeny a gonosz GPU gyartok muve, hogy akkarjal ujabb kartyat venni.. )


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem a WebGL specifikacio a hibas azert mert szarok a driverek

Ezt nem is állította senki. Arra hagyatkozni viszont, hogy majd a gyártók javítják, amikor évek óta köztudott biztonsági hibákat se javítanak hatalmas nagy álom.

Az input megfelelo szuruse meg implementacios kerdes

Tévedés, eleve olyan protokollt kell kidolgozni, amely nem enged direkt kommunikációt a felsőbb réteggel. Ez nem csak egy egyszerű input szűréses kérdés.

egyesek szerint driver verzio novekedesvel romlo teljesitmeny a gonosz GPU gyartok muve

-> és emiatt sem frissítenek video drivert (meg egyébként se szoktak az átlag userek, nincsenek is rákényszerítve) -> még ha javítanák a gyártók a hibákat, akkor is védetlen marad a felhasználók jórésze -> tehát nem abban kell reménykedni, hogy majd a driverek lassú javítgatása megoldja az egész problémakört

"Tévedés, eleve olyan protokollt kell kidolgozni, amely nem enged direkt kommunikációt a felsőbb réteggel. Ez nem csak egy egyszerű input szűréses kérdés."

- Protokoll az valami olyan ami arrol szol, hogy mi megy a droton, es hogy ebbol mi mit jelenet, mire mit illik/szabad valaszolni.
Semmi koze hozza, hogy kapott infoval mit kezd az adott implementicio.

- WebGL nem protokoll.

- WebGL olyan APIt mutat ami "veletlenul" nagyon hasonlit az OpenGL ES 2.0 -hoz, az hogy mogotte tenylegesen mi van , ahhoz nincs semmi koze. Lehet ,hogy pont az van, hogy kozvetlenul meghivja az egyezo nevu fuggvenyt az adott rendszeren levo nativ programok altal is hasznalt libGl -bol , az is lehet (erosen valloszinu), hogy nem. Majd a bongeszo iroi eldontik, mivel ez impementacios kerdes.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Protokoll az valami olyan ami arrol szol, hogy mi megy a droton

Nem gond, ha nem tudod mit jelent a szó, csak nézz inkább utána mielőtt írsz.

Semmi koze hozza, hogy kapott infoval mit kezd az adott implementicio

Huh? Na jólvan inkább kímélj...

"Nem gond, ha nem tudod mit jelent a szó, csak nézz inkább utána mielőtt írsz."

Wiki:"Az informatikában a protokoll egy egyezmény, vagy szabvány, amely leírja, hogy a hálózat résztvevői miképp tudnak egymással kommunikálni. Ez többnyire a kapcsolat felvételét, kommunikációt, adat továbbítást jelent."

Pontosan tudom, hogy van tagabb ertelmezese, vagy mondjuk az orvostudomanyba mire hasznaljak. De informatikaban csak erre.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Akkor pontosan tudnod kellene azt is - még ha hálózatra korlátozod az értelmezését -, hogy akkor se az implementációtól függ az hogy kell értelmezni a protokollt, vagy a parancskészletet.

Mint például, amikor egyértelműen definiálva van, hogy az évet négyjegyű számmal _kell_ ábrázolni, lásd SMTP esetén is (RFC 5321).

Persze te implementálhatod máshogy is, csak épp nem lesz szabványos.

Nem mellesleg az RFC-kben rendszerint külön ki is emelik, hogy, mi az ami "MUST" vagy "MUST NOT", vagy "SHOULD" és "SHOULD NOT" és mi az, ami "MAY" vagy "OPTIONAL"...

Az SMTP-nel maradva, az SMTP megmondja, hogy hogyan kuldj el/fogadj egy uzenetet. De arrol semmit nem mond, hogy mit kezdesz vele. Nem resze az pl. hogy az SMTP szervernek mailboxban kell tarolnia a levelet, vagy relacios adatbazisban, vagy ...
Sot azt sem mondja meg milyen headerjei lehetnek egy uzenetnek.

Az sem resze, hogy milyen algoritmussal dontod el, hogy fogadod -e az adott cimre erkezo levelet vagy sem. Nem resze, hogy hasznalasz -e specialis hardvert , vagy sem. Nem mondja ki hogy Ethernetet kell hasznalnod.. (bugos firmwarrel:) )

Nem mondja, hogy text/shell-script content-type-al jovo levelet , le kell futatni rootkent azonnal, vagy sem.

WebGL -nel sincs megmondva, hogy mit hasznalsz ahhoz, hogy a specifikacioban foglalt eredmeny keruljon a megfelelo helyre.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

> az évet négyjegyű számmal _kell_ ábrázolni,
> Persze te implementálhatod máshogy is, csak épp nem lesz szabványos.

Őőőőőőő, ha az "év" == 3217, akkor implementálhatom, hogy kivágom a francba a klienssel együtt aki küldte? :-)))

a probléma az, hogy a kérdéses szoftverben nem hogy nincs implementálva ilyen, hanem az egészet vizsgálat nélkül továbbítja a video drivernek, tetszikérteni?! úgyhogy lehet benne "3217" helyett "zamboriz1bohóc" is

Tovább esett az IQ-d, már a magad nyitotta subthread-et sem tudod követni. Nem baj, segítek. Ott tartunk, hogy:

>>> akkor se az implementációtól függ az hogy kell értelmezni a protokollt, vagy a parancskészletet.

>> ha az "év" == 3217, akkor implementálhatom, hogy kivágom a francba?

> [implicit igen]

Helyes; tehát mégiscsak "az implementációtól függ ...". [ Láttunk már olyan kódot, ami tele volt if-ekkel az ilyen-olyan implementációk "egyedi" értelmezései miatt ... ]

Tovább esett az IQ-d

Ugyan nem lenne elképzelhetetlen, hogy a veled való társalgás során az ember IQ-ja rohamosan esik (a sajátod saját magadtól nem tud az abszolút nulláról), de szerencsére csupán te beszélsz össze-vissza. Viszont a bohócoktól ezt megszoktuk, úgyhogy hajrá tovább zambojimiz! :)))

Tovább esett az IQ-d. Gondolom reggelre visszaáll majd valamennyire.

A Chrome-os blogger pont ezt hozta fel, hogy mindegy, hogy hogy szűröd az inputot, ahoz, hogy valami hasznosat tudj csinálni a GPU-val, muszáj megengedni potenciális, akár a drivert fagyasztó műveleteket (pl. valami jó bonyolult poligon számítást). Vagy be kéne tenni a szabványba, hogy mondjuk csak 10000 objektumot lehet létrehozni?
Meg inkább DOS-ról beszélt, nem exploitról (mint a te screenshotodon is).
Na szóval én nem vagyok egy grafikai programozó, úgyhogy ezekkel az érvekkel én nem vitatkozom. Persze szar, hogy ezentúl egy weboldal miatt kifagy a videokártyád...Na de most egy szar flash miatt is használhatatlanul be tud lassulni a gép. Lesz itt még webglblocker...

mindegy, hogy hogy szűröd az inputot, ahoz, hogy valami hasznosat tudj csinálni a GPU-val, muszáj megengedni potenciális, akár a drivert fagyasztó műveleteket (pl. valami jó bonyolult poligon számítást)

Szerintem ha egy driver le tud fagyni, akkor az eleve nem normális működés. A leterhelt RAID vezérlőtől se fagy meg a drivere... vagy ha igen, akkor az se normális dolog.

Vagy be kéne tenni a szabványba, hogy mondjuk csak 10000 objektumot lehet létrehozni?

Nyilván nem, hisz különböző videokártyák különböző teljesítményre képesek.

Meg inkább DOS-ról beszélt, nem exploitról (mint a te screenshotodon is).

Nyilván DoS-t egyszerűbb előidézni, de a probléma ott van, hogy kódvégrehajtást elérni se lehetetlen és itt közvetlen kernel címtérben való natív kódfuttatásról beszélünk, ahol nem játszik a böngésző biztonsága, a sandbox védelme, vagy akár magának a futtató felhasználónak a korlátozása/jogosultságai. A kernelben futó kód bármit megtehet alapból. Ezért is dolgozik már évek óta PaX Team pl. a kernel self-protection témakörén. A PaX-on kívül viszont sehol máshol nincsenek olyan jellegű védelmek, amelyek a kernelben és driverekben található biztonsági hibák kihasználását nehezítenék meg, vagy bizonyos támadási formákat kompletten ellehetetlenítenének.

Persze szar, hogy ezentúl egy weboldal miatt kifagy a videokártyád...Na de most egy szar flash miatt is használhatatlanul be tud lassulni a gép.

Ha kifagy az lesz a jobbik eset. Másrészről az se mindegy, hogy kifagy a rendszer, vagy csak belassul...

Régebbi ATI videokártyával és driverrel kékhalált is sikerült előidéznem. Szerintem pár éven belül lesznek WebGL/video driver exploitok már szép számmal, ha nem változtatnak drasztikusan a gyártók a jelenlegi helyzeten (amit viszont kétlek, mert a videokártya driver gyártókat nem érdekli ez a probléma).

vajon ez csak vga driver specifikus probléma lenne? más driver-ekkel mi van, amelyek bemenete függ kinti hálózatról érkező adatoktól? pl. wifi driver a kapcsolat felépítésekor?

Találtak és használtak már ki biztonsági hibát ethernet és wifi driverekben is (meg persze video driverekben is, de jobbára csak lokálisan).

A különbség az, hogy hálózati drivereknél jobban kiderülnek ezek a problémák (hálózati stressz tesztelés, fuzzing által pl.), jobban oda is figyelnek a fejlesztők az ilyen jellegű hibákra, mint a video drivernél, ahol eddig nem nagyon számított a biztonság. Ráadásul egy video drivernek nagyságrendekkel nagyobb és bonyolultabb kódbázisa van, mint egy hálózati drivernek.

kösz.


Szerintem ha egy driver le tud fagyni, akkor az eleve nem normális működés. A leterhelt RAID vezérlőtől se fagy meg a drivere... vagy ha igen, akkor az se normális dolog.

Igazából nem is a drájver fagy, hanem a GPU...azzal, hogy ráküldenek egy olyan számítást, ami alatt az nem tud mást csinálni (desktopot se tud rajzolni közben). És itt jön az, hogy a driver meg lelövi a túl sokáig futó műveletet, és jön az ominózus üzenet. Persze ez baromira idegesítő, de a jelenlegi hardverek ezt tudják. Mellesleg ez a memóriával is előfordul, ott jön az OOM killer, CPU-val is, na ott meg a reset gomb.


Régebbi ATI videokártyával és driverrel kékhalált is sikerült előidéznem. Szerintem pár éven belül lesznek WebGL/video driver exploitok már szép számmal, ha nem változtatnak drasztikusan a gyártók a jelenlegi helyzeten (amit viszont kétlek, mert a videokártya driver gyártókat nem érdekli ez a probléma).

Ez akkor sem a WebGL hibája...A kékhalál videokártya miatt mindig is volt, sokaknál. WebGL nélkül.
De ezen, hogy milyen exploitokat lehet becsempészni, amit mondjuk a Silverlight-al nem lehet, nem tudok vitatkozni továbbra sem, lévén nem programozok egyikben sem.

Viszont ezzel azt is el tudom képzelni, hogy javul a driverek minősége idővel...most ugye letesztelik pár mainstream játékkal, ha azok elmennek, akkor jó. De hogy egyre általánosabban kezdik használni, kitesztelődik az összes code-path bennük...

Persze ez baromira idegesítő, de a jelenlegi hardverek ezt tudják.

Nem hiszem, ez színtiszta bénázás csak a mostani driverekben.

Mellesleg ez a memóriával is előfordul, ott jön az OOM killer

A memóriahasználat jól kontrollálható minden modern operációs rendszeren (setrlimit(2) ugye pl.).

CPU-val is, na ott meg a reset gomb

Már miért jönne a reset gomb? Te reszethez nyúlsz, ha valamelyik program elkezdi a CPU-t dolgoztatni?

Ez akkor sem a WebGL hibája...

Bah... senki nem mondta, hogy _ez_ a WebGL hibája.

.A kékhalál videokártya miatt mindig is volt, sokaknál. WebGL nélkül.

"Nincs itt semmi látnivaló, mindenki menjen szépen haza!"

milyen exploitokat lehet becsempészni, amit mondjuk a Silverlight-al nem lehet, nem tudok vitatkozni továbbra sem

Silverlight esetén van egy wrapper, ami egy layer és az beszélget a DirectX API-val, ami egy másik layer, mindkettőnél van ellenőrzés. A DirectX ráadásul szintén az MS kezében van és biztonsági szempontból is folyamatosan vizsgálják. A WebGL viszont közvetlenül a videokártya OpenGL interfacével beszélget (nincsenek meg azok a külön layerek, mint Silverlight+DirectX esetén), amelyik ráadásul nem a rendszer szállítójának a kezében van (MS), hanem a videokártya driver fejlesztőjének a kezében, aki magasról tesz a biztonságra, mert csak a minél jobb teljesítmény elérése a cél, másra nincs rákényszerítve.

Viszont ezzel azt is el tudom képzelni, hogy javul a driverek minősége idővel...

Idővel biztos, ha nagyobb nyomást fognak gyakorolni a video driver szállítókra. De ez egy tipikusan lassú folyamat.

De hogy egyre általánosabban kezdik használni, kitesztelődik az összes code-path bennük...

Van egy versenyhelyzet itt, amelyet a fuzzerekhez és debuggerekhez jobban értő exploit írók fognak inkább megnyerni, mint a fejlesztők.

Ráadásul a játékfejlesztőket szintén nem érdekli a biztonsági vonzata ezeknek a hibáknak. Nekik az a fontos, hogy a saját fejlesztésük haladjon. Kérdezz meg egy 3D engine programozót, hogy hány workaroundot kell beiktatni video driverek bugjai miatt. A hibák jórészét be se jelentik a gyártóknak, mert hajtás van, inkább valahogy megkerülik a problémát és haladnak tovább...

"A WebGL viszont közvetlenül a videokártya OpenGL interfacével beszélget"
Ha tobbszor leirod attol meg nem lesz feltetlen igaz.

"amelyik ráadásul nem a rendszer szállítójának a kezében van (MS), hanem a videokártya driver fejlesztőjének a kezében, aki magasról tesz a biztonságra, mert csak a minél jobb teljesítmény elérése a cél, másra nincs rákényszerítve."

A koztes layert a browserrrel egyutt lehet szallitani.
Netan ok is tesznek a biztonsagra ?

Az meg van -e, hogy az OpenGL ES 2.0 , eleve csak a reszhalmaza az OpenGL -nek? Megvan az is hogy az a resz konyebben implementalhato, es pl. regebbi OpenGL -ben levo unsafe dolgok nincsenek benne ?

DirectX -es backend reszt, olyan vendorok irjak akik nem tesztenk a biztonsagra, csak akkor ha OpenGL -rol van szo?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem fogom ismételni magamat.

Vitatkozz John Carmackkel, nyilván nála is jobban értesz az OpenGL-hez.

A Silvarlight -rol mit modott ?

A DriectX -hez, nem pl. az ATI es Nvidia Driver fejlesztoi fejlesztenek drivert ?

Ne adj szavakat a szamba, es Carmackeba se.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem elegge.

(Egyebkent nagy osszegekben mertem volna fogadni abban, hogy valakinek tutira nem fog eljutni a kozvetlLENEB es a kozvetLEN kozotti kulonbseg.)

----------------
Lvl86 Troll

Mindenkepp betolti a szart, csak az a kerdes, h mennyi ido alatt. Akkor nem tokmind1?

tompos

Hmm, az ilyen "prefetch to cache" jellegu megoldasoknal mindig fura erzesem tamad. Ugyanez van ugye a "gyorsitsuk a boot folymatot" es egyeb esetben is. Ezt valahogy en mindig "csunya workaround" kategorianak tekintettem. Ilyen elven sokkal szebb lenne, ha be lenne vezetve egy uj syscall ami kb "cache hinting" lenne vagy hasonlo, es kozolne a kernellel, hogy a dolgok jelenlegi allasa szerint nagy biztonsaggal szukseg lesz az XYZ dolgokra. Aztan egy kernel thread (vagy akar user space cuccos is - foleg ha van info arrol pl user space fele kiexportalva) megnezne, hogy a cache-ben benne van-e mar, ha nem, akkor esetleg elkezdene beolvasgatni oda (esetleg kisse komplex dontesekkel, hogy megeri-e, miegymas). Akkor nem kene minden software, folyamat, whatever eseten "implementalni" ezt a feature-t, ami nem is biztos, hogy minden esetben optimalis raadasul (pl: keves a memoria mar amugy is, nincs is ertelme nagyon ennek akkor, ugyse nagyon fog cache-ben ottmaradni, ha nincs erre eleg memoria eppen: akkor csak felesleges I/O volt, ami adott esetben pont hogy lassit). Hasonloan gondoltam volna mint pl a madvise(), csak eppen itt meg egy nem feltetlen mmap-elt file-rol van szo, hanem csak a jovoben fog jonni. Vagy van ilyesmi, csak en nem tudok rola?

Simpsons Microsoft already did it.

Windows ugyekben nem vagyok kepben, de errol olvastam mar regebben. Azonban az nem tiszta, hogy ez ilyen dinamikus dolog-e (egy applikacio kerheti-e tetszolegesen) vagy "beledrotozott dolog", es per app/eset alapon mindig ugyanugy tortenik. Ha ez utobbi, akkor lenyegeben nem sokkal tobb mint ezek a hack-ek amit a mozilla is csinalt (max kicsit szofisztikaltabb), de nem egy altalanos memory subsystem feature, ami rugalmasan igenyelheto.

Dinamikus. Elvileg monitorozza, hogy mit hogy hasznalsz es az alapjan precacheli a dolgot.

----------------
Lvl86 Troll

Preload..? Since 2005. :)

+1

ez mekkora hülyeség (az indító téma).

ők is leimplementálnak valamit, aminek a rendszer oldalon kellene eldőlni. akkor már tényleg jobb lenne egy kernel space megoldás, ahol pl. a cache ürítésnél (vagy prefetch-nél) a döntést súlyozná az app-ok memóriában töltött idejük-, vagy kiosztott CPU idejük mértéke szerint, akár előzőkben gyűjtött statisztika szerint.

Én azt nem értem csak, hogy miért pont a 7-be (ugye most jelenik meg még csak az 5-ös)? Ilyen előre tervezett RoadMap van, hogy a startuppal kapcsolatos optimalizációk a 7-es verzióban lesznek?

Nálam a prefetch (Linux nem Firefox) tiltva van, mert ugye sokkal lassabb volt a boot-olás vele, mint nélküle.

Minden hónapban egyszer indítok OpenOffice.org-ot, de a marhája minden boot-nál prefetchelte, hogy nekem gyorsabb legyen. Szóval megvadultam és az egészet kivágtam a fenébe.

Persze lehet, hogy a mai prefetch már értelmesebb és figyelembe veszi a user szokásait is, de a legelső változattól az agyam eldobtam.

A legutolsó openSuSE-n persze nem érzem a hatását. Vagy letiltották, vagy a Molnár Ingo scheduler patch óta tényleg background megy az egész.

Igen, így van.

Napjában én is csak egyszer indítom el a Firefoxot, így kábé leszarom mennnyi idő alatt indul el.

--
GPLv3-as hozzászólás.

2011 a linux deskt 2 * 10^n soros csodapaccsok éve!

a grub-ba már bele kéne tenni, ez így szar.

BIOS-ba/EFI-be. :)

--
Don't be an Ubuntard!

+1 ez tetszett :D

java'nother blog

Erossen /o\ megoldas.

----------------
Lvl86 Troll

+1

brotip: use file cache for moar speed. Problem? :D

[naive troll mode]
Akkor most már elindulás előtt is képes lesz megenni sok száz mega memóriát?
[/naive troll mode]

a RAM mar nem eleg draga, masbol kell minel tobbet elvinni :D

Ezek szerint a disk IO-ra gyúrnak?

nem, a cache-re, van egy CPU 1 Mega L2 cache-sel, nehogyma' abbol 768kB ne lehessen a bugrokae! De majd a Firefox 7-hez mar 3 Mega cache-t fog enni a roka, igy mar a minimum kovetelmeny 4 Megas L2 cache-es processzorral valo rendelkezes lesz a Firefox 7 futtatasahoz!

Aztan jon majd meg tobb, az L1 cache-re vagyas a gyors indulasert, es minimum kovetelmeny lesz a 4 magos processzor, hogy a negyedikben meg maradjon hely a nemilyen modon tervezett programoknak :D

Meg hirtelen az a csunya jovokep is elem tarult, hogy 30 ev mulva: "mar egy 5 eves elavultnak szamitogepben is van 64 processzormag, mit zavar teged, hogy ezekbol 4-5 folyton vegetelen ciklusban fut es meg a cache-uket is elhasznaltatjak az osszeset a gonosz fejlesztok. Kulonben is most is arrol olvasod a hupot!!!!11!!!11 De optimalizalassal is max 10%-ot gyorsithatsz, tehat nem eri meg!!!"

(this comment is just kidding)

Komolyra forditva a szot: nekem boven eleg a RAM-ban, ki tudom varni azt a par masodpercet. Ha meg azt az IO miatt kell varnom alapbol (diszkrol fajlolvasas), akkor meg ennyi RAM mellett inkabb legyen egy rendes lehetosegem rendes copytoram-ra

Ez azt hiszem mindent elmond mindegyik tamogatott platform prefetchelserol...


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem, ez mindent elmond a mozilla hozzá nem értéséről, lásd itt.

--
Don't be an Ubuntard!

Nem.

Sehol nem irtak, hogy oskuvelt windowsrol van szo ahol nincs superfetch.
Tehat az is szar lehet.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ez a modszer gyorsit a nem hasznalt/alig hasznalt rendszeren torteno inditast, es esetlegesen lenyegesen lassitja a hasznalt rendszeren torteno inditast.
Nalam ssd van /usr -re, nalam lassitana minden esetben.