- Samsung Galaxy Watch6 Classic - tekerd!
- Kis telefon hatalmas teleppel
- Huawei P20 Pro - profit csinál minden fotósból
- Leépíti a Sony az európai piacot?
- Körvonalazódnak az S26 Edge kamerarészletei
- iOS alkalmazások
- iPhone topik
- Mobil flották
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 15 - kicsi telefon nagy energiával
Aktív témák
-
#86
kisfurko
senior tag
Darth Vader
#84
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 -
kisfurko
senior tag
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. -
#77
kisfurko
senior tag
Darth Vader
#76
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). -
kisfurko
senior tag
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... -
kisfurko
senior tag
Ez az idegen kód végrehajtásosdi inkább a system process-ekre veszélyes.
Normál esetben megfelelően reagál mondjuk egy Apache. Ekkor simán csak a neked való oldalakat tudod lekérdezni. Ha egy lekéréssel be tudod juttatni a saját kódodat, akkor olyan oldalt, Apache rendszerfile-t is megkaphatsz, amit nem tudnál normálisan.
E? -
kisfurko
senior tag
''de előfordulhat az, hogy egy teljesen normális rutin gonosz paraméterekkel meghívva gonosz dolgot csinál. A verem átírásával (a verembe írást semmi nem akadályozza meg) ilyen módon továbbra is támadható marad a gép.''
Persze ez nem az architektúra hibája, hanem a szubrutiné. Illetve a rendszeré, ha nem azonos jogú dolgok egy vermet használnak. -
kisfurko
senior tag
Nem olvastam még el, de én úgy tudom elképzelni, hogy csak az futhat (lap), aminek be van állítva az execute flag-je. A rendszer pedig csak a kód lapjainak állítja be. A kód lapjait meg nem lehet módosítani, mert read-only. Tehát nincs gonosz kód. Vagy valamit kifelejtettem?
-
kisfurko
senior tag
Eleinte nekem sem tetszett (főleg az el.....-t valós módú:)). Biztonságosabbak lehetnének egy nagyságrenddel a programok. Persze ez az execute-only page is OK. Hogy miért nem csinálták meg előbb...
Egyébként a szegmensek annyival jobbak még, hogy ha a szegmens nem nagyobb, mint 1 MB, akkor byte-ra pontosan megadhatod a méretét. -
kisfurko
senior tag
Szerintem nem lenne gáz a sel:offs típusú címzés, feltéve, hogy csak lib-enként lenne külön szegmens (máskülönben minek máshova rakni). A BSS-részüket meg egy nagy közösbe. BSS alatt értem a dinamikusan foglalt, futás alatt módosuló szegmenst.
Egyszerűen csak azért hagyták ki az op.rendszerekből, mert másik architektúra nem támogatta. Szerintem, persze... -
kisfurko
senior tag
Aktív témák
Hirdetés
- Ford topik
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Samsung Galaxy Watch6 Classic - tekerd!
- A fociról könnyedén, egy baráti társaságban
- Milyen billentyűzetet vegyek?
- A TSMC gyárthatja a Nova Lake legfontosabb komponensét
- Kis telefon hatalmas teleppel
- Windows 7
- Kerékpárosok, bringások ide!
- További aktív témák...
- Új! Számla + 1-3ÉV Gari! Áfás! Gamer PC - Számítógép! I5 14400F / RTX 5060 / 32GB DDR5 / 1TB M.2 SSD
- LG 27GP95RP - 27" Nano IPS - UHD 4K - 160Hz 1ms - NVIDIA G-Sync - FreeSync Premium PRO - HDR 600
- Motorola G72 128GB, Kártyafüggetlen, 1 Év Garanciával
- AKCIÓ! MSI Z390 i5 9400F 16GB DDR4 512GB SSD RTX 2060Super 8GB Corsair Carbide Series 200R 600W
- Samsung S23 Ultra 256GB Állapot: 10/10 6 Hónap Jótállás!
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest