On Wed, 2018-11-28 at 12:59 +0100, Peter Dreuw wrote: [...] > While XSA-275 and XSA280 might be easy to apply the upstream fix, > XSA-279 does not apply to the current Xen 4.4 state. XSA-279 does only > affect after implementing the XSA-254 (Meltdown) fixes. From this > perspective. XSA-279 could be safely ignored until the back ports are done. That makes sense. > XSA-273 could be fixed only if microcode and kernel is fixed too. > According to the bug tracker, for the kernel this is not the case yet. > The patch relies on the code fixing spectre / meltdown issues so it had > to be postponed until these fixes have been ported. Only Intel CPU might > be vulnerable. A mitigation is possible but undesirable due to heavy > performance impacts. CVE-2018-3646 specifically relates to hypervisors using EPT. It is open for Linux because KVM needs mitigations for it, but I don't believe that a fix for Xen would depend on any of the changes in Linux. I wish you would query possible Xen/Linux dependencies with me rather than quietly deferring the Xen fixes. > XSA-267 could be fixed as there is a fixed kernel in Jessie security. > The first patch for this can be applied directly, the second one relies > on code for XSA-254 (spectre / meltdown). Mitigation is possible by cpu > pinning to VMs. Based on a very quick look, I don't see any complex interaction with the earlier mitigations, so it might be backportable without all of XSA-254. > XSA-263 depends on fixing XSA-254 too. The other constraints like kernel > and microcode are fixed already. There is no other mitigation known but > fixing the code and firmware. > > XSA-254 aka Spectre / Meltdown is still open for Xen but never made it > to the Debian security tracker for Xen, surprisingly. So let's add it there. > Currently, there is no mitigation for CVE-2017-5753 (Spectre variant 1, > SP1) Indeed, no general mitigation seems to be possible with reasonable performance impact. However there is a static checker available that's been used to identify likely vulnerable sites in Linux and there is an ongoing flow of fixes based on this; is the same happening in Xen? > For SP2, Spectre CVE-2017-5715 there are the BTI fixes in upstream. Are those likely to be backportable? > For SP3, aka > Meltdown, CVE-2017-5754, running guests in PVH or HVM context. PV guests > could be run under special shim hypervisors available for Xen 4.10 and > up. But according to the XSA, running Linux PV guests in this way makes *them* vulnerable to Meltdown (since Linux expects Xen to swap page tables in PV mode, and it won't in this case). Have we already advised users to use HVM/PVH for guests other than dom0? [...] > If so, the other fixes are probably not to much work. But implementing > BTI fixes is a long and unknown road. I cannot give any reliable numbers > how much work that would be. But anybody can estimate that this will be > much more than a few days to get done. There might be a shortcut for > some patches by back porting independent code chunks like I did with the > grant table code for Xen 4.1 (Wheezy) but for now, I can't oversee all > of this in total yet and I doubt that there will be a great shortcut to > be found. Having spent several days on similar backports for Linux 3.2 and 3.16, I recognise the likely difficulty and complexity of the task and I think it still needs to be done. (But for future releases we do seriously need to consider whether Xen should be covered by LTS, given the amount of work needed.) > Another option would be backporting the Xen > 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10 (and following) package from > Stretch to Jessie. This could be done including testing within a few > hours, maybe a little more than a working day or less if we abandon Xen > 4.4. [...] I don't see this as an acceptable option for LTS. We could maybe add a xen-4.8 package if it was popular in jessie-backports, but that doesn't excuse us from having to support 4.4. Ben. -- Ben Hutchings Beware of bugs in the above code; I have only proved it correct, not tried it. - Donald Knuth
Attachment:
signature.asc
Description: This is a digitally signed message part