La moderna sicurezza dei driver per GPU Linux

3

Quanto sono sicuri i moderni driver per GPU Linux?

Il modello di minaccia è un utente malintenzionato che può eseguire codice arbitrario nel contesto di un processo utente non privilegiato, che è strongmente bloccato da seccomp-bpf, spazi dei nomi e altri meccanismi. In particolare, ha un descrittore di file aperto per la GPU, uno per il framebuffer predefinito e uno per un file anonimo in /tmp (per allocare memoria). Non è possibile aprire file o eseguire chiamate di sistema non richieste per allocare memoria heap o utilizzare la GPU.

I moderni driver per GPU Linux per desktop sono sufficientemente sicuri da fornire isolamento dai programmi dannosi dell'utente?

L'applicazione di destinazione che spero di usare per questo è Qubes OS, che al momento non può usare la GPU per altro tranne il compositing, quindi il livello di sicurezza deve essere paragonabile a quello fornito dall'ipervisor Xen o l'idea è un non -starter.

    
posta Demi 28.03.2018 - 21:25
fonte

1 risposta

3

I moderni driver GPU (non solo limitati a Linux) sono davvero, davvero insicuri. Il modo in cui un'applicazione comunica con una GPU è attraverso Direct Rendering Manager , o interfaccia DRM, utilizzando ioctl(2) . Queste syscall vengono utilizzate per passare i riferimenti a strutture di dati complesse tra l'utente e il kernel. L'interfaccia DRM è disponibile sotto forma di due dispositivi a caratteri :

  1. Il nodo principale , che gestisce le operazioni con privilegi (ad esempio controllo dello schermo). È esposto come dispositivo carattere /dev/dri/cardX . Spesso è scrivibile solo dagli utenti nel gruppo video . Questo dispositivo è tradizionalmente tenuto aperto dal server X, che si rende master DRM . Il nodo master DRM ha una superficie di attacco considerevole e utilizza un'API complessa.

  2. Il rendering node , che gestisce le operazioni generalmente non privilegiate (ad esempio GPGPU computing e rendering). È esposto come dispositivo carattere /dev/dri/renderDX . Questo dispositivo ha una considerevole area di attacco, nonostante gestisca solo operazioni non privilegiate.

Le verifiche delle autorizzazioni per i nodi DRM vengono eseguite all'avvio del file del dispositivo, con alcune eccezioni . Una volta che il descrittore di file è presente, qualsiasi applicazione con quel descrittore nel suo insieme sarà in grado di inviare comandi privilegiati arbitrari al sottosistema grafico. Ciò significa che l'isolamento termina non appena il processo non affidabile ha un descrittore di file valido su un nodo DRM. La sicurezza del sottosistema grafico dipende sia dalla sicurezza del livello DRM (che ha un interfaccia molto complessa ), così come le interfacce specifiche dell'hardware definite da il driver grafico stesso. Driver diversi definiscono interfacce diverse, alcune delle quali sono più complesse di altre.

Hai detto che stavi usando seccomp-bpf. Questo è buono! Sarai in grado di ampiamente di ridurre i problemi di sicurezza intrinseci in un sottosistema grafico complesso. Assicurati di filtrare qualsiasi ioctl che viene chiamato contro un nodo DRM. Whitelist i comandi che è possibile inviare a ioctl . Sebbene non sia possibile autorizzare la struttura dei dati passata al kernel, la whitelist del comando generale è spesso sufficiente e ridurrà di molto la superficie disponibile per un utente malintenzionato.

Un elenco tutt'altro che esaustivo di errori gravi dei driver di grafica:

Radeon

Nvidia (proprietario)

Intel (i915, ecc.)

Qualsiasi driver (bug nel sottosistema DRM sottostante)

L'hardware x86 moderno è una bestia spaventosa. È complesso e non progettato pensando alla sicurezza. Anche in assenza di vulnerabilità del software del driver, le GPU possono ancora porre una minaccia semplicemente dovuta alla loro natura complessa e all'interazione con una complicata architettura del computer su protocolli arcani regolato dall'appartenenza a sole migliaia di pagine specifiche . La sicurezza è Difficile ™.

    
risposta data 29.03.2018 - 01:53
fonte

Leggi altre domande sui tag