Come essere sicuri che un certo codice non chiami gli interrupt?

Question

Come essere sicuri che un certo codice non chiami gli interrupt?

#1 da (1 voti)

3

Immagina di avere un file codice oggetto da una fonte non attendibile. Si desidera eseguire questo codice per conoscere il risultato del suo calcolo e si desidera che il codice funzioni rapidamente, quindi l'impostazione di un'intera macchina virtuale è l'ultima risorsa. Inoltre, non desideri che nulla accada al tuo sistema dopo l'esecuzione del codice.

Tenendo presente questo, per quanto ho capito, quel codice non sarebbe in grado di fare alcun danno se si limita il numero di interrupt per esso o si disabilitano gli interrupt di sorta. Un modo per assicurarsi che non ci siano interruzioni nel codice è di scansionarlo in base alle istruzioni e rifiutarsi di eseguire se c'è almeno un'istruzione int in essa. Ciò risolverà il problema, ma questo approccio non consentirà alcuna chiamata di sistema e il codice senza chiamate di sistema è scarsamente utile. Se il lato in esecuzione decide di consentire quel codice che richiama solo alcune interruzioni nella whitelist, il lato in esecuzione deve essere sicuro che il codice in esecuzione non si modifichi in fase di esecuzione. Se cambia, allora ogni istruzione da eseguire deve essere riesaminata, il che influirebbe sulle prestazioni.

Sarebbe bello avere una sorta di gateway tra gli interrupt host e guest, che potrebbe tradurre gli interrupt ospite in eventuali interruzioni host diverse o rifiutarsi di farlo. Ci sono soluzioni o ricerche disponibili per questo argomento?

security assembly verification

posta Craig 03.10.2015 - 08:34

fonte

1 risposta

Leggi altre domande sui tag security assembly verification

Consigli sull'architettura (WCF / MVC) App Android con Ruby Backend Server

score 1 · Answer 1

Questo è estremamente dipendente dall'ambiente che stai usando, e non penso che tu possa evitare di legarlo a un sistema operativo. Dato che questo tipo di lavoro è strongmente dipendente dal kernel (si sta cercando di evitare interruzioni, dopo tutto, una funzionalità del kernel stesso), non abbiate paura di utilizzare una soluzione specifica per Linux o Windows.

Il tuo approccio di scansione del file oggetto per istruzioni specifiche non è sufficiente, perché come hai detto, disabiliterà anche le chiamate di sistema. Ciò dipende anche dall'architettura su cui stai lavorando, e dal momento che non vuoi che la soluzione sia dipendente dal SO, probabilmente non vuoi nemmeno un'architettura dipendente.

I contenitori hanno un sovraccarico minore rispetto alle macchine virtuali e possono essere avviati e smontati in modo estremamente rapido, ma dal momento che stai parlando della separazione dal kernel, un contenitore non sarebbe sufficiente.

Detto questo, una macchina virtuale è la soluzione migliore, ed è ciò che viene generalmente utilizzato in una situazione come questa. Certo, c'è un piccolo sovraccarico all'avvio / arresto di una macchina virtuale e un po 'di sovraccarico di runtime durante l'esecuzione dell'applicazione. Ma questi possono essere risolti utilizzando una macchina virtuale hardware, che utilizza un hypervisor per fornire alla macchina virtuale l'accesso diretto all'hardware. È un po 'difficile da configurare inizialmente, ma elimina la maggior parte del sovraccarico che è presente quando si esegue un'applicazione in una macchina virtuale.