Esistono attualmente architetture che utilizzano l'isolamento del processo forzato dall'hardware? Cosa ci vorrà per aggiungerlo a x86?

Question

Esistono attualmente architetture che utilizzano l'isolamento del processo forzato dall'hardware? Cosa ci vorrà per aggiungerlo a x86?

#1 da (14 voti)
#2 da (1 voti)

13

Primo richiedente / commentatore, lettore di lunga data.

Come qualcuno che al momento sta facendo un sacco di pensieri e amp; scrivere su misure che potrebbero migliorare fondamentalmente la sicurezza del computer (cioè, coinvolgendo non solo il tipo di passaggi evolutivi, piuttosto modesti su cui la maggior parte dei produttori di tecnologia si stanno concentrando in questo momento, ma perseguire cambiamenti "grandi" potrebbe rompere la compatibilità all'indietro ma renderebbe i sistemi < em> molto più sicuro). Sono molto preso dall'idea di utilizzare un solido isolamento generale dei processi per cercare di prevenire i programmi in modalità utente o, comunque, quelli che oggi chiamiamo programmi in "modalità utente", dall'essere in grado di fare cose cattive come provare a leggere / rubare dati usati da altri programmi in modalità utente o colpire il sistema operativo con attacchi di escalation di privilegi.

Ora, ci sono certamente aziende / organizzazioni là fuori che hanno provato o stanno cercando di implementare solidi schemi di isolamento dei privilegi nel software. Ad esempio, Singularity SO di Microsoft che ha trasformato quasi tutto in "processi isolati e sigillati" che potevano comunicare tra loro e il sistema operativo solo attraverso "contratti" restrittivi di trasmissione dei messaggi. (Ce ne sono sicuramente altri, compresi alcuni che sono in uso con i governi per scenari militari / di intelligence ad alta sicurezza, lo capisco). Tuttavia, suppongo di essere una persona riluttante a dare una tremenda fiducia nelle difese di sicurezza che non sono radicate , alla fine della giornata, in una sorta di applicazione diretta dell'hardware. Il che mi porta alle mie due domande (strettamente correlate):

In primo luogo, ci sono microprocessori non governativi, prodotti commercialmente oggi, che sono destinati all'elaborazione multi-purpose; nessun chip di smart card o qualcosa del genere - che usa insiemi di istruzioni / architetture specificamente progettati per rafforzare l'isolamento / separazione del processo? (In modo tale che nemmeno un attacco che sfrutti un difetto del kernel del sistema operativo in esecuzione sul dispositivo sarebbe sufficiente a consentire al codice malevolo in un processo di uscire dall'isolamento.)

In secondo luogo, che tipo di modifiche dovresti apportare al set di istruzioni x86-64 & corrispondente architettura del chip per renderlo in grado di fornire supporto imposto dall'hardware a un strong isolamento del sistema operativo / separazione dei singoli processi?

(FYI, so che Intel ha aggiunto alcune funzionalità di sicurezza proprietarie ad alcuni dei loro chip negli ultimi 5-10 anni, con Skylake con SGX quest'anno supponiamo di portare alcune funzionalità per isolare un determinato programma che ha necessità di sicurezza dal resto del sistema, ma sarebbero necessari ulteriori passaggi più ampi per perseguire l'isolamento forzato dall'hardware, ad esempio, almeno, tutti i processi che oggi vengono eseguiti in modalità utente. / p>

architecture operating-systems memory process

posta halfinformed 09.09.2015 - 23:28

fonte

2 risposte

1

In primo luogo, l'attuale implementazione di "isolamento forzato dall'hardware" sembra insufficiente e debole. Qui ci sono solo alcune domande "cattive":

A cosa serve il processo in esecuzione in modalità "privilegiata" ha accesso ai dati di tutti gli altri processi?
I driver di periferica dovrebbero funzionare in modalità "privilegiata" o in modalità "utente"? Entrambe le soluzioni danno problemi: i driver in esecuzione in modalità "privilegiata" hanno troppo accesso ai dati sensibili. I driver in esecuzione in modalità "utente" devono accedere ai dispositivi, pertanto l'accesso al dispositivo deve essere concesso alle applicazioni.
Ci fidiamo davvero dei fornitori di tutti i driver di periferica?
Tutti i sistemi operativi moderni provengono dai tempi in cui quelle che definiamo "buone pratiche di programmazione" erano chiaramente sconosciute. Si può controllare il codice di qualsiasi sistema operativo open source e trovare un sacco di (mi dispiace) pasticcio lì. Crediamo che i sistemi operativi commerciali siano di gran lunga migliori, solo perché non possiamo vedere la loro fonte?
Qualsiasi sistema operativo moderno è davvero complesso SW. Il modo comune per migliorare l'affidabilità di SW complessi è la sua strutturazione. Questa strutturazione deve essere supportata da alcuni "confini" forzati tra i vari moduli. Non ci sono mezzi per supportare / rafforzare tale isolamento nella programmazione del sistema operativo. Quindi ci fidiamo solo delle buone intenzioni delle persone che progettano, supportano e codificano i sistemi operativi.

Questo elenco può essere continuato.

Recentemente ho cercato i progetti di CPU che aiutano a risolvere questi problemi. Non sono stati trovati disegni di questo tipo.

risposta data 25.11.2016 - 09:01

fonte

Leggi altre domande sui tag architecture operating-systems memory process

Come determinare se il sito è protetto dal punto di vista dell'utente comune? In che modo l'inserimento di un numero di telefono "a" aiuta Google "verifica che sia io?"

score 14 · Accepted Answer

In realtà, quasi tutte le CPU sul mercato, ad eccezione di quelle molto piccole destinate ai dispositivi embedded a bassa potenza, offrono "isolamento forzato dall'hardware". Questa è chiamata MMU . In sintesi, la MMU suddivide lo spazio indirizzo in singole pagine (in genere 4 o 8 kB ciascuna, dipende dall'architettura e dalla versione della CPU) e ogni volta che una parte di codice accede a una pagina, la MMU applica i diritti di accesso e mappa anche l'accesso ad un indirizzo fisico (o meno - questo è il modo in cui "la memoria virtuale" funziona). In qualsiasi momento, la CPU informa la MMU se il codice corrente è "codice utente" o "codice kernel" e la MMU utilizza tali informazioni per sapere se l'accesso deve essere concesso o meno.

I diritti di accesso e il mapping agli indirizzi fisici di ogni pagina sono configurati in tabelle speciali in memoria, che il kernel mostra alla MMU (fondamentalmente scrivendo l'indirizzo iniziale nella RAM fisica della tabella principale in un registro dedicato). Commutando la configurazione della MMU, il kernel implementa la nozione di process : ogni processo ha il proprio spazio di indirizzamento, e quando il kernel decide che la CPU deve essere concessa a un processo, lo fa facendo Configurazione MMU per quel processo la configurazione attiva.

Si tratta di un sistema che impone l'hardware come queste cose possono ottenere. Se volevi un'applicazione di isolamento solo software , dovresti considerare cose come Java o C # /. NET: strong tipizzazione, controllo dei limiti della matrice e raccolta dei rifiuti consentono la convivenza di parti distinte di codice con isolamento e senza l'aiuto di una MMU.

L'isolamento del processo basato su MMU funziona bene nella pratica - i processi non possono alterare o persino vedere le pagine di altri processi. Gli ultimi principali sistemi operativi in cui ciò non è stato fatto correttamente erano la famiglia Windows-95 (fino alla famigerata Windows Millenium Edition, nel 2001).

I problemi iniziano quando si inizia a capire che l'isolamento completo è inutile: i processi applicativi devono, a un certo punto, essere in grado di interagire con l'hardware, salvare i file o inviare dati sulla rete o visualizzare immagini. Pertanto, ci devono essere alcuni gateway specifici che consentono ad alcuni dati di entrare e uscire dallo spazio di indirizzi isolato di ciascun processo, sotto stretto controllo di un sistema di arbitrato che mantiene la coerenza e l'allocazione delle risorse hardware da elaborare; quel sistema di arbitraggio è esattamente ciò che è noto come "Sistema operativo". I "gateway" per l'isolamento di escape sono spesso chiamati chiamate di sistema .

In questo momento, il sistema operativo è software, e ha dei bug, perché ogni pezzo significativo di software ha dei bug. Alcuni di questi consentono al processo scritto in modo malevolo di influire negativamente su altri processi; questo è noto come "buchi di sicurezza". Tuttavia, fare un "sistema operativo completamente hardware" non risolve nulla; infatti, probabilmente peggiorerebbe le cose. Anche l'hardware ha dei bug; e la fonte di bug è che ciò che lo sviluppatore sta cercando di fare è complesso. Facendolo in hardware rende solo più difficile la risoluzione dei bug, quindi non migliora affatto la sicurezza.

Quindi, per migliorare l'isolamento tra i processi, la soluzione non è quella di gettare più hardware sul problema. Ce ne sono già abbastanza (e forse troppo). Ciò che è necessario è una riduzione della complessità , che è in realtà una completa eliminazione e riprogettazione dell'elenco delle chiamate di sistema. Un kernel Linux di base offre oltre 300 diverse chiamate di sistema! Questo rende un lotto di lavoro quando si cerca di evitare buchi di sicurezza. Purtroppo, la rimozione delle chiamate di sistema interrompe la compatibilità con il codice esistente.