On Thu, January 11, 2018 2:57 pm, Andrew David Wong wrote: Some random questions:
> The Xen Security Team did _not_ > previously share information about these problems via their (non-public) > security pre-disclosure list, of which the Qubes Security Team is a > member. What good is a pre-disclosure list if vulnerabilities aren't pre-disclosed? Is this how the industry is going to operate from now on? > Meltdown, the most reliable attack of the three discussed, cannot be > exploited _from_ a fully-virtualized (i.e. HVM or PVH) VM. > ## Virtualization makes at least one variant of Spectre seem difficult > > Of the two Spectre variants, it _seems_ that at least one of them might > be significantly harder to exploit under Xen than under monolithic systems > because there are significantly fewer options for the attacker to interact > with the hypervisor. It's good to see Qubes' design choices validated like this. > This is because any pages from shutdown VMs will > typically very quickly get allocated to other, running VMs and get wiped > as part of this procedure. Aren't the pages scrubbed in balloon.c on a decrease_reservation, i.e. when they are freed versus allocated? > There are two important points regarding the Qubes 3.2 update. First, > this update will work only when the hardware supports VT-x or equivalent > technology. Qubes 3.2 will continue to work on systems without VT-x, but > there will be no mitigation against Meltdown on such systems. Users on > systems that do not support VT-x are advised to take this into > consideration when assessing the trustworthiness of their systems. > > Second, the Qubes 3.2 update will also switch any VMs that use a custom > kernel to PVH mode Does PVH (v2/lite) also require SLAT? I'm thinking here of first generation Intel virtualization that supports VT-x but not SLAT. > Xen hypervisor, undermines this clean architecture by > internally mapping all physical memory pages into its address space. Of > course, under normal circumstances, this isn't a security problem, because > no one is able to read the hypervisor memory. However, the bugs we're > discussing today might allow an attacker to do just that. I think I understand how full virtualization blocks Meltdown from doing this, but why doesn't it also apply to Spectre? I know it's a hardware level exploit, but virtualization instructions are hardware level too. Is it considered a security check and therefore ignored during speculation? > Qubes 4.0-rc4, which we plan to release next week Looking forward to it. Please ignore my questions until a build is running or something, or if anyone else has answers that would be good too. -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/c5742f14a7ff1721f739d8a664b4f444.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
