3 ms·
>Last time VT-d virtualization was escaped was in 2006 and done by the Qubes founder herself: Have you been living under a rock [0]? >How is it about the cont
by Always_Anon 3y ago
>Last time VT-d virtualization was escaped was in 2006 and done by the Qubes founder herself:
Have you been living under a rock [0]?
>How is it about the containers?
Container security aka OS virtualization has been quite secure for a while now.
[0] https://www.csoonline.com/article/551445/significant-virtual-machine-vulnerability-has-been-hiding-in-floppy-disk-code-for-11-years.html https://www.csoonline.com/article/551445/significant-virtual...
- fsflover 3y ago> Have you been living under a rock [0]? I think you don't understand: Qubes relies on hardware, not software virtualization: https://en.m.wikipedia.org/wiki/Hardware-assisted_virtualization https://en.m.wikipedia.org/wiki/Hardware-assisted_virtualiza...
- Always_Anon 3y agoI think you don't understand. Qubes relies on software virtualization in conjunction with hardware assisted virtualization instruction sets. The aforementioned vulnerability existed in Qubes Xen.
- deleted 3y ago[deleted]
- fsflover 3y agoIt seems the aforementioned vulnerability (XSA-133) didn't even affect Qubes: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/. Also, such vulnerabilities were the reason for them to switch to VT-d by default: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-2017.txt https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs.... I'm not an expert, but how could it affect the VT-d even in principle? AFAIK VM escape is impossible with software exploits in this case, only side-channel attacks are.