-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Jan 17, 2018 at 02:40:08PM -0800, Vít Šesták wrote: > I mostly agree with Axon. But I'd like to ask how is it supposed to behave if > user declines the update? > > a. User no longer gets any update for dom0 until they decide to accept the > update. > b. User receives updates, but they are not protected from Meltdown/Spectre.
Closer to "b", but not exactly. Most system components will be exactly the same and can receive updates. This applies to all packages in VMs, and most in dom0, except: - xen - core-admin - probably libvirt That's about technical side. It doesn't mean we will keep such parallel "3.2" and "3.3". Because it also make testing harder (more possible configurations). > Also, it depends on what happens with users without VT-x/AMD-v. Such CPUs are > probably rare, but still it might make sense. Also, such CPU are likely not > to be vulnerable. If they can still work with newer Xen, just with all VMs in > PV, it is OK. (I hope this is possible.) If not, then I'd like to follow the > approach B. Yes, PV will remain supported. And we'll switch to PVH automatically if hardware allows for that. Oh, there may be also third option: do not upgrade Xen version in 3.2 and apply Meltdown mitigation patches for PV on Xen 4.6. Apparently development of those patches went much much faster than we (and Xen Security Team) have anticipated. This is solution similar to what Linux have done, but simplified version. Malicious VM could still use Meltdown to read some of Xen memory, but it is largely limited (especially no access to the whole host memory). Similar to the Linux version - this will have noticeable performance impact. The mitigation code can be disabled from Xen command line, but that will make the system vulnerable to the attack again. We're testing this approach right now. PVH option (original plan for R3.2) do not have this problem, if hardware allows (VT-x/AMD-v + HAP/EPT/SLAT/RVI)[1]. [1] https://github.com/QubesOS/qubes-core-admin/pull/178#issuecomment-357520110 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlpf2PAACgkQ24/THMrX 1yzsEggAlNvEfWfMh3Juf6/TvcBtX4RQHfzQycQHXUEFyA1BtP6VQUPnxkHWhJyM 49Qve48wsjGyUCjym6bv7u6Cp0zcU+UJwEoKaqnfD+bOiED/DISt3Ql5Po7XxpdG ezEGW24/qzc4c2r9pjRNndyzPtBdbRdt1sLPDdlhgAgYRP0muNiLd7urytuFw1gV WmKCL8NJiu8rN2fE0WhxoUdAEu3c+9IlMvB2TbCu0PrgKjymzAo3+5thwHGtBvbA izPopmlaFnDsCHiXcqShQhxS52K5v311IhKCX0ddCF/isvNNV3530LI8AR1GxnlF eSCMQymIAE3KbcdSWGO5I4twoknJEA== =UNp/ -----END PGP SIGNATURE----- -- 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/20180117231456.GQ2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.
