Supporto No Execute in Linux

Supporto No Execute in Linux

Intel e Red Hat rilasciano una patch che permette di sfruttare la tecnologia No Execute, già integrata nei processori Intel, AMD e VIA

di pubblicata il , alle 10:44 nel canale Sistemi Operativi
IntelAMD
 
34 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
sinadex07 Giugno 2004, 13:45 #11
purtroppo si parla degli altri 4/5 di cielo, viste le penetrazioni di mercato...
cmq, da più parti leggo allarmi in quanto sarebbe un preludio a palladium e via dicendo, io però non ci credo molrto... qualcuno mi illomina?
jappilas07 Giugno 2004, 13:59 #12
Originariamente inviato da sinadex
purtroppo si parla degli altri 4/5 di cielo, viste le penetrazioni di mercato...
cmq, da più parti leggo allarmi in quanto sarebbe un preludio a palladium e via dicendo, io però non ci credo molrto... qualcuno mi illomina?


mah ... mi piaceva credere che i due contendenti se la battessero ad armi pari...

mah (2).. il buffer overflow è il meccanismo su cui si basa l' esecuzione di buona parte dei virus/trojan in circolazione... e mi pare palladium c' entri poco... palladium, o altro modo in cui si può chiamare la "trusted computing base", si baserebbe su autenticazione e cifratura per autorizzare/negare l' esecuzione del SW ...
se un programma è affetto dal buffer overflow, è per cattivo design/scrittura/testing, il fatto di ricevere l' autorizzazione da aprte del sistema non lo rende automaticamente un buon programma ...

inoltre per implementare la funzione di autenticazione/cifratura, si dovrebbero poter seguire due strade:
HW, cioè con un chip dedicato o parte del chipset,
SW, tramite qualche funzione del "BIOS" (si dovrebbe chiamare firmware, perchè bios aveva un altro significato, ma vabbè ) o del sistema operativo
inoltre nel caso HW, siccome è prevista la possibilità di escludere il chip di decrypt, ci sarà una qualche opzione nella schermata di setup...
bene, se è vero quello che diceva la intel sul suo firmware di prossima generazione (EFI) , cioè che sarà "opensource o quasi"...
ilsensine07 Giugno 2004, 14:06 #13
Originariamente inviato da sinadex
cmq, da più parti leggo allarmi in quanto sarebbe un preludio a palladium e via dicendo, io però non ci credo molrto... qualcuno mi illomina?

Se veramente si tratta di quello che ha detto Ikitt_Claw (e comincio a crederlo), non c'entra nulla con Palladium. Anzi, è una cosa implementata da tempo nei processori "seri" (ad es. Sparc).

Ci sono rimasto di sasso leggendo che sui nostri scaldapizzette ancora non è implementata una cosa così ovvia.
Fabry Xp07 Giugno 2004, 14:10 #14
Sai com'è, finchè dedicavano tutte le risorse aziendali solamente ad aumentare frequanza e istruzioni multimediali...... forse adesso gli Ingenieri cominciano ad ingeniarsi.... :d Grazie AMD!!! (da un utente Intel)
sinadex07 Giugno 2004, 14:15 #15
vabè se è così resto tranquillo
ps: e poi magari robe palladium-like potremmo ritrovarcele sensa che nessuno ce lo abbia detto, un po' come i 64bit nelle ultime cpo intel, gia presente da un po' ma disabilitato... per saperlo si dovrebbero vedere i progetti delle cpu, cosa che nessuno credo farebbe
paletta07 Giugno 2004, 14:21 #16
paletta07 Giugno 2004, 14:25 #17
Palladium non c'entra. E' solo una patch per evitare i buffer overflow.
Ikitt_Claw07 Giugno 2004, 14:28 #18
Originariamente inviato da paletta
Maggiori informazioni qui:
http://kerneltrap.org/node/view/324...1cae81200ade070


Vado a citare:

From: Ingo Molnar [email blocked]
To: linux-kernel
Subject: [announce] [patch] NX (No eXecute) support for x86, 2.6.7-rc2-bk2
Date: Wed, 2 Jun 2004 22:50:25 +0200

[...]
What does this patch do? The pagetable format of current x86 CPUs does
not have an 'execute' bit. This means that even if an application maps a
memory area without PROT_EXEC, the CPU will still allow code to be
executed in this memory. This property is often abused by exploits when
they manage to inject hostile code into this memory, for example via a
buffer overflow.

The NX feature changes this and adds a 'dont execute' bit to the PAE
pagetable format. But since the flag defaults to zero (for compatibility
reasons), all pages are executable by default and the kernel has to be
taught to make use of this bit.

If the NX feature is supported by the CPU then the patched kernel turns
on NX and it will enforce userspace executability constraints such as a
no-exec stack and no-exec mmap and data areas. This means less chance
for stack overflows and buffer-overflows to cause exploits.

furthermore, the patch also implements 'NX protection' for kernelspace
code: only the kernel code and modules are executable - so even
kernel-space overflows are harder (in some cases, impossible) to
exploit. Here is how kernel code that tries to execute off the stack is
stopped:

kernel tried to access NX-protected page - exploit attempt? (uid: 500)
Unable to handle kernel paging request at virtual address f78d0f40
printing eip:
...


Se c'e` di piu` non lo so, ma questo pare sia quanto relativamente a NX e al supporto che avra` su Linux (e OpenBSD, e FreeBSD...)
Ikitt_Claw07 Giugno 2004, 14:29 #19
Originariamente inviato da ilsensine
Ci sono rimasto di sasso leggendo che sui nostri scaldapizzette ancora non è implementata una cosa così ovvia.


L'ho scoperto preparando Calcolatori Elettronici, e ho iniziato seriamente a capire come mai alcuni dicono cosi` tanto male di x86...
ilsensine07 Giugno 2004, 14:44 #20
Originariamente inviato da Ikitt_Claw
The NX feature changes this and adds a 'dont execute' bit to the PAE
pagetable format.

Ho capito male o per usare l'NX occorre per forza usare il PAE?
Cosa fanno, aggiungono un hack ad un'altro hack?

Smentiscimi ti prego...

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^