2. Fórumok
  3. Processzorok, tuning
  4. Vírusvédelem a processzorokban
  5. (téma lezárva)
Keresés

Aktív témák

  • #91 tocsa senior tag Darth Vader #89
    #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
    #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
    #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.

  • #83 tocsa senior tag Darth Vader #81
    #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
    #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.

  • #78 tocsa senior tag kisfurko #73
    #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?

  • #72 tocsa senior tag Darth Vader #10
    #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.

  • #71 tocsa senior tag Erasmus #18
    #71
    Ö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 Erasmus #18 üzenetére

    Kosz az URL-t.
    Jol forditottad. Az eredeti hir is ilyen. Keveri a virust a buffer overflow exploitokkal, habar nagyon sok fereg es virus ilyen tipusu exploit segitsegevel aktivizalodik.

    Es az eredeti cikkben sem rantjak le a leplet arrol, hogy itt tulajdonkeppen a verem szegmens flag-rol van szo.

  • #70 tocsa senior tag Darth Vader #10
    #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.

Aktív témák

Hirdetés