Hirdetés

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

Aktív témák

  • #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?

  • #75 Alan aktív tag kisfurko #73
    #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.

Aktív témák