Il Pentium 4 strizza l'occhio all'SP2

Anche Intel, dopo AMD, attiva nei suoi chip la tecnologia per la protezione della memoria supportata nell'ultimo service pack per Windows XP. Il colosso ha lanciato anche i suoi primi compilatori per codice x86 a 64 bit

Santa Clara (USA) - Seguendo le orme della sua più diretta rivale, AMD, Intel ha introdotto - senza troppa pubblicità - i suoi primi processori con la tecnologia per la protezione della memoria NX (No Execute), qui implementata con il nome di Execute Disable Bit (EDB).

Il supporto software al bit NX è stato incluso da Microsoft nel Service Pack 2 per Windows XP con il nome di Data Execution Prevention (DEP). Come spiegato nello speciale di Punto Informatico sull'SP2, questa tecnologia ha lo scopo di rafforzare la separazione tra le aree di memoria riservate ai dati e quelle riservate al codice, questo per impedire che un programma malevolo, sfruttando uno dei cosiddetti bug "buffer overflow", possa inserire del codice in aree riservate ai dati e successivamente invocarne l'esecuzione.

La tecnologia NX è integrata anche nei più recenti chip mobili di Transmeta e nell'imminente famiglia di processori Esther di VIA, inoltre esiste già una patch di Intel e Red Hat che ne aggiunge il supporto anche al kernel di Linux.
I processori di Intel in cui è stata attivata la funzione EDB sono contrassegnati dalla lettera "J" dopo il numero di modello. Tutti i Pentium 4 e i Celeron da 90 nanometri che d'ora in avanti giungeranno sul mercato saranno dotati della tecnologia EDB: il loro prezzo rimane invariato.

Fra i Celeron "J" lanciati sul mercato in questi giorni vi sono i primi modelli basati sul Socket T (775 pin) e la prima versione desktop del modello 340.

I prossimi chip ad implementare il bit NX saranno gli Xeon DP "Nocona", i primi ad aver abbracciato la tecnologia x86 a 64 bit di Intel nota come EM64T (Extended Memory 64 Technology).

A proposito di 64 bit, il chipmaker di Santa Clara ha di recente annunciato la disponibilità di una suite di strumenti per lo sviluppo di applicazioni ottimizzate per i chip EM64T. Fra questi tool, che supportano sia Windows che Linux, vi sono compilatori, debugger, analizzatori di prestazioni e la Math Kernel Library di Intel. Un portavoce del colosso ha spiegato che i nuovi compilatori generano codice pienamente compatibile con la tecnologia AMD64.
TAG: hw
33 Commenti alla Notizia Il Pentium 4 strizza l'occhio all'SP2
Ordina
  • Perché molti definiscano come Inutile questa feature (Che, tra l'altro, è presente in diversi processori architetturalmente più evoluti degli X86, che come sappiamo tutti sono, per problemi di legacy, dei papocchi immani).
    Ovvio, si possono utilizzare sistemi software (Stackguard, Propolice e i vari "canarini", implementati se non sbaglio soprattutto in OpenBSD) per evitare di "debordare" da un buffer
    Questo risolve il problema di Buffer Overflow, ma non dell'eventuale eseguibilità dello stack: se lo stack è sufficientemente grande, è possibile scrivere nello stack del codice malevolo e poi mandarlo in esecuzione, in un modo o nell'altro. Con questo tipo di protezione, invece è comunque possibile scrivere codice malevolo nello Stack ma appena si prova a mandarlo in esecuzione, il Processore si rifiuterà di farlo, perché la pagina di memoria che contiene lo stack sarà stata precedentemente marcata come "Non eseguibile".
    Tutto qui.

    ==================================
    Modificato dall'autore il 05/10/2004 11.30.04

  • - Scritto da: Parliamone

    > Perché molti definiscano come Inutile
    > questa feature

    Non e' propriamente inutile, pero' lascia un pochino perplessi il fatto che per arginare il fenomeno di "cattivi programmatori" si debba ricorrere a trucchi ad un livello piu' basso.
    Mi viene in mente quel tale che, comperata l'auto nuova, sfrecciava come un disgraziato per la citta', sicuro del suo airbag e delle barre lateraliSorride

    Personalemnte la trovo una feature interessante, non indispensabile pero'. Anche perche' ultimamente si tende a "virtualizzare" il contesto nel quale gira l'applicazione (JVM, per esempio), parando il culo a molti cattivi programmatori a livello piu' alto Sorride


    11237
  • - Scritto da: Giambo
    >
    > - Scritto da: Parliamone
    >
    > > Perché molti definiscano come
    > Inutile
    > > questa feature
    >
    > Non e' propriamente inutile, pero' lascia un
    > pochino perplessi il fatto che per arginare
    > il fenomeno di "cattivi programmatori" si
    > debba ricorrere a trucchi ad un livello piu'
    > basso.
    > Mi viene in mente quel tale che, comperata
    > l'auto nuova, sfrecciava come un disgraziato
    > per la citta', sicuro del suo airbag e delle
    > barre lateraliSorride
    >
    > Personalemnte la trovo una feature
    > interessante, non indispensabile pero'.
    > Anche perche' ultimamente si tende a
    > "virtualizzare" il contesto nel quale gira
    > l'applicazione (JVM, per esempio), parando
    > il culo a molti cattivi programmatori a
    > livello piu' altoSorride
    >
    >

    ricorda, non stiamo parlando di incompetenze in programmazione, ma di codice malevolo, e questo, se c'è l'interesse, può esser scritto per qualsiasi SO (e ora venite pure a dirmi che Linux è sicuro e non lo cracca nessuno e anche se lo cracca non può far danni che così mi faccio Cuattro Crasse Risate)

  • - Scritto da: avvelenato

    > ricorda, non stiamo parlando di incompetenze
    > in programmazione, ma di codice malevolo,

    Non proprio, si sta' parlando di "programmatori" che, non checkando i buffers, permettono di riscrivere aree di memoria riservate ad altro con codice malevolo.
    Contro il codice malevolo (Trojan, spyware, ...) l'unica arma e' avere il sorgente del programma che stai per installareSorride
    11237
  • po*ca pu77ana, dimenticarsi di controllare i puntatori ai buffer è il primo errore che si fa il primo giorno che si comincia a programmare in C, nonostante ciò adesso invece di svegliarsi e di imparare a programmare come si deve, occorre implementare in hardware qualcosa che previene i bachi software, ribaltando così la gerarchia chi-controlla-cosa...
    Insomma ne ho conosciuti di programmatori impediti che non si rendevano minimamente conto di cosa significa prevedere le condizioni d'errore, neppure in programmi semplicissimi, ma non credevo chela situazione fosse così grave!
    bye
    non+autenticato
  • ... Scusa ma non ho capito:
    Se io nell'area dati (esempio: faccio un malloc, parlimo in C dunque!) e ci scrivo dati qualunque è tutto OK.
    Se poi faccioun salto a quell'area il sistema operativo NON dovrebbe lasciarmelo fare. Non vorrei uscire fuori campo, ma potrebbe solo farlo con le istruzioni privilegiate in modalità supervisore. Ma lasciamo perdere.).
    Quindi è un problema di S.O., NON tanto di microcodice del sistema!
    Adesso che questo si possa fare indiscriminatamente è senz'altro sbagliato. Mi sembra incredibile che una simile stupidata non venisse controllata prima. Ma visto che neppure Linux permetteva di farlo (solo im modalità superuser forse? boh!!).
    Ora se un programma generico (= qualunque) NON controlla i puntatori, beh, neppure io l'ho mai fatto, e non vedo perchè dovrei. Semplicemente se alloco memoria mi preoccupo che questa mi venga data dal S.O. e basta, poi ci metto quello che mi pare. Onestamente non ho MAI fatto caso a cosa sucedeva SE saltavo ad eseguire in quella zona. Posso però dirti che se sbagliavo un puntatore (eh, non è così difficile ... !) il sistema crashava, senza dirmi perchè o dove,
    Con appositi tools mi accorgevo di questo (NuMega, se nn mi sbaglio), e magari mi diceva anche dove. Altrimenti erano proverbiali C...I!
    Se io permetto ad un driver per esempio (che gira nel kernel) di allocare memoria oppure con un buffer owerflow (oppure Integer out of range esempio!), penso che il S.O. non controlli pper questioni di priorità e velocità.

    Corretto?

    Ciao
  • Mi riferivo a svarioni molto più banali: esempio tipico, il sedicente programmatore deve ricevere una stringa lunga x dalla seriale, allora alloca un buffer di dimensione x+1 (per lo zero finale, perchè i sedicente programmatore è diligente!), poi scrive una bellissima routine che aspetta i caratteri dalla seriale e li mette uno per uno nel buffer fino a che arriva il carriage return (o il carattere eof a seconda delle preferenze) e alla fine aggiunge il terminatore - zero finale. Il "buffer" non è altro che un vettore di caratteri e il "puntatore" è semplicemente l'indice usato per puntare ai caratteri del buffer... più semplice di così!?!?!?!?
    Durante le prove, tutto bene.
    Appena installato dal cliente... un disastro. Basta che il sistema remoto mandi stringhe diverse (più lunghe) da quelle previste, ecco il buffer overflow! Oppure basta che restino dei caratteri spurii nei buffer di ricezione gestiti dal sistema operativo... e il buffer lungo x+1 allocato dal nostro bravo programmatore va subito in overflow. Allora lui comincia a dare la colpa ai disturbi, all'hardware instabile, ai cavi... Poi come al solito si dimostra dove stava l'errore, ma pochi capiscono la gravità di un simile modo di programmare... Così il Bravo Programmatore non viene cacciato via a calci nel sedere. Anzi, molti saranno ancora portati a credere che i problemi erano dovuti all'hardware instabile ecc. ecc.
    non+autenticato
  • > Corretto?

    Per evitare un BOF devi controllare non tanto che i puntatori siano usati correttamente, ma che non venga scritto + di quanto il buffer associato al puntatore possa contenere.
    Di solito questo avviene quando scrivi direttamente nel buffer dell'input dell'utente senza prima controllarne la lunghezza.

    Ad esempio, più che controllare i puntatori devi controllare di non usare certe funzioni (tipo get) direttamente su un array di char ...

    E' facile che qualche volta te ne scappi qualcuno, e su un programma notevolmente complesso ben venga il NX ...

    non+autenticato
  • sborone che c...o c'entra saper programmare o meno
    forse per te, quando ti si blocca il pc mentre smanetti coi tuoi programmini in c, eviti di riavviare
    non+autenticato
  • - Scritto da: Anonimo
    > sborone che c...o c'entra saper programmare
    > o meno
    > forse per te, quando ti si blocca il pc
    > mentre smanetti coi tuoi programmini in c,
    > eviti di riavviare

    Ma una volta questo non era punto informatico?
    non+autenticato
  • Ma se si risolve il problema a monte non è meglio comunque?

    Esistono per lo stesso motivo i linguaggi ad alto livello: per non reinventare l'acqua calda!
    non+autenticato
  • - Scritto da: Anonimo
    > Ma se si risolve il problema a monte non
    > è meglio comunque?
    >
    > Esistono per lo stesso motivo i linguaggi ad
    > alto livello: per non reinventare l'acqua
    > calda!

    Tu saresti in grado di scrivere un codice di migliaia di righe (per non parlare di un sistema operativo) completamente esente da bug? Se ci riesci, ti candido personalmente al premio Nobel (a patto di non riempire il codice di nop 's).
    non+autenticato
  • non credo abbiate capito il problema

    c'è chi fa il BOF volontariamente
    per mettere in memoria il suo bel worm come se fosse un'immagine o una file audio

    quello che cercano di fare è impedire ai virus writer di sfruttare il BOF in futuro

    ALK
    non+autenticato
  • Il service pack due a me non funziona!
    Le propietà di rete/connessioni .. spariscono!
    Non si avviano i processi il computer va in tilt ...

    hehehehe il tipo ha paura senza sp2 .. io no! Sorride


    non+autenticato
  • - Scritto da: Anonimo
    > Il service pack due a me non funziona!

    Se a te non funziona e ad altri milioni si... mmmm... direi che forse il problema e' "tuo" non loro.Sorride
    non+autenticato
  • > Se a te non funziona e ad altri milioni
    > si... mmmm... direi che forse il problema e'
    > "tuo" non loro.Sorride
    Mmmm...
    se con alcuni bios non funziona...
    se con numerosi software non funziona...
    se (stime M$) su 10 installazioni 3 vanno a farsi benedire (certo, se hai 100 macchine gemelle che ricadono nell'altro 70% dei casi e installi una *unica* immagine funzionante non hai problemi)...
    mi sa che i poblemi sono di un certo sig. Cancelli!
    non+autenticato
  • Mi interesserebbe sapere se questa "limitazione" hardware influenzera' anche la possibilita' di "modificare" un codice iniettandolo con le proprie routine. Io per hobby creo "mods" per giochi e spesso mi capita di dover modificare aree di memoria-codice sostituendo appunto parti di routine con le mie, oppure chiamando pezzi di codice scritti da me che risiedono nella memoria a disposizione dell'utente (proprio come dice l'articolo). Non e' un buffer overflow, ma il principio di funzionamento e' il medesimo... leggendo l'articolo pare che questo non sara' piu' possibile, be' spero di no, moddare i giochi e' la mia passione.Triste
    non+autenticato
  • se utilizzato mentre il codice non è in esecuzione funziona (quindi crakkatori, non temete). Creare tuttavia software che modifica il codice di un applicativo di esecuzione in runtime allora sei fregato amico. E' vero, per alcune cose è limitativo, come forse nel tuo caso (non ho capito, realizzi tipo trainer per i giochi?), ma credo che in realtà i mod li prepari prima che il programma parta quindi non dovresti avere problemi
    non+autenticato
  • Creo mod, non trainer o cheat per scelta "etica"Sorride (anche se il principio di funzionamente e' identico) ...odio i cheater.
    In pratica "inserisco" nel gioco funzioni non implementate nella versione originale (le "mancanze" che riscontrano i giocatori) oppure "correggo" errori, in pratica mini-patch, della cui realizzazione dovrebbe curarsi la casa, le faccio io (cosi' come molte altre persone) per passione.
    Ovviamente non posso intervenire sul sorgente, quindi devo necessariamente "patchare" l'eseguibile, e purtroppo nei giochi "moderni" questo non e' possibile intervenendo sull'eseguibile sul disco ma devo farlo in memoria, perche'? Perche' le nuove protezioni anticopia sono prese da un film di spionaggioA bocca aperta ...almeno oggi patchare un eseguibile protetto ad esempio con starforce3 (ultima versione) e' una impresa impossibile non disponendo del sorgente originale, visto che gran parte dello stesso e' cryptato (viene decryptato in memoria).
    In poche parole sono fotutto (almeno amatorialmente).Triste
    non+autenticato
  • - Scritto da: Anonimo
    > Creo mod, non trainer o cheat per scelta
    > "etica"Sorride (anche se il principio di
    > funzionamente e' identico) ...odio i
    > cheater.
    > In pratica "inserisco" nel gioco funzioni
    > non implementate nella versione originale
    > (le "mancanze" che riscontrano i giocatori)
    > oppure "correggo" errori, in pratica
    > mini-patch, della cui realizzazione dovrebbe
    > curarsi la casa, le faccio io (cosi' come
    > molte altre persone) per passione.
    > Ovviamente non posso intervenire sul
    > sorgente, quindi devo necessariamente
    > "patchare" l'eseguibile, e purtroppo nei
    > giochi "moderni" questo non e' possibile
    > intervenendo sull'eseguibile sul disco ma
    > devo farlo in memoria, perche'? Perche' le
    > nuove protezioni anticopia sono prese da un
    > film di spionaggioA bocca aperta ...almeno oggi
    > patchare un eseguibile protetto ad esempio
    > con starforce3 (ultima versione) e' una
    > impresa impossibile non disponendo del
    > sorgente originale, visto che gran parte
    > dello stesso e' cryptato (viene decryptato
    > in memoria).
    > In poche parole sono fotutto (almeno
    > amatorialmente).Triste

    se viene decrittato in memoria ci dev'essere una parte di codice dedicata alle routines di decrittaggio, e da qualche parte una chiave.


    come si dice in questi casi? Ravana, ravana!A bocca aperta
  • - Scritto da: avvelenato
    >
    > se viene decrittato in memoria ci dev'essere
    > una parte di codice dedicata alle routines
    > di decrittaggio, e da qualche parte una
    > chiave.
    >
    >
    > come si dice in questi casi? Ravana, ravana!
    >A bocca aperta

    Ho parlato di criptazione, restando sul generico... vai a leggerti un po' di documentazione sulla Starforce3 e vedi di che si tratta. Io "ravenerei" pure, ma non saprei da dove cominciare e probabilmente morirei di vecchiaia.

    E' l'unica protezione attualmente in circolazione (da circa sei mesi) che e' rimasta ancora inviolata, nel senso che ci stanno lavorando (ovviamente) tutte le crew piu' quotate. L'unico modo per "aggirarla" e' ricostruire ogni porzione di file (non solo il main code) dove e' stata "iniettata" la protezione, questo significa "riscrivere" diversi MB di software... ad esempio al momento per copiare un gioco sf3 (copiarlo e farlo funzionare) servono crack da decine di megabyte (piu' software criptato c'e' dentro piu' sara' grande la patch) e una competenza fuori dal comune.
    Vedi ad esempio se riesci a trovare una "semplice" no-cd patch per Race Driver 2 (per PC), per non dire una versione pirata, non esiste... figuriamoci quindi se io sarei in grado di fare una cosa del genere, per i miei mod, mi gira la testa al solo pensiero.Occhiolino
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 9 discussioni)