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

Re: Xen 4.4 updates - request for feedback



On 2018-10-24 19:33:45, Peter Dreuw wrote:
> Am 24.10.18 um 17:24 schrieb Antoine Beaupré:
>> On 2018-10-23 14:03:37, Peter Dreuw wrote:
>>> Hello, everyone, 
>>>
>>> I prepared another set of fixes based on the current Xen package on jessie-security (4.4.4lts2-0+deb8u1, DLA-1549).
>>>
>>> These fixes include 
>>>
>>> CVE-2017-15595 / xsa 240 
>>> CVE-2017-15593 / xsa 242 
>>> CVE-2017-15592 / xsa 243 
>>> CVE-2017-16693 / xsa 244 
>>> CVE-2017-17044 / xsa 246 
>>> CVE-2017-17045 / xsa 247 
>>> CVE-2018-10472 / xsa 258 
>>> CVE-2018-10981 / xsa 262
>>>
>>> The testing packages are available here: 
>>>
>>> https://share.credativ.com/~pdr/xen-test/ 
>> I'll be reviewing those diffs shortly, thanks!
> Thank you very much.
>>> These testing packages are auto generated by our new build system, so the package name is somewhat cryptic as it reflects the date and time of build as well as parts of the git hash it is based on. 
>>>
>>> You can find the repository here: https://github.com/credativ/xen-lts 
>>>
>>> dpkg might tell you about a potential downgrade, but you can ignore this for testing purposes safely. I expect them to be working but I would appreciate some feedback on this version before passing them to the public repository. 
>> Did you do any kind of smoke testing or is that something that could be
>> useful per se?
>>
>> I always find it tricky to test Xen packages because, well... In what
>> environment do you test it? Qemu? Xen? Virtualbox? :)
>
> I am testing the x86 packages on real hardware and virtual box. But of
> course, my hardware spectrum available for this is not to broad. In
> general, I make shure that my packages work for me before I would
> release them in any way ;)  I'm working on integration of Xen fixes into
> old versions for a while, now. I already did this on the Xen 4.1 in
> Wheezy, fyi.
>
> The arm packages - which are currently not included in my request for
> feedback - are tested on Qemu only. But the arm-only bugs/fixes are
> mostly easy to done as the upstream patches apply and upstream does a
> great amount of testing. So I consider the work already done not harmful
> to the arm systems right now - at least if the x86 tests don't fail ;)

That makes sense. Thanks! I won't be doing additional smoke testing
then.

I encourage others who *have* running Xen systems to give the test
packages a shot and will ping a partner here who does.

>>> I will head on to the next issues to fix. 
>> I'm curious: what is your take on XSA-254 and the Meltdown/Spectre
>> issues in Xen? Are those fixable?
>
> I am not sure if this can be done with Xen 4.4 - at least not to a level
> of a 100% solution. Looking into the upstream code for e.g. 4.6 there
> are many changes that would need to be considered. I am thinking of
> this, currently, yes. The same goes to
>
>
> XSA 263 / CVE-2018-3639
>
> XSA 267 / CVE-2018-3665
>
> XSA 273 / CVE-2018-3620,CVE-2018-3646
>
> The upstream fixes for these XSA rely on the XSA 254 work already done. 
> So getting xsa 263/267/273 fixed would need to adapt much of the work
> done for xsa 254.

Right. It's a huge challenge and sensitive if not confusing code.

>> Should we consider encouraging people to switch to other virtualization
>> solutions in LTS/jessie considering the difficulty of mitigation in Xen
>> environments?
>
> Hum, this looks like a need for a political answer ;)

Well, you know what they say in french: if you don't care about
politics, politics will take care of you. ;)

> I honestly don't know if the difficulty level of mitigation in other
> old virtualization solutions is really lower.

I am going with the assertion that Linux and KVM, in particular, is
being fixed in jessie. It may be flawed, but I know a lot of effort was
put in resolving those issues in the kernel, for obvious reasons.

My impression was that mitigation has been much harder in Xen and that
many hosting providers were migrating away. For example, RedHat
recommends to migrate to KVM here as well:

https://access.redhat.com/solutions/3307791

> An alternative might be offering a version of a more recent Xen package.
> AFAIK there is a Xen 4.9 package in Jessie backports already, but this
> is not too fresh, I think. I know, LTS users might not like the idea of
> shifting to new versions but the spectre/meltdown issue is a class of
> its own when it comes to solutions. 

My comments were not specifically regarding 4.4. From what I understand,
those issues affect all versions of Xen. I know at least that my old job
is migrating away from Xen completely, towards KVM, for that very
reason. But between migrating from Xen 4.4 to 4.9 and Xen to KVM, maybe
the former is easier. So if it actually fixes the "speculation" issues,
it might be worth it.

But there is much... er... speculation on this on my part, I wish we had
a clearer picture of where all this stands right now. In any case, it
seems essential we make a (political? :) decision on the topic and
publicize it officially, maybe in a errata or DLA notice on the
announcement list.

Thanks!

A.

PS: after a short grace period, I suggest we actually upload the fixes
that are ready to the archive already. This will allow us to deliver
those fixes more quickly to our uses, but also provide a way to detect
which patches introduce regressions, if any.

-- 
C'est la nuit qu'il est beau de croire à la lumière
                        - Edmond Rostand


Reply to: