Per ironia della sorte, dopo decenni in cui si è andati alla continua ricerca di meccanismi e di tecnologie che permettessero di ottimizzare e di rendere più efficiente l'esecuzione del codice da parte dei processori, l'ultimo trend è ora quello di limitare la porzione di codice che può essere eseguita.
Questo compito verrà affidato alla tecnologia NX (No Execute) già integrata nei processori Opteron e Athlon 64 di AMD e, presto, anche in quelli di Intel e Trasmeta.
L'SP2 supporta tali meccanismi hardware attraverso la tecnologia software Data Execution Prevention (DEP), sviluppata all'interno del progetto Palladium (ora noto come NGSCB): il suo scopo è quello di rafforzare la separazione tra le aree di memoria riservate ai dati e quelle riservate al codice e impedire che un programma malevolo possa inserire del codice in aree riservate ai dati e successivamente invocarne l'esecuzione.
Una delle più comuni vulnerabilità di sicurezza è infatti rappresentata dalla mancanza di un meccanismo di controllo che verifichi se l'indirizzo della cella di memoria che contiene la prossima istruzione da eseguire appartenga ad una zona che dovrebbe contenere dati o codice. Uno degli attacchi più frequenti consiste nel far traboccare un buffer di memoria riservato ai dati per corrompere o per sovrascrivere aree di memoria adiacenti al buffer. A questo punto, se questo spazio era riservato al codice del programma, può in genere essere cambiato l'indirizzo della cella di memoria con la prossima istruzione da eseguire, sostituendolo con uno al cui interno sono contenute le istruzioni malevoli.
Installando l'SP2 questo tipo di vulnerabilità sarà quindi fortemente ridotta. Questa maggiore sicurezza ha però uno scotto da pagare: buona parte delle attuali applicazioni sviluppate per Windows non tiene conto del fatto che esistono zone di memorie riservate ai dati e zone riservate al codice da eseguire. Questo vuol dire che, ad esempio, programmi come i compilatori Java, che generano il codice in tempo reale e che eseguono le istruzioni all'interno delle aree di dati, dovranno essere riscritte per essere compatibili con il SP2.
La DEP marca tutte le locazioni di memoria assegnate ad un processo come non eseguibili a meno che la locazione non contenga esplicitamente del codice eseguibile. Ogni qual volta venga richiesto l'accesso ad una cella di memoria che contiene la prossime istruzione da eseguire, il sistema operativo andrà a controllare lo stato del bit NX e solleverà un'eccezione (ovvero, una "status access violation") qualora si tenti di accedere ad una cella che è marcata come "dati": successivamente sarà terminato il processo che ha provato ad eseguire questa operazione.
Pur riconoscendo che questo sia un modo poco elegante per risolvere il problema (soprattutto perché questo comportamento è molto simile ai Blue Screen Of Death di Windows 9.x), ha osservato che è l'unico un modo funzionale per impedire l'esecuzione di codice non autorizzato.
La funzionalità di Windows XP SP2 chiamata DEP per potere funzionare necessita che il processore sia in grado di marcare una cella di memoria con un attributo che indichi che il codice non può essere eseguito in una determinate cella di memoria. Generalmente quello che avviene è che la memoria del sistema operativo (in questo caso stiamo parlando di Windows) è organizzata per pagine virtuali e che esiste una tabella che contiene due colonne: nella prima è indicato il numero della pagina, nella seconda se è stata marcata (overo se può contenere solo dati o codice eseguibile). Vi è da osservare che anche se le implementazioni hardware di DEP e il modo con cui viene marcata una pagina di memoria virtuale possono cambiare da processore a processore, il fattore cruciale è che i processori che supportano la DEP siano capaci di sollevare delle eccezioni quando si prova ad eseguire del codice da una pagina che è marcata come dati.
Gli sviluppatori di software avranno la possibilità di disabilitare selettivamente l'execution production sulle applicazioni a 32 bit utilizzando la fix denominata "DisableNX", presente nel compatibility toolkit dell'SP2. Gli utenti avranno invece tre possibilità: la prima è quella di disabilitare tranquillamente la DEP; la seconda è quella di attivarla su tutte le applicazioni; la terza è quella di attivarla su tutte le applicazioni a meno di quelle indicate espressamente dall'utente.
Come si è detto in precedenza, i processori della famiglia Athlon 64 e Opteron supportano in tutti i modelli la funzionalità NX. Intel ha da poco annunciato che aggiungerà la funzionalità XD (equivalente a NX) nei Pentium 4 della prossima generazione, noti come Prescott, che dovrebbero uscire nel corso del terzo trimestre di quest'anno. Transmeta lo scorso Maggio ha raggiunto un accordo con Microsoft per aggiungere il supporto NX nei suoi chip Efficeon, che dovrebbero uscire nella seconda metà di quest'anno. VIA Technologies ha promesso che il supporto NX sarà inserito nel core di C5J Esther, la cui data di rilascio non è ancora stata fissata.
Nel Service Pack 2 è stato inoltre introdotto un altro meccanismo per proteggere la memoria chiamato sandboxing che funziona sui processori a 32 bit. Per realizzare un meccanismo che riduca le possibilità che venga eseguito del codice su aree di memoria che dovrebbero contenere dati anche su questa famiglia di CPU, Microsoft ha aggiunto dei controlli software, chiamati sandboxing, ai due tipi di strutture della memoria che sono usati dal codice nativo: stack e heap. Lo stack è usato per tenere le variabili locali temporanee ed ha un ciclo di vita abbastanza breve: il suo spazio nella memoria viene allocato automaticamente quando una funzione viene invocata e viene rilasciato quando le funzione è terminata. La struttura heap è invece utilizzata dai programmi per allocare e liberare dinamicamente i blocchi della memoria e può avere una durata più lunga rispetto allo stack. Per proteggere lo stack, tutti i binari di Windows sono stati ricompilati utilizzando un'opzione che abilita il controllo della sicurezza sul buffer dello stack. Inoltre sono state aggiunte alcune istruzioni alle sequenze di invocazione e terminazione delle funzioni che permettono alle librerie runtime di catturare (il termine inglese è "catch") la maggior parte degli overrun che possono capitare nel buffer dello stack. Nel caso della struttura heap, sono stati invece aggiunti dei "cookies", ossia dei marcatori speciali che segnano l'inizio e la fine del buffer allocato. Questi cookies sono invocati dalle librerie che sono impiegate a tempo di esecuzione per controllare se i blocchi della memorie sono allocati o sono liberi. Se i cookies non ci sono o sono inconsistenti, le librerie a tempo di esecuzione rilevano che si è verificato un overrun nel buffer del heap e sollevano un'eccezione software.