Che cosa implica disabilitare syscall in Intel SGX

Question

Sto cercando di programmare con la funzione Intel Software Guard Extensions (SGX) di recente. L'idea di SGX è creare un'enclave in cui il codice sensibile alla sicurezza sia caricato ed eseguito. Soprattutto l'accesso alla memoria (e molte altre restrizioni) a quell'enclave viene applicato dall'hardware.

Nel suo manual, ho trovato che l'istruzione syscall è illegale all'interno di un'enclave (vedere la Tabella 3-1), insieme a molte altre istruzioni potrebbe modificare il livello di privilegi. Mi chiedo cosa implichi questo. Poiché il servizio del kernel come open, socket termina con l'aumento delle chiamate di sistema, significa che vietare l'istruzione syscall proibisce effettivamente il codice all'interno dell'enclave da qualsiasi servizio del kernel, come file e socket? Mi sembra abbastanza poco convincente perché in questo modo ciò che può fare un enclave sarebbe severamente limitato. Quindi penso che abbia frainteso o che ci sia del lavoro in giro.

Answer 1

Hai ragione quando dici che non è possibile utilizzare i servizi del kernel o qualsiasi chiamata di sistema, perché l'istruzione Syscall è proibita all'interno dell'enclave. Il sistema operativo non fa parte del trusted computing base (TCB) in SGX. lasciamo presumere che syscall sia abilitato all'interno dell'enclave e si scrivano istruzioni in assembly per eseguire l'istruzione syscall (diciamo con i parametri per la chiamata di sistema aperta sys_open). Quando esegui un syscall, durante il boot passi all'impostazione predefinita della posizione da parte del kernel per avviare l'esecuzione del codice del kernel. Ciò significa che stai saltando dal codice scritto da te (che è affidabile) al codice che non è stato scritto da te (sistema operativo, che non è affidabile e non fa parte del tuo TCB). Se tu fossi in grado di farlo, ciò avrebbe vanificato le garanzie di sicurezza fornite da SGX. Dato che il kernel/OS/qualsiasi altro software non scritto da te non è affidabile, potresti avere un kernel maligno la cui chiamata di sistema aperta legge i dati all'interno della tua enclave e ruba i tuoi segreti.

Questo è severamente limitante come dici tu perché non saresti in grado di utilizzare socket o altro direttamente dal tuo codice di enclave. Ma se volessi usare questi servizi all'interno dell'enclave, devi fidarti del codice non scritto da te che rompe il modello di sicurezza di SGX.

Non penso che SGX sia destinato ad usi come quello che si potrebbe pensare. qui ci sono alcuni casi d'uso previsti come mostrato da Intel e dovrebbe spiegare come è possibile ottenere queste applicazioni senza l'uso di chiamate di sistema.

https://software.intel.com/en-us/articles/using-innovative-instructions-to-create-trustworthy-software-solutions

Answer 2

destro. Vedere l'attestazione locale in uno dei tre articoli pubblicati da Intel su SGX. L'enclave che vuole dimostrare che è in esecuzione in un'enclave su una CPU Intel, crea un report all'interno dell'enclave (EREPORT). Il report non contiene alcun segreto, ma è MAC che usa la chiave del report, che è accessibile e generata all'interno dell'enclave. Il report viene inviato all'altra enclave tramite il canale non attendibile (Ie, OS fornito da IPC), quindi il report viene verificato all'interno dell'altra enclave, che ha accesso alla stessa chiave report (segreto condiviso) all'interno dell'enclave e può verificare il integrità della struttura utilizzando il MAC e la chiave di segnalazione (segreto condiviso tra enclavi). Se tutte le informazioni nel rapporto corrispondono, le due enclavi possono fidarsi dell'esecuzione sulla stessa piattaforma SGX. Possono quindi eseguire scambi di chiavi come lo scambio di chiavi DH o qualsiasi altro modo per stabilire un canale sicuro e possono comunicare tra loro in modo sicuro.