Intel SGX Threading e TCS

Question

Sto cercando di capire la differenza tra i thread SGX abilitati da TCS e threading non affidabile fornito da SDK.

Se ho capito bene, TCS consente a più processori logici di entrare nella stessa enclave. Ogni processore logico avrà il proprio TCS e quindi il proprio punto di ingresso (il campo OENTRY in TCS). Ogni thread viene eseguito fino a quando si verifica un AEX o raggiunge la fine del thread. Tuttavia, questi thread abilitati da TCS non hanno ancora modo di sincronizzarsi l'uno con l'altro. Almeno, non ci sono istruzioni SGX per la sincronizzazione.

Quindi, SGX SDK offre un set di Primitive di sincronizzazione thread, principalmente mutex e condizione variabile. Queste primitive non sono attendibili poiché alla fine sono servite dal sistema operativo.

La mia domanda è, sono questi Primitive di sincronizzazione thread destinate a essere utilizzate dai thread TCS? Se così fosse, non peggiorerebbe la sicurezza? Il sistema operativo è in grado di giocare con la programmazione come desidera.

Answer 1

primo, cerchiamo di gestire la sua terminologia alquanto vaga della

discussioni SGX abilitati dal TCS e filettatura non attendibile fornita da SDK.

All'interno di un'enclave, possono essere eseguiti solo i thread "attendibili". Non c'è threading "non attendibile" all'interno di un'enclave. Forse, la seguente frase nella Guida SDK [1] ti ha ingannato:

La creazione di thread all'interno dell'enclave non è supportata. Le discussioni che girano all'interno della enclave sono creati all'interno dell'applicazione (non attendibile).

L'applicazione non affidabile deve configurare le pagine TCS (per ulteriori informazioni su TCS, vedere [2]). Quindi, come può il TCS impostato dall'applicazione non affidabile essere la base per i thread affidabili all'interno dell'enclave? [2] fornisce la risposta:

EENTER è garantito solo per eseguire salti controllati all'interno del codice di un'enclave se il contenuto di tutte le pagine TCS viene misurato.

Misurando le pagine TCS, l'integrità dei thread (il TCS definisce i punti di ingresso consentiti) può essere verificata tramite l'attestazione enclave. Pertanto, solo i percorsi di esecuzione conosciuti possono essere eseguiti all'interno dell'enclave.

Secondo, esaminiamo le primitive di sincronizzazione.

L'SDK offre primitive di sincronizzazione, che si dice non sono attendibili perché alla fine sono servite dal sistema operativo. Vediamo la descrizione di queste primitive in [1]:

• sgx_spin_lock() e sbloccare operare esclusivamente all'interno della enclave (utilizzando le operazioni atomiche), senza la necessità di interazione del sistema operativo (senza OCALL). Usando uno spinlock, potresti implementare le primitive di livello superiore.
• sgx_thread_mutex_init() inoltre non esegue un OCALL. La struttura dei dati mutex è inizializzata all'interno dell'enclave.
• sgx_thread_mutex_lock() e sbloccare potenzialmente eseguire OCALLS. Tuttavia, poiché i dati mutex si trovano all'interno dell'enclave, possono sempre applicare la correttezza del blocco all'interno dell'enclave sicura.

Osservando le descrizioni delle funzioni mutex, suppongo che gli OCALL servano per implementare l'attesa non occupata all'esterno dell'enclave. Questo è effettivamente gestito dal sistema operativo e suscettibile di attacchi. Il sistema operativo può scegliere di non riattivare un thread in attesa fuori dall'enclave. Ma può anche scegliere di interrompere un thread in esecuzione all'interno di un'enclave. SGX non protegge dagli attacchi DoS (Denial of Service) dal sistema operativo (potenzialmente compromesso).

Per riepilogare, spin-lock (e per estensione qualsiasi sincronizzazione di livello superiore) possono essere implementati in modo sicuro all'interno di un'enclave. Tuttavia, SGX non protegge dagli attacchi DoS e quindi non si può presumere che un thread verrà eseguito. Questo vale anche per il blocco delle primitive: un thread in attesa su un mutex potrebbe non essere risvegliato quando il mutex viene liberato. Realizzando questa limitazione intrinseca, i progettisti dell'SDK hanno scelto di utilizzare OCALL (non attendibili) per implementare in modo efficiente alcune primitive di sincronizzazione (ad esempio attesa non occupata).

[1] SGX SDK Guide

[2] SGX Explained

Answer 2

qweruiop, per quanto riguarda la tua domanda nel commento (la mia risposta è troppo lungo per un commento):

sarei ancora contare che, come un Attacco DoS: il sistema operativo, che gestisce le risorse delle enclaves, nega l'accesso T alla risorsa tempo di elaborazione della CPU. Ma sono d'accordo, devi progettare gli altri thread in esecuzione in quell'enclave con la consapevolezza che T potrebbe non funzionare mai. La semantica è diversa dai thread in esecuzione su una piattaforma che controlli. Se vuoi essere assolutamente sicuro che la variabile di condizione sia selezionata, devi farlo su una piattaforma che controlli.

Lo sgx_status_t restituito da ciascuna funzione proxy (ad es. Quando si effettua un ECALL in un'enclave) può restituire SGX_ERROR_OUT_OF_TCS. Quindi l'SDK dovrebbe gestire tutto il threading per te - basta fare ECALLs da due diversi ("non attendibili") thread A e B fuori dall'enclave, e il flusso di esecuzione dovrebbe continuare in due ("fidati") thread all'interno dell'enclave, ognuno legato a un TCS separato (supponendo che 2 TCS non utilizzati siano disponibili).