Hirdetés
- Megjött a Cherry legfrissebb, taktilis karakterisztikájú kapcsolója
- 8 bővítőhelyes Jonsbo "akvárium", akár kábeleket rejtő alaplapokhoz is
- 4K felbontású, 240 Hz-es OLED monitorokkal köszönti az őszt a Lenovo
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- Legalább 20 éves lemaradásban vannak a kínai litográfiai cégek?
- Milyen billentyűzetet vegyek?
- Projektor topic
- Fejhallgató erősítő és DAC topik
- Legalább 20 éves lemaradásban vannak a kínai litográfiai cégek?
- Milyen videókártyát?
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- 3D nyomtatás
- Dell notebook topic
- Ismét egy teljesen friss egérrel gyarapította kínálatát a Pulsar
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
Aktív témák
-
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 -
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. -
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). -
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... -
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? -
''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. -
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?
-
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. -
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... -
Aktív témák
- Bomba ár! HP ProBook 440 G6 - i5-8GEN I 8GB I 256SSD I HDMI I 14" FHD I Cam I W10 I Gari!
- BESZÁMÍTÁS! LENOVO LOQ 15AHP9 15 FHD notebook - R7 8845HS 32GB DDR5 1TB SSD RTX 4060 6GB WIN11
- Extra olcsó! HP 230 Vezetéknélküli USB-s Billentyűzet
- Samsung Galaxy A55 128GB, Kártyafüggetlen, 1 Év Garanciával
- Azonnali készpénzes félkonfig / félgép felvásárlás személyesen / csomagküldéssel korrekt áron
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest