Link alla notizia: http://www.hwupgrade.it/news/software/supporto-no-execute-in-linux_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.

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

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

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

uscirà...intanto ti puoi scaricare la RC

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

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

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

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

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

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.

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 :muro:

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 :muro:

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

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?

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... ;) :rolleyes:

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è :rolleyes: ) 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"... :D

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.

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)

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

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

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

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

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

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

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? :muro:

Smentiscimi ti prego...

Originariamente inviato da ilsensine
Ho capito male o per usare l'NX occorre per forza usare il PAE?
Cosa fanno, aggiungono un hack ad un'altro hack? :muro:

Smentiscimi ti prego...

Premesso che sono abbastanza pippa in materia di kernel e sopratutto VM,
leggendo qualche link su kerneltrap pare che ci voglia:


- enable CONFIG_HIGHMEM64G in the .config.

(da http://people.redhat.com/mingo/nx-patches/QuickStart-NX.txt)
E questo mi parrebbe semplicemente il supporto per HIGHMEM... No?

Questo puo` esserti di interesse?
http://people.redhat.com/mingo/nx-patches/nx-2.6.7-rc2-bk2-AE

Trovi tutto a partire dal link su kerneltrap postato da paletta, comunque.

Originariamente inviato da Ikitt_Claw
- enable CONFIG_HIGHMEM64G in the .config.

Oh mammaaaa!!

Chi è il genio, il _GENIO_ progettista di cpu che si è inventato 'sta fesseria??!!! :muro:

Originariamente inviato da ilsensine
Oh mammaaaa!!


Fa cosi` schifo quest'implementazione?

Originariamente inviato da Ikitt_Claw
Fa cosi` schifo quest'implementazione?
Hai più di 4GB di RAM o ti piace abilitare HIGHMEM64G per far fare un pò di lavoro inutile al tuo annoiato processore? :muro:

Originariamente inviato da ilsensine
Hai più di 4GB di RAM o ti piace abilitare HIGHMEM64G per far fare un pò di lavoro inutile al tuo annoiato processore? :muro:

Pensavo che per com'e` fatto l'athlon 64 non dovrebbe essere un grosso problema; non credo che Molnar si metta a scialare da questo punto di vista.
O no?

Originariamente inviato da Ikitt_Claw
Pensavo che per com'e` fatto l'athlon 64 non dovrebbe essere un grosso problema; non credo che Molnar si metta a scialare da questo punto di vista.
O no?
L'Athlon64, usato a 64 bit, non usa PAE o altre diavolerie simili. Bontà sua, non ha bisogno di simili hack.

Mi riferivo ovviamente a processori a 32 bit o all'x86-64 usato a 32 bit. Dal tuo primo link:

this patch is only meant for 32-bit x86 kernels and distributions

Originariamente inviato da ilsensine
Mi riferivo ovviamente a processori a 32 bit o all'x86-64 usato a 32 bit. Dal tuo primo link:

Ok, scusa il malinteso: non avevo notato quella riga. In questo caso sono d'accordo con te.

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?
NESSUNO
se la possono tenere...

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?

Certo che siete proprio paranoici! :D

Non è che l'architettura x86 sia tanto male: l'aggiunta del flag NX si è resa necessaria a causa del nuovo modello di memoria previsto dall'architettura x86-64, che è SOLAMENTE paginato. Non sono presenti più i segmenti (per essere precisi, per le applicazzioni nello spazio utente sono inutilizzabili/inutili; per le applicazioni nello spazio supervisore vengono utilizzati dal kernel solamente per accedere alle proprie aree di memoria), per cui viene meno ciò che veniva offerto da questo modello di memoria, che difatti prevedeva già dal 286 la non esecuzione di codice nei segmenti di dati/stack (poteva essere eseguito solamente in segmenti di codice, appunto).

Poiché gli x86-64 implementano questo flag col sistema di paginazione, per renderlo utilizzabile anche in modalità a 32 bit è necessario abilitare le PAE. Comunque non vedo problemi in ciò: basta non usare i 4 bit superiori per gli indirizzi a 36 bit, e si rimane sempre nell'ambito dei 4GB di memoria indirizzabili. Col vantaggio, però, di poter attivare questo flag.

In ogni caso, adesso che pure gli sviluppatori Linux hanno deciso di implementare questa funzionalità, spero che i timori di quanti ravvisavano lo spettro di palladium siano spariti... ;)

Originariamente inviato da Raid5
Certo che siete proprio paranoici! :D ho riportato le voci che ho letto in giro... ho chiesto giusto per scrupolo

Originariamente inviato da cdimauro
Poiché gli x86-64 implementano questo flag col sistema di paginazione, per renderlo utilizzabile anche in modalità a 32 bit è necessario abilitare le PAE.
Scusa, ma è una argomentazione che non mi convince. Già in modalità "normale" (non pae) c'è il supporto per abilitazione in lettura e/o scrittura a livello di singola pagina; manca - ed è grave - l'abilitazione in esecuzione. Usare l'x86-64 in modalità "compatibile" non vuol dire per forza passare per il pae. Inoltre, da quello che si subodora leggendo in giro, credo che l'NX sarà introdotto anche nei processori a 32 bit puri (non solo amd).
Il pae è un brutto hack che non è mai piacuto a nessuno. Aggiungere un hack sull'hack per me è il modo più sbagliato di affrontare un problema. Se questa deve essere la soluzione, sarebbe stato meglio lasciare l'NX per i processori a 64 bit puri (il cui scopo principale è proprio buttare alle ortiche il pae).


Comunque non vedo problemi in ciò: basta non usare i 4 bit superiori per gli indirizzi a 36 bit, e si rimane sempre nell'ambito dei 4GB di memoria indirizzabili. Col vantaggio, però, di poter attivare questo flag.
Questo non ti libera dall'overhead aggiuntivo di utilizzare il pae, che prevede comunque una tabella di paginazione addizionale. Gli indirizzi usati dai programmi sono sempre e comunque di 32 bit, quarda ad es. qui (http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/w2k3tr_pae_how.asp)

Originariamente inviato da ilsensine
Scusa, ma è una argomentazione che non mi convince. Già in modalità "normale" (non pae) c'è il supporto per abilitazione in lettura e/o scrittura a livello di singola pagina; manca - ed è grave - l'abilitazione in esecuzione.
Questo l'ho già spiegato: si è sempre fatto uso della segmentazione, che offre restrizioni e privilegi molto più "fini".
Usare l'x86-64 in modalità "compatibile" non vuol dire per forza passare per il pae.
Lo so, ma sarà quello che Amd ha deciso di fare nell'implementazione dell'x86-64 e delle conseguenti migliorie che "appaiono" anche in modalità a 32 bit.
Inoltre, da quello che si subodora leggendo in giro, credo che l'NX sarà introdotto anche nei processori a 32 bit puri (non solo amd).
Dovrebbero implementarlo i prossimi Prescott con 2MB di cache L2, se non erro.
Il pae è un brutto hack che non è mai piacuto a nessuno.
Neppure a me.
Aggiungere un hack sull'hack per me è il modo più sbagliato di affrontare un problema.
Indubbiamente. Probabilmente hanno voluto semplificare il design, lasciandolo attivo sempre e soltanto col PAE attivo.
Se questa deve essere la soluzione, sarebbe stato meglio lasciare l'NX per i processori a 64 bit puri (il cui scopo principale è proprio buttare alle ortiche il pae).
Veramente il PAE in modalità x86-64 dovrebbe essere sempre attivo, e l'unico modo disponibile per indirizzare la memoria.
Questo non ti libera dall'overhead aggiuntivo di utilizzare il pae, che prevede comunque una tabella di paginazione addizionale. Gli indirizzi usati dai programmi sono sempre e comunque di 32 bit, quarda ad es. qui (http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/w2k3tr_pae_how.asp)
Sì, ho visto. Questo è anche uno dei motivi per cui AMD ha aumentato le entrate nella cache TLB. D'altra parte, avendo sempre 4 livelli d'indirezione, era una scelta praticamente obbligata.
Comunque, penso che sia stata una scelta di comodo e di omogenità (in ogni caso si hanno 4 livelli di indirezione), quella di implementare il flag NX solo con il PAE attivo anche nella modalità a 32 bit. Si saranno fatti bene i conti: se già nella modalità a 64 bit bisogna per forza di cosa avere 4 livelli d'indirezione, tanto vale usarli anche in quella a 32 bit; l'aumento della cache TLB servirà a mitigare questo ulteriore passaggio.
E' una scelta che non condivido neppure io, ma fra il non avere una funzionalità, e averla un po' "castrata", meglio la seconda. Tanto più che chi avrà un processore a 64 bit passerà ancora poco tempo a utilizzare un s.o. a 32 bit... ;)

Originariamente inviato da cdimauro
Veramente il PAE in modalità x86-64 dovrebbe essere sempre attivo, e l'unico modo disponibile per indirizzare la memoria.

:eek:
cioè l' unico modo consiste nel dare ai programmi 64 bit di address space virtuale, da trasformare in (se non ricordo male) 48 fisici, passando attraverso una gestione bank swapping a blocchi di 32? :wtf::doh:

magari ho capito male... LO SPERO vivamente :muro:

No, se ti riferisci alla modalità nativa a 64 bit, la situazione è la seguente:

1) I registri indirizzo a 64 bit
2) Indirizzi virtuali utilizzabili 2^48 (in futuro sarà possibile estenderli, ovviamente)
3) Indirizzi fisici mappabili 2^40 (idem come sopra)

Non esiste nessun bank swapping, non ti preoccupare: c'è la "solita" catena dovuta alla traduzione dall'indirizzo virtuale all'indirizzo fisico, tramite "l'albero" delle page directory entry, che questa volta è 4 livelli, rispetto ai 3 necessari nella modalità a 32 bit normale (non PAE, che diventa a 4 livelli). D'altra parte, con 48 bit d'indirizzamento virtuale, almeno un livello in più doveva essere aggiunto... :)