Un processo non privilegiato in un sistema hardware-virtualizzato causa una "VMExit" senza cooperazione dal kernel?

Quello che ti serve per capire le istruzioni sono Sviluppatore software Intel manuali . Per quello che vale, a volte li trovo un po 'opachi - quindi metto a confronto ciò che leggo su google e nei manuali di AMD mentre entrambi implementano l'architettura x86 / x64.

In particolare, per questo è necessario Vol 3C: Virtualizzazione . A partire dal manuale corrente si desidera pagina 293 ("VMCALL-Call to VM Monitor"). Lì, hai questa espressione utile:

IF not in VMX operation
    THEN #UD;
ELSIF in VMX non-root operation
    THEN VM exit;
ELSIF (RFLAGS.VM = 1) or (IA32_EFER.LMA = 1 and CS.L = 0)
    THEN #UD;
ELSIF CPL > 0
    THEN #GP(0);
...

Traduzione in inglese: #GP è un'eccezione di protezione generale, CPL è il livello di privilegio corrente. L'operazione non root di VMX è:

There are two kinds of VMX operation: VMX root operation and VMX non-root operation. In general, a VMM will run in VMX root operation and guest software will run in VMX non-root operation.

Quindi, ciò implicherebbe che le istruzioni di VMCall possano essere emesse da qualsiasi livello di privilegio sul guest . Il requisito dell'anello 0 si applica solo al sistema host. Tuttavia, lo avverto con un disclaimer - vedi le mie implicazioni bulletpoints in un minuto.

Pazzamente pazzo, lo so. Apparentemente, tuttavia, è vero. Leggi la questa discussione dove gli sviluppatori del kernel KVM stanno discutendo esattamente questo. La patch KVM in questione ha fatto questo:

kvm_get_segment(vcpu,&cs, VCPU_SREG_CS);
if (cs.dpl != 0) {
    ret = -KVM_EPERM;
    goto out;
}

Che considera "hypercall" non valido se non creato da guest ring 0.

Implicazioni:

1. Qualsiasi codice a livello di ospite può emettere un VMCall . Tuttavia, dalla lettura molto preliminare che ho fatto sembra che ( potrebbe ) potrebbe essere impossibile perché ciò sia utile in qualsiasi modo - come gli indirizzi di ring 3 sarebbero presumibilmente virtuali rispetto al guest che opera sistema (e quindi non significa nulla per l'host). Sospetto strongmente che sia questo il caso, ma non posso (ancora) confermarlo.
2. Se ci pensi, questo ha senso: se il codice a livello di ospite attiva un altro tipo di VM Exit, vuoi che il VMM prenda il controllo.
3. Tuttavia, sospetto che molti hypervisor implementino la restrizione di cui sopra - solo ring 0 guest o alcune altre condizioni dell'API hypercall a cui si applicano.
4. Tuttavia, non possono.

Quindi, ciò che devi fare se vuoi veramente approfondire la questione è verificare:

• Quali hypercalls, se presenti, supportano la tua VMM.
• Quali condizioni considerano valida un ipercall. Come ho detto, prevedo che VMCall sarà limitato solo al guest ring 0.

Se è vero che VMCall et al può essere eseguito in modo significativo dall'anello 0, allora il codice ospite del client deve essere in grado di eseguire anche nel ring 0, o persuadere parte del codice esistente a fare qualcosa non dovrebbe Ad esempio:

1. Puoi persuadere il kernel ad eseguire un pezzo di codice arbitrario che contiene VMCall per fare quello che vuoi.
2. Convinci un driver esistente che utilizza VMCall per fare in modo che quella chiamata sia la tua strada con i tuoi argomenti, piuttosto che con quelli che potrebbe usare normalmente.

Il successo di questo per un exploit dipende interamente dall'hypervisor e se tali VMCalls sono vulnerabili o meno. Se non lo sono, non importa se sei riuscito a chiamarli - l'hypervisor può rifiutarli come appropriato. A questo punto, onestamente, non penso che questa via di exploit (attraverso un VMCall ) sia molto probabile (anche se le conseguenze sono ovviamente piuttosto gravi se ce ne fosse una).

Due cose che ho perso qui:

• Esistono molti altri trigger per le uscite VM. I processi guest possono causarli ? Non a livello di codice, non penso: si verificano a causa di qualcosa che l'ospite sta facendo (condizioni per le uscite fornite da VMM) piuttosto che in risposta diretta a un codice operativo.
• Ancora una volta, "scoppiare" di una VM è un termine allentato. Gli utenti di macchine virtuali dovrebbero anche stare attenti a cose come l'emulazione di rete - se il guest e l'host possono parlare tra loro su TCP / IP e lo stack IP dell'host ha una vulnerabilità e il codice sul guest può sfruttarlo - si potrebbe ancora essere compromesso Allo stesso modo, il trasferimento di file da guest a host comporta un rischio intrinseco.

Sì, il codice guest non privilegiato può attivare l'uscita di una VM.

Tuttavia, questo non significa che il codice guest non privilegiato può uscire dalla VM. Quando viene attivata un'uscita VM, il controllo viene trasferito al codice del monitor della macchina virtuale. Se il codice VMM è scritto correttamente, è responsabile della gestione dell'uscita della VM in modo sicuro: e in particolare, in un modo che non consente al codice ospite malevolo di uscire dalla VM.

Si noti che una "uscita VM" è un termine tecnico, che si riferisce al trasferimento del controllo a VMM. Nonostante l'uso della parola "uscita", non implica che il codice ospite possa uscire dalla VM. Si riferisce a un modo di invocare il VMM, non a una sorta di violazione della sicurezza. Se il VMM è privo di vulnerabilità della sicurezza, il codice ospite non può uscire dalla VM, indipendentemente dal fatto che sia in esecuzione nel ring 0 (nel guest) o in modalità non privilegiata.

Quindi, mentre la risposta alla tua domanda è sì, è molto meno pericolosa di quanto potrebbe sembrare a prima vista.