Aktív témák

• #81 Darth Vader csendes tag kisfurko #80

  2004-02-08 16:34:14 #81

  Ö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 kisfurko #80 üzenetére

  Szia,
  
  Most szerintem jol latod a kerdest. Egyebkent volt szegmentalas a linux kernelben, de az mar regen volt es pont a portolhatosag miatt vettek ki belole. A gond szerintem az, h sokan pont az x86-ot szidjak, h milyen szar, h meg erre sincs benne vedelem, pedig van, csak bizonyos okok miatt nem alkalmazzak.
  Egyebkent szerintem nem jo indok az, h a portolhatosag miatt bealdozzak a kernel biztonsagat.

• #78 tocsa senior tag kisfurko #73

  2004-02-07 15:09:53 #78

  Ö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 kisfurko #73 üzenetére

  Nnna.
  Szóval akkor már ne haragudj, de ezt maga Ingo Molnár irta, a linuxos exec-shield techonógia bejelentése kapcsán. Ez 2003 Május 3.-ra datálódik. Tehát sajnos nem oldható meg olyan egyszerűen a buffer overflow védelem, mint ahogyan azt ti gondoljátok:
  
  ''Background:
  -----------
  
  It is commonly known that x86 pagetables do not support the so-called
  executable bit in the pagetable entries - PROT_EXEC and PROT_READ are
  merged into a single 'read or execute' flag. This means that even if an
  application marks a certain memory area non-executable (by not providing
  the PROT_EXEC flag upon mapping it) under x86, that area is still
  executable, if the area is PROT_READ.
  
  Furthermore, the x86 ELF ABI marks the process stack executable, which
  requires that the stack is marked executable even on CPUs that support an
  executable bit in the pagetables.
  
  This problem has been addressed in the past by various kernel patches,
  such as Solar Designer's excellent ''non-exec stack patch''. 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.''
  
  De könyörgöm. Gondolkozzatok el egy picit, mielőtt írtok. Ha a 386-os vagy i586 óta megoldott lenne egy ilyen probléma, akkor miért lenne most olyan nagy durranás az AMD féle Execution Protection? Na jó, mondhatjuk, hogy a marketing miatt. De én meg azt mondom, hogyha hw támogatással 100%-ig blokkolni lehetett volna a buffer ovweflow exploitokat, akkor azt az Open Source közösség tutira implementálta volna. Hát nem? Miért szenvedtek volna akkor, miért szenvedett volna Solar Designer, miért fejlesztette volna ki az IBM a ProPolice-t, Miért léteznének szintén ezek a software-es ''erőlködések''?:
  IMMUNIX StackGuard
  IBM ProPolice
  SecureWave SecureStack
  mingo féle Exec Shield
  PaX stack védelem
  HAP patch gyűjtemény stack védelme
  OpenWall patch gyűjtemény stack védelme
  GRSecurity patch gyűjtemény stack védelme (PaX-on kivül)
  LOMAC patch gyűjtemény stack védelme
  
  Hmmm?
  

• #75 Alan aktív tag kisfurko #73

  2004-01-11 01:35:09 #75

  Ö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

  

  Alan

  aktív tag

  válasz kisfurko #73 üzenetére

  Nagyon jól mondod, a 68020-as, a 68030-as (és utódai is) fantasztikus processzorok voltak.
  
  Szerintem két okból nem használják az operációs rendszerek az i386 szegmentálást: egyrészt jelentősen bonyolítaná a memóriakezelő kódját, ami nem biztos, hogy kívánatos, hiszen így is találnak hibákat sok-sok év után is, másrészt a szegmentálás + lapozás egyszerre történő használatával nagyon lelassulna a címfordítás a +1 szint miatt (virtuális cím -> lineáris cím -> fizikai cím a virtuális cím -> fizikai cím helyett), ami TLB miss esetén jelentős teljesítményvisszaesést okozna. De azért bevallom, annyira én nem értek az x86-hoz, lehet, hogy más oka is van.

• #63 rog addikt kisfurko #60

  2004-01-09 17:16:58 #63

  Ö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

  

  rog

  addikt

  válasz kisfurko #60 üzenetére

  magyarul modjuk egy mplayernek beadok egy olyan mp3-at, vagy avi-t, ami ott egy függvényen verem túlcsordulást okoz. ettől a vezérlés rárkerül az mp3-fájlba rejtett és a tulcsordulást okozó adatcsoport részét képező destruktív kódra.
  valahogy így ugye?
  

• #59 rog addikt kisfurko #58

  2004-01-09 17:06:38 #59

  Ö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

  

  rog

  addikt

  válasz kisfurko #58 üzenetére

  de ha x és y is ugyanannak a processnek, programnak a része, akkor nincs értelme a gonosz részeket így aktivizálni, hisz egyszerűen ráadja a vezérlést és kész.
  nem kerek a dolog..

• #53 WN31RD addikt kisfurko #50

  2004-01-09 16:56:35 #53

  Ö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 kisfurko #50 üzenetére

  Nem értem, mit nem értesz... :F
  (Viszont rövid időn belül ellépek a net mellől, tehát egy darabig nem lesz alkalmam válaszolni.)

• #46 WN31RD addikt kisfurko #41

  2004-01-09 16:41:53 #46

  Ö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 kisfurko #41 üzenetére

  Tényleg nem az architektúra hibája.
  Természetesen a privilegizált szinteknek külön verme van, viszont itt szó nincs különböző jogú processzekről... :F
  

• #32 Darth Vader csendes tag kisfurko #30

  2004-01-09 15:54:20 #32

  Ö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 kisfurko #30 üzenetére

  Tudod mennyire igazaf van :))) Epp az egyik Understanding Linux kernel cimu konyvben olvastam, ha jol emlekeszem, hogy pont ezert martadt ki a szegmentalas asszem a 2.2.x-es kernelektol kezdve.(portolasi nehezseg miatt maradt ki a szegmentalas)

• #28 WN31RD addikt kisfurko #27

  2004-01-09 15:31:49 #28

  Ö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 kisfurko #27 üzenetére

  Az lehet, hogy nem lenne bonyolultabb, mint a lapozás, de akkor is növelné a memóriakezelő rész bonyolultságát (mert lapozásra mindenképpen szükség van, de most még szegmensek kezelésére is szükség lenne). :)
  
  Ha nemcsak egy-egy szegmens van egy adott fajtából, akkor a fordítókat úgy kell írni, hogy szelektor:offszet típusú mutatókat kezeljenek... ez elég komoly változás lenne, bonyolítaná a fordítókat, lassítaná a programokat, stb. :O
  Nem véletlenül hagytak fel ezzel.
  
  [Szerkesztve]

Aktív témák