Ataques side-channel (canal lateral) al Kernel - CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
Red Hat ha sido notificada de múltiples problemas de implementación de microarquitectura (hardware) que afectan a muchos microprocesadores modernos y que requieren la actualización del kernel de Linux y de los componentes relacionados a virtualización, en combinación con una actualización del microcódigo. Un atacante sin privilegios puede hacer uso de este defecto para sortear las restricciones de seguridad convencionales de la memoria y obtener acceso a memoria privilegiada que, de otro modo, sería inaccesible. Hay 3 CVE conocidas que se relacionan con este problema, en conjunto con arquitecturas Intel, AMD y ARM. También, afecta a otras arquitecturas conocidas como: IBM System Z, POWER8 (Big Endian y Little Endian) y POWER9 (Little Endian).
Antecedentes
Se registró en la industria una vulnerabilidad en la forma en que muchos microprocesadores modernos, por diseño, implementan la ejecución especulativa de instrucciones (optimización de rendimiento comúnmente utilizada). Existen tres variantes primarias de esta vulnerabilidad, que difieren en la manera en que puede aprovecharse la ejecución especulativa. Las tres se basan en que los microprocesadores modernos de alto rendimiento implementan la ejecución especulativa y usan caches VIPT (Virtually Indexed, Physically Tagged) nivel 1 a las que se les puede asignar información en el espacio de dirección virtual del kernel durante la especulación.
Las primeras dos variantes se aprovechan de la ejecución especulativa para realizar bounds-check bypass (CVE-2017-5753) o utilizan branch target injection (CVE-2017-5715) para lograr que el código del kernel, en una dirección bajo control de un atacante, ejecute especulativamente. Colectivamente, estas dos variantes se conocen como "Spectre". Ambas se basan en la presencia de una secuencia de instrucción precisamente definida en el código privilegiado, como en el hecho de que los accesos a la memoria pueden ocasionar una asignación en la cache de datos nivel 1 del microprocesador aun para instrucciones ejecutadas de manera especulativa que nunca se llevan a cabo realmente. Como resultado, un atacante sin privilegios podría hacer uso de estos dos defectos para leer memoria privilegiada realizando ataques dirigidos del tipo side-channel (canal lateral) a la cache. Estas variantes podrían ser utilizadas tanto para cruzar el límite de syscall (variante 1 y variante 2) como para cruzar el límite del guest/host (variante 2).
La tercer variante (CVE-2017-5754) se basa en que durante la ejecución especulativa de instrucciones en los microprocesadores afectados, si ocurre una falla por permisos, la excepción que se debería disparar en este caso se suspende hasta que el bloque de instrucción se retira por completo. Los investigadores llaman "Meltdown" a esta variante. Los accesos subsiguientes a la memoria podrían ocasionar una asignación en la cache de datos L1 aun cuando referencian a ubicaciones inaccesibles de la memoria. Como resultado, un atacante sin privilegios podría leer memoria (incluyendo ubicaciones arbitrarias en la memoria física de un host) privilegiada (kernel space) mediante ataques dirigidos del tipo side-channel (canal lateral) a la cache.
Reconocimientos
Red Hat agradece a Google Project Zero por reportar estas fallas.
Referencias adicionales
What are Meltdown and Spectre? Here’s what you need to know.
https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html
Options to address CVE-2017-5753 on XEN platform
Impacts of CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715 to Red Hat Virtualization products
Productos afectados
El área de Red Hat Product Security ha calificado a este problema como Importante en cuanto a su impacto en la seguridad.
Las siguientes versiones de productos de Red Hat se encuentran afectadas:
- Red Hat Enterprise Linux 5
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Atomic Host
- Red Hat Enterprise MRG 2
- Red Hat OpenShift Online v2
- Red Hat OpenShift Online v3
- Red Hat Virtualization (RHEV-H/RHV-H)
- Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno)
- Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7
- Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7
- Red Hat OpenStack Platform 8.0 (Liberty)
- Red Hat OpenStack Platform 8.0 (Liberty) director
- Red Hat OpenStack Platform 9.0 (Mitaka)
- Red Hat OpenStack Platform 9.0 (Mitaka) director
- Red Hat OpenStack Platform 10.0 (Newton)
- Red Hat OpenStack Platform 11.0 (Ocata)
- Red Hat OpenStack Platform 12.0 (Pike)
Mientras que los contenedores de Red Hat Linux no están directamente afectados por problemas de kernel, su seguridad depende de la integridad del entorno de kernel del host. Red Hat recomienda que utilice las versiones más actuales de las imágenes del contenedor. El Container Health Index, parte del Catálogo de Red Hat Container se puede utilizar para verificar el estado de la seguridad de los contenedores de Red Hat. Para proteger la privacidad de los contenedores en uso, deberá garantizar que el host del contenedor (ej: Red Hat Enterprise Linux o Atomic Host) haya sido actualizado para hacer frente a estos ataques. Red Hat ha publicado una actualización de Atomic Host para este caso de uso.
Descripción e impacto de los ataques
Los ataques que se describen en este artículo se aprovechan de la capacidad de ejecución especulativa de los microprocesadores modernos de alto rendimiento. Los microprocesadores modernos implementan una optimización de diseño conocida como ejecución Out-of-Order (OoO), lo que significa que el microprocesador comenzará a ejecutar instrucciones independientes tan pronto como las dependencias de datos estén disponibles (el llamado modelo data flow) en lugar de ejecutar siempre las instrucciones en el orden literal proporcionado por el programador a través del binario de la aplicación. La ilusión de una ejecución secuencial se mantiene dentro del procesador por medio de diversas estructuras de reordenamiento interno que almacenan estos estados de ejecución intermedios del procesador y presentan los resultados in-order. La ejecución Out-of-Order (OoO) fue originalmente inventada por Robert Tomasulo en 1967 para su uso el los primeros sistemas mainframe de IBM. En las décadas transcurridas, se ha convertido en una funcionalidad estándar de casi todos los microprocesadores.
Una extensión del modelo de ejecución Out-of-Order agrega algoritmos de predicción de saltos sofisticados que apuntan a predecir si se ejecutará un path específico del código del software. Un salto puede pensarse como el cambio en el flujo de las instrucciones que el procesador ejecuta en respuesta a una declaración de tipo “Si” (condicional): “Si ocurre esto, realice A, de lo contrario, realice B”. La condición por la que se toma un salto o no depende de los datos que pueden no estar disponibles de manera inmediata (por ejemplo, porque requiere la carga, por parte de una RAM más lenta, en la jerarquía de la cache de datos interna del microprocesador). Debido a que la condición del salto puede no estar disponible de manera oportuna, es posible que el procesador comience a ejecutar especulativamente el path más probable, en base al input del predictor de saltos. Los resultados de esta ejecución se almacenan de manera tal que el path completo puede ser descartado si la dirección especulada del salto luego resulta ser incorrecta. Así, la ejecución especulativa es, por lo general, completamente invisible para el programador u otros usuarios del mismo sistema.
Los ataques que se describen en este artículo se basan en abrir la “caja negra” que es el estado interno del microprocesador durante la ejecución especulativa. En particular, los ataques se basan en una técnica conocida como análisis side-channel (canal lateral) de la cache. Durante la ejecución especulativa, un procesador no tendrá los resultados disponibles en la memoria de manera inmediata ni habrá registros visibles para el programador, otros procesadores u otras aplicaciones que se estén utilizando. Aun así, para acceder a la memoria dentro de los paths de código especulados, se debe incluir la información en la cache del procesador. El análisis side-channel (canal lateral) le permite a un atacante observar las asignaciones especuladas (loads) en las cache de los sistemas, incluso las provenientes de los paths de ejecución que finalmente se han descartado. Así, se puede crear un programa especialmente diseñado para realizar asignaciones de manera especulativa en la cache de ubicaciones de memoria privilegiada y monitorear los resultados que pueden ser utilizados para inferir el contenido de dicha memoria privilegiada.
Un caso que dispara la ejecución especulativa de CPU son los saltos. Un atacante puede comenzar por “capacitar” al predictor de saltos diciéndole que un salto del código de kernel en particular es muy utilizado (o no utilizado). La próxima vez que se ejecute dicho salto, el procesador comenzará a ejecutar el código en la dirección elegida por el atacante. Si el atacante elige un path que carga un valor desde la memoria, dicho valor será ejecutado especulativamente. Los ataques contra la predicción de saltos pueden (en algunas implementaciones de microprocesadores afectados) extenderse a través de los límites del kernel/hipervisor, permitiendo a sistemas operativos guest sin privilegios ejercer influencia sobre la ejecución del hipervisor y, al combinarse con el análisis side-channel (canal lateral), extraer memoria sensible del hipervisor.
Los efectos de la ejecución especulativa, sin embargo, pueden tener un mayor alcance. Debido a que el estado interno del microprocesador no es visible para el programador y otros usuarios o aplicaciones que corren en el sistema, es posible que el procesador acceda a datos especulativos incluso antes de confirmar si están permitidos. Las verificaciones de permisos ocurren en paralelo y finalmente disparan un aborto de la especulación antes de volver a intentar ejecutar las instrucciones especuladas y hacer visibles los resultados de la ejecución fuera del procesador. Si el procesador usa de manera especulativa información en cache desde la memoria antes de completar las verificaciones de permisos, es posible observar dicha información y utilizarla en accesos subsiguientes a la memoria.
Un ejemplo de dichas verificaciones de permisos son las verificaciones de acceso a las páginas desde la unidad de administración de memoria (MMU). La paginación, también conocida como memoria virtual, es una funcionalidad común en los microprocesadores de alto rendimiento; le permite al sistema operativo controlar el mapeo de direcciones virtuales a direcciones físicas de la RAM del sistema y limitar el acceso a direcciones virtuales a través de bits de control de acceso. Por ejemplo, una página puede ser marcada como read-only (por lo que la escritura ocasiona una excepción de tipo fallo de página) o como “memoria de kernel” (por lo que el acceso en modo usuario ocasiona una excepción de tipo fallo de página).
Debido a que las verificaciones de permisos del procesador imponen que las aplicaciones de usuario no puedan acceder a la memoria del kernel, es una práctica estándar en la industria de los kernel de sistemas operativos (incluyendo Linux) mapear direcciones de memoria virtual de kernel al mismo espacio de dirección que las aplicaciones de usuario. Esto genera una ventaja de performance significativa ya que las aplicaciones hacen uso frecuente de system calls (llamadas de sistema) provistas por el kernel, y el intercambio de espacios de dirección durante cada llamada de sistema significa una sobrecarga del rendimiento. Cada cambio requeriría realizar un flush (invalidar) del contenido de muchas de las estructuras internas de la CPU, tales como los TLB (Translation Lookaside Buffers) que almacenan en cache traducciones de memoria virtual a física y aceleran el uso de la memoria virtual.
El hecho de compartir las tablas de página entre el kernel y las aplicaciones de usuario, sin embargo, permite otro tipo de ataque contra la ejecución especulativa. En este caso, en la fase preparatoria, el atacante “engaña” al kernel para que cargue direcciones virtuales “interesantes” en la cache nivel 1 (L1) del procesador. La cache L1 comúnmente es organizada mediante el uso de una técnica conocida como VIPT (Virtually Indexed, Physically Tagged), que permite que ocurran la traducción de direcciones virtual a física y las verificaciones de permisos en paralelo al acceso. En presencia de un espacio de dirección virtual compartido, es posible para un usuario de código no confiable acceder de manera especulativa a direcciones virtuales privilegiadas del kernel a través de la cache L1, durante la ejecución especulativa, y puede usar los valores cargados a lo largo de todo el path ejecutado de manera especulativa. Así, un segundo acceso a la memoria especulativa puede llenar la cache de manera que ésta dependa del contenido de la memoria privilegiada, pudiendo ocasionar la obtención de dicho contenido.
Estos ataques de tipo side-channel (canal lateral) al microprocesador pueden permitir a un usuario no confiable acceder a una máquina para extraer información sensible de kernel privilegiado o de la memoria de un hipervisor, y de otras aplicaciones o máquinas virtuales que corran en el mismo sistema. La mitigación implica una serie de pasos discretos, serán requeridos algunos o todos según la versión o modelo del microprocesador, cada uno de los cuales pueden ser vulnerables en distinta medida a cada variante del ataque:
- Separar los espacios de dirección virtual del kernel y del usuario: esto se realiza utilizando un cambio de diseño en el kernel del sistema operativo que se conoce como KPTI (Kernel Page Table Isolation), en ocasiones se hace referencia al mismo con su nombre anterior “KAISER”.
- Deshabilitar la predicción de saltos indirecta cuando se accede al kernel o al hipervisor: se han agregado nuevas capacidades a muchos microprocesadores en la industria, a través de microcódigo, milicódigo, firmware y otras actualizaciones. Estas nuevas funcionalidades son potenciadas por las actualizaciones de Red Hat Enterprise Linux que controlan su uso.
- Realizar un fence de las cargas especulativas de ciertas ubicaciones de memoria: Dichas cargas deben ser comentadas a través de cambios pequeños en el kernel de Linux, que han sido integradas en las actualizaciones de Red Hat.
Estas soluciones de software, en combinación con el microcódigo, milicódigo y las actualizaciones de firmware, pueden mitigar los ataques que se describen en este artículo. Sin embargo, la mitigación tiene como costo una reducción del rendimiento del sistema. Dependiendo del sistema, versión y modelo del microprocesador, y de las características de las cargas de trabajo, el impacto en el rendimiento puede ser significativo. Red Hat está tomando una posición proactiva que favorece la seguridad por sobre el rendimiento, mientras que le brinda a los usuarios la flexibilidad de evaluar su propio entorno y realizar las negociaciones correctas mediante la habilitación y deshabilitación selectiva de las diversas mitigaciones.
El área de Red Hat Performance Engineering creó un artículo que reporta el impacto observado en el rendimiento para varias cargas de trabajo representativas y describe opciones para que los usuarios deshabiliten parte de los fixes de seguridad para recuperar el nivel de rendimiento deseado si el cliente está seguro de que sus equipos están físicamente aislados. Se publicará información adicional sobre el rendimiento a medida que se desarrolla este incidente. Las áreas de Red Hat Performance Engineering y Product Engineering han desarrollado un artículo que detalla los ajustes disponibles para habilitar o deshabilitar de manera selectiva estas funcionalidad de seguridad nuevas.
Determine si su sistema es vulnerable
Determine si su sistema es vulnerable. Use el script de detección publicado aquí para determinar si su sistema es actualmente vulnerable a esta falla. Para comprobar la legitimidad del script, puede descargar también la detached GPG signature. La versión actual del script es la 1.1.
Para quienes utilizan productos de Red Hat Virtualization, se ha creado un artículo para verificar que se haya aplicado el microcódigo/firmaware provisto por OEM.
Actúe
Se recomienda enfáticamente a los clientes de Red Hat que corren versiones afectadas de productos de Red Hat que actualicen en cuanto las erratas estén disponibles. Se les sugiere que apliquen las actualizaciones correspondientes de manera urgente. Todos los productos afectados deben aplicar los fixes para mitigar las tres variantes; CVE-2017-5753 (variante 1), CVE-2017-5715 (variante 2), and CVE-2017-5754 (variante 3).
NOTAS
- Meltdown es el nombre comercial de la CVE-2017-5754 (variante 3).
- Spectre es el nombre comercial de la CVE-2017-5753 (variante 1) & CVE-2017-5715 (variante 2) combinadas.
- Debido a la naturaleza de los cambios requeridos, NO habrá un kpatch disponible para los clientes que corran Red Hat Enterprise Linux 7.2 o posterior.
- La Variante 2 puede ser explotada de manera local (dentro del mismo OS) y a través de los límites de guests de virtualización. Los fixes requieren que el microcódigo/firmware de la CPU se activen. Para los clientes que usan Red Hat OpenStack Platform, hay un artículo adicional disponible.
Actualizaciones para productos afectados
Producto | Paquete | Aviso/Actualización | Aplicable a la variante |
Red Hat Enterprise Linux 7 (z-stream) | kernel | 1,2,3 | |
Red Hat Enterprise Linux 7 | kernel-rt | 1,2,3 | |
Red Hat Enterprise Linux 7 | libvirt | 2 | |
Red Hat Enterprise Linux 7 | qemu-kvm | 2 | |
Red Hat Enterprise Linux 7 | dracut | 2 | |
Red Hat Enterprise Linux 7.3 Extended Update Support** | kernel | 1,2,3 | |
Red Hat Enterprise Linux 7.3 Extended Update Support** | libvirt | 2 | |
Red Hat Enterprise Linux 7.3 Extended Update Support** | qemu-kvm | 2 | |
Red Hat Enterprise Linux 7.3 Extended Update Support** | dracut | 2 | |
Red Hat Enterprise Linux 7.2 Advanced Update Support***,**** | kernel | 1,2,3 | |
Red Hat Enterprise Linux 7.2 Advanced Update Support***,**** | libvirt | 2 | |
Red Hat Enterprise Linux 7.2 Advanced Update Support***,**** | qemu-kvm | 2 | |
Red Hat Enterprise Linux 7.2 Advanced Update Support***,**** | dracut | 2 | |
Red Hat Enterprise Linux 6 (z-stream) | kernel | 1,2,3 | |
Red Hat Enterprise Linux 6 | libvirt | 2 | |
Red Hat Enterprise Linux 6 | qemu-kvm | 2 | |
Red Hat Enterprise Linux 6.7 Extended Update Support** | kernel | 1,2,3 | |
Red Hat Enterprise Linux 6.7 Extended Update Support** | libvirt | pendiente | 2 |
Red Hat Enterprise Linux 6.7 Extended Update Support** | qemu-kvm | pendiente | 2 |
Red Hat Enterprise Linux 6.6 Advanced Update Support***,**** | kernel | 1,2,3 | |
Red Hat Enterprise Linux 6.6 Advanced Update Support***,**** | libvirt | pendiente | 2 |
Red Hat Enterprise Linux 6.6 Advanced Update Support***,**** | qemu-kvm | pendiente | 2 |
Red Hat Enterprise Linux 6.5 Advanced Update Support*** | kernel | 1,2,3 | |
Red Hat Enterprise Linux 6.5 Advanced Update Support*** | libvirt | pendiente | 2 |
Red Hat Enterprise Linux 6.5 Advanced Update Support*** | qemu-kvm | pendiente | 2 |
Red Hat Enterprise Linux 6.4 Advanced Update Support*** | kernel | 1,2,3 | |
Red Hat Enterprise Linux 6.4 Advanced Update Support*** | libvirt | pendiente | 2 |
Red Hat Enterprise Linux 6.4 Advanced Update Support*** | qemu-kvm | pendiente | 2 |
Red Hat Enterprise Linux 6.2 Advanced Update Support*** | kernel | 1,2,3 | |
Red Hat Enterprise Linux 6.2 Advanced Update Support*** | libvirt | pendiente | 2 |
Red Hat Enterprise Linux 6.2 Advanced Update Support*** | qemu-kvm | pendiente | 2 |
Red Hat Enterprise Linux 5 Extended Lifecycle Support* | kernel | pendiente | 1,2,3 |
Red Hat Enterprise Linux 5 Extended Lifecycle Support* | libvirt | pendiente | 2 |
Red Hat Enterprise Linux 5 Extended Lifecycle Support* | qemu-kvm | pendiente | 2 |
Red Hat Enterprise Linux 5.9 Advanced Update Support*** | kernel | pendiente | 1,2,3 |
Red Hat Enterprise Linux 5.9 Advanced Update Support*** | libvirt | pendiente | 2 |
Red Hat Enterprise Linux 5.9 Advanced Update Support*** | qemu-kvm | pendiente | 2 |
RHEL Atomic Host | kernel | Imágenes actualizadas el 5 de enero de 2018 | 1,2,3 |
Red Hat Enterprise MRG 2 | kernel-rt | 1,2,3 | |
Red Hat Virtualization 4 (RHEV-H/RHV-H) | redhat-virtualization-host | 1,2,3 | |
Red Hat Virtualization 4 (RHEV-H/RHV-H) | rhvm-appliance | 1,2,3 | |
Red Hat Virtualization 4 (RHEV-H/RHV-H) | qemu-kvm-rhev | 2 | |
Red Hat Virtualization 4 (RHEV-H/RHV-H) | vdsm | 2 | |
Red Hat Virtualization 4 (RHEV-H/RHV-H) | ovirt-guest-agent-docker | 2 | |
Red Hat Virtualization 4 (RHEV-H/RHV-H) | rhevm-setup-plugins | 2 | |
Red Hat Virtualization 3 (RHEV-H/RHV-H) | redhat-virtualization-host | 1,2,3 | |
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H) | rhev-hypervisor7 | 1,2,3 | |
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H) | qemu-kvm-rhev | 2 | |
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H) | vdsm | 2 | |
Red Hat Virtualization 3 ELS (RHEV-H/RHV-H) | rhevm-setup-plugins | 2 | |
Red Hat Enterprise Linux OpenStack Platform 6.0 (Juno) for RHEL7 | qemu-kvm-rhev | 2 | |
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) for RHEL7 | qemu-kvm-rhev | 2 | |
Red Hat Enterprise Linux OpenStack Platform 7.0 (Kilo) director for RHEL7 | director images | 1,2,3 | |
Red Hat OpenStack Platform 8.0 (Liberty) | qemu-kvm-rhev | 2 | |
Red Hat OpenStack Platform 8.0 (Liberty) | director images | 1,2,3 | |
Red Hat OpenStack Platform 9.0 (Mitaka) | qemu-kvm-rhev | 2 | |
Red Hat OpenStack Platform 9.0 (Mitaka) | director images | 1,2,3 | |
Red Hat OpenStack Platform 10.0 (Newton) | qemu-kvm-rhev | 2 | |
Red Hat OpenStack Platform 10.0 (Newton) | director images | 1,2,3 | |
Red Hat OpenStack Platform 11.0 (Ocata) | qemu-kvm-rhev | 2 | |
Red Hat OpenStack Platform 11.0 (Ocata) | director images | 1,2,3 | |
Red Hat OpenStack Platform 12.0 (Pike) | qemu-kvm-rhev | 2 | |
Red Hat OpenStack Platform 12.0 (Pike) | director images | 1,2,3 | |
Red Hat OpenStack Platform 12.0 (Pike) | containers | 1,2,3 |
*Se requiere una suscripción ELS activa para tener acceso a este parche, Por favor, contacte al equipo de ventas de Red Hat o a su ejecutivo de cuentas para obtener más información si su cuenta no tiene una suscripción ELS activa.
**Se requiere una suscripción EUS activa para tener acceso a este parche, Por favor, contacte al equipo de ventas de Red Hat o a su ejecutivo de cuentas para obtener más información si su cuenta no tiene una suscripción EUS activa.
¿Qué es la suscripción Red Hat Enterprise Linux Extended Update Support?
***Se requiere una suscripción AUS activa para tener acceso a este parche en RHEL AUS.
¿Qué es Advanced mission critical Update Support (AUS)?
****Se requiere una suscripción TUS activa para tener acceso a este parche en RHEL TUS.
***** Los suscriptores deben contactarse con sus OEM de hardware para obtener las versiones más actuales del microcódigo/firmware de la CPU.
Mitigación
No hay mitigación conocida más que la aplicación de las actualizaciones de software de los proveedores en conjunto con las actualizaciones del microcódigo/firmware de la CPU del hardware OEM. Todos los clientes de Red Hat deben aplicar las soluciones de los proveedores para contar con el parche en sus CPU y actualizar el kernel a medida que estén disponibles los parches.
Se sugiere a los clientes que sigan una estrategia basada en los riesgos al mitigar el problema. Se debe tratar primero a los sistemas que requieren un alto nivel de seguridad y confianza y se los debe aislar de sistemas no confiables hasta que haya un tratamiento a aplicar a dichos sistemas para reducir el riesgo de que esta vulnerabilidad sea explotada.
Los clientes que utilizan hipervisores Xen deben tener en cuenta las limitaciones técnicas de dicho software, que no puede eliminar por completo la variante 2 de la vulnerabilidad y no puede eliminar la variante 3 en guests para-virtualizados. Red Hat ha desarrollado un artículo que detalla el caso de Xen y las opciones disponibles para los usuarios de este hipervisor.
Comments