[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Xen 4.4 updates vs. Xen Stretch backport

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-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

> 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 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

Reply to: