Supporto No Execute in Linux

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwupgrade.it/news/softwar...nux_12557.html

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

Click sul link per visualizzare la notizia.

[NoX83]

Niente di nuovo, ma sicuramente una buona cosa se non nasconderà sorprese.

[Aryan]

...va segnalato che Microsoft inserirà del Service Pack 2 gli aggiornamenti...

Non dicono nemmeno per chi è sto SP(ovviamente XP)!!!
Chissà maise uscirà!

[Wonder]

uscirà...intanto ti puoi scaricare la RC

[Davirock]

... che la prima a passare ai fatti sia stata AMD con l'introduzione di questa tecnologia negli Athlon 64 e sarà attivata con il SP2.

Qualcuno può spiegarmi come funziona esattamente?

Bye

[WarDuck]

Wonder per la RC devi avere Windows in inglese se non sbaglio...

[Lo ZiO NightFall]

Chi mi garantisce che un domani, una volta diffusa tale tecnologia, non utilizzino la stessa funzione per inibire altri programmi?
NESSUNO
se la possono tenere...

[Ikitt_Claw]

Originariamente inviato da Lo ZiO NightFall
Chi mi garantisce che un domani, una volta diffusa tale tecnologia, non utilizzino la stessa funzione per inibire altri programmi?

Te lo garantisce la tecnologia stessa, per com'e` fatta.
Il bit NX permette di marcare come non eseguibile pagine di memoria.
Lo stack e l'area dati di un processo, ad esempio.
Tutta roba che su architetture meno raffazzonate di X86 esiste da anni o lustri...

Ora: te fai uso abituale di programmi che sfruttano buffer overflow?
Perche` non mi viene in mente nessun'altro caso in cui NX potrebbe essere molesto...

[ilsensine]

Originariamente inviato da Ikitt_Claw
Te lo garantisce la tecnologia stessa, per com'e` fatta.
Il bit NX permette di marcare come non eseguibile pagine di memoria.

No dev'esserci qualcosa in più, è possibile marcare le pagine come "non eseguibili" già dal 386...infatti grsec utilizza proprio questa tecnica per prevenire buffer overflow ecc.

[ilsensine]

Originariamente inviato da ilsensine
No dev'esserci qualcosa in più, è possibile marcare le pagine come "non eseguibili" già dal 386...infatti grsec utilizza proprio questa tecnica per prevenire buffer overflow ecc.

Ho scoperto con grande sorpresa che non è così...sugli x86 "leggibile" implica "eseguibile", e grsec in effetti doveva fare vere alchimie per prevenire i buffer overflow...

Insomma si è dovuto aspettare il 2004 per una cosa così ovvia

[jappilas]

Originariamente inviato da ilsensine
Ho scoperto con grande sorpresa che non è così...sugli x86 "leggibile" implica "eseguibile", e grsec in effetti doveva fare vere alchimie per prevenire i buffer overflow...

Insomma si è dovuto aspettare il 2004 per una cosa così ovvia

e l' "altra metà del cielo " (cioè le macchine basate su cpu intel) dovrà aspettare ancora ... ..

[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?

[jappilas]

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"...

[ilsensine]

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 Xp]

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)

[sinadex]

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

[paletta]

Maggiori informazioni qui:
http://kerneltrap.org/node/view/3240?PHPSESSID=455f4a9e1d1b6e0f71cae81200ade070

[paletta]

Palladium non c'entra. E' solo una patch per evitare i buffer overflow.

[Ikitt_Claw]

Originariamente inviato da paletta
Maggiori informazioni qui:
http://kerneltrap.org/node/view/3240...cae81200ade070

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_Claw]

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...