On Monday, January 15, 2018 at 12:57:09 PM UTC+1, awokd wrote: > It matters a bit because Spectre is harder to exploit than Meltdown. IIUR, > Qubes' design allowed it to constrict Meltdown to a single VM
Not in PV, which are primary type of VM in 3.2. > I'm still > somewhat unclear on how Spectre operates under hardware virtualization but > you're right, it needs to be fixed. As far as I understand, Spectre can read the memory available of victim. That is: * If an application does not mitigate Spectre and attacker finds useful entry point, attacker can read memory of the application (but nothing more). * If VM kernel does not mitigate Spectre and attacker finds useful entry point, attacker can probably read memory of whole VM (but other VMs are not affected). * If Xen does not mitigate Spectre and attacker finds useful entry point, attacker can probably read memory of whole system. Please note that: * Attacker needs a suitable entry point. It might be difficult to find it. * All code needs to be recompiled in order to mitigate Spectre. It is not binary that you are/aren't protected. Some parts of system might be protected at the same time when others aren't. * Lowlevel components might need additional work because of assembly code. * Microcode update is needed only for some variants of patches. But retpoline might be preferred for both performance reasons and not need of microcode update. Regards, Vít Šesták 'v6ak' -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cb5afe86-bd1a-4444-8bb8-4bc875eeab2d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
