¿Puede un proceso no privilegiado en un sistema virtualizado por hardware causar un 'VMExit' sin la cooperación del kernel?

Lo que necesita para comprender las instrucciones son Desarrollador de software Intel Manuales . Por lo que vale, a veces los encuentro un poco opacos, por lo que comparo lo que leo en google y en los manuales de AMD, ya que ambos implementan la arquitectura x86 / x64.

Específicamente, para esto necesita Vol. 3C: Virtualización . A partir del manual actual desea la página 293 ("VMCALL — Llamar a VM Monitor"). Allí tienes esta expresión útil:

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);
...

Traducción al inglés: #GP es una excepción de protección general, CPL es el nivel de privilegio actual. La operación no root de VMX es:

  

Hay dos tipos de operación VMX: operación raíz VMX y   Operación no root de VMX. En general, un VMM se ejecutará en la operación raíz de VMX y el software invitado se ejecutará en la operación no root de VMX.

Por lo tanto, eso implicaría que las instrucciones VMCall pueden emitirse desde cualquier nivel de privilegio en el invitado . El requisito del anillo 0 solo se aplica al sistema host. Sin embargo, lo advierto con un descargo de responsabilidad: vea mis implicaciones en un minuto.

Locamente loco, lo sé. Al parecer, sin embargo, es cierto. Lea este este hilo donde los desarrolladores del kernel de KVM están discutiendo exactamente esto. El parche KVM en cuestión hizo esto:

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

Lo que considera que la "hipercall" no es válida si no está hecha desde el ring 0 de invitado.

Implicaciones:

1. Cualquier código de nivel de invitado puede emitir un VMCall . Sin embargo, a partir de la lectura preliminar que he hecho, parece que ( podría ) podría ser imposible que eso sea útil de alguna manera, ya que las direcciones del anillo 3 probablemente sean virtuales y el invitado esté operando. Sistema (y por lo tanto no significan nada para el host). Sospecho que este es el caso, pero no puedo (todavía) confirmarlo.
2. Si lo piensa, esto tiene sentido: si el código de nivel de invitado activa algún otro tipo de salida de VM, quiere que el VMM se haga cargo.
3. Sin embargo, sospecho que muchos hipervisores implementan la restricción anterior: solo son 0 invitados, o algunas otras condiciones en la API de hiperconificación que aplican.
4. Sin embargo, no pueden.

Entonces, lo que debes hacer si realmente quieres profundizar es verificar:

• Qué hipercalse, si existe, admite tu VMM.
• ¿Qué condiciones consideran un hypercall válido. Como dije, espero que VMCall se restrinja solo al tono 0 de invitado.

Si es el caso de que VMCall et al solo puede ejecutarse de manera significativa desde el ring 0, entonces su código de invitado del lado del cliente también debe poder ejecutarse en el ring 0, o persuadir a algunos de sus códigos existentes para que hagan algo. no deberia Por ejemplo:

1. Puede persuadir al núcleo para que ejecute un fragmento de código arbitrario que contenga VMCall para hacer lo que sea que desee.
2. Usted persuade a un controlador existente que usa VMCall para que haga esa llamada a su manera, es decir, con sus argumentos, en lugar de los que normalmente usaría.

El éxito de eso para un exploit depende completamente del hipervisor y si esos VMCalls son vulnerables o no. Si no lo son, no importa si logró llamarlos: el hipervisor puede rechazarlos según corresponda. En este punto, honestamente no creo que esta ruta de explotación (a través de un VMCall ) sea muy probable (aunque las consecuencias son, por supuesto, bastante graves si hubiera una).

Dos cosas que me he perdido aquí:

• Hay muchos otros activadores para las salidas de VM. ¿Los procesos invitados pueden provocarlos ? No programáticamente, no creo que ocurran debido a algo que el huésped está haciendo (condiciones para las salidas proporcionadas por el VMM) en lugar de responder directamente a un código de operación.
• Nuevamente, "romper" una VM es un término suelto. Los usuarios de máquinas virtuales también deben desconfiar de cosas como la emulación de red: si su invitado y el host pueden comunicarse entre sí a través de TCP / IP y su pila de IP del host tiene una vulnerabilidad y el código del huésped puede explotarlo. estar comprometido Del mismo modo, la transferencia de archivos del invitado al host conlleva un riesgo inherente.

Sí, el código de invitado sin privilegios puede activar una salida de máquina virtual.

Sin embargo, esto no no significa que el código de invitado sin privilegios puede salir de la máquina virtual. Cuando se activa una salida de máquina virtual, el control se transfiere al código del monitor de la máquina virtual. Si el código de VMM está escrito correctamente, es responsable de manejar la salida de la VM de manera segura: y en particular, de una manera que no permita que el código de invitado malicioso salga de la VM.

Tenga en cuenta que una "salida de VM" es un término técnico, que se refiere a transferir el control a la VMM. A pesar del uso de la palabra "salir", no implica que el código de invitado pueda salir de la máquina virtual. Se refiere a una forma de invocar el VMM, no a algún tipo de violación de la seguridad. Si el VMM está libre de vulnerabilidades de seguridad, el código del invitado no puede salir de la máquina virtual, independientemente de si se está ejecutando en el anillo 0 (en el invitado) o en el modo sin privilegios.

Por lo tanto, si bien la respuesta a tu pregunta es sí, es mucho menos peligrosa de lo que parece a primera vista.