Link alla notizia: http://news.hwupgrade.it/12767.html

Nel terzo trimestre dell'anno Intel ha intenzione di implementare la tencologia di sicurezza NX Bit

Click sul link per visualizzare la notizia.

Perdonado l'ignoranza, mi spieghereste in breve cosa è "la tecnologia di sicurezza NX Bit (Excute Disable Bit)"? Grazie

Non so se hanno fatto articoli al riguardo (non mi sembra..) ma detta così è una notizia un po' inutile..
Esagero?

credo sia un aggeggio che impedisce al procio di far girare codice "cattivo", in particolare quelli che provocano i buffer owerflow

credo

chissà se funzionerà bene e non potrà essere aggirata questa tecnologia, comunque già iniziano a complicare il modelling number che dovrebbe invece semplificare la vita all'utente medio.
Voglio vedere un negoziante a spiegare MN e poi anche la tecnologia legata alla lettera J, per non parlare poi dell'hyper threading e compagnia bella, mezz'ora solo per dare info sulla cpu ;)

In pratica per entrare in un sistema si sfruttano i buffer overflow... Cioè si manda una quantità di dati superiore a quella prevista del buffer che riceve i dati (è uno dei più comuni errori di programmazione)... Progettando in maniera oculata questi dati si può fare in modo che corrispondano a codice eseguibile che, ad esempio, può fornire una shell sul sistema in questione... L'NX bit fa in modo di generare una eccezione (errore grave che interrompe l'esecuzione) nel caso in cui si tenti di eseguire codice in un pagina di memoria read/write (dedicate ai dati)...invece solitamente il codice eseguibile viene caricato in pagine read only in modo che non venga modificato in fase di esecuzione...

Questa tecnica viene usata anche da molti virus... Come ad esempio Nimda, CodeRed e Blaster...

Se non sbaglio l'NX bit è già sfruttabile in tutte le CPU AMD a 64 bit con core rev CG...ed anche in questo caso è Intel a rincorrere...
Potrà essere sfruttato con l'instalalzione del SP2 di XP... La cosa più che altro è interessante dal lato server... Infatti rende di fatto non sfruttabili la maggior parte dei bug...

Intel insegue AMD...

non vorrei esagerare ma negli sparc, l'nx bit esiste da almeno dieci anni.

era ora che sia amd che intel si diano una mossa!

Originariamente inviato da Crisa...
era ora che sia amd che intel si diano una mossa!

dessero ;)

l'NX non è una novità, c'era già nell'itanium e in altri processori prima dell'A64

Come i 64 bit c'erano nell'Alpha...
Chiaramente qui si parla di processori x86

Le fonti hanno sottolineato che i processori desktop Pentium 4, Celeron D e Nocona con supporto NX Bit sarà disponibile nel terzo trimestre dell'anno
in questa frase c'è qualcosa che nn va...
riguardo a questo NX nn sarà un buon precedente per palladium?

Originariamente inviato da Lucrezio
riguardo a questo NX nn sarà un buon precedente per palladium?

Se e` quello che dichiarano, no.

Originariamente inviato da repne scasb
La novita' consiste nel fatto che finora il condizionamento dell'esecuzione in funzione del modello di mappatura della RAM si
era visto sono in achitetture inefficienti (sia RISC che Vliw).

Qualche dettaglio in piu` su questa inefficienza? E` un fatto di design?


quanto tempo impiega una CPU per verificare che CS:EIP sta in RO?


Il tempo di un lookup ulteriore nel TLB nel caso medio, suppongo

Da questo punto di vista il NO_EXECUTE non
permettera' piu' la possibilita' di scrivere codice automodificante; in sostanta tutto cio' rappresentera' una certa perdita di
efficienza per il software che fa della velocita' un fattore critico, non solo per quanto riguarda la possibilita' del codice
assembly di automodificarsi,
Infatti questo è male. Ho letto su www.doom9.org di un utente che ha il service pack 2 e virtuadub (un noto programma fortemente ottimizzato per l'editing video) va in errore sembra proprio a causa di codice assembler automodificante. Ora considerando che occorrono ore e ore per fare editing video se ciò dovesse essere confermato vorrà dire che non potremo più contare su tale codice ottimizzato aumentando i già lunghi tempi di video editing.

quello che avevo sentito era che in realtà il codice automodificante sarebbe stato "bandito" anche se non ufficialmente , cioè deprecato, e che lo stesso kernel di NT non ne consentirebbe l' esecuzione...
e ciò da anni, per limitare la pericolosità dei virus (soprattutto quelli polimorfici, che nel decennio scorso andavano abb di moda) e di programmi scritti in modo "sporco" ...

...può anche essere che fossero tutte storie ... :rolleyes: :rolleyes:

cmq Ikitt_claw & "repne scasb" (MITICO!!) è sempre un piacere leggervi, non sarò l'ultimo scemo sulla terra in fatto di PC ma voi ne sapete veramente troppaa!!! sapete che un tempo (ma anche oggi) famiglie intere muoiono stranamente perchè sapevano troppe cose?? non vorrei che vi succedesse anche a voi :D

cmq siete dei grandi!!!!

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

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?

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? :wtf:
(D'accordissimo sull'elegante inefficienza dell'algoritmo MAC)

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.

repne scasb: sei un mito... Ogni volta che intervieni rimango :sbavvv:
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...

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!

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

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)

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.

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

intel sempre a rincorre ultimamente.....

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

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/content_type/white_papers_and_tech_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.

:eek:
:ave::ave::ave:

Lo scopo di NX è dichiarare una pagina non eseguibile. Se mappi una pagina _senza_ il bit NX _e_ scrivibile, puoi utilizzare il codice polimorfico.
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.

Originariamente inviato da magilvia
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.

Originariamente inviato da repne scasb
Non vorrei imbattermi in implicazioni filosofiche/polemiche, o peggio buonistiche/qualunquistiche, ma sono io che ti ringrazio, per aver avuto la costanza di ascoltarmi. Faccio molta "fatica" a trovare interlocutori disposti a leggere "tutto" quello che scrivo (non soffro di falsa modestia), e faccio ancora piu' fatica a trovare dei "dialogatori" disposti a confutare in modo "sensato", quello che scrivo (ho anche provato a inserire nei post piu' chiavi di lettura, o informazioni volutamente "errate", ma nulla).

P.S. Magari questo post, irritera' qualcuno.
Lungi da me irritarmi, non mi stupisco del fatto che trovi pochi interlocutori... parli una lingua sconosciuta! :D
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 :D).



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

Ciao a tutti :)

Originariamente inviato da xeal

Visto che chiami in causa anche gli altri... :)

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

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.


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,

Beh, si certo: basterebbe non sbagliare programmando :D
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 ;)

Originariamente inviato da repne scasb
I 128 registri float di Itanium sono a 82 bit,
Ecco spiegato l'arcano. ;)
guarda caso il doppio di 41, e un pacchetto e' formato da 3 istruzioni a 41 bit + 5 bit di maschera; la maschera spiega come devono essere le tre istruzioni che compongono il pacchetto, non puoi mischiare tutte le combinazioni, ne puoi utilizzare solo alcune; perdipiu' la maschera inizializza e deinizializza le porzioni di codice parallelo. Un rompicapo insomma, praticamente impossibile da fare a mano.
Sì, di questo avevo già delle informazioni. :)
Ci sono, ma si preferiscono i bit di predicato in quanto per tutte le istruzioni di Itanum e' disponibile l'esecuzione predicativa (pensa invece che a dei flag di stato a dei registri a un bit, per esempio il carry va a 1, adesso metto questo risultato nel bit di predicato 49, e fra 10 pacchetti lo vado a ripescare; in realta' c'e' una somma intera ma e tipo un LEA, spero che il compilatore la utilizzi al posto del MAC, per le moltiplicazioni-divisioni non c'e' soluzione).
L'utilità dei predicati m'è nota, ma con questo sistema c'è comunque un problema: bisogna calcolare il carry (o uno degli altri flag), quando serve, e questo porta via tempo (esecuzione di una o più istruzioni) e risorse (lo spazio per esse); non è che sia una bella cosa.
A ciò aggiungi pure il fatto che un buon programmatore generalmente sa fare buon uso di questi flag, a seconda del tipo di algoritmo da implementare chiaramente (in assembly).
Queste ci sono, ma non le puoi utilizzare sempre (per esempio non ne puoi utilizzare 2 insieme se non fai almeno un accesso alla memoria.........che disperazione.........mi sembra il modo HAM dell'Amiga); di fatto un ALU ce l'hai, ma e' realmente castrata.
Almeno l'HAM aveva un significato e un'utilità. :) Comunque, inizia a sorgermi un dubbio: ma i centinaia di milioni di transistor dell'Itanium, a che servono? :D
Questo e' ovvio. Un achitettura a parallelismo stretto, se gli dai un problema che non puo' essere reso "bene" in modo parallelo, non avra' di certo grandi performace.
Appunto. Mi sembravi un po' troppo convinta della possibilità che anche EPIC potesse arrivare a dei risultati strabilianti, tempo e risorse umane permettendo: ciò non è sempre possibile, per quante risorse di questo tipo di abbiano a disposizione. La natura del codice non si presenta sempre come la si vorrebbe.
Su itanium in caso di grande sfortuna, un pacchetto puo' anche conternere solo la maschera di "fine parallelismo" ossia 128 bit - 16 byte solo per dare quest'opcode (+ 3 istruzioni che non fanno nulla, e pure qua hai delle limitazioni non puoi dare 3 NOP di seguito...........)).
Beh, ma puoi sempre infilare 3 branch in un bundle, no? ;) Anche se l'utilità di questa configurazione della maschera è tutta da dimostare: già le configurazione possibili sono veramente poche, così non si fa che buttare via possibilità di miglioramento per il futuro (chissà cosa si fumano gli ingegneri di HP e Intel :D)

Originariamente inviato da repne scasb
Che io sappia e' tutta cache (o quasi); per il discorso fatto in un mio precedente post poiche i/b e' molto basso la cache deve essere molto grande.
Direi...con l'opcode da 128 bit ;)
Ma a questo punto a chi programma su Itanium non conviene fare tutto o quasi con i flotaing point ?

Infatti...questa cosa l'avevo notata dai vari test...ed ora ho capito perchè succede... Grazie ;)

Originariamente inviato da repne scasb
Se utilizzi un linguaggio di alto livello direi di si, tutto "double". Tanto poi il compilatore trasforma gli int in double, tanto vale dichiararli subito come double.
Questo puoi farlo se il programma che scrivi girerà solamente su Itanium, altrimenti è più conveniente qualche #ifdef per utilizzare int o double a seconda del processore per cui verrà compilato.

Ciao a tutti! Mi scuso per essere tornato su questo thread soltanto adesso (ma lo avevo già anticipato, e rinnovo l'avviso per future risposte, nella speranza che qualcuno lo segua/seguirà ancora).

Originariamente inviato da repne scasb
"itanium non ha istruzioni assembly intere per fare somme/sottrazioni".


Ma allora perchè hanno messo ben 4 alu? Ok, 2 servono anche (a questo punto direi solo) per accedere in memoria, almeno lo spreco non è completo, certo però che si tratta proprio di una genialata...


Dal mio punto di vista una CPU senza ALU e' inefficiente (leggi i miei precedenti post per chiarimenti.


Sono d'accordo, semplicemente speravo che quelle alu servissero a qualcosa di concreto, capisco che itanium ha una fpu mostruosa, però usandola nelle operazioni sugli interi non può che cedere il passo a chi sfrutta un'ALU.


Magari ora e' piu' chiaro perche Itanium non e' "molto" performante quanto si utilizzano gli interi.

Stavo cominciando a pensarlo anch'io, però lo hai scritto prima tu. Mi hai anticipato... di una quidicina di giorni :D :sofico:

Comunque ti è sfuggita una mia piccola provocazione (eh si, ho provato a copiare il tuo "stile" :D, non mi sembra un'idea poi così malvagia), anche perchè mi sembra di capire che tu stenderesti volentieri un velo pietoso su itanium. Quel velo, però, io lo riferivo un po' a tutta la categoria: mi spiego, se è vero che con gli x86 si giunge rapidamente ad una ottimizzazione decente, mentre per sfruttare appieno le potenzialità di un risc occorrono diversi anni, non è possibile che in questi anni si possa affinare il codice x86 fino a giungere ad una sostanziale equivalenza, o addirittura fino a mantenere il gap iniziale (o almeno una parte), oppure si giunge inevitabilmente ad un sorpasso?

Inoltre i cisc attuali sono molto complessi e in un certo senso (ti prego di concedermi l'uso del termine) "ibridi", poichè spezzano le istruzioni cisc in micro-operazioni che ne rendono il funzionamento effettivo (correggimi se sbaglio) simile a quello di un risc, cercando di ottimizzare il codice assembly tenendo conto delle caratteristiche "interne" del processore, e quindi provando ad esaltarne la natura (chiedo nuovamente comprensione per le mie "licenze poetiche") "risc-like" (se non sbaglio alcuni compilatori, come gli intel, fanno qualcosa del genere per cercare di ottimizzare al meglio il codice rispetto ai risultati ottenibili prendendo come modello un x86 generico) non si potrebbero ottenere risultati ottimi anche con gli x86, stabilendo un equilibrio con le altre architetture, se non un vantaggio legato al gap temporale di partenza?

Cioè, visto che gli x86 di oggi cercano di migliorare le proprie prestazioni cercando di coniugare i vantaggi dei due modelli classici (cisc-risc), non si potrebbe fare altrettanto nel codice (fermo restando i limiti che potrebbero risiedere nella natura intrinseca di tipo cisc delle istruzioni x86)?


"Sembrerebbe" che NX_STATUS possa essere modificato solo da ring 0.


Ehm, chiedo mercè ma le mie conoscenze in questo campo sono piuttosto limitate, potresti gentilmente tradurre "ring 0" in italiano per profani? Se poi mossa da pietà decidessi di ricorrere ad un paio di dialetti (il siciliano è più che sufficiente), te ne sarei immensamente grato :D :D :D


Da come l'hai descritto sembra un antivirus. Comunque, come gia' fatto notare dall'utente magilvia se la disabilitazione dell'NX_STATUS e' semi-automatica a che serve? Se un software automodificante fa apparire un richiesta di Windows "Disabilito XYZ?" quanti utenti saprebbero che fare? Come distiunguo un software automodificante da un overflow sullo stack?



In effetti mi sono un po' ispirato al meccanismo di antivirus/firewall. La disabilitazione "semi-automatica" potrebbe servire a salvare capra e cavoli. Per il resto, rispondo tra qualche riga.


Originariamente inviato da cdimauro
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.

Pensavo anch'io ad una syscall, come ha suggerito anche Ikitt_Claw. Del resto, si tratta di gestire risorse che potrebbero creare conflitti se lasciate all'arbitrio dei singoli processi, quindi il ricorso alle chiamate di sistema è d'obbligo. Pensavo però ad un meccanismo che consenta un controllo sui processi per ovviare all'impossibilità per il sistema operativo di distinguere tra un uso proprio e improprio della disabilitazione su richiesta del flag nx.

Ovviamente questo meccanismo presuppone un buon livello di conoscenza da parte dell'utente, quindi bisognerebbe operare una selezione tra gli utenti:[list=a]
creiamo una versione di base (diciamo una home) con il flag sempre attivo e non alterabile

creiamo una versione per utenza esperta, con flag disattivabile solo da alcune categorie di utenti (con le quali non si dovrebbe accedere a internet)
[/list=a]
Nella versione "professionale", riservata ad un utenza particolarmente esperta che supponiamo essere destinataria dei programmi più professionali e ottimizzati che fanno uso di codice automodificante, il flag nx dovrebbe essere comunque attivo di default, per evitare problemi. Il programma che necessita la disabilitazione del flag dovrebbe richiederla al sistema operativo, che chiede l'autorizzazione all'utente con un messaggio sintetico espandibile, nella cui versione estesa vengano esposti in maniera chiara e semplice i pro e i contro dell'autorizzazione, elencando brevemente le principali tipologie di programmi che potrebbero necessitare la disabilitazione del flag, compresi i virus, e sconsigliando il consenso a file scaricati come allegato a qualche email. La scelta operata dall'utente dovrebbe essere memorizzata (meglio se permanentemente) per due motivi:[list=a]
per non dover richiedere nuovamente il consenso alle esecuzioni successive;

per poter ripristinare il valore corretto del flag ogni volta che il controllo del sistema torna ad un processo che ha ottenuto il consenso alla disabilitazione del flag (qui entra in gioco il meccanismo di gestione del context switch).
[/list=a]
Si potrebbe pensare anche alla possibilità di richiedere "permessi multipli" per più componenti (eseguibili, librerie) da integrare negli installer, i quali ad un certo punto dell'installazione dovrebbero rendere nota all'utente la necessità di settare il flag (in maniera comprensibile) così che l'utente possa scegliere l'opzione corretta alla successiva richiesta del sistema operativo; in questo modo il meccanismo di interazione contestuale alla prima richiesta da parte di un processo diventerebbe (gradualmente) marginale e limitato ad una funzione di sicurezza.

Ritengo opportuno che l'interfaccia del programma con il s.o. rimanga essenziale ed omogenea (in ogni caso si attiva una ricerca in un database con conseguente eventuale interazione con l'utente) al fine di limitare la possibilità che presenti dei bug. Del resto, anche il meccanismo di abilitazione/disabilitazione fissa per un'intera sessione potrebbe presentare dei bug sfruttabili da un virus (che potrebbe riuscire a disattivare il controllo per la sessione successiva, in modo da poter sfruttare eventuali bug di buffer overrun al successivo riavvio; per risolvere il problema definitivamente occorrerebbe forse delegare interamente il controllo all'hardware in maniera non disattivabile via software, ma in genere i compromessi sono preferibili alle soluzioni più drastiche). Ovviamente questa è la mia visione del problema, aspetto le vostre critiche (mi raccomando, non abbiate pietà :D).


Questo puoi farlo se il programma che scrivi girerà solamente su Itanium, altrimenti è più conveniente qualche #ifdef per utilizzare int o double a seconda del processore per cui verrà compilato.

Scusa, ma non c'è il rischio di dover mettere troppi ifdef (e simili)? Se bisogna scegliere ogni volta il tipo corretto in maniera condizionale, credo che ci sia il rischio di dover inserire un ifdef - elif ogni tre righe, all'interno di tutte le funzioni (eventualmente di libreria) o anche nella definizione dei parametri e del tipo di ritorno. A mio avviso (sono sotto l'influsso illuminante della dea Pigrizia :D) si potrebbe risolvere il problema anche scrivendo il programma prima per... il resto del mondo, con tutti gli int del caso, per poi derivare la versione dei sorgenti per itanium con una semplice sostituzione globale e automatica di tutti gli int (unsigned, long ecc.) con dei double :D :p

Chiedo scusa, l'ho un po' sparata (colpa del sonno). Basterebbe una sola direttiva condizionale con un opportuno typedeff, quindi lavorare nè con int, nè con double, ma con "floatint" o qualcosa del genere. Comunque l'alternativa del "trova e sostituisci" è sicuramente meno elegante, ma valida :p. Ovviamente la compilazione condizionale è migliore, nell'ottica di inserire altre eventuali ottimizzazioni specifiche.


Originariamente inviato da Ikitt_Claw
...nell'interprete/VM/Compilatore JIT/quelchee` del linguaggio ad alto livello.

"Quelcheè" è la variante corretta, pensavo ad un linguaggio comunque compilato, non interpretato. Da java ho preso come spunto di riflessione il trattamento degli array come oggetti che hanno come proprietà peculiari un'area di memoria dove immagazzinare dati con dei limiti ben precisi, la cui violazione genera un'eccezione. Effettivamente questo potrebbe incidere sul grado di ottimizzazione del codice risultante, soprattutto (credo) in termini di memoria occupata (dipende da quanto complesso è l'oggetto in questione), oltre che di overhead di calcolo (per la verifica della correttezza dell'indirizzo richiesto).

Spero che qualcuno mi risponda e abbia la pazienza di aspettare un'altra quindicina di giorni per una mia eventuale replica. Ciao :)

Originariamente inviato da xeal
Cioè, visto che gli x86 di oggi cercano di migliorare le proprie prestazioni cercando di coniugare i vantaggi dei due modelli classici (cisc-risc), non si potrebbe fare altrettanto nel codice (fermo restando i limiti che potrebbero risiedere nella natura intrinseca di tipo cisc delle istruzioni x86)?
I compilatori già lo fanno. :)
Ehm, chiedo mercè ma le mie conoscenze in questo campo sono piuttosto limitate, potresti gentilmente tradurre "ring 0" in italiano per profani? Se poi mossa da pietà decidessi di ricorrere ad un paio di dialetti (il siciliano è più che sufficiente), te ne sarei immensamente grato :D :D :D
RING 0 è il livello "kernel", parafrasando il temine in uso nei s.o., ed è l'unico che permette di utilizzare alcune istruzioni "delicate", come quelle per controllare la paginazione della memoria, i task, ecc.
[...]Ritengo opportuno che l'interfaccia del programma con il s.o. rimanga essenziale ed omogenea (in ogni caso si attiva una ricerca in un database con conseguente eventuale interazione con l'utente) al fine di limitare la possibilità che presenti dei bug. Del resto, anche il meccanismo di abilitazione/disabilitazione fissa per un'intera sessione potrebbe presentare dei bug sfruttabili da un virus (che potrebbe riuscire a disattivare il controllo per la sessione successiva, in modo da poter sfruttare eventuali bug di buffer overrun al successivo riavvio; per risolvere il problema definitivamente occorrerebbe forse delegare interamente il controllo all'hardware in maniera non disattivabile via software, ma in genere i compromessi sono preferibili alle soluzioni più drastiche). Ovviamente questa è la mia visione del problema, aspetto le vostre critiche (mi raccomando, non abbiate pietà :D).
Una soluzione semplice e provo a darla io. Basterebbe utilizzare un nuovo "hunk" BSS per gli eseguibili, per indicare al s.o. di non impostare il flag NX.
Infine, eseguibili di questo tipo dovrebbero essere certificati da qualche ente indipendente, che ne garantisca il funzionamento non malevo: soltanto in questo caso sarebbe possibile eseguirli. Il s.o. dovrebbe leggere il certificato, e se valido permettere, tramite opportune syscall, di poter anche allocare memoria senza flag NX.
Tutto ciò sarebbe trasparente agli occhi degli utenti, che non si accorgerebbero di nulla.
E' anche pratico, perché sono ben poche le applicazioni che hanno queste particolare necessità, e che quindi richiedano la certificazione appropriata.
Chiedo scusa, l'ho un po' sparata (colpa del sonno). Basterebbe una sola direttiva condizionale con un opportuno typedeff, quindi lavorare nè con int, nè con double, ma con "floatint" o qualcosa del genere. Comunque l'alternativa del "trova e sostituisci" è sicuramente meno elegante, ma valida :p. Ovviamente la compilazione condizionale è migliore, nell'ottica di inserire altre eventuali ottimizzazioni specifiche.
Ti sei risposto da solo... :)
Spero che qualcuno mi risponda e abbia la pazienza di aspettare un'altra quindicina di giorni per una mia eventuale replica. Ciao :)
No problem. Per le altre questioni, penso che repne scasb sia persona più indicate a fornire le informazioni che chiedi... :)

Originariamente inviato da cdimauro
Una soluzione semplice e provo a darla io. Basterebbe utilizzare un nuovo "hunk" BSS per gli eseguibili, per indicare al s.o. di non impostare il flag NX.
Infine, eseguibili di questo tipo dovrebbero essere certificati da qualche ente indipendente, che ne garantisca il funzionamento non malevo: soltanto in questo caso sarebbe possibile eseguirli. Il s.o. dovrebbe leggere il certificato, e se valido permettere, tramite opportune syscall, di poter anche allocare memoria senza flag NX.
Tutto ciò sarebbe trasparente agli occhi degli utenti, che non si accorgerebbero di nulla.
E' anche pratico, perché sono ben poche le applicazioni che hanno queste particolare necessità, e che quindi richiedano la certificazione appropriata.


Sarebbe una buona soluzione. Io ero partito dall'ipotesi della possibilità per l'utente di scegliere se abilitare o meno la protezione, cercando di immaginare un meccanismo per arginare le possibili conseguenze negative del "libero arbitrio", cercando di renderlo poco invasivo.

La tua idea non è affatto male, anche se temo (sarò troppo paranoico di questi tempi) che se realizzata possa essere strumentalizzata al fine di imporre palladium. So bene che non ha niente a che fare il non execute, però un paragone sarebbe a mio avviso possibile, nel senso che si tratterebbe, alla luce del sistema di certificazione che ipotizzi, di due protezioni hardware che consentono l'accesso a determinate risorse in una determinata modalità (palladium inizialmente dovrebbe presentarsi come una particolare modalità disattivabile, come anche l'NX bit) sulla base di certificazioni software che ne garantiscono l'autorizzazione; delle due soluzioni la seconda (palladium) è sicuramente la più complessa: a questo punto non si potrebbe cercare di spacciare maliziosamente la seconda per una evoluzione "naturale", più "sofisticata" ed efficiente della prima?

Provo a spiegarmi meglio: Nx da solo non può essere in alcun modo considerato come un precursore di palladium, daccordissimo, ma che mi dici di Nx più una certificazione sul diritto dell'eseguibile a disabilitare la protezione, in modo analogo a come le certificazioni in ambiente tcpa consentirebbero il rilascio delle chiavi per decriptare i dati e poter eseguire del codice, disattivando di fatto la protezione laddove sia noto che non è più necessaria? Qualcuno non potrebbe forzare il paragone dicendo: "Ecco, con palladium abbiamo risolto il problema alla radice, perchè adesso non solo non sarà più eseguito codice che potrebbe sfruttare un bug, ma saranno eseguiti solo i programmi certificati da un gruppo di esperti che controlleranno minuziosamente tutto cercando di individuare ed eliminare ogni pericolo! Nessun virus potrà più infettarvi!"?

D'altra parte ogni sistema di sicurezza basato su certificazioni provenienti dall'alto può comportare dei rischi: tempo fa ricordo il furto proprio di alcuni certificati validi non ancora attribuiti che avrebbero potuto essere sfruttati da qualche virus/spyware/ecc. (non ricordo esattamente come andò a finire la vicenda). In genere si tratta di rischi potenziali ma poco concreti, se le cose sono fatte bene, però con gli interessi che girano dietro palladium mi guarderei bene da qualunque cosa gli assomigli anche lontanissimamente.

Certo, se il sistema venisse implementato solo come dici tu e l'ente certificatore fosse realmente non malevolo sarebbe la soluzione ideale, su questo non ci piove: semplice, trasparente, a prova di cretino. Tuttavia temo che tale organo non possa permettersi di essere troppo benevolo per motivi economici: se è vero che le applicazioni che fruirebbero del "servizio" sono molto poche, potrebbe risultare antieconomico un meccanismo del genere e più semplice abbandonare la programmazione di codice automodificante, a meno che non ruotino altri interessi attorno al sistema di certificazioni.

Forse la mia è solo paranoia pura, però con palladium alle porte consentimi di essere diffidente verso ogni idea anche la più innocua prima di averne valutato tutte le possibili (o impossibili) conseguenze, anche le più paranoiche e deliranti.

Mi è sembrato di capire da alcuni tuoi post che ritieni lecito pensare che stiano lavorando "sottobanco" per metterci di fronte al fatto compiuto, e in fondo stanno lavorando bene: alcune periferiche (le audigi 2 o sbaglio? i prescott con lagrande, perfino - se non sono male informato - alcuni thinkpad che integrano già il chip fritz) sono già conformi, praticamente manca solo il software. Mi viene in mente la battuta di un film (di cui non ricordo il titolo, comunque non si tratta dei pirati di silicon valley): "La più grande beffa che il diavolo abbia mai fatto è stata far credere al mondo che non esiste..."; non riesco a fare a meno di collegarla alla notizia di una battuta di arresto nel processo di sviluppo di palladium, per concentrare altrove le risorse della Microsoft, salvo poi venir fuori al momento opportuno con una propaganda massiccia sull'utilità di palladium quando tutto sarà pronto. Probabilmente non potremo farci niente comunque, però almeno preferirei non concedere la possibilità di far passare palladium per una cosa "buona e giusta" che nasce da un'altra cosa "buona e giusta", con la quale abbiamo convissuto "anche se non lo sapevamo". Certo che per fini propagandistici (perchè è di questo che stiamo parlando, non certo della bontà di una soluzione semplice e trasparente per salvare capra e cavoli come vorrebbe repne scasb) si potrebbe strumentalizzare qualsiasi cosa, soprattutto per far leva sui meno esperti, si potrebbe dire qualcosa di simile anche per la mia idea: "Adesso sarete protetti meglio, e non dovrete più rispondere alle richieste dei programmi che si installano o che vengono eseguiti, il sistema farà tutto in automatico" e questo a prescindere dalla sua praticabilità. Comunque tremo letteralmente all'idea di associare una protezione hardware ad un sistema di controllo sulla stessa basata su certificati, seppur per fini decisamente positivi, con la minaccia incombente di un sistema in un certo senso simile ma decisamente meno opinabile, soprattutto perchè temo che il paragone che ho formulato prima potrebbe servire a confondere le acque e prendere tempo, in aggiunta alle lungaggini burocratiche, in caso di controversie con l'antitrust. Meglio non cedere terreno al nemico (palladium, non la MS in sè) se possibile, no?

Ad ogni modo, se mi concedi di concludere questa panoramica delle "opere" nel mio museo personale della paranoia, il paragone si potrebbe portare comunque: le autorizzazioni mediante certificati esistono da tempo (sui contenuti internet, sui driver testati...), un meccanismo di protezione hardware c'è anche (il bit NX), se mettiamo le due cose insieme e creiamo un sistema hw più "sofisticato" del bit NX otteniamo un sistema perfetto. Speriamo che non venga in mente a nessuno, o che nessuno ci creda. Resta il fatto che il bit NX "è veramente cosa buona e giusta", serve, eccome...


RING 0 è il livello "kernel", parafrasando il temine in uso nei s.o., ed è l'unico che permette di utilizzare alcune istruzioni "delicate", come quelle per controllare la paginazione della memoria, i task, ecc.


Originariamente inviato da repne scasb
Una CPU 80386 o superiore e' in grado di "imitare" il completo spazio d'indirizzamento con un massimo di 4 nidificazioni; tali nidificazioni si chiamano "ring" e sono numerati da 0 a 3. Un software che funzioni in ring 3 e' "convinto" di avere a disposizione un proprio "mondo" fatto di istruzioni/porte/locazioni di memoria, tale mondo in realta' e' solo fittizio ed e' generato e limitato da un altro software che gira in ring 2. Anche il software che gira in ring 2 e' "convinto" che il suo spazio d'indirizzamento (...) e' quello reale ma in realta' e' controllato e generato da un software in ring 1, e via di seguito (molto Matrix). In Windows sono utilizzati i ring 0 (kernel) e ring 3 (applicativi). Non solo, un software applicativo e' in grado di imitare (layer hardware+software) completamente anche la struttura a ring della modalita' protetta. Quindi un kernel che gira in ring 0 e' "sicuro" di essere l'anello piu' profondo, in realta'.... (un ottimo esempio di questo meccanismo (hardware+software) e' offerto dal software vmware workstation).


Capito. In sostanza si tratta dell'implementazione diciamo di basso livello (per quanto riguarda almeno la gestione della memoria) del concetto di programmazione a strati (macchine virtuali) del sistema operativo, che nei "vecchi" S.O. multiutente (dedicati al timesharing) consentivano a ciascun utente/applicativo di vedere l'hw come dedicato in maniera esclusiva, con tanto di modo utente e supervisore per ciascuno strato e trap allo strato inferiore. VMware workstation funziona praticamente in questo modo, giusto (non per il multiutente, non credo lo supporti)?

Non mi e' possibile rispondere a questa domanda in modo non esaustivo, e non possiedo il tempo necessario per una risposta esaustiva. Aggiongo inoltre che: anche rispondendo in modo esaustivo la risposta sarebbe poco plausibile oltre e "altamente" opinabile (sarebbe come tentare di prevedere il comportamento di un automa-cellulare di quarta classe dopo 1 milione di generazioni).

In effetti servirebbe la sfera di cristallo. Continuo a chiedermi, comunque, se giocando sulla maggiore flessibilità (interna) ed efficienza delle micro operazioni dei cisc di oggi non sia possibile ottenere un'ottimizzazione del codice paragonabile a quella dei risc per problemi specifici e ben noti, anche se probabilmente si incontrerebbe qualche limite nel dover gestire comunque le macroistruzioni x86, che probabilmente hanno una "flessibilità" minore (ai fini dell'ottimizzazione) rispetto alle istruzioni risc e alle stesse micro-op interne, magari potendole gestire direttamente (cosa che probabilmente è la carta vincente dei risc sulla lunga distanza) si potrebbe giocare molto più "di fino" nella gestione della potenza di calcolo.

P.S. Cesare, ti sei laureato poi? Devo chiamarti ingegniere? Se è cosi, auguri :)
In caso contrario, in bocca al lupo per la tesi.

Ciao a tutti. ;)

sinceramente c'ho messo due ore a leggere tutto il thread e non posso non fare i complimenti a repne scasb, veramente una delle persone più competenti che abbia mai letto su forum italiani ed esteri.

Originariamente inviato da xeal
Sarebbe una buona soluzione. Io ero partito dall'ipotesi della possibilità per l'utente di scegliere se abilitare o meno la protezione, cercando di immaginare un meccanismo per arginare le possibili conseguenze negative del "libero arbitrio", cercando di renderlo poco invasivo.
Sì, ma sarebbe troppo complicato: agli utenti devi dare un sistema quanto più semplice possibile da utilizzare. :)
La tua idea non è affatto male, anche se temo (sarò troppo paranoico di questi tempi) che se realizzata possa essere strumentalizzata al fine di imporre palladium. [OMISSIS]
Non credo che questo sistema di certificazioni possa essere in qualche modo pensato come l'apripista di Palladium. Certamente MS potrebbe prenderne spunto e inserirlo dentro il contesto di Palladium, ma io la vedo come una cosa completamente a sé stante, che può "godere di vita propria". Tra l'altro, la soluzione che ho immaginato dipende completamente dal software: serve a sfruttare meglio una caratteristica hardware già presente nei nuovi processori, e che è nata per uno scopo ben preciso.
Certo, se il sistema venisse implementato solo come dici tu e l'ente certificatore fosse realmente non malevolo sarebbe la soluzione ideale, su questo non ci piove: semplice, trasparente, a prova di cretino. Tuttavia temo che tale organo non possa permettersi di essere troppo benevolo per motivi economici: se è vero che le applicazioni che fruirebbero del "servizio" sono molto poche, potrebbe risultare antieconomico un meccanismo del genere e più semplice abbandonare la programmazione di codice automodificante, a meno che non ruotino altri interessi attorno al sistema di certificazioni.
Guarda, le applicazioni che necessitano di poter controllare lo stato del bit NX sono talmente poche, che tenere in piedi un sistema di certificazione per MS o per qualunque altro ente non dovrebbe essere assolutamente un problema; e neppure per le società che richiederebbe questo tipo di certificati.
Proprio per questi motivi ho avanzato la mia proposta per risolvere questo problema.
Forse la mia è solo paranoia pura, però con palladium alle porte consentimi di essere diffidente verso ogni idea anche la più innocua prima di averne valutato tutte le possibili (o impossibili) conseguenze, anche le più paranoiche e deliranti.
Anch'io sono MOLTO diffidente su Palladium, e in passato quando sono intervenuto in merito sull'argomento ho espresso valutazioni pesantemente negative, ma in questo caso bisogna discernere: non si può mettere tutto in un calderone per paura del grande fratello, anche se il rischio di strumentalizzazione può essere alto.
Mi è sembrato di capire da alcuni tuoi post che ritieni lecito pensare che stiano lavorando "sottobanco" per metterci di fronte al fatto compiuto, e in fondo stanno lavorando bene: alcune periferiche (le audigi 2 o sbaglio? i prescott con lagrande, perfino - se non sono male informato - alcuni thinkpad che integrano già il chip fritz) sono già conformi, praticamente manca solo il software. Mi viene in mente la battuta di un film (di cui non ricordo il titolo, comunque non si tratta dei pirati di silicon valley): "La più grande beffa che il diavolo abbia mai fatto è stata far credere al mondo che non esiste..."; non riesco a fare a meno di collegarla alla notizia di una battuta di arresto nel processo di sviluppo di palladium, per concentrare altrove le risorse della Microsoft, salvo poi venir fuori al momento opportuno con una propaganda massiccia sull'utilità di palladium quando tutto sarà pronto. Probabilmente non potremo farci niente comunque, però almeno preferirei non concedere la possibilità di far passare palladium per una cosa "buona e giusta" che nasce da un'altra cosa "buona e giusta", con la quale abbiamo convissuto "anche se non lo sapevamo".
Concordo: di Palladium non se ne sta più parlando, e questo è un male. MS e le altre società del consorzio lavorano alacramente lontano da occhi e orecchi indiscreti, e alla fine ci ritroveremo in un mondo Palladium-ready senza accorgercene... :(
Meglio non cedere terreno al nemico (palladium, non la MS in sè) se possibile, no?
Sì, ma è bene anche non lasciarsi prendere dal panico. :)Palladium va ben oltre un banale ;) meccanismo software come quello che ho ipotizzato.
Ad ogni modo, se mi concedi di concludere questa panoramica delle "opere" nel mio museo personale della paranoia, il paragone si potrebbe portare comunque: le autorizzazioni mediante certificati esistono da tempo (sui contenuti internet, sui driver testati...), un meccanismo di protezione hardware c'è anche (il bit NX), se mettiamo le due cose insieme e creiamo un sistema hw più "sofisticato" del bit NX otteniamo un sistema perfetto. Speriamo che non venga in mente a nessuno, o che nessuno ci creda. Resta il fatto che il bit NX "è veramente cosa buona e giusta", serve, eccome...
Appunto. E finché la situazione rimane così, senza ulteriori modifiche all'hardware, mi sta benissimo, e si può pensare di applicare una soluzione come quella di cui sopra. Oltre no, non ci sto assolutamente.
[...RING...]VMware workstation funziona praticamente in questo modo, giusto (non per il multiutente, non credo lo supporti)?
Penso proprio di sì. :)
In effetti servirebbe la sfera di cristallo. Continuo a chiedermi, comunque, se giocando sulla maggiore flessibilità (interna) ed efficienza delle micro operazioni dei cisc di oggi non sia possibile ottenere un'ottimizzazione del codice paragonabile a quella dei risc per problemi specifici e ben noti, anche se probabilmente si incontrerebbe qualche limite nel dover gestire comunque le macroistruzioni x86, che probabilmente hanno una "flessibilità" minore (ai fini dell'ottimizzazione) rispetto alle istruzioni risc e alle stesse micro-op interne, magari potendole gestire direttamente (cosa che probabilmente è la carta vincente dei risc sulla lunga distanza) si potrebbe giocare molto più "di fino" nella gestione della potenza di calcolo.
Secondo me l'architettura x86 ha raggiunto, ormai, una flessibilità superiore a quella dei RISC: con l'aggiunta delle varie istruzioni SIMD, si è riusciti a coprire anche la carenza prestazionale nell'ambito del calcolo in virgola mobile. Il tutto a costi nettamente inferiori a quelli di macchine RISC più o meno blasonate.
Di cosa ha bisogno ancora l'architettura x86? Di niente: x86-64 ha portato una ventata d'aria fresca e l'ultima innovazione che mancanza per "chiudere il cerchio", IMHO. :)
P.S. Cesare, ti sei laureato poi? Devo chiamarti ingegniere? Se è cosi, auguri :)
In caso contrario, in bocca al lupo per la tesi.

Ciao a tutti. ;)
Mi sono laureato, ma per amici e conoscenti resto sempre Cesare. :p

Non credo che questo sistema di certificazioni possa essere in qualche modo pensato come l'apripista di Palladium.

Infatti parlavo di una possibile strumentalizzazione. Ok, esagero, è che palladium mi sta proprio sulle... palladie. No mi va giù l'idea di non poter "scippare" il mio processore e usarlo come fermacarte senza che la scheda madre se lo riprenda dicendomi che non ho un certificato che mi autorizza a farlo... :p


Guarda, le applicazioni che necessitano di poter controllare lo stato del bit NX sono talmente poche, che tenere in piedi un sistema di certificazione per MS o per qualunque altro ente non dovrebbe essere assolutamente un problema; e neppure per le società che richiederebbe questo tipo di certificati.


Credevo fosse il contrario, anche perchè lì per lì avevo pensato ad un ente del tutto autonomo, creato ad hoc, che dovesse campare su queste certificazioni. In tal caso la quantità inciderebbe, però se si trattasse del lavoro marginale di un organismo più grosso i conti tornerebbero.


Sì, ma è bene anche non lasciarsi prendere dal panico. Palladium va ben oltre un banale meccanismo software come quello che ho ipotizzato.


Vero, solo che potrebbe schematizzarsi come un complesso sistema di protezione hw, basato su cifratura, superabile solo da sw certificato: da qui è scattata la mia paranoia. Gridare "al lupo" per tutto ciò che può lontanamente somigliare, comunque, non serve a gran che, hai ragione; restare guardinghi, magari, si.


Mi sono laureato, ma per amici e conoscenti resto sempre Cesare

Beato te... :)

Ciao.

Grazie. :)

Per l'ente si dovrebbe fare qualcosa di simile a ciò che avviene attualmente con i driver WHQL. In ogni caso, ben poco lavoro per MS...