NX Bit anche per Intel

Sei sicuro di questo? Mi sembra strano perchè NX oltre a proteggere da buffer overflow dovrebbe anche proteggere da virus polimorfici come già menzionato da qualcun'altro qui sopra. Ma se basta dichiarare una pagina come hai detto _senza_ il bit NX _e_ scrivibile allora anche i virus potranno farlo e viene meno uno degli scopi del NX. Correggimi se sbaglio.

Questo dipende dal sistema operativo, se vuole consentirlo o meno.
Normalmente le sezioni di codice (eventualmente dopo polimorfismi vari) devono essere in sola lettura anche sulle architetture non-NX. Non per obblighi particolari, ma per buon senso.

Lungi da me irritarmi, non mi stupisco del fatto che trovi pochi interlocutori... parli una lingua sconosciuta!
Proverò a leggere con calma ciò che hai scritto ma dubito che ne capirò molto.

X repne scasb

algoritmo mac: scusa, ma a cosa serve moltiplicare per "1.0f"? Comunque, già di suo l'aritmetica di macchina per i floating point non rispetta alcune condizioni della completezza di R (proprietà commutativa ecc.), non è che si rischia di perdere alcune proprietà anche con gli interi? Non vorrei spararla col botto, ma, in relazione alla precisione usata per gli interi e i floating point, non c'è il rischio che, se il numero di cifre "rilevanti" per l'intero da convertire supera quello previsto per la mantissa, si perdano informazioni sui bit meno significativi per arrotondamento o troncamento e non valgano più le proprietà delle operazioni elementari (magari con conseguenze sgradevoli in qualche ciclo particolare)?

Per quanto riguarda le alu, fortunatamente non tutti i risc e (simili) non le hanno, itanium che io sappia ne ha 4, anche se due vengono impiegate in operazioni di load/store e le prestazioni sugli interi sono quelle che sono.... via stendiamo un velo pietoso (esagerazione a parte), anche perchè aspettare una decina d'anni per poter sfruttare pienamente una tecnologia mi sembra un po' troppo.


NX bit: non mi è chiara una cosa: questo flag va impostato per tutta una sessione del sistema operativo (resta necessariamente attivo/disattivo fino al riavvio successivo) oppure si può modificare "in corso d'opera" (probabilmente dipenderà dal sistema operativo)? In questa ipotesi, non si potrebbe pensare ad una gestione dipendente dai processi, magari integrata nel modulo che esegue il context switch (in modo analogo al settaggio del modo utente/supervisore) su richiesta di un processo "autorizzato"? Si potrebbe pensare a qualcosa di simile al controllo dei firewall software sui programmi che tentano di accedere alla rete, dando all'utente (più esperto) la possibilità di scegliere se consentire o meno l'esecuzione non protetta (a vantaggio del codice automodificante): l'allocazione di una pagina di memoria si effettua mediante system call, giusto? Bene, il sistema potrebbe riconoscere la richiesta di disabilitazione del flag nx e avvertire l'utente della pericolosità della situazione ma anche del fatto che il programma potrebbe averne bisogno e che potrebbe non esserci alcun pericolo reale, quindi dovrebbe memorizzare la richiesta dell'utente per quel "modulo" (eseguibile, libreria condivisa, ecc.), in un qualche database (per non riproporla). A questo punto si completerebbe il quadro con una programmazione oculata che inserirebbe richieste di disabilitazione del non execute solo laddove si usi codice polimorfico, evitando in ogni caso categoricamente di farlo in moduli che interagiscano con l'utente o con altri processi e in generale in ogni parte del codice che faccia uso di un qualsiasi buffer. Forse però alcuni rischi (se non molti) resterebbero, e il sistema potrebbe risultare più lento/invadente. Che ne pensi, anzi (mi rivolgo a tutti) che ne pensate? Comunque, se viene richiesta la disabilitazione solo in parti polimorfiche e prive di buffer potrebbe funzionare...


Sono comunque dell'idea che la miglior protezione sia ottenibile lato software, ponendo mooolta attenzione nel controllo sulla dimensione di un buffer, oppure introducendo dei controlli specifici nel linguaggio di alto livello da usare, sulla falsariga di java tanto per intenderci (anche se farti un esempio per specificare credo sia del tutto superfluo, ne sai decisamente più di me ).



codice automodificante: un'ultima cosa, la modifica del codice non richiede comunque del tempo? Oppure si può considerare un'operazione, diciamo, O(1) (o comunque trascurabile rispetto all'ordine di grandezza delle altre operazioni, in termini di costo computazionale)?

Ti ringrazio in anticipo per le risposte, anche perchè potrebbe passare un po' di tempo prima che io le legga (ed eventualmente replichi per continuare la discussione). Mi scuso per eventuali errori di battitura, ma non ho tempo per controllare e sto scrivendo da un mac con tastiera qzerty (e praticamente mi sto dannando l'anima... )

Ciao a tutti

Visto che chiami in causa anche gli altri...



Trooooppo macchinoso! Comunque l'idea non e` malvagia, dipendentemente dalle caratteristiche dell'OS potrebbe venir realizzata.
[edit]
mi riferisco ad un'eventuale syscall "disabilita NX" o comunque alla possibilita` di un programma di intervenire in questo senso. Sto facendo comunque delle mere speculazioni
[/edit[
Potrebbe essere cioe` che NX, anche dove disponibile, non sia usato per forza
sempre e comunque, proprio per evitare di danneggiare usi leciti...
Comunque per questo occorre vedere le varie implementazioni disponibili o che saranno disponibile.



Beh, si certo: basterebbe non sbagliare programmando
Purtroppo questo e` irrealizzabile in pratica, quindi c'e` bisogno di tutto l'aiuto che l'hardware puo` dare.
Per quanto riguarda il linguaggio di alto livello hai ragione, ma occorre considerare che a volte c'e` necessita` di usare comunque linguaggi di livello medio-basso (C...) per vari motivi: legacy, ottimizzazione spinta, quindi il problema, ridotto, rimane. Fermo restando la possibilita`, sempre presente, di bug nell'interprete/VM/Compilatore JIT/quelchee` del linguaggio ad alto livello.

La conversione da intero a float comporta comunque dei problemi, nel caso in cui la mantissa non sia dotata di un numero di bit ALMENO pari a quelli dell'int da caricare. Nel caso dell'Itanium, se la mantissa non è almeno pari a 64 bit, effettuando operazioni con interi a 64 bit è possibile che vengano fuori risultanti errati (anche di molto).

Rimangono un altro paio di dubbi:
1) processori come questi avranno pure dei flag di carry, overflow, segno e zero; mi sembra difficile riuscire a gestirli in queste condizioni, specialmente per i primi due;
2) anche con istruzioni di shift e rotazione possono verificarsi dei problemi.

Infine, rimango dell'idea che, pur conoscendo i tipi di algoritmi che si dovranno implementare, alcune architetture non potranno avere delle buone prestazioni per le loro limitazioni intrinseche.

Dimenticavo: per l'NX, penso sia meglio lasciarlo sempre attivo. Se serve generare del codice automodificante, è meglio richiedere al s.o. l'allocazione di memoria e chiedergli poi di azzerare questo flag.

Insomma non mi sembra che ti esaltino tanto l'assembly e l'architettura dell'Itanium