NX Bit anche per Intel

Ecco spiegato l'arcano.

Sì, di questo avevo già delle informazioni.

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

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?

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.

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 )

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

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




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





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.




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

Comunque ti è sfuggita una mia piccola provocazione (eh si, ho provato a copiare il tuo "stile" , 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)?





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





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.




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




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

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 . Ovviamente la compilazione condizionale è migliore, nell'ottica di inserire altre eventuali ottimizzazioni specifiche.




"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

I compilatori già lo fanno.

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.

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.

Ti sei risposto da solo...

No problem. Per le altre questioni, penso che repne scasb sia persona più indicate a fornire le informazioni che chiedi...

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







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



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.