NX Bit anche per Intel

[^TiGeRShArK^]

ma ke io sappia il codice automodificante era utilizzato solo in ambiti molto particolari quali demo tecnologiche (tipo quelle ke in 64 kb fanno una marea di animazioni 3d x intenderci) e ke cmq serviva solo a contenere le dimensioni complessive del file e non ad aumentarne la velocità....
in effetti non riesco proprio ad immaginare una situazione in cui il code morphing possa postare ad incrementi prestazionali anzikè a peggioramenti....
se qualcuno mi ilumina mi fa un grooso piacere....

[Kralizek]

ehm...
sono in piena crisi mistica... avevo sempre letto che l'architettura x86 fosse la più inefficiente del mondo... e che si era diffusa per uno scherzo del destino...
ancora... dopo quello che ho letto... comprare un itanium per fargli fare da server è buttare soldi dalla finestra?

[Ikitt_Claw]

Originariamente inviato da repne scasb
E' molto complesso dare una risposta dettagliata ed esaustiva;

Certamente
Per quel che mi riguarda, sei stato comunque illuminante su tutta una serie di punti che, onestamente, non conoscevo o valutavo in modo diverso.
Rispondo solo ad una serie di punti che non mi quadrano completamente.

1) Uso di istruzioni assembly a dimensione fissa. Negativo, in quanto diminuisce statisticamente la quantita' i/b (istruzioni
per byte). Tale elemento fa si che a parita' di Kb il codice in esso contenuto (a parita' di problema) sia minore. Cio' generera
la necessita' di ampie porzioni di cache per contenere il codice. 6 Mbyte di cache di Itanium equivalgono a 1 Mbyte di cache x86/PM32.

Tralasciando il caso di VLIW di cui non ho non so quasi nulla, nel caso di RISC
questa controindicazione non dovrebbe essere significativamente ridotta su architetture a 32 bit?

2) Troppi registri. Negativo, ...

Interessantissima obiezione ma... Non e` che x86 classico ne ha troppo pochi invece?
D'accordissimo che per ovviare a questo si usano, se non mi sbaglio, tecniche tipo register shadowing (e che tali tecniche, sempre se non mi sbaglio, sono state importate anche sui risc di ultima generazione), parlo dal punto di vista del design architetturale, di come la CPU si presenta (si presenterebbe) al programmatore.

4) Eliminazione dell'ALU.

Ma non e` una prerogativa fondamentale del RISC! Oppure si?
(D'accordissimo sull'elegante inefficienza dell'algoritmo MAC)

[repne scasb]

[repne scasb]

[repne scasb]

[Ikitt_Claw]

Originariamente inviato da repne scasb
Molto lungo da chiarire [...]

Fa nulla, comunque piu` o meno ho capito cosa intendi, nel complesso.
In effetti dovrei prima approfondire determinati argomenti prima di affrontare una discussione di questo genere.

Ti ringrazio molto per gli interventi illuminanti.

[cionci]

repne scasb: sei un mito... Ogni volta che intervieni rimango

Originariamente inviato da repne scasb
Un processore come Itanium e' di gran lunga la migliore soluzione la dove sono noti "A PRIORI" i problemi da risolvere. Se devo fare (per esempio) calcolo matriciale non mi sognerei mai di utilizzare un x86 (neanche sotto tortura), una soluzione Itanium e' nettamente piu' "efficiente" (sarebbe da chiarire il concetto di efficienza...).

Intendi che se si ottimizza mooolto il codice assembly è più performante Itanium ? sapevo che una delle cose + difficili da fare in assembly Itanium è l'ottimizzazione del codice... Proprio perchè l'istruction level parallelism crea non pochi problemi logici a chi fa queste operazioni... Certo starsi lì a calcolare quanto un'istruzione ci mettere ad essere eseguita...e tenersi sempre uno schema delle unità di calcolo allocate/libere diventa veramente problematico...

I compilatori dovrebbero farlo per noi...ma ancora sono molto, e stranamente, indietro...nonostante Intel disponga di un buon team di sviluppo per i compilatori...

[repne scasb]

[eltalpa]

Vorrei sapere se la tecnologia NX sarà disabilitabile dall'utente (come su A64) oppure sulle CPU intel bisognerà sorbirsela così com'è... Qualcuno ha informazioni in merio?

PS: Permettetemi di fare una vagonata di complimenti a Ikitt_Claw e a repne scasb, queste sono le discussioni che vorrei sempre vedere in commento ad una news!

[repne scasb]

[cionci]

E pensare che 5 anni fa volevano introdurre IA64 sui desktop nel 2005

[ilsensine]

Originariamente inviato da repne scasb
Da questo punto di vista il NO_EXECUTE non
permettera' piu' la possibilita' di scrivere codice automodificante

mmap(PROT_READ|PROT_WRITE|PROT_EXEC)

[magilvia]

Vorrei sapere se la tecnologia NX sarà disabilitabile dall'utente (come su A64) oppure sulle CPU intel bisognerà sorbirsela così com'è... Qualcuno ha informazioni in merio?

Si ho letto che era possibile disabilitarlo ma se il 90% degli utenti non lo farà/non saprà come farlo è chiaro che nessun programma verrà più scritto in assembler automodificante.

[repne scasb]

[crismatica]

peccato che amd negli AMD 64 bit abbia già questa tecnolgia integrata che si abilità con sp2

intel sempre a rincorre ultimamente.....

[ilsensine]

Originariamente inviato da repne scasb
Ora, attivano il bit NX "non" dovrebbe essere possibile dichiarare una pagina di memoria contemporaneamente "PROT_WRITE" e "PROT_EXEC" (PROT_WRITE|PROT_EXEC), si dovrebbe pttenere un eccezione 0dh.

Lo scopo di NX è dichiarare una pagina non eseguibile. Se mappi una pagina _senza_ il bit NX _e_ scrivibile, puoi utilizzare il codice polimorfico.

Il "piccolo" problema dei programmi esistenti è che essi piazzano il codice polimorfico sullo stack o sull'heap. Il sistema operativo utilizza l'NX per rendere non eseguibili queste regioni, che notoriamente sono il target degli attacchi con buffer overflow. Sperabilmente chi usa queste tecniche di programmazione la smetterà finalmente di scrivere codice in questo modo; la tecnica _corretta_ (e chi ha usato questa può star tranquillo anche con l'NX) è la seguente:
mmap con accesso RW+exec
crei il codice da eseguire nella regione mappata
mprotect R+exec (toglie l'accesso W!)

[repne scasb]

[ilsensine]

Originariamente inviato da repne scasb
Stiamo parlando due lingue diverse, e ho il sospetto che stiamo parlando di due cose diverse. Assodato che per NX flag stiamo parlando di questo: http://www.amd.com/us-en/assets/cont...docs/20734.pdf Cap 4.1.3.3 (e non del _NO_EXECUTE_FLAG_ disponibile in alcuni sistemi operativi), dico che:

Sto parlando di quello. Dove hai letto che una pagina scrivibile non può avere l'NX a 0? Mi hai fatto venire il dubbio, ma non riesco a trovare nulla su questo punto.

1) Ho provato "ora" presa da curiosita il SP2 non devinitivo di WinXP su Athlon64.

Non conosco questi dettagli di windows e non so come hanno implementato la gestione.

[repne scasb]