2. Fórumok
  3. Processzorok, tuning
  4. Vírusvédelem a processzorokban
  5. (téma lezárva)
Legfrissebb anyagok
PROHARDVER! témák
Mobilarena témák
IT café témák
GAMEPOD témák
Keresés

Aktív témák

  • #85 Darth Vader csendes tag tocsa #83
    #85
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Darth Vader

    csendes tag

    válasz tocsa #83 üzenetére

    Semmi gond :))))

  • #84 Darth Vader csendes tag tocsa #82
    #84
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Darth Vader

    csendes tag

    válasz tocsa #82 üzenetére

    :)) Nem huztam fel magam. Ha te igy erezted, akkor bocs. Semmi bajom sincs veled :))))
    Elolvasa alatt azt ertem, h eloszor en mindig ugy olvasom az ilyen konyvet, mint egy regenyt. Elejetol a vegeig. Majd utana, ha valami erdekel ujra, akkor tudom, h hol kell kinyitni. Igy egyuttal mar teljesen tisztaban is vagyok az adott proci kepessegeivel.
    Ha valaki nem olvassal el legalabb egyszer teljesen a konyvet, akkor honnan tudhatja, h mit tud a proci valojaban? :)))
    Ezert mondtam azt, h sok programozo csak szovegel(itt nem rad gondolok), mikorzben fogalma sincs az adott proci igazi kepessegeirol.
    Ha feluletesen olvasol el egy ilyen konyvet, akkor pl fel sem tunik, h az adott proci tud szegmentalni es milyen vedelemmel rendelkezik.
    Sokan szerintem ugy gondoljak, h a szegmentalas elavult dolog, ezert ezt a reszt, adott esetben ki is hagyjak, at se nezik. Igy mondanak utana butasagokat. :(((

    uDv,
    Pedro

  • #80 kisfurko senior tag tocsa #78
    #80
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    kisfurko

    senior tag

    válasz tocsa #78 üzenetére

    Szia!

    No, itt van a kutya elásva:

    ''These patches mostly operate by using the x86 segmentation feature to set the code segment 'limit' value to a certain fixed value that points right below the stack frame. The exec-shield tries to cover as much virtual memory via the code segment limit as possible - not just the stack.''

    Azért állítják a kód szegmens határait, mert pont az határozza meg, hogy melyik rész futhat. Ami azon kívül van, az nem. Itt tehát a patch a szegmentálást használja. Mivel nem ismerem a Linux kernelt, ezért csak tippelni tudok, hogy valószínűleg tényleg nem használ szegmenseket, ezért kellett ez a patch.
    Szóval a probléma nehézsége nem abból adódott, hogy egyáltalán nehéz megcsinálni, hanem abból, hogy csak lapozással kell megoldani. Nyilván nem kellett volna a patch, ha a kernel írói is akarták volna használni a szegmentálást, mert akkor maguk implementálták volna a patch tartalmát. :)
    Nem szabad elfelejteni, hogy a Linux platformfüggetlen szeretne maradni, tudomásom szerint viszont nincs másik processzor, ami ehhez hasonló szegmentálást biztosítana.

  • #79 Darth Vader csendes tag tocsa #78
    #79
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    Darth Vader

    csendes tag

    válasz tocsa #78 üzenetére

    Kedves Tocsa,

    Mar ne is haragudj, de te olvastal mar eredeti Intel 386-os konyvet????
    Egyebkent ajanlom figyelmed be az Understanding Linux Kernel cimu muvet. Ott leirtak, h miert nincs segmentalas a kernelben!!!!
    Egyebkent pedig igen is van vedelem. A gond az, h a mostani ujitas mar a lapok leirojaba is beleteszi azt, amit eddig csak a szegmensleirokban volt benne.
    Olvasd el jobban amit ide masoltal. Ott is pont errol van szo!!!
    Epp ezert, eloszor _Te_ gondolkozzal es csak utana irj ilyen stilusu hozzaszolast.
    Egyebent az AMD modszere sem csodaszer! Csak akkor segithet, ha tenyleg hasznalni is fogjak. De ettol meg ugyan ugy lesz buffertulcsortdulas.
    Az AMD valszeg azert dontott e mellett, mert rajottek arra, h sok olyan programozo van, aki _nem_ olvas el egy konyvet rendesen, csak feluletesen. Ennek meg is van a kovetkezmenye. Egyebkent pedig a 2.0.x-es kernelben meg van szegmentalas, h jol emlekszem.
    Az altalad felhozzott projectek pedig azert vannak, mert a linux kernel olyan amien. Mivel Linus nem hajlando valszeg segmentalni, ezert maskepp kell megoldani a problemat. Ami igy olyan lett, amilyen. :(((

  • #73 kisfurko senior tag tocsa #72
    #73
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    kisfurko

    senior tag

    válasz tocsa #72 üzenetére

    Már ne haragudj, de tényleg töltsd le valamelyik x86-os (értelemszerűen 386+) processzor programmers (vagy users) guide-ját, értsd meg, majd meglátod, hogy bizony szegmentálással simán elkerülhető ez! Ha pedig arra gondolsz, hogy nem oda tér vissza a program (mert a visszatérési címet felülírta), azt ez a flag sem fogja megoldani. A nemkívánatos stack-felülírás (a visszatérési címre gondolva) csak valami állítható határregiszterekkel lenne megoldható.
    OFF
    Egyébként az ''i386 nagyon meghaladta a korat'' kijelentés nagyon sántít. Pl. a 68020 (ami vagy 3!! évvel korábban jelent meg) is címzett 4GB memóriát, és a 386-tal egyidőben megjelent 68030 ráadásul 1.5-szer gyorsabb is volt azonos órajelen. Persze nem volt benne szegmentálás, de cserébe egy flexibilisebb lapozás figyelt ott (az utasításkészletről már nem is beszélve). Meg, ugye, a 256 byte kód és 256 byte adat cache...

Aktív témák