Aktív témák

• #91 tocsa senior tag Darth Vader #89

  2004-02-25 15:38:27 #91

  Ö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

  

  tocsa

  senior tag

  válasz Darth Vader #89 üzenetére

  Megnéztem az Understanding The Linux Kernel idevágó részeit.
  Mint kideritettem OReilly könyv, orosz site-ról sikerült letölteni pdf-ben. :)
  
  A Linux kernel beli szegmentálás:
  ''The 2.2 version of Linux uses segmentation only when required by the Intel 80x86
  architecture. In particular, all processes use the same logical addresses, so the total number of segments to be defined is quite limited and it is possible to store all Segment Descriptors in the Global Descriptor Table (GDT).''
  ...
  ''For each process, therefore, the GDT contains two different Segment Descriptors: one for the TSS segment and one for the LDT segment.''
  
  Lapozás
  ''Furthermore, instead of the three types of access rights (Read, Write, Execute) associated with segments, only two types of access rights (Read, Write) are associated with pages. If the Read/Write flag of a Page Directory or Page Table entry is equal to 0, the corresponding Page Table or page can only be read; otherwise it can be read and written.''
  
  ''pte_exec( )
  Returns the value of the User/Supervisor flag (indicating whether the page is
  accessible in User Mode). Notice that pages on the Intel processor cannot be protected against code execution.''
  
  
  PAE:
  
  ''The other main change is related to physical memory addressing. Recent Intel 80x86
  microprocessors include a feature called Physical Address Extension (PAE), which adds four extra bits to the standard 32-bit physical address. Linux 2.4 takes advantage of PAE and supports up to 64 GB of RAM. However, a linear address is still composed by 32 bits, so that only 4 GB of RAM can be ''permanently mapped'' and accessed at any time.''
  

• #90 tocsa senior tag Darth Vader #89

  2004-02-25 15:23:17 #90

  Ö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

  

  tocsa

  senior tag

  válasz Darth Vader #89 üzenetére

  Én is így értelmezem. Tehát laponként lesz egy-egy bit.
  
  Egyéb magyarázat: a PAE pontosan azt a +4 bitet takarja, amivel a Pentium óta a a címszélesség 36 bit lehet, azaz összesen 64 GB memória állhat rendelkezésre a processzeknek. Azonban mint korábban felhívták rá a figyelmet, továbbra sem növekszik meg az egyben megcímezhető memória mérete (4GB).
  

• #87 tocsa senior tag Darth Vader #84

  2004-02-09 17:48:46 #87

  Ö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

  

  tocsa

  senior tag

  válasz Darth Vader #84 üzenetére

  ''Ezert mondtam azt, h sok programozo csak szovegel(itt nem rad gondolok), mikorzben fogalma sincs az adott proci igazi kepessegeirol.''
  
  Pedig van meg mit utananeznem a dolgoknak. Azt hiszem irni fogok ebbol a temabol egy cikket. Nem tudtam, hogy a Linux kernel nem hasznal szegmentalast.
  
  Lehet, hogy majd kerdezek toled infokat.
  

• #86 kisfurko senior tag Darth Vader #84

  2004-02-09 12:47:09 #86

  Ö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 Darth Vader #84 üzenetére

  OFF
  
  ''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.''
  Arról nem is beszélve, hogy ez a legbonyolultabb része a doksinak...:)
  No meg a V86-os mód...:o
  

• #83 tocsa senior tag Darth Vader #81

  2004-02-09 12:03:30 #83

  Ö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

  

  tocsa

  senior tag

  válasz Darth Vader #81 üzenetére

  Mindazonaltal Mea Culpa egyebkent.
  
  Egyebkent szerintem nem jo indok az, h a portolhatosag miatt bealdozzak a kernel biztonsagat.
  
  Teljes mertekig egyetertek, maximalisan biztonsag parti vagyok. Inkab csokkenjen a rendszer teljesitmenye 3-5%-al (a korabban emlitett megoldasoknak mind-mind van ilyen hatranyuk), netalan 10%-al is, de legyen biztonsagos.
  

• #82 tocsa senior tag Darth Vader #79

  2004-02-09 12:01:46 #82

  Ö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

  

  tocsa

  senior tag

  válasz Darth Vader #79 üzenetére

  Nyugi. Ne huzd fel magad.
  
  Megigerem, hogy alaposabban utana fogok nezni a dolgoknak, mert egyre jobban foglalkoztat a dolog.
  
  Belenezek majd az Understanding Linux Kernel konyvbe.
  
  Mit ertesz azalatt, hogy olvasni az i386 konyvet? Mert az nem egy olyan konyv, mint az Odusszeia, hogy kinyitja az ember, aztan szepen vegigolvassa. De volt mar olyan hogy beleneztem. Arra valo.
  
  Lesz meg ugyan buffertulcsordulas az AMD megoldasa utan is, de ha hasznaljak a vedelmet, akkor a tulcsordulas megtortenik, de a beinjektalt kod mar nem tud lefutni. Ergo a tulcsordulasos exploitok mind-mind DoS exploitta degradalodnak le. Es ez valami. A szenzaciohajhasz hirek mindent osszeirtak, de abban igazuk volt, hogy ha ez regebben megtortent volna akkor sok fereg nem terjedt volna. A Slammer SQL exploit vagy a Blaster RPC exploitnak is annyi lenne.
  
  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.
  
  Ezt nem ertem.
  
  Egyebkent nagyon szivesen elolvasnam az Intel sokszaz oldalas konyvet, de _nincs_idom_ ra. Errol nem tehetek.
  

• #77 kisfurko senior tag Darth Vader #76

  2004-01-11 18:18:23 #77

  Ö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 Darth Vader #76 üzenetére

  Meg lehet oldani, hogy ne lassuljon a címfordítás. A címgeneráló pl. fixen hozzáadja a bázist.
  Mellesleg tuti, hogy így van, gondoljatok csak a valós módra, ott is folyton hozzá kell adni a szegmens*16-ot (ami ugye a bázis).

• #72 tocsa senior tag Darth Vader #10

  2004-01-10 14:23:48 #72

  Ö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

  

  tocsa

  senior tag

  válasz Darth Vader #10 üzenetére

  Sajnos nem.
  Az i386 nagyon meghaladta a korat, pl. a 4GB memoria cimzessel, azonban a buffer overflow-s stack feluliras majd vegrehajtas kerdeskore az x86 architekturanak egy hianyossaga volt.
  Valaki itt irta, hogy nezzuk mega flag-eket, meg stb. Nezze meg a falg-eket, es azt hogy azok pontosan mit jelentenek stack szegmens eseten.
  
  Ha ez meg lett volna oldva, akkor nem lett volna a rengetek software-es workaround: openwall fele vedelem, majd GRSecurity fele vedelem, PAX vedelem. Vagy az IBM Propolice, egyeb vedelmek. Mind emiatt szulettek. Persze a hardware nyujtotta lehetosegeket most is kisernie es tamogatnia kell az oprencernek, de mar nem kellenek olyan workaround-ok, sokkal egyszerubb lesz a rendszer. Es a hardware-es vedelem nem iktathato ki olyan konnyen, mint egy szoftware-es.
  

• #70 tocsa senior tag Darth Vader #10

  2004-01-10 14:16:44 #70

  Ö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

  

  tocsa

  senior tag

  válasz Darth Vader #10 üzenetére

  Ezt nem tamogatjak.
  
  Mas architekturak eseten, mint pl SUN UltraSparc, mar regebb ota jol mukodis Stack Szegmens eseten a privilegium flag-ezes. Eddig sem ertettem, hogy miert nem tudjak a flag-eket rendeb rakni ebben az esetben.
  Vegre rajottek.
  

• #25 WN31RD addikt Darth Vader #22

  2004-01-09 14:47:31 #25

  Ö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

  

  WN31RD

  addikt

  válasz Darth Vader #22 üzenetére

  Van szegmentálás, csak nem használják ki ennek a lehetőségeit.
  Na de nem kötözködöm: effektíve tényleg nincs szegmentálás a Linuxban, hanem lineáris címteret használ (legalábbis pl. a GRSecurity patch megfelelő opciójának a bekapcsolása nélkül).
  Amit leírtál az teljesen oké, csak az a gond, hogy ha használnák a szegmentálást, akkor vagy előre el kellene dönteni, hogy a 4 GB-os lineáris címtéren hogyan osztoznak a szegmensek (ez történik a GRSecurity-ban, ha ...PAX_SEGMEXEC=y), és ha valamelyik proginak többre van szüksége pl. az adatszegmensben, akkor gond van, vagy pedig menet közben kell tologatni és növelgetni a szegmenseket, ennek megfelelően átírni a laptáblátkat, ráadásul mindezt osztott kódot (libek) tartalmazó rendszerben, stb. Ez viszont már nagyon jelentősen bonyolítaná a memóriakezelést.

• #24 dabadab titán Darth Vader #22

  2004-01-09 14:47:19 #24

  Ö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

  

  dabadab

  titán

  válasz Darth Vader #22 üzenetére

  Ugy most ezzel nem azt akarod mondani, hogy mivel minden program megkapja a maga 4GB-os address space-et, ez azt jelenti, hogy mindegyikuk ugyanazt a fizikai memoriat latja?... Merthogy termeszetesen ez nem igy van.
  
  

• #17 dabadab titán Darth Vader #10

  2004-01-09 14:27:27 #17

  Ö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

  

  dabadab

  titán

  válasz Darth Vader #10 üzenetére

  Milyen szegmentalas?... Az x86-ok 32 bites modjaban max. szelektorok vannak, nem szegmensek, a szegmens az a 16 bites mod 64K-s szeleteire fenntartott terminus technicus.
  Amugy meg konkretan Linuxhoz van is patch, ami a stackrol leszedi az execution flaget, amit egy elozo hozzaszolasban emlitett is valaki, amint azt is hozzatette, hogy a vilag azert messze nem ilyen egyszeru, hogy chmod a-x /proc/stack, aztan jolvan :)
  
  
  
  [Szerkesztve]

• #16 WN31RD addikt Darth Vader #15

  2004-01-09 14:19:44 #16

  Ö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

  

  WN31RD

  addikt

  válasz Darth Vader #15 üzenetére

  (Elég régen foglalkoztam már ilyesmivel, tehát lehet, hogy tévedek, vagy nem veszek figyelembe valami új procikban meglévő lehetőséget... úgyhogy javítsatok ki, ha szükség van rá!)
  Mivel nem lehet szegmensenként elválasztva mappelni a lineáris címteret, szükségszerű, hogy egy processznek a szegmensei ugyanazon lineáris címtartomány eltérő részein legyenek, ha különböző tartalmuk van. Márpedig lineáris címekből 4 GB-nyi van, ezen kell osztozni, tehát nem lehet szegmensenként különböző 4 GB-ot használni.
  (Tekintsünk el a 36 bites PAE-től, és maradunk a ''hagyományos'' 4 GB-nál.)

• #13 WN31RD addikt Darth Vader #10

  2004-01-09 13:54:23 #13

  Ö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

  

  WN31RD

  addikt

  válasz Darth Vader #10 üzenetére

  Elsőre nem is jutott ez eszembe:
  A szegmentálásos védelemmel az a gond, hogy az amúgy sem túl nagy (legalábbis manapság már nem) 4 GB-os logikai címteret tovább csökkenti. De egy 64 bites proci esetében ez már nem lesz gond, nyugodtan lehet külön pakolni az adat/kód/stb. szegmenseket.
  Viszont akkor mi értelme van ennek az új feature-nek?
  Ha csak annyit tud, hogy a lapozási mechanizmusba berak egy execute-only flaget, akkor az egyetlen haszna ennek az lehet, hogy a 32 bites alkalmazásoknál is legyen védelem, ahol a kód és az adat címtér nem választható szét (ha szükség van a 4 GB-ra). Viszont ezeknek a régi progiknak a nagy része nem úgy íródott, hogy erre fel legyen készítve, és így is fusson. Ha meg módosítják őket, akkor ilyen erővel fordíthatják már 64 bitesre is.
  Érti valaki, hogy miről van itt szó igazából? :F

Aktív témák