Kritikus hiba az MPlayer-ben

MPlayer

Az MPlayer távolról kihasználható sebezhetőségben szenved. Az Open Source Computer Emergency Response Team (oCERT) figyelmeztetőt adott ki a problémával kapcsolatban. A hiba sikeres kihasználása akár tetszőleges kódfuttatásra is alkalmat adhat. A hiba az összes MPlayer verziót - beleértve a legutoljára (2007 októberében) kiadott 1.0-rc2-t is - érinti. Patch készült a problémára. 25 órával ezelőtt be is került a forrásfába. Érdemes foltozni / checkout-olni és javított verziót pörgetni.

( denes | 2008. 10. 01., sze – 14:22 )

Nem tudom mi ebben hir. En pl. amikor par napja yuv4mpeg formatumot probaltam lejatszani, uzembiztosan merevre fagyasztotta az egesz gepet (vagy lehet, hogy csak a monitort sikerult lekapcsolnia), pedig nem is root-kent csinaltam.
Mondandom lenyege csak annyi lenne, hogy azok az emberek kisse furcsan gondolkodnak, akik sebezhetoseget keresnek az mplayerben es ahelyett, hogy kuldenenek ra egy javitast, inkabb ugyanakkora energiabefektetessel irnak egy advisory-t, gyakorlatilag csak hogy reklamozzak magukat.

- Use the Source Luke ! -

a hibat egy mplayer fejleszto javitotta, a hiba jelentese utan. a hiba bejelentoje nem javitotta, hanem inkabb PoC-ot irt ra - ami amugy tobb munka, tehat eleg rohejes szerintem. a timelineban ez mind le is van irva, lehet, hogy gondok vannak az olvasasi kepessegeiddel?

- Use the Source Luke ! -

most vagy en fogalmazom rosszul erthetoen, vagy tenyleg mindenki hulye korulottem.
az mplayerben felo, hogy meg most is rengeteg hiba van (erre irtam is peldat az elejen), bizonyara sokuk tavolrol ki is hasznalhato. na most ahelyett, hogy ezekre a hibakra egyenkent advisory-t es PoC-t irnak, amit 20 hirportal publikal, ertelmesebb lenne ha siman bekuldenenek javitast a projectnek, ezzel kevesebb munkaval tobb jot tennenek az emberisegnek. mert ha az ember attol lesz security expert, hogy az mplayerben kihasznalhato hibat talal, akkor en is es meg igen sokan security expertek, akik eddig nem is tudtak rola.

- Use the Source Luke ! -

"most vagy en fogalmazom rosszul erthetoen, vagy tenyleg mindenki hulye korulottem."

Hianyolok egy harmadik lehetoseget.

"az mplayerben felo, hogy meg most is rengeteg hiba van (erre irtam is peldat az elejen)"

Igy van, viszont csak egy kis szazalekuk relevans biztonsagi szempontbol.

"na most ahelyett, hogy ezekre a hibakra egyenkent advisory-t es PoC-t irnak, amit 20 hirportal publikal, ertelmesebb lenne ha siman bekuldenenek javitast a projectnek"

Nem lenne ertelmesebb, mert
a.) advisory nelkul nem tudnanak rola a juzerek
b.) PoC nelkul nem tudnak a juzerek (meg a fejlesztok), hogy mennyire kritikus/mire hasznalhato ki/sikerult-e javitani/nem kamuzik-e a tisztelt bejelento
c.) egy korrekt vuln. reportbol a patchet megcsinalni akar 10 percbe is beletelhet

"ha az ember attol lesz security expert, hogy az mplayerben kihasznalhato hibat talal, akkor en is es meg igen sokan security expertek"

Na, muti (PoC-al, ofcoz).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Igy van, viszont csak egy kis szazalekuk relevans biztonsagi szempontbol.
PoC nelkul nem tudnak a juzerek (meg a fejlesztok), hogy mennyire kritikus/mire hasznalhato ki/sikerult-e javitani/nem kamuzik-e a tisztelt bejelento

na most ha van akarmilyen overflow, vagy ilyesmik - bevallom nem vagyok valojaban security expert - akkor eleg jol meg lehet tippelni, hogy az kihasznlhato, legfeljebb tul ovatosak voltunk. Es nem hiszem, hogy az mplayer csapat a commithoz feltetelul szabna a PoC megletet minden haromsoros hibajavitashoz - bar az igaz, hogy egy publikus PoC talan meggyorsitja a patch commitjat.

Na, muti (PoC-al, ofcoz).

mondom, merevre fagyott a gep 3-bol haromszor (aztan mar nem probaltam, hiaba, tanulekony vagyok :) ). Az denial of service tamadasnak elmegy nem (de ha ezt sikerult, akkor nyilvan lehet kevesbe feltuno tamadast is kieszkozolni a modszer finomitasaval)? Amugy HD yuv4mpeg pipepal lehet ilyet csinalni, bekopiztam volna a commandline-t ha benne lenne a historyban (a merevrefagyas soran elfelejtette visszairni a lemezre a bash historyt), viszont most nem fogok emiatt resetelni.

- Use the Source Luke ! -

"na most ha van akarmilyen overflow, vagy ilyesmik (...) akkor eleg jol meg lehet tippelni, hogy az kihasznlhato, legfeljebb tul ovatosak voltunk"

Kodfuttatasra? Kozel sem.

"Es nem hiszem, hogy az mplayer csapat a commithoz feltetelul szabna a PoC megletet minden haromsoros hibajavitashoz"

Az mplayer csapat eppen lehet hogy pont nem, de ezzel inkabb ok vannak kisebbsegben.

"mondom, merevre fagyott a gep 3-bol haromszor"

Jode ez onmagaban semmit sem mond. Ahhoz, hogy ebbol valami legyen, ahhoz eloszor is ki kellene deriteni, hogy ez tenyleg mplayer bug (es nem pl. videokartya-driver, vagy Xorg, ami pedig gyanus, hogy de), aztan megnezni egy debuggerrel (es megkeresni forrasban, ha van), hogy egeszpontosan mi ez, pontosan mi kell az eloidezesehez (nem a "nezd a matrix3 legujabb bluray-es warez rls-et, es a 28. percnel ha kicsit visszatekered..."-szintu, hanem amit le lehet kovetni a forrasban), mit lehet vele hogyan es mire atirni, aztan pedig osszerakni valamilyen inputot, ami ezt triggereli is (es ez a PoC).

Egyebkent azt erdemes meg meggondolni, hogy ez az advisory-PoC-stb moka egy bevett iparagi gyakorlat, ami ugyanigy mukodik closed-source cuccoknal, vagy szolgaltatasoknal (pl. gmail) is, ott pedig nem igazan mukodik a patchkuldes.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

A lenyeg, hogy az mplayer - neha filozofiai okobol - nem biztonsagos. Ezek utan lehet kuldeni 1000+1 advisoryt, de egyszerubb siman kijavitani a hibat.

Egyebkent tudom mi az a PoC, es azt is sejtettem, hogy a video driver (fglrx) hathatos segitsege nelkul nehez volna merevre fagyasztani a gepet sima userkent.

Ami az bevett iparagi gyakorlatot illeti, epp azt mondom, hogy pl. az mplayer eseten - ami deklaraltan nem biztonsagos, ez mindig benne volt a FAQ-ban is - nem ez a celravezeto, szerintem.

Amugy nem hiszem, hogy alapveto velemeny kulonbseg lenne koztunk, csak legfeljebb bizonyos reszletekben :)

- Use the Source Luke ! -

Elmagyarazom, mert latom egy kicsit lemaradtal. A hibam csak egy pelda, ilyen keves informacioval meg advisoryt sincs ertelme irni. A problema gyokeret megkeresni viszont en nem fogom, mert nem erdekel - de ha megtennem azt nem egy advisoryban latnad viszont, es utana nem PoC-ot irnek, hanem kuldenek egy ketsoros patchet az mplayer listara.

- Use the Source Luke ! -

pontosan mi kell az eloidezesehez (nem a "nezd a matrix3 legujabb bluray-es warez rls-et, es a 28. percnel ha kicsit visszatekered..."-szintu, hanem amit le lehet kovetni a forrasban)

Mindig kivancsi voltam ra, hogy azok, akik csinaltak mar ilyet, hogyan csinaltak. En csak az idezett kerulendo modon tudnam a problemat megfogalmazni, de aztan hogyan lehet tovabblepni? (Csak egy peldat irjon valaki, pls, hogy halovany elkepzelesem legyen rola.) Holtig kell tanulnom, pedig nem vagyok jo pap... :) De tenyleg nem tudom, hogy hogyan lehet ilyet. Es erdekel.

remote debuggerben futtatod az mplayert, igy mikor meghal tudod mi hivodott meg (ha tenyleg mplayer bug)

igy mar megvan a kodreszlet ami miatt fagyott, utana visszakoveted hol kap erteket, ez az input mely reszebol all elo (vagy ha csak bent all elo, akkor az input hogyan befolyasolja ezt, mintha egy call-grapht csinalnal, csak a valtozot figyeled), aztan csinalsz olyan inputot ami kihasznalja :)

ez a mesterseges hibaeloallitas nagyjabol, aztan a PoC mar nincs ilyen messze innen, de mondom, ez local DoS max (mar mint ha lefagy a gep), remote mar izgibb csinalni [streambe agyazol olyan inputot ami ezt okozza], remote kodfuttatas az nehezebb dolog.. :)

> uzembiztosan merevre fagyasztotta az egesz gepet

mar bocs, de erre az mplayer nem kepes sajnos (ha kepes lenne, akkor benne lenen a man-ban, pl. mplayer -hangup: crash your box). sot, linuxon semmilyen userspace-ben futo program se. talan ha rootkent fut es belepiszkal /proc/kmem-be, ugy esetleg. de az mplayer nem csinal ilyet.
(na jo, regebbi grsec-es kernelen a splice-s bug exploitja userkent futtatva lefagyasztotta a kernelt.)

ha nalad szetfagy a gep, az inkabb attol lehet, hogy valami videokartya drivered szar, es az mplayer csak triggereli a hibat benne... ilyen hibakat mi is talaltunk anno eleg sokat, foleg az nvidia binaris driverevel lehetett szepen fagyizni, eleg volt pl nem 4-el oszthato szelessegu Xv ablakot nyitni. De azok mind egyertelmuen driver bugok voltak...

A'rpi

Arra probalok celozni, h kb. 10 oldalon at szidod azt a szerencsetlent, hogy mert irni egy cetlit a bugrol, ahelyett h kijavitana, erre utana 5 oldalon kifejted mekkora szar bughalom az mplayer, reszletezed az okokat es az egyutt allasokat, de a hiba kijavitasa mar snassz. Valahogy nem latom a ket cselekedett kozott a kulonbseget, sot. De a tobbit mar inkabb nem feszegetem, nincs kedvem. :)

---
pontscho / fresh!mindworkz

( nevergone v | 2008. 10. 01., sze – 14:39 )

Mondjuk jöhetne már egy új release...

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

>mplayer megmaradt ugyanazon a szinten, ahol kb. 5éve volt

mondjuk egyetertek: a regebbi mplayer is lejacca amit az uj (nem exotikus formatumra gondolok), egyes esetekbe talan jobban/gyorsabban is.

de szerinted a tobbi hova huzott? vlc tulkepp ugyanazt tudja, de van guija ami nalam/nekem nem igazan jott be van 1-2 dolog amiben jobb es forditva

te mit szeretnel latni az mplayer be?

--
http://blog.sartek.net

Ezek szerint 5 éve nemnagyon használtad :-) Mindenesetre - bár kétségtelen, hogy most leginkább alvó project- de még mindig megállja a helyét, úgy is mondhatnánk, hogy elég lassan érték/érik utol. Mondjuk anno elég magasra rakták a lécet a fiúk. Sorba kipróbáltam minden lejátszót ami szóba jöhet (mert tény, hogy mplayerrel sem probléma nélküli az élet), beleértve időről időre pl a vlc bétáit is, de nekem valahogy sosem volt szerencsém velük. A billentyűzetről vezérlést vezérlést meg sehol nem bírták ilyen kényelmesre szabni szerintem.
Az egyetlen problémám jelenleg az mplayerrel, hogy HD filmekben nem lehet vele olyan finoman seekelni, mint amit megszoktam. De legalább rászoktat arra, hogy végignézzek egy filmet :-D

Hát igen nekem is a HD filmek seekelésével volt gondom. Ám, hogy megvédjem MPlayert (minek?) anno 1 magos AMD Athlon64-es procimon az 1920-as HD filmek csak MPlayerrel futottak nézhetően.

De nagy előny volt számomra, hogy az akciós DVD-k reklámjai simán áttekerhetőek voltak... :-)

@@
"You can hide a semi truck in 300 lines of C."
Debian Lenny 2.6.25-2-amd64

( psc | 2008. 10. 01., sze – 14:47 )

Forgat nekem valaki Mac OS-ra egy frisset? :-I

( mrev | 2008. 10. 01., sze – 15:23 )

Nem értek hozzá, azért kérdezem: Miért az mplayer hibája ez? Bárki írhat olyan programot, amibe direkt beleteszi a kódot, amit az mplayerben most hibásnak mondanak, kijátszva ezzel a Linux biztonsági rendszerét. Szerintem ez azt mutatja, hogy a Linux a lyukas, és ezen nem változtat, hogy kijavítják-e az mplayert, vagy nem.
--
CCC3

Metafora: Tegyük fel, hogy van egy biztonsági zár, amit sajnálatos módon ki lehet nyitni a Dunamenti Pálcikaművek által gyártott hurkapálcikákkal. Mi most a teendő.

1) Javítunk a biztonsági záron.

2) A Pálcikaművek ezentúl gombos végű kivitelben gyártja a pálcikákat.

A második opcióval az a baj, hogy vannak a piacon régi pálcikák, ráadásul lesznek, akik letörik az új pálcikák végét, vagy egyenesen legyártják maguknak a gomb nélküli változatot.
--
CCC3

Jó, akkor nem Linux, hanem tetszőleges olyan os, amin az mplayer fut. Ha a Linux mentes a hibától, azt külön érdemes volna említeni. Egyébként egyáltalán nem akartam a Linuxot ócsárolni. Amúgy, ha egy szoftverben hibát találnak, az nem olyan nagy meglepetés. Nyilván az mplayerben is fognak még többszáz hibát találni. Attól az még egy fontos és jó program. Ilyenek a programok. Hibásak.

Konkrétabb? A Linux a biztonsági zár, az mplayer a hurkapálcika, a végén a gomb a patch. Azt is írjam, hogy mi a metafora?
--
CCC3

Ok. Nincs több metafora.

Nekem a hírből az jött le, hogy az mplayert futtató rendszer távolról feltörhető. Nem jó ez így. Megoldás-e a hibára, ha kijavítják az mplayert? Szerintem nem. Tegyük fel, hogy egy rosszindultaú alkalmazott backdoort akar nyitni a vállalata szerverén. Ehhez annyit kell tennie, hogy fordít magának egy patch nélküli mplayert és megnéz egy jó filmet.

Legalábbis a hír szerint (az én buta értelmezésemben).
--
CCC3

"Nekem a hírből az jött le, hogy az mplayert futtató rendszer távolról feltörhető."

Ez igy van (es ebbe implicite az is beleertendo, hogy feltores==tavolrol tetszoleges kodot tud futtatni az mplayer(t futtato user) neveben).

"Tegyük fel, hogy egy rosszindultaú alkalmazott backdoort akar nyitni a vállalata szerverén. Ehhez annyit kell tennie, hogy fordít magának egy patch nélküli mplayert és megnéz egy jó filmet."

De akkor mar miert nem fordit maganak egy backdoort?

"Nem jó ez így."

Tenyleg nem. Mit javasolsz?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Szerintem az alábbi a helyzet:

Attól remote ez az exploit, hogy kreálhatok egy speciális streamet (http://.../porno.avi), amit ha megnézel, akkor a gépeden futtathatok kódot a nevedben, a te jogosultságaiddal.

A vállalati szerverre ha backdoort akar tenni az alkalmazott, akkor egyszerubb, ha fordit maganak egy backdoort es felteszi. Ha ehhez nincs joga, akkor az mplayer hiba kihasználásával sem lesz.

Köszönöm mindenkinek, aki elmagyarázta. A "tetszőleges kód" az mplayer futtatójának uid-je alatt fut. Ez se jó, de azért nincs az os biztonsági rendszere "kijátszva", mintha rootként futna, ahogy először gondoltam. Ez viszont nem annyira kritikus, nyilván sok hasonló van. Lejjebb szó van a Paxról, ret2libc-ről, látom, vannak próbálkozások és nehézségek.
--
CCC3

Hja, csakhogy egy otthoni gépen (tipikus filmnézős) nem a rendszer épsége a lényeg, mert az bármikor újrarakható, hanem a felhasználó adatai. Úgyhogy hiába nem root, pont az értékes dolgok vesznek el.

--
"There are two kinds of people in this world, and you're not one of them."

Az "mplayert futtató gép" egy speciálisan erre a célra készített videofile helyi userrel való lejátszatásával "törhető" csak fel. Social engineering ("te Béla néddmámeg küldöm a linket/filet"), vagy rosszindulatú weboldalba beépített stream kell hozzá.
Attól még hogy a mplayer program fenn van a gépen és esetleg nézel rajta valamit, nem fog titkos backdoor portot nyitni..........

Amire te gondolsz, hogy "nem az mplayert kéne javítani hanem az OS-t", a mandatory access control (kb.: egy program előre beállított szabályzat alapján csak azt csinálhatja, amire a normál működéséhez szükség van, bármi más tiltott neki). SElinux, apparmor kifejezésekre keress rá ha érdekel a téma.

Nem szeretem a felesleges személyeskedést (ellenben rühellem), de végigolvasva ezt azt egészet olybá' tűnik, hogy nem igazán vagy képben (igaz én sem) azzal kapcsolatban, amiről itt szó volt, ezért érdemben csak egy "lol" -ra tellett. Szép dolog a metafóra és a hurkapálcika, illetve a "mi lenne ha" elméleti hozzáállás, de attól tartok, nem mutat jól egy gyakorlati probléma megoldásának vitája során.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

a kérdés szerintem laikus szinten jogos (én is ezen a szinten vagyok és engem is érdekelne a válasz)
szóval nem lehetne úgy megírni a kernelt, hogy egy felhasználói program ne lehessen alkalmas ilyesmire? mondjuk nem férne hozzá semmihez ami nem az ő illetősége, így hogy maradjunk az mplayer-es példánál, csak a videolejátszás fagyna el, de kódot futtatni semmilyen szinten ne lehessen.
Végül is vannak ilyen jellegű dolgok: pl a chrome legutóbb de még a vista is használ sandboxot. hogy ez mennyire jó megoldás elvileg illetve gyakorlatilag, hogy mennyire lehet kernel szinten általánossá tenni, hogy mennyire erőforrásigényes, vagy mennyire hülyeség azt nem tudom, de a kérdés szerintem jogos.

-----------------------------
Ubuntu 8.04

"szóval nem lehetne úgy megírni a kernelt, hogy egy felhasználói program ne lehessen alkalmas ilyesmire?"

Igen, es nem. Egyreszt tudsz olyat, hogy felhuzol egy policyt, hogy az mplayer ide nyulkalhat, oda meg nem, fuggetlenul, hogy mit futtatnak a neveben (pl. grsec), vagy megprobalhatod magat a kodfuttatast megakadalyozni (pl. PaX). Viszont egyik sem tokeletes.

"a vista is használ sandboxot"

Ja, de az csak sandbox, a kodfuttatast nem akadalyozza meg. (Ha van valami local priv. esc.-re alkalmas exploitod, akkor azt ebben a helyzetben jol el lehet loni).

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

A válasz az, hogy igen is, meg nem is. Az ilyen kódfuttatások arról szólnak, hogy a hibás program (jelen esetben az mplayer) olyan helyre ír adatot, ahova nem lenne neki szabad. Egy kretén példán bemutatva: a videólejátszó alkalmazás lefoglal magának egy helyet a memóriában, arra a célra, hogy oda beteszti a videó feliratának egy sorát, amire mondjuk azt mondja, legyen 1024 bájt. Ebbe belefér minden normális felirat, de ha geci vagyok, és olyan feliratot csinálok, aminek az egyik sora ezt meghaladja, több dolog történhet. A jó eset, hogy a program ezt kezeli, és max annyi történik, hogy nem látom a felirat egészét. A rossz pedig ha nem kezeli. Ilyenkor fogja, és a feliratot elkezdi bemásolni a kijelölt memóriaterületre. Az első 1024 probléma nélkül felmegy, a probléma ezután kezdődik. Ugyanis ha memóriában a ezen 1024 bájt után megint egy puffer áll, akkor abba íródik bele, holott lehet, hogy az a log puffere. De állhat ezután olyan adat is, ami a későbbiekben utasításként fog értelmeződni. Ekkor olyan feliratot csinálok, ami gépi kódot töltet erre a memóriaterületre, így fordulhatnak elő az ilyen hibák.

A jelenlegi felfogás az, hogy minden (nem kernel szintű) program egy virtuális gépet lát, ami többek között azt jelenti, hogy processz ami memóriaterületet lát, azt csak ő látja, és ő sem látja másik folyamat memóriaterületét. Ha memóriára van szüksége (allokálna magának), akkor az operációs rendszertől kap, ami nyilván tartja, hogy milyeneket adott ki (egyszerre egy nagyobb címtartományt ad ki, ún. lapokat), és gondoskodik arról, hogy azt más user-space program ne lássa. Erre van szoftver, illetve leginkább hardvertámogatás. (Az előző példánál maradva így az is megeshet, hogy amikor túlírom az 1024 bájot, akkor oda írnék, ami az oprendszer szerint nem az egyim, ekkor keletkezik a segfault, és a process futása megszakítódik).

A megoldások alapvetően mind ugyanazon sémára dolgoznak: válasszuk szét a végrehajtandó kódot és az adatot. Ilyen megoldások a Harvard architektúrájú rendszerek, ahol külön van utasítás-memória és adatmemória. Ez jelenleg elsősorban mikrovezérlőkre jellemző. (Ezeknek a cpu-knak is gyakran van olyan utasítása, amivel a két tár szerepe megcserélhető (debug okokból), de ilyenkor az kell, hogy az utasítás-memóriába eleve legyen ilyen utasítás, ami release buildeknél nem jellemző, illetve hogy az adott cpu-prioritás szinten ezen utasítás legyen engedélyezve.) Megjegyzendő, hogy a modern processzorok L1 cache és alatt ugyan harvard architektúrájúak, csak kifele mutatnak Neumann architektúrát, de a cache elévülési mechanizmusok okán a D-cache tartalma bármikor átkerülhet az I-cachebe.

A másik, sok processzoron implementált fícsör a memórialapok futattás-megtagadás bittel való ellátása. Ekkor már fordítás-időben az adatnak fenntartott helyen megtiltódik a kódvégrehajtás (ez is hardveres védelem, ilyenkor a processzor ugyanúgy értesíti az operációsrendszert, mint pl. laphiba esetén). Ezzel ugye megint több gond van: egyfelől nem véd, mert még mindig írhatok utasításokat tartamazó lapokra, legfeljebb megnehezíti azt, de sok körültekintést igényel. (pl: az allokálni kívánt terület adatnak lesz (triviális), vagy esetleg valamilyen dinamikusan linkelt függvénykönyvtáré lesz, ami ugye megint végrehajtható).

Szóval a dolog kb. ennyi, remélem még mások is hozzátesznek.

Tűnődtem kicsit a dolgon. Amit írsz, azt jelenti, hogy az os védi (védené) egymástól a processzeket, de nem védi őket saját maguktól. Nekem olyan emlékeim vannak, hogy az os ügyesen ugyanazt a (readonly?) utasítás-memóriát több processznek is rendelkezésre bocsátja, ezzel szemben minden processz saját elkülönített adat-memóriával rendelkezik. Vagyis, a többszörösen használt kód csak egy példányban van benn a memóriában. Namost, ha ez igaz, és a programok mégis írni tudnának a kódszegmensbe, akkor egymás ellen sem volnának védve.

Úgy tudom, már a 286-os processzorok is tudták így védeni a kódszegmenst.

Még tovább kapirgáltam az emlékeimben, és felderengett, hogy az os-ek még ügyesebbek: mindaddig közös a közösen használt memória, amíg az egyik processz nem módosít rajta. A módosítás hatására másolat keletkezik a kérdéses lapból, és az utak szétválnak.

Mindezek nekem azért azt mutatják, hogy a megoldást az os szintjén kellene keresni. Azt várni, hogy minden egyes felhasználói program tökéletes lesz, elég reménytelen.
--
CCC3

Nem csak az lehet probléma, hogy a program felülírja az utasítás memóriát.
Az egyik legelterjedtebb hiba az szokott lenni, hogy az a bizonyos 1024 bájt nem az oprendszertől lett kérve memóriaterület gyanánt, hanem lokális változóként lett lefoglalva, azaz a veremben van.

A veremről két dolgot kell még tudni: visszafelé töltődik, azaz a nagyobb memória címtől a kisebb felé, illetve fv hívásnál a visszatérési cím is ebben tárolódik. Emiatt, mivel a visszatérési cím előbb lett a verembe rakva mint a lokális változók, ezért a memóriában az 1024 bájtos lokális változó mögött van, azaz ha túlírom az 1024 bájtot, akkor az elsők között lesz, ami felülíródik. Azaz lényegében tetszőleges címre ugorhat a program a fv visszatérésekor. Ekkor tudom elérni, hogy a program adatterületen lévő programot futtasson.

Mielőtt valaki azt mondaná, hogy: "Remek, akkor ne engedjük a programoknak, hogy olyan területnek adják a vezérlést amit előtte írtak", jusson eszébe a Java, vagy bármilyen JIT fordító...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Igen, a memóriaszegmenseket meg lehet jelölni, többek között, hogy futtaható -e a kód rajta, illetve írható -e.

Előállhat olyan helyzet, amikor több processz fér hozzá ugyanahhoz a memóriaterülethez. A legtriviálisabb a megosztott memória, mint IPC mechanizmus, amikor a processzek megkérik az operációs rendszert, hogy szeretnének olyan címtartományt kapni, ahova mindketten írhatnak és olvashatnak. Amit a többszörösen használt kódról írsz, ott azt gyanítom, a megosztott könyvtárakra gondolsz. Ezek olyan függvénykönyvtárak, amiket a programok közösen használhatnak, és az operációs rendszer kezeli őket. Jó esetben ha lét program használja ugyanazt a libet, akkor az csak egyszer fog a memóriába betöltődni, és a címét az OS mappeli be igény esetén a processz címtartományába. Ilyen könyvtárak használatával oprendszer hívás ezek betöltése is. A másik, amire gondolhattál, az pl. a fork() metódus, ami a szülő processz pontos másolatát hozza létre, ami tudomásom szerint valóban egy on-demand copy, azaz csak módosítás után másolódik.

Azonban a lényeg, ami ezen dolgok mögött van, az a hardver. 386-on már biztos, de lehet, hogy előtte is, a cpu prioritási szinteket kezel. Ring0 -án minden cpu-utasítás meghívjató, itt fut a kernel. Ring3-onn futnak a user-space programok. Itt már az utasításkészlet egy részhalmazát lehet csak elérni. (Van ring1 és 2 is, itt elvileg egyéb driverek futnak.)

Tehát mi történik egy on-demand copy esetén? A futó, user-space (ring3) process kiad egy cpu-utasítást (CALL FAR), aminek hatására egy szoftveres interrupt keletkezik. Interrupt az egy olyan esemény, aminek hatására a CPU lementi, hogy éppen hol tartott a futással, és átadja a vezérlést egy erre kialakított szoftver-rutinnak (kernel implementálja). Az interrupttal egy időben a CPU ring0-ra, azaz teljes módra vált. Az interrupt hatására a vezérlés tehát a kernel megfelelő kezelő-rutinjára ugrik, ami eldönti, hogy az adott process jogosult -e az adott rendszerhívásra. Nem esetén kezeli a hibát (lelövi a processzt), igen esetén pedig elkezdi a rendszerhívás végrehajtását (igény esetén futási szintet vált, pl driver-kód hozzáférésénél), visszateszi a processz memóriaterébe a visszatérési értéket, majd visszatölteti a CPU-val az eredeti állapotot, azaz visszaadja a vezérlést és visszaáll ring3-ra. Ha az utasítás következménye egy on-demand copy, akkor megjelöli az adott szegmenset leíró struktúrában, hogy az nem írható mert on-demand, és ezt bemappeli az új processz címtartományába. Ez a struktúra nem azonos a CPU által látott, egyszerűbb struktúrával, ez kernel-szinten van kezelve, illetve másolódik át a memóriakezelő egységbe. Tegyük fel, hogy az egyik processz írna erre a területre. Ekkor a CPU-ban megint egy interrupt keletkezik (=>ring0), mert olyan művelet lett volna kieszközölve, amit nem tud végrehajtani. Ezt megvizsgálva a kernel látja, miért keletkezet, lemásolja az adott területet mégegyszer, és eltünteti a szegmensek leírójáról, hogy nem írható, mert on-demand, majd átmappeli az új szegmenst valamelyik processzhez (kitörölve a régit), és frissíti a CPU-ban az adatokat, majd visszatér.

Szóval elvileg a kódvédelem megoldható bizonyos mértékig processz szinten is, az utasítás-terület csak olvasható, és az adatterület nem futattható megjelölésével, erre os, fordító és programozói támogatás kellene, pl. JIT-eknél a heap-re foglalásnál kezelni a futtathatóság engedélyezését. Hogy miért nincs ez így, hát az passz.

( seregr | 2008. 10. 01., sze – 20:20 )

/Szerk./ Válasz erre: ( sartek | 2008. október 1., szerda - 16:03 )

Lejátszás gyorsítás - lassítás, kockánként ugratás, pillanatkép felvétele.
Audio hangsáv menet közbeni váltása /mondjuk ez lehet csak nekem nem megy/.
Pillanatnyilag ennyi jut eszembe.
A gui engem szabályosan zavar, ezért is használom ezt a lejátszót.

> Lejátszás gyorsítás - lassítás

man mplayer, az itteni lista utolsó 3 eleme a tied, ha nem csalódom.
keyboard control
<- and ->
Seek backward/forward 10 seconds.
up and down
Seek forward/backward 1 minute.
pgup and pgdown
Seek forward/backward 10 minutes.
[ and ]
Decrease/increase current playback speed by 10%.
{ and }
Halve/double current playback speed.
backspace
Reset playback speed to normal.

> kockánként ugratás
ez is itt van:
.
Step forward. Pressing once will pause movie, every con-
secutive press will play one frame and then go into pause
mode again (any other key unpauses).

Szóval ha jól gondolom, az általad hiányzónak mondott fícsörökről mindről megmutattam, hogy tudja, úgyhogy most te mutasd meg, hogy mi módon kell futás közben hangsávot váltani, mert ezt nem találtam meg a manual-ban.

Kiderült hát, hogy figyelmesebben kell olvasnom.
Eszembe jutott még egy: Az após gépére évekkel ezelőtt valami régi Suse rendszerre fordítottam mplayert. Ez a szám billentyűkkel képes volt a videó fényerő, kontraszt, gamma beállításait lejátszás közben módosítani. Nomost ezt azóta sem sikerült reprodukálni a saját gépemen. Jelenleg ez még elérhető valahogy?

Nekem utoljára a funkció Radeon7000-rel (DRI project CVS-ből a drivert felgányolva) működött, nvidiával nem. Azóta (évek óta) nem is próbálkoztam vele mert nem volt rá szükségem.

A -vf eq2 viszont megoldja a problémát, természetesen nem a videokártya képességeit használva.

( mrev | 2008. 10. 01., sze – 20:28 )

Érdemes foltozni / checkout-olni és javított verziót pörgetni.

Nem teljesen ide tartozik, de éppen tegnap próbáltam Intrepid-en mplayert (1.0rc2) fordítani. Nem fordul. Szvsz a gcc 4.3.2-ben bekövetkezett "fejlesztések" miatt.
--
CCC3

( 4fonya | 2008. 10. 01., sze – 20:43 )

Egyszer az MPlayer fejlesztője tett egy olyan megnyilatkozást miszerint ha minden eljárásban ellenőrizgetnék a mutatók értékeit akkor tetemesen lelassulna a program. Ráadásul ha ezt megtennék, a készen használt dekóder modulok - acm, ax, dll-ek és mások - belsejében még mindig bőven akadnak "elvarratlan" szálak, amik biztonsági kockázatokat jelentenek. Tehát bármit tesznek akkor is marad még hiba.

Az lehet hogy en voltam, mindenesetre igy van.

Pl. ott a libmpeg2 es az ffmpeg12 codec. A kulonbseg az, hogy az elso gyorsabb, mert nem ellenorizget folyton, a masodik viszont nem szall el a hibaktol, sot megprobalja a legtobbet kihozni a hibas adatokbol is (ne essen szet teljesen a kep, csak par kocka, ha csak par bit hiba volt).

De ettol meg a halozati reszekben igyekeznek torekedni az ellenorzesekre es a biztonsagra, ott ugyse nagyon van sebessegkritikus kod (a szuk keresztmetszet a halozat savszel), es itt vedhetok ki a tavoli hibak. Persze ettol meg ha valaki letolt egy megfeleloen preparalt x264 mkv-t es lejatssza az siman beszophat barmit...

A'rpi

Hm, de nem úgy van, hogy a csilliárd géjgahertzes processzorokon és külön hűtött videokártyákon halál mindegy, hogy hány ellenőrzés van? Ha valaki filmet néz, úgyse csinál mást, az átkódolás meg legfeljebb kicsit lassabb lesz.

Nem tudod, mi most az mplayer projekt célja? Mi az a gép, amin még akarják hogy elfusson? Én mondjuk mindenhová azt rakom.

Reszben igaz, de ahogy a cpu-k erosodtek, kozben a codecek is, a h264/x264 dekodolashoz tobbszorosen erosebb cpu kell mint mondjuk divx-hez.
Az igaz, hogy kis felbontasu, divx/mpeg cuccokat a mai gepeken agyon ellenorizgethetne akkor is maradna cpu mellette quake-zni, de egy HD felbontasu h264 filmnel minden orajelre szukseg van hogy birja akadas nelkul, meg egy core2 procin is.

Azt nem tudom mi a celjuk, de szerintem nincs ilyen :)
Igazabol ahogy en nezem az mplayert nem is fejlesztik mar evek ota, csak bugfixelgetik. Az ffmpeg fejlodik csak, azt is par ember csinalja, Niedermayer-en kivul foleg google SoC-os emberek.

A'rpi