Perché ci è voluto così tanto tempo per applicare le autorizzazioni di memoria?

È prima di tutto una questione di analisi costi-benefici da parte del produttore dell'hardware e una questione di analisi del rischio per conto dei fornitori di sistemi operativi.

L'architettura x86 ha fornito i diritti di accesso alle pagine di memoria fin dall'80386, ma in quel momento l'implementazione dell'hardware sarebbe stata costosa da implementare nell'hardware e non è stata vista come necessaria. I computer erano già proibitivi per la maggior parte degli utenti e per la maggior parte delle piccole imprese, quindi i produttori di hardware non volevano aumentare il costo per una funzione che i loro clienti non avrebbero capito o di cui preoccuparsi.

Con il passare del tempo, questo compiacimento è diventato più evidente. L'era dei buffer overflow è stata alle porte e stava iniziando a danneggiare le grandi aziende. Nel 2003, la sicurezza dei computer si era dimostrata un settore commercialmente redditizio ei prezzi dell'hardware erano scesi a livelli di commodity. AMD e Intel hanno finalmente deciso che l'applicazione dell'hardware era una funzionalità redditizia, quindi hanno implementato Never eXecute (NX) all'inizio del 2004. AMD ha rilasciato l'Athlon XP-M "Dublin" con supporto NX e il primo processore Intel a supportarlo era il Pentium 4 Prescott (revisione E0). Tuttavia, a questo punto, la quota di mercato dei processori con NX era minima.

Il principale ostacolo all'implementazione del software è stato che l'estensione degli indirizzi fisici (PAE) doveva essere abilitata e supportata prima che NX fosse disponibile per l'uso. Ciò ha comportato modifiche sostanziali alla gestione della memoria di base all'interno dei kernel del sistema operativo.

Un'altra parte del problema sul lato software erano applicazioni scritte male. Alcuni codici si basavano sulla possibilità di eseguire erroneamente i dati che non erano stati inseriti nelle pagine di memoria contrassegnate come eseguibili. Con l'avvento dell'applicazione hardware dei flag di accesso alla memoria, questi programmi genererebbero una violazione di accesso. Era necessaria un'attenta considerazione dei benefici prima di andare avanti con i cambiamenti. Il concetto di DEP come concetto, senza supporto hardware, era considerato una potenziale funzionalità di Linux in una data precedente, ma è stato rifiutato a causa di problemi di complessità, interruzione delle modifiche e del fatto che i meccanismi di applicazione del software potevano essere facilmente aggirati.

Una volta che il supporto hardware era disponibile, i sistemi operativi dovevano essere modificati per usarlo. Questo non era un compito banale. DEP contrassegna alcune strutture importanti, come lo stack e gli heap, come non eseguibili. Ciò ha richiesto ogni routine di inizializzazione che riguardava la creazione di thread e processi da modificare per supportare NX, nonché alcune modifiche alla gestione della memoria (ad esempio, allocazioni dell'heap). Infine, è stato necessario modificare il codice del livello di astrazione hardware per riconoscere correttamente il flag NX sui processori di supporto.

Tutto sommato, questo in realtà è successo sorprendentemente rapidamente. Una volta disponibile l'applicazione hardware NX, sia Windows XP che Linux hanno rilasciato versioni compatibili NX entro 8 mesi.

Ci sono due ragioni: (a) la sicurezza non era una priorità strong e (b) le differenze nelle architetture a 32-bit vs 64-bit.

Il bit NX è supportato solo su architetture a 64 bit. Il bit NX fornisce autorizzazioni di esecuzione a livello di pagina, pertanto il sistema operativo può contrassegnare alcune pagine come non eseguibili. Il bit NX è il modo standard per rendere certe pagine non eseguibili e quindi è il modo standard e più pulito per implementare il DEP. Tuttavia, le architetture a 64 bit hanno richiesto un po 'di tempo per guadagnare popolarità, quindi implementare il supporto nel sistema operativo per DEP basato su NX bit è diventato un significativo vantaggio per la sicurezza una volta che molte persone hanno iniziato a utilizzare architetture a 64 bit.

Pertanto, l'implementazione del DEP è stata in parte rallentata dall'adozione lenta delle architetture a 64 bit. (Se le piattaforme Intel a 32 bit hanno supportato il bit NX, potremmo aver visto una precedente distribuzione di DEP, ma non è così, quindi non è stato così.) Il DEP non si è diffuso fino ai chip Intel / AMD a 64 bit divenne molto diffuso Quindi, è per questo che ci è voluto così tanto tempo prima che la DEP si diffondesse.

OK, ora è qui che ammetto che quanto sopra è un po 'troppo semplicistico, anche se non troppo. In effetti, esiste un modo per implementare il DEP su architetture a 32 bit, ma è molto più difficile e non si adatta bene al modo in cui la maggior parte dei sistemi operativi sono attualmente costruiti.

Nelle architetture Intel a 32 bit, esistono in realtà due diversi meccanismi di protezione della memoria: protezione a livello di pagina e protezione a livello di segmento. La maggior parte dei sistemi operativi si basa sul meccanismo a livello di pagina (tabelle di pagina e così via) per la protezione della memoria. Il meccanismo a livello di pagina è il più flessibile, poiché ogni pagina può avere il proprio livello di protezione (ad es., Sola lettura vs lettura / scrittura, accessibile dall'utente e solo kernel). Tuttavia, i processori Intel a 32 bit supportano anche la protezione della memoria basata su segmenti. Un segmento è una regione di memoria consecutiva e puoi avere alcuni segmenti diversi. Ogni segmento può ricevere il proprio accesso di protezione. Poiché la protezione a livello di pagina è più flessibile, la maggior parte dei sistemi operativi non utilizza la protezione a livello di segmento (trattano in modo efficace la memoria come un unico grande segmento e l'inizio della segmentazione).

Per alcune ragioni sconosciute, su architetture a 32 bit, la protezione a livello di segmento consente di contrassegnare un segmento come non eseguibile, ma il meccanismo di protezione a livello di pagina non consente di contrassegnare una pagina come non eseguibile. (Non so perché, probabilmente è solo un artefatto della storia.) Ciò significa che è possibile implementare DEP su un'architettura a 32 bit, utilizzando le protezioni a livello di segmento. Tuttavia, questo richiede tutti i tipi di contorsioni e le principali modifiche al sistema operativo. In questo modo diventa piuttosto complicato e complicato, e ha anche alcune implicazioni sulle prestazioni. Per questo motivo, molti sistemi operativi erano riluttanti ad implementare DEP su architetture a 32 bit.

Quindi non è abbastanza preciso dire che DEP è impossibile su architetture a 32 bit e prima è diventato possibile su architetture a 64 bit, ma, per scopi ingegneristici, è abbastanza vicino alla verità.