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

Re: Xen 4.4 updates - request for feedback



Am 24.10.18 um 20:34 schrieb Antoine Beaupré:
>> 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.
yes, it is. I think it will be doable but I have no real idea how mich
time this would consume.
>>> Should we consider encouraging people to switch to other virtualization
>>> solutions in LTS/jessie considering the difficulty of mitigation in Xen
>>> environments?
>> [...]
> 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

yes, I understand this point of view. On the other hand I am confident
in the Xen project to provide a solution for these issues on supported
versions, too.

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

When it comes to speculation, I would say, there is no way of
encouraging people using a LTS distribution moving to either another
virtualization solution or to a more recent backport because we are
talking about an LTS distribution. One of the key features of LTS
distributions is avoiding migration and the risks of migration. My
conclusion is: yes. It would be better to have a more recent version of
Xen running, even maybe, following the RedHat recommendation shifting to
KVM... But in this case, people could move to Stretch ;) So, the only
option is fix the old code as good as possible. For some convenience, a
more recent and fresh package of Xen, which behaves almost like the old
one can be an easy to gain migration step, at least smaller than
switching the complete distribution.


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

Yes, I think so. I have the next fixes in the pipeline to be reviewed.


Cheers,

Peter


-- 
Peter Dreuw
Teamleiter
Tel.:  +49 2166 9901-155
Fax:   +49 2166 9901-100
E-Mail: Peter.Dreuw@credativ.de

gpg fingerprint: 33B0 82D3 D103 B594 E7D3  53C7 FBB6 3BD0 DB32 ED41
http://www.credativ.de/

**********************************************
Jetzt neu: 
Elephant Shed - PostgreSQL Appliance
PostgreSQL und alles was dazugehört

Von Backup über Monitoring bis Reporting: 
https://elephant-shed.io/index.de.html
**********************************************

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

begin:vcard
fn:Peter Dreuw
n:Dreuw;Peter
org:credativ GmbH;Team Support
adr;quoted-printable:;;Trompeter Allee 108;M=C3=B6nchengladbach;Nordrhein-Westfalen;41189;Deutschland
email;internet:peter.dreuw@credativ.de
title:Teamleiter
tel;work:+4921669901155
tel;fax:+4921669901100
note;quoted-printable:gpg fingerprint: 33B0 82D3 D103 B594 E7D3  53C7 FBB6 3BD0 DB32 ED41=0D=0A=
	=0D=0A=
	credativ GmbH, HRB M=C3=B6nchengladbach 12080=0D=0A=
	USt-ID-Nummer: DE204566209=0D=0A=
	Gesch=C3=A4ftsf=C3=BChrung: Dr. Michael Meskes, J=C3=B6rg Folz, SaschaHeu=
	er
url:www.credativ.de
version:2.1
end:vcard


Reply to: