- A hozzászóláshoz be kell jelentkezni
Hozzászólások
+ 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.
- A hozzászóláshoz be kell jelentkezni
catolnám
azt, lasd 1soros linuxos patch: `cat *.so >/dev/null`, lenyegeben :]
- A hozzászóláshoz be kell jelentkezni
Egszerubb ha az egesz gepen csak firefoxot futtatsz, mert igy valoszinuleg bucsut inthetsz az esetleg mas fontos dolgoknak ami mar cachelve van. Yuppe
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
é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... ;)
- A hozzászóláshoz be kell jelentkezni
Irt mar valaki olyan exploitot ami fix vsyscalls nelkul nem johetett volna letre ?
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Azt a szot, hogy ironia, ismered?
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
Nalad ez a ket dolog egymassal szemben all?
wow <-
- A hozzászóláshoz be kell jelentkezni
> Nalad ez a ket dolog egymassal szemben all?
Nem, egymás mellett.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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 ... :-)))
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
> Kicsit lentebb azzal eteted a nepet,
Szép nyitás; tavaly ráléptem a lábadra, vagy mi?
- A hozzászóláshoz be kell jelentkezni
?
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Jó döntés; csak így felvetődik a költői kérdés, hogy akkor minek kezdtél bele ... ?
- A hozzászóláshoz be kell jelentkezni
Nem, ez egy ertetlenkedes volt azzal kapcsolatban, h gozom sincs mirol beszelsz.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
> gozom sincs mirol beszelsz.
Akkor döntetlen, én se tudom miért kezdesz kötekedéssel.
- A hozzászóláshoz be kell jelentkezni
Nem kezdtem, folytattam mert picit elszallt az agyvizem. De mar megy a legkondi.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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 :-)))
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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: ???
...
:-)))
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Jó döntés, akkor erről ennyit.
- A hozzászóláshoz be kell jelentkezni
Most mar igazan eltunhetnel.
- A hozzászóláshoz be kell jelentkezni
> Most mar igazan eltunhetnel.
A nap poénja :-)))
[ hátha ebből rájössz miért: "2011. június 21., kedd - 14:30" ]
- A hozzászóláshoz be kell jelentkezni
Nem mindenki log a hupon 24/7.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
Hasonloan a multbeli esetekhez, szeretnem kerni zamboriz kollega eltunteteset, koszi trey. :)
- A hozzászóláshoz be kell jelentkezni
jajne, akkor mártír lenne még a végén kedvenc bohócunkból! :)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
lehet uncsizza a produkciódat csak, vagy másik piros pingponglabdaorr kellene már :(
- A hozzászóláshoz be kell jelentkezni
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"
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Szakvélemény Redmond-ból:
Vélemény a Mozilla-tól:
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
- A hozzászóláshoz be kell jelentkezni
Hozzafer a hw-hez kozvetlenebbul.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Eleg mesze van az a kozvetlentol.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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.
- A hozzászóláshoz be kell jelentkezni
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ó.
- A hozzászóláshoz be kell jelentkezni
> é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.
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
> 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".
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Leesett az IQ-d nagyon. Hallottunk már olyat hogy valami kőbe volt vésve, aztán mégiscsak változtattak rajta.
- A hozzászóláshoz be kell jelentkezni
Hallottunk már olyat
Komoly érvek ezek a tények ellen.
- A hozzászóláshoz be kell jelentkezni
> 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 hozzászóláshoz be kell jelentkezni
a terelős "hallottunk már olyat" dumád az ami fantáziálás csupán :)))
- A hozzászóláshoz be kell jelentkezni
Implementacios kerdes.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+1
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Megvan a megoldás: implementálni kell a WebGL-t Javában framebufferbe renderelős szoftveres OpenGL backenddel :-).
- A hozzászóláshoz be kell jelentkezni
Nem mondtam, hogy hibatlan az Nvidia vagy az AMD Windowsos drivere.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Bezzeg a Linuxos, vagy hogy érted?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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"...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
> 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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 ... ]
- A hozzászóláshoz be kell jelentkezni
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! :)))
- A hozzászóláshoz be kell jelentkezni
Tovább esett az IQ-d. Gondolom reggelre visszaáll majd valamennyire.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
kösz.
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
Nem fogom ismételni magamat.
Vitatkozz John Carmackkel, nyilván nála is jobban értesz az OpenGL-hez.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem elegge.
(Egyebkent nagy osszegekben mertem volna fogadni abban, hogy valakinek tutira nem fog eljutni a kozvetlLENEB es a kozvetLEN kozotti kulonbseg.)
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Mindenkepp betolti a szart, csak az a kerdes, h mennyi ido alatt. Akkor nem tokmind1?
tompos
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
Simpsons Microsoft already did it.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Dinamikus. Elvileg monitorozza, hogy mit hogy hasznalsz es az alapjan precacheli a dolgot.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Preload..? Since 2005. :)
- A hozzászóláshoz be kell jelentkezni
+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.
- A hozzászóláshoz be kell jelentkezni
É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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
2011 a linux deskt 2 * 10^n soros csodapaccsok éve!
- A hozzászóláshoz be kell jelentkezni
a grub-ba már bele kéne tenni, ez így szar.
- A hozzászóláshoz be kell jelentkezni
BIOS-ba/EFI-be. :)
--
Don't be an Ubuntard!
- A hozzászóláshoz be kell jelentkezni
+1 ez tetszett :D
- A hozzászóláshoz be kell jelentkezni
Erossen /o\ megoldas.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
+1
- A hozzászóláshoz be kell jelentkezni
brotip: use file cache for moar speed. Problem? :D
- A hozzászóláshoz be kell jelentkezni
[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 hozzászóláshoz be kell jelentkezni
a RAM mar nem eleg draga, masbol kell minel tobbet elvinni :D
- A hozzászóláshoz be kell jelentkezni
Ezek szerint a disk IO-ra gyúrnak?
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ez azt hiszem mindent elmond mindegyik tamogatott platform prefetchelserol...
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni